Setting extent size in structure file to save space gained from archive.

[jdrouil]

I archived a good chunk of data from the database (91E), and now want to cut back on the number of extents so that the database has a smaller footprint. Of course I want to allow room for growth with an empty fixed extent or two, plus the last one variable.

I have one area in the database with a total size of 2.3g per the Record Block Summary in the dbanalys. I set up 5 extents at .5 gig each, giving me (I thought) 2.5g of fixed. Actually I meant to do 6 fixed, but this is just a test.

d "TRANSACTION":7,64 /pilot/mfgpilot_7.d1 f 512000
d "TRANSACTION":7,64 /pilot/mfgpilot_7.d2 f 512000
d "TRANSACTION":7,64 /pilot/mfgpilot_7.d3 f 512000
d "TRANSACTION":7,64 /pilot/mfgpilot_7.d4 f 512000
d "TRANSACTION":7,64 /pilot/mfgpilot_7.d5 f 512000
d "TRANSACTION":7,64 /pilot/mfgpilot_7.d6

After the binary load, it put me well into the 6th (variable) extent. Is it because I got inaccurate information from the dbanalys by running it while the database was up? Or is there a better tool to gauge disk space/extents?

-rw-r--r-- 1 root system 524288000 Nov 12 14:42 mfgpilot_7.d1
-rw-r--r-- 1 root system 524288000 Nov 12 14:41 mfgpilot_7.d2
-rw-r--r-- 1 root system 524288000 Nov 12 14:41 mfgpilot_7.d3
-rw-r--r-- 1 root system 524288000 Nov 12 14:41 mfgpilot_7.d4
-rw-r--r-- 1 root system 524288000 Nov 12 14:41 mfgpilot_7.d5
-rw-r--r-- 1 root system 157155328 Nov 12 14:41 mfgpilot_7.d6

 

[TomBascom]

What is your average record size?

Of course the standard mfg/pro storage area arrangement with "functional" groupings of tables and indexes is flawed to begin with... You really shouldn't do it that way. You should be grouping tables into storage areas based on their average row size.

By the way, 9.1E is ancient, obsolete and not very supported. You should upgrade.

 

[jdrouil]

Appreciate the input, and I see your points, but what can I do for now? I guess I will just multiply the storage area disk space usage by 1.5 for fixed extents and post back on the results.

 

[cj_brandt]

tabanalys and dbanalys don't show the overhead needed by OE to store the records. The more records you have in an area, the larger that overhead will become and may account for your difference. I stumbled upon this and now there is an entry in the Progress online KB describing it in more detail.

 

[MaximMonin]

You can find out tables with a lot of records and optimize storage only for these tables.
Then move table and indexes to new areas.
for small records it is possible to keep 128 or even 256 records per block, instead 32. It can reduce db size in 4-8 times