Kbase P95972: Is the whole cluster loaded into shared memory when using Type II Storage Areas?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/21/2010 |
|
Status: Verified
GOAL:
Is the whole cluster loaded into shared memory when using Type II Storage Areas?
GOAL:
When using type II areas, is the bufferpool holding the whole cluster of blocks, that that a needed block belongs to ?
GOAL:
When using Type 2 storage areas, do whole area clusters load into the buffer pool?
GOAL:
Do Type II storage areas cause entire clusters to load into memory?
GOAL:
Do single blocks load into memory when using Type 2 storage areas?
FACT(s) (Environment):
OpenEdge 10.x
All Supported Operating Systems
FIX:
When reading records from a Type II area, the buffer pool behaves the same as with type I areas. Access to data remains at the block level. Each buffer in shared-memory contains only one block, (iow: only the block containing the record needed) not the whole cluster the block is a member of.
Clusters in TypeII Storage Areas are merely a "grouping" of blocks on disk at the Storage Area level, to ensure contiguous records of a database object within the cluster. When you request (say) only one record, then only that block containing that record (as found by the RECID) and the blocks containing the fragments as necessary are read in. Reading whole tables that reside in Type II storage areas will be a lot quicker, because the records will be stored in contiguously arranged blocks belonging to the cluster that that database object (table) belongs.
For example, the binary dump utility is greatly enhanced by this feature:
$ proutil dbname -C dump <table> -index 0
In effect, no index is used to find the needed records to dump. Instead a full table scan is achieved by the fact that database objects are unique to the cluster they are stored in, so the utility can accurately find the needed blocks that the dumped table are stored in by referencing the cluster manager chains.
The database engine however, will only load the blocks containing the data and indexes required by the request being executed, not the entire cluster of blocks.
For example, if an area had a 512 cluster size and the following command was run: FIND FIRST orderline NO-LOCK.
The database engine would read into memory maybe 2 or 3 blocks (index & data blocks) which satisfy the "FIND FIRST", not say 1024 blocks (2 x 512 clusters) if this first orderline record was fragmented over two blocks housed in two seperate clusters belonging to the 'orderline' database object.