1.) Verify the size needed from the probkup:
$ prorest dbname backupfile -list
Area Name: <Area_Name>
Size: 2130958090, Records/Block: 32, Area Number: 9, Cluster Size: 1
2.) From the output calculate the space needed per Storage area for the restore:
Restore_Size = “Size_from_prorest” / RPB * dbblocksize
266,369,761 = 2130958090 / 32 * 4
Restore_Size = 254.03 GB
3.) Sum the extent sizes in the existing structure file in use (dbname.st) to find how much extra space is needed.
available space – Restore_size
265,000,000 – 266,369,761 = -1,369,761 KB
Therefore add at least 1.4 GB worth of extent(s) and a variable extent to this Storage Area in the dbname.st (to accommodate database growth as needed). However in this case, please first refer to the sanity check in step 4 below.
4.) As a sanity check, verify the remaining space once the restore has succeeded:
2,147,483,648 = 2^31 recbit limit on Type I Storage Areas and Type II Storage Areas pre OpenEdge 10.1B
sizes in GB
rpb 1 4 8 dblocksize
32 64 256 512
64 32 128 256
128 16 64 128
256 8 32 64
Continuing the above example:
TOTAL POSSIBLE SPACE = 256 GB
TOTAL POSSIBLE SPACE – Restore_size:
268435456 – 266369761
iow, circa 1.97 GB of addressable space remaining in this storage area.
5.) Remove all the database files from the previous prorest, then run the restore again using the modified structure file.
– Upgrade to OpenEdge 10.1B where the 2 billion rowid limit per area has been lifted with the advent of 64-bit keys.
Progress Soluton P120084, “Summary of compatibility rules for 10.1B and earlier OpenEdge versions”
– If using Type II Storage Area architecture, upgrade to OpenEdge 10.1A02 at least
Progress Solution P115577, “Excessive space usage for some tables in type II storage areas”
– Tablemove database objects into new Storage Areas.