Table E (File architecture): Difference between revisions

From m204wiki
Jump to navigation Jump to search
m (→‎Summary: typo)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Holds Large Object Data (BLOBs and CLOBs)  
<span class="pageSubtitle">Holds Large Object data (BLOBs and CLOBs)</span>
 
Table E is enabled by reorganizing/[[CREATE command: File|creating]] a file with <var>[[ESIZE parameter|ESIZE]]</var> greater than 0, and then [[DEFINE FIELD command|defining a field]] with a data type of [[Field design#BLOB.2C CLOB.2C and MINLOBE_attributes|CLOB or BLOB]] (the file must have a non-zero <var>ESIZE</var> value for the latter to occur).
 
Table E is available as of Model 204 V7.1
 
==Summary==
Storage and manipulation of Large Objects (LOBs) differs greatly depending on whether <var>[[FILEORG parameter|FILEORG]]</var> X'100' is set:
 
:[[Table E and non-FILEORG X'100' files (File architecture)|Table E without FILEORG X'100']]
   
   
:[[Table E and FILEORG X'100' files (File architecture)|Table E with FILEORG X'100']]


Enabled by reorganizing / [[CREATE command: File|CREATE]]ing a file with [[ESIZE parameter|ESIZE]] greater than 0, and then [[DEFINE FIELD command|defining a field]] with a data type of [[Field design (File management)#BLOB.2C CLOB and MINLOBE attributes|CLOB or BLOB]] (the file must have an ESIZE for the latter to occur).  
<p>Regardless of the <var>FILEORG</var> setting, an individual LOB occurrence may be up to 2 GB. The maximum [[ESIZE parameter|size of Table E]] is 1,073,741,823 pages.</p>


Available as of Model 204 V7.1
==Table E differences without or with the X'100' setting==


==Summary==
<table class="thJustBold" style="width:90%">
<tr class="head">
<th align="center">Function</th>
<th align="center">non X'100'</th>
<th align="center">X'100' </th></tr>


Storage and manipulation of Large Objects (LOBs) differs greatly depending on whether [[FILEORG parameter|FILEORG]] x'100' is set.  
<tr><th nowrap>General space management</th>
<td>LOBs require contiguous space.
<p>
New LOBs are always written starting at <var>[[EHIGHPG parameter|EHIGHPG]]</var>; if <var>[[ESIZE parameter|ESIZE]]</var> is reached, Table E is scanned for contiguous space (due to deletes).</p>
<p>
Table E can "fill," even with many available pages, if the space is fragmented. </p></td> 


:[[Table E non x'100' (File architecture)|Table E without FILEORG x'100']]
<td>LOBs are stored as a series of chained pages, and new LOBs are written first using those in the reuse queue (due to deletes).
<p>
Table E will fill only if all pages are used. </p></td></tr>
<tr><th>Overhead</th>
<td>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).
<p>
The first page of every LOB occurrence contains a 32 byte LOB header. </p></td>
 
<td>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. </td></tr>
   
   
:[[Table E FILEORG x'100' (File architecture)|Table E with FILEORG x'100']]
<tr><th>Storing small amounts of <br>
data in a LOB field</th>
<td>Even a single byte of data requires a full page of Table E. </td>


<p>Regardless of the FILEORG setting, an individual LOB occurrence may be up to 2 Gb. The maximum [[ESIZE parameter|size of Table E]] is 1,073,741,823 pages.</p>
<td>Fields can be defined with the <var>[[Field design#BLOB.2C CLOB.2C and MINLOBE_attributes|MINLOBE]]</var> attribute to permit small amounts of data to be stored directly in the record in Table B. <var>MINLOBE</var> can be set up to 200 bytes. </td></tr> 
<tr><th>Change a LOB</th>
<td>At the time a LOB is first stored, if you expect to subsequently need to increase its size, you will need to <var>RESERVE</var> the necessary space in the initial [[Data maintenance#ADD statement|add]]. </td>


== Table E Differences Without / With the x'100' Setting ==
<td>LOBs may be changed as needed (on adds and stores, the <var>RESERVE</var>, if present, is ignored).
<p>
Change statements are not permitted if <var>MINLOBE</var> is in use. (A delete / add or insert can be used.) </p></td></tr>
<tr><th><var>COMPACTE</var> command</th>
<td>Used to defragment Table E to increase the amount of contiguous space. </td>


{| class="wikitable";style="width="90%
<td>The <var>[[COMPACTE command|COMPACTE]]</var> command is not necessary, and attempts to execute it will generate an error. </td></tr>
|-
</table>
! align="center" scope="col" | Function
! align="center" scope="col" | non x'100'
! align="center" scope="col" | x'100'
|-
! scope="row"| General space management
| 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/> <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
| Even a single byte of data requires a full page of Table E.
| Fields can be defined with the [[Field design (File management)#BLOB.2C CLOB and MINLOBE_attributes|MINLOBE attribute]] to permit small amounts of data to be stored directly in the record in Table B. MINLOBE can be set up to 200 bytes.
|-
! scope="row"| 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 [[Data maintenance#ADD statement|add]].
| LOBs may be changed as needed (on adds and stores, the RESERVE, if present, is ignored). <br/>
Change statements are not permitted if MINLOBE is in use. (A delete / add or insert can be used.)
|-
! scope="row"| [[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.  
|}


[[Category:File architecture]]
[[Category:File architecture]]

Latest revision as of 20:50, 1 September 2016

Holds Large Object data (BLOBs and CLOBs)

Table E is enabled by reorganizing/creating a file with ESIZE greater than 0, and then defining a field with a data type of CLOB or BLOB (the file must have a non-zero ESIZE value for the latter to occur).

Table E is 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 without FILEORG X'100'
Table E with FILEORG X'100'

Regardless of the FILEORG setting, an individual LOB occurrence may be up to 2 GB. The maximum size of Table E is 1,073,741,823 pages.

Table E differences without or 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 can be defined with the MINLOBE attribute to permit small amounts of data to be stored directly in the record in Table B. MINLOBE can be set up to 200 bytes.
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 changed 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 can be used.)

COMPACTE command 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.