Kbase P145425: Type II Storage Area - space not being reused after table is deleted and chains rebuilt
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
01/02/2010 |
|
Status: Verified
SYMPTOM(s):
Database engine is not reusing clusters after Table deletion in a Type II storage area.
When a new table is loaded to the Type II storage area the area expands in proportion to the new data loaded
After table is deleted chains are rebuilt through dbrpr
rebuilding the RM and Free Chains does free up blocks but makes no difference to the space occupied after the load
Chanalys reports error 14160 after chains are rebuilt through dbrpr
SYSTEM ERROR: Last rowid() in chain inconsistent () (14160)
prostrct statistics shows Total Blocks increase in proportion to the new table which is loaded to the Type II area
Dbanalys shows that Average Record size multiplied by Total # of records should occupy much less disk space than is being occupied
FACT(s) (Environment):
Type I Storage areas reuse the previously deleted blocks
if the table is not dropped from the schema then the subsequent load re-uses space
UNIX
Windows
OpenEdge 10.1C
OpenEdge 10.2A
CAUSE:
Bug# OE00183719
CAUSE:
cluster free list is not being properly populated by the dbrpr utility as when ALL areas are selected and the current area is a Type I Storage Area, the utility does not take into account the different area type when encountered.
FIX:
Upgrade to OpenEdge 10.2B, 10.1C04, 10.2A02 where this issue has been fixed
Note:
This issue does
ot/ affect re-using clusters if a table is not deleted in a Type II Storage Area and chains are rebuilt prior to loading the new table schema to this same storage area
Workaround A:
If all database objects (tables/indexes) were previously removed from this Type II Storage Area - truncate the Storage Area before loading the Schema (.df) and data into this area again.
$ proutil dbname -C truncate area <area-name>
Workaround B:
Load new database object to a new Type II Storage Area
Workaround C:
After deleting the table, do not run dbrpr to rebuild chains. Instead, load the .df and associated data directly. There should be no inherent requirement to rebuild chains as a pre-requisite to re-use space.