Table E (File architecture): Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
|||
Line 28: | Line 28: | ||
|- | |- | ||
! scope="row"| General space management | ! scope="row"| General space management | ||
| LOBs require contiguous space<br/> New LOBs are always written starting at [[EHIGHPG parameter|EHIGHPG]]; if [[ESIZE parameter|ESIZE]] is reached, Table E is scanned for contiguous space (due to deletes).<br/> <br/>Table E can 'fill' even with many available pages if the space is fragmented. | | LOBs require contiguous space<br/> <br/> New LOBs are always written starting at [[EHIGHPG parameter|EHIGHPG]]; if [[ESIZE parameter|ESIZE]] is reached, Table E is scanned for contiguous space (due to deletes).<br/> <br/>Table E can 'fill' even with many available pages if the space is fragmented. | ||
| LOBs are stored as a series of chained pages, and new LOBs are written first using those in the reuse queue (due to deletes). <br/>Table E will 'fill' only if all pages are used. | | LOBs are stored as a series of chained pages, and new LOBs are written first using those in the reuse queue (due to deletes). <br/> <br/>Table E will 'fill' only if all pages are used. | ||
|- | |||
! scope="row"| Overhead | |||
| There is a 27 byte pointer in the record on Table B / X for every occurrence of every LOB<br/> <br/>There are bitmap pages for every 49152 pages in Table E (plus 16 additional overhead pages)<br/> <br/>The first page of every LOB occurrence contains a 32 byte LOB header. | |||
| There is a 27 byte pointer in the record on Table B / X for every occurrence of every LOB<br/> <br/>There are 4 bytes reserved on every page in Table E for the chaining of LOBs. | |||
|- | |- | ||
! scope="row"| Storing small amounts of data in a LOB field | ! scope="row"| Storing small amounts of data in a LOB field | ||
| Even a single byte of data requires a full page of Table E | | Even a single byte of data requires a full page of Table E | ||
| | | Fields may be defined with the [[MINLOBE parameter]] to permit small (MINLOBE may be set up to 200 bytes) of data to be stored directly in the record in Table B. But see the 'Change' section, below. | ||
|- | |- | ||
! scope="row"| Change a LOB | ! scope="row"| Change a LOB |
Revision as of 03:27, 2 April 2013
Holds Large Object Data (BLOBs and CLOBs)
Enabled by reorganizing / CREATEing a file with ESIZE greater than 0, and then defining a field with a datatype of CLOB or BLOB (the file must have an ESIZE for the latter to occur).
Available as of Model 204 V7.1
Summary
Storage and manipulation of Large Objects (LOBs) differs greatly depending on whether FILEORG x'100' is set.
Table E Differences Without / With the x'100' Setting
Function | non x'100' | x'100' |
---|---|---|
General space management | LOBs require contiguous space New LOBs are always written starting at EHIGHPG; if ESIZE is reached, Table E is scanned for contiguous space (due to deletes). Table E can 'fill' even with many available pages if the space is fragmented. |
LOBs are stored as a series of chained pages, and new LOBs are written first using those in the reuse queue (due to deletes). Table E will 'fill' only if all pages are used. |
Overhead | There is a 27 byte pointer in the record on Table B / X for every occurrence of every LOB There are bitmap pages for every 49152 pages in Table E (plus 16 additional overhead pages) The first page of every LOB occurrence contains a 32 byte LOB header. |
There is a 27 byte pointer in the record on Table B / X for every occurrence of every LOB There are 4 bytes reserved on every page in Table E for the chaining of LOBs. |
Storing small amounts of data in a LOB field | Even a single byte of data requires a full page of Table E | Fields may be defined with the MINLOBE parameter to permit small (MINLOBE may be set up to 200 bytes) of data to be stored directly in the record in Table B. But see the 'Change' section, below. |
Change a LOB | At the time a LOB is first stored, if you expect to subsequently need to increase its size, you will need to RESERVE the necessary space in the initial add. | LOBs may be changes as needed (on adds and stores, the RESERVE, if present, is ignored). Change statements are not permitted if MINLOBE is in use. (A delete / add or insert may be used). |
COMPACTE command | Is used to defragment Table E to increase the amount of contiguous space. | The COMPACTE command is not necessary, and attempts to execute it will generate an error. |