Consultor Eletrônico



Kbase P122954: Prorest fails with Unable to extend data files enough to proceed. (6743)
Autor   Progress Software Corporation - Progress
Acesso   Público
Publicação   14/10/2009
Status: Verified

SYMPTOM(s):

Prorest fails with Unable to extend data files enough to proceed. (6743)

Database crashed with error 210 having reached the 2 billion rowid limit per area

Restore fails during the prorest phase

Restore of an earlier probkup fails with error 6743

Unable to extend data files enough to proceed. (6743)

Restore failed. (1618)

!!! ERROR - Database restore utility FAILED !!! (8564)

prostrct create session end. (334)

Any access to the database shows block corruption

SYSTEM ERROR: read wrong dbkey at offset 524288 in file <dbname>.d1 (9445)

bkRead: Error occurred in area 6, block number: 63, extent . (10560)


prostrct add fails with error 1124

SYSTEM ERROR: wrong dbkey in block. Found 0, should be 4096 in area 6 (1124)

FACT(s) (Environment):

There is enough disk space
The empty structure is successfully created
The probkup was confirmed as valid
All Supported Operating Systems
Progress 9.x
OpenEdge 10.x

CAUSE:

The structure file in use with the prorest is not large enough to accommodate the restore content.

FIX:

STEPS:

1.) Verify the size needed from the probkup:
$ prorest dbname backupfile -list

Example:
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.

Example:
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:

Quick reference:
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:

Records/Block: 32
Blocksize: 4KB
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.

Next considerations:

- 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.