Table E and non-FILEORG X'100' files (File architecture): Difference between revisions

From m204wiki
Jump to navigation Jump to search
(Created page with "Holds Large Object Data (BLOBs and CLOBs) Enabled by reorganizing / CREATEing a file with ESIZE greater than 0, and then [[DEF...")
 
No edit summary
Line 11: Line 11:
Storage and manipulation of Large Objects (LOBs):  
Storage and manipulation of Large Objects (LOBs):  


Table E under non [[FILEORG parameter|FILEORG]] x'100' files remains a good choice for static stores of Large Objects (scanned forms, for example). If it is expected that there will be large numbers of adds, changes and deletes, strong consideration should be given to [[Table E fileorg x'100' (File Architecture)|Table E with FILEORG x'100']].
Table E under non [[FILEORG parameter|FILEORG]] x'100' files remains a good choice for static stores of Large Objects (scanned forms, for example). If it is expected that there will be large numbers of adds, changes and deletes, strong consideration should be given to [[Table E FILEORG x'100' (File Architecture)|Table E with FILEORG x'100']].




== Table E Structure ==


== Space Utilization ==
=== Bitmaps to track space availability ===
 
 
== Storing Data in Table E ==
 
When a field is defined as a large object (LOB) ([[BLOB attribute|BLOB]] or [[CLOB attribute]]s) a pointer is stored in the record (in Tables B or X) and the LOB is stored in Table E:
 
=== Pointer in the record ===
 
=== Large Object Header ===
<p>Every large object stored in Table E starts with a Large Object Header (this is used to make the [[COMPACTE command|Table E compact]]ion work better. The large object header contains a field for the Table B record number that points to the large object—thus a backward pointer to the Table B record.</p>
<p>Implementing a large object header requires file reorganization if the file was
created earlier than V7R1.0. Only V7R1.0 or later files are eligible for
COMPACTE processing. No application changes are required.</p>
<p>Note: Files created in V7R1.0 with Table E size greater than zero are not
backward compatible and cannot be opened in earlier releases.</p>
When each large object is stored, the new header is also included. The large
object header requires the following additional storage and must be calculated
for Table E sizing requirements.
The large object header has the following 4-byte fields:
• Table B record number
• Large object length in pages, including reserved pages
• Field attribute
The field attribute facilitates the Table B record search to find a field with
the object descriptor. The header length is 32 bytes
 
 
=== Table E Space Utilization ===


Each instance of a Large Object field occupies an integral number of Table E pages, where each page can hold up to 6144 bytes of data.
Each instance of a Large Object field occupies an integral number of Table E pages, where each page can hold up to 6144 bytes of data.
Line 22: Line 50:
::Large Object data of 6145 bytes requires two Table E pages.
::Large Object data of 6145 bytes requires two Table E pages.


 
=== Storing a Large Object ===
== Storing a Large Object ==


The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored (and you must if you wish the object to expand in size after its initial store), then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.
The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored (and you must if you wish the object to expand in size after its initial store), then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.
Line 34: Line 61:


If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you use [[FILORG parameter|FILEORG]] x'100'files.   
If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you use [[FILORG parameter|FILEORG]] x'100'files.   





Revision as of 23:08, 1 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):

Table E under non FILEORG x'100' files remains a good choice for static stores of Large Objects (scanned forms, for example). If it is expected that there will be large numbers of adds, changes and deletes, strong consideration should be given to Table E with FILEORG x'100'.


Table E Structure

Bitmaps to track space availability

Storing Data in Table E

When a field is defined as a large object (LOB) (BLOB or CLOB attributes) a pointer is stored in the record (in Tables B or X) and the LOB is stored in Table E:

Pointer in the record

Large Object Header

Every large object stored in Table E starts with a Large Object Header (this is used to make the Table E compaction work better. The large object header contains a field for the Table B record number that points to the large object—thus a backward pointer to the Table B record.

Implementing a large object header requires file reorganization if the file was created earlier than V7R1.0. Only V7R1.0 or later files are eligible for COMPACTE processing. No application changes are required.

Note: Files created in V7R1.0 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.

When each large object is stored, the new header is also included. The large object header requires the following additional storage and must be calculated for Table E sizing requirements. The large object header has the following 4-byte fields: • Table B record number • Large object length in pages, including reserved pages • Field attribute The field attribute facilitates the Table B record search to find a field with the object descriptor. The header length is 32 bytes


Table E Space Utilization

Each instance of a Large Object field occupies an integral number of Table E pages, where each page can hold up to 6144 bytes of data.

A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages.
Large Object field data from 1 to 6144 bytes occupies one Table E page. If the data is from 1 to 6143 bytes, the page is not completely filled. so the remainder of the page is unused.
Large Object data of 6145 bytes requires two Table E pages.

Storing a Large Object

The pages used to store a Large Object value are always contiguous in Table E. If you specify the RESERVE option when the data is stored (and you must if you wish the object to expand in size after its initial store), then enough contiguous pages are allocated to hold the full RESERVE length, even if the actual size of the data initially stored is less than that.

If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past EHIGHPG—even if there are free pages in Table E before the EHIGHPG point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages in Table E. Unused pages are a result of deleting Large Object data.

Generally speaking, the cost of finding free space in Table E is very low during the initial phase, when EHIGHPG is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large Object data stored in the file show a wide variation in size.

If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you use FILEORG x'100'files.





The following Parameters and Commands relate to the Use of Table E

COMPACTE command Defragment the contents of Table E
EHIGHPG parameter The highest active Table E page. (The first page in Table E is page zero.)
EPGSUSED parameter The number of Table E pages currently in use.
ESIZE parameter The number of pages in Table E
FILEORG parameter The file organisation

whose use is discussed in Table E (File Management)