This Article outlines a database structure recovery method using
PROSTRCT UNLOCK -extents to re-populate physically missing extents that are still part of the Control Area structure. Article
How to recover from a missing extent using dummy extents? describes another method replacing physically missing extents with those from another copy of the database.
Important Note:If this is a Progress 9.1C or 9.1D database, due to a
Defect# OE00099678 the following actions can only be undertaken once the Progress 9.1D09 Sevice Pack has been applied. Details are described in Article:
To recover from a deleted index.d extent with PROSTRCT UNLOCK -extents:The following steps describe using a methodology that can be employed to reconstruct missing index extents from the Control Area, by way of example:
- The database index extents that are missing were in a Storage Area called: "index_sa"
- All the index extents were in the same directory to simplify matters
Steps:1. If this is the only backup available, please back it up again somewhere safe with OS copy and verify that it is a complete and valid backup of the all the remaining database files that are currently available.
2. Get a database structure file output (dbname.st) as understood by the database Control Area (dbname.db) currently:
$ prostrct list dbname dbname.st
3. Edit the dbname.st to 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.
4. Repair the Control Area (dbname.db) to update the full paths from Step 3:
$ prostrct repair dbname dbname.st
5. Build and repair the missing extents on disk:
$ prostrct unlock dbname -extents
$ [answer yes "y" at the prompt]
Message similar to the following should result indicating successful repair operation:
...
"Processing extent: /progress/db/dbname_10.d1 size: 384
** Cannot find or open file /progress/db/dbname_10.d1, errno = 2. (43)
WARNING: Database is damaged, missing extent file /progress/db/dbname_10.d1. (1990)
** Cannot find or open file /progress/db/dbname_10.d1, errno = 0. (43)
** Creating missing Data extent /progress/db/dbname_10.d1. (1991)
...
2 inconsistency(ies) fixed. (6951)
6. Truncate the bi file with the FORCE option.
This is necessary because we cannot be sure if there are pending updates in the Physical and Logical Redo Phases of roll back recovery related to indexes in the missing Storage Area:
$ proutil dbname -C truncate bi -F
$ [answer yes "y" at the prompt]
Warning: Now that the database has been forced in to, it should not be used in a production environment as there could be inconsistencies in it. The database should also be dumped and loaded as per the Database Administration Guide.
7. If the entire Index Area was reconstructed, proceed to
Step 8. If only some of the index extents needed to be reconstructed, truncate the Index Area.
This will reset the high-water mark in the index Storage Area back to the beginning of the Storage Area. This hi-water mark reset frees all of the space in the Storage Area for re-use. Any indexes are initialised to the state they were in before they contained any index entries. Before resetting the hi-water mark, the before image (.bi) file is automatically truncated, which another reason for explicitly skipping crash recovery above.
$ proutil dbname -C truncate area "index_sa"
$ [answer yes "y" at the prompt]
8. Run the
offline Database Repair utility (DBRPR) to scan the database.
There may have been data entries that may need removing/ rolling back because they were incomplete when the database was shut down:
$ proutil dbname -C truncate bi
$ proutil dbname -C dbrpr
Select: 1. Database Scan Menu
then: 1,3,4,5,A,G
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
9. Rebuild the indexes. This action will also clear the 'damaged' flag in the Master Block
$ proutil dbname -C idxbuild ALL -TM 32 -TB 24 -B 1024
10. Take a full backup of the recovered database:
$ probkup dbname /bakup/dbname.bak1 -verbose
Using PROSTRCT UNLOCK -extents to re-populate physically missing DATA extentsThe above method can also be used to recover Data Extents, however the Tables in that Area will no longer be accessible. This is because when missing data extents are created with
"prostrct unlock -extents", the table's template record is not created in the Storage Area.
Enhancement PSC00158415 / OE00112109 was raised to ensure that the template record is populated as part of this method, but after due consideration was marked "no plans to fix".
As a consequence of the missing template record:
- Errors like: SYSTEM ERROR: bfcr called with no template. (73) for example when creating new records.
- Table definitions cannot be DROP or deleted through the Data Dictionary.
- The template record cannot be loaded from another database.
So should the method described in this Article be used to re-construct Storage Areas with Table record data:
- 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, usually the most recent data prior to the missing extents crash, it's advisable to save time by only build the primary index on each table (or the index used for dump operations).
