Kbase P81853: Is there any advantage to using Type II Areas for a table when I already have it within its own Type
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
2/3/2009 |
|
Status: Verified
GOAL:
Is there any advantage to using Type II Areas for a table when I already have it within its own Type I Storage Area?
GOAL:
Is there any advantage to using Type 2 Areas for a table when it is the only table in a Type 1 storage area?
FACT(s) (Environment):
All Supported Operating Systems
OpenEdge 10.X
FIX:
With Type II Areas Progress allocates space very differently, so (active) dynamic tables will benefit greatly from Type II Areas. Static tables that are the only object in a Type I Area will not see much performance gain by converting to a Type II Area with the current release (OpenEdge 10.0A). However, in the future, more performance enhancements and functionality are planned for Type II Areas, such as scanning a table without an index, which will never be possible in a Type I Area.
Also, with Type II areas, you can have several tables in the same area and get much of the same effect as having each in a separate area. The "rules" for which tables to group in the same Storage Area are much the same as in Type I Areas, the factor which contributes most, is the "records per block" (rpb) that is set. This can be estimated by running a "proutil tabanalys", then dividing the:
(database-blocksize - 100)/mean_record_size and then rounding to the rpb values available (1,2,4,8,16,32,64,128,256).
To sum up, if the table is in an area all by itself and is NOT growing (ie static data), then there will be little performance gain by converting it to a Type II Area. It could be loaded to a Type II Area in the future if you wanted to take advantage of a specific feature that may be implemented in future releases. If this is not the case (ie the table is growing/dynamic), then a performance gain will be seen by moving it to a Type II Area that has been and correctly scoped with grouped tables in each clustered area by optimal records per block definitions.
Refer to Progress Solution P81745, "Are there any guidelines for the new blocks per cluster setting with Progress OpenEdge 10.X?" for further advice.