Recovering Index Extents:
This Article outlines a database structure recovery method using PROSTRCT UNLOCK to re-populate physically missing extents that are part of the Control Area structure using copies of those extents with those from another copy of the database.
Another method replacing physically missing extents with empty extents using the
PROSTRCT UNLOCK -extents qualifier is described in Article:
The following describes a methodology that can be employed to reconstruct missing index extents,
by way of example:
Setup the missing index extents:$ mkdir 01 # is where the current database with missing index extents is
$ mkdir 02 # is where the dummy database files are going to be created
Make a copy of the sports2000 database:
$ cd 01/01 $ procopy $DLC/sports2000 dbnameRemove the Cust_index extents from the database:
/01 $ rm dbname_10*Recovering the missing index extents:1.) Get a dbname.st structure file as currently understood by the dbname.db Control Area :
/01 $ prostrct list dbname dbname.st2.) Copy the dbname.st to the dummy directory and correct the file path:
/01 $ cp dbname.st /02/dbname.st$ cd 02Manually edit the dbname.st file reflect the full path of the current location of every extent that should belong to the database, if it is physically missing or not. Take care that this is 100% correct.
On UNIX this can be achieved as follows:
/02 $ cat dbname.st | sed "sF01/F02/Fg" > pip.st/02 $ mv pip.st dbname.st3.) Create a dummy void structure of the database, use the same database blocksize as the original database
/02 $ prostrct create dbname dbname.st -blocksize 40964.) Copy the missing extents back into the database directory
/02 $ cp dbname_10* /01/dbname_10*5.) There is no need to repair the structure, the dbname.db Control Area still expects the missing index extents to be there, however the time-stamp differences on the new files need correcting:
$ cd 01/01 $ prostrct unlock dbname dbname.st6.) Truncate the bi file with the FORCE option. We need to do this because we cannot be sure of the pending updates in the Physical and Logical Redo phases of roll back recovery:
/01 $ proutil dbname -C truncate bi -F -G 0/01 $ [answer yes "y" at the prompt]7.) Run PROUTIL DBRPR to scan the database. There may have been data entries that may need removing because they were incomplete when the database was shut down:
01/ $ proutil dbname -C truncate bi -G 001/ $ proutil dbname -C dbrprSelect: 1. Database Scan Menu
Then: 1,3,4,5,A,G as shown below
DATABASE SCAN MENU
------------------
ON 1. Report Bad Blocks
ON 3. Reformat Bad Blocks
ON 4. Report Bad Records
ON 5. Delete Bad Records
ON A. Apply scan to all areas
G. GO
Scan Backward (Yes/No)? n
8.) Run a full index re-build.
If your database larger than 2GB, then this utility will need to be run with a multi-volume sort file in versions prior OpenEdge 10.1B. For further detail refer to Article 000021283,
How to scope and define a multi-volume srt file for idxbuild01/ $ proutil dbname -C idxbuild ALL -TM 32 -TB 24 -B 10249.) Take a full backup:
01/ $ probkup dbname /backup/dbname.bak0001/ $ prorest dbname /backup/dbname.bak00 -vf 10) Start the database.
Recovering Data Extents:
The above method can also be used to recover
Data Extents, however the Tables in that Area will no longer be accessible if
Template Records are missing in the Storage Area.
If the .d1 extent did not need recovering, it is likely that the template record is instated but cannot be guaranteed. In this regard the ‘
.d1’ extent refers to the first data extent of any Storage Area
except the “Schema Area”.
The existence of the template record for the table(s) in question can be verified with ABL code to display what the template record has stores as the default values:
FIND _File NO-LOCK WHERE _File-Name = "<tablename>" NO-ERROR.
FIND <tablename> WHERE RECID(<tablename>) = _file._template.
IF AVAILABLE (<tablename>) THEN DO:
DISPLAY <tablename>.
END.
Otherwise, it is not possible to recover the template record of a Table. As a consequence of the missing Template Record:
- When creating new records errors like: SYSTEM ERROR: bfcr called with no template. (73)
- Table definitions cannot be DROP or deleted through the Data Dictionary.
- The template record cannot be loaded from another database.
Should the method described in this Article be used to re-construct Storage Areas with Table record data:
- When Data extents are missing, the best next step is always to revert to backup and roll forward.
- When running IDXBUILD, do not run a full IDXBUILD but a selective one excluding all Tables (with missing template records) that were in that Storage Area. Otherwise the IDXBUILD operation will fail and the database will be inaccessible until an IDXBUILD operation is re-run to completion or reverted to a pre-idxbuild state backup.
- Since the purpose of recovering such a database is in order to recover 'other' schema data in areas that were not affected by the missing extents, usually the most recent data prior to the missing extents crash, it's advisable to save time by only building the primary index on each table (or the index used for dump operations).
- If Schema Area .d1 is missing, restoring to backup is the only real solution. Using a reconstructed dummy.d1 after loading the .df or another backup's .d1, it is unlikely that the schema layout of an object, (object number, object type, object block dbkey, index root etc) is the same when replacing the missing .d1 with a backup copy or reconstructed copy. If there is a mismatch in this information between the .d1 file and the actual data file, you won’t be able to find the data. Moreover this extent contains a lot more information than simply the meta and application schema. _User table records and passwords for example.
- If a Data .d1 was replaced, this contains the High Water Mark for the area. Data in the remaining extents, assuming it was only the .d1 which was lost and the .d2 .d3 etc remained, will not be readable above the HWM contained in the restored dummy.d1
What about recovering other Database extent types?
If the
Control Area .db file is missing, refer to Article: 000021365,
How to recover a missing .db file on a multi-volume database If
Before-Image .b files are missing, refer to Article 000020841,
Before Image (.bi) file is missing, corrupt, or lost and the database fails to start If After-Image .a file(s) are missing, refer to Article 000046256
, How to recover from lost AI files ? 
