Kbase P56652: How to reconstruct a Progress 9.1x Database without index storage areas extents
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
22/04/2008 |
|
Status: Verified
GOAL:
How to reconstruct a Progress database that is missing index storage areas extents
GOAL:
How to rebuild database index extents
GOAL:
What to do if a Progress 9.1D index.d extent goes missing
GOAL:
How to recover from a missing index.d
FACT(s) (Environment):
Progress 9.1D09
FIX:
In the following example:
o all the extents are in the same directory to simplify matters,
o the index extents that are missing were in a Storage area called: "index_sa"
** Please note, due to a BUG# 20040106-008, the following actions can only be undertaken once Progress 9.1D Service Pack 09 applied **
0.) If this is the only backup that you have, please back it up again to somewhere safe and verify that it is a complete and valid backup of the files that you currently have.
1a.) get a db.st file as understood by the dbname.db currently:
$ prostrct list dbname dbname.st
1b.) Edit the dbname.st to reflect the current location of every extent that should belong to the database, if it is missing or not. Take care that this is 100% correct
1c.) repair the dbname.db file:
$ prostrct repair dbname dbname.st
2.) Then run the following command to build and repair the missing extents:
$ prostrct unlock dbname -extents
$ [answer yes "y" at the prompt]
Message similar to the following should result indicating sucessful repair opertaion:
"Processing extent: /progress/wrk/dbname_10.d1 size: 384
** Cannot find or open file /progress/wrk/dbname_10.d1, errno = 2. (43)
WARNING: Database is damaged, missing extent file /progress/wrk/dbname_10.d1. (1990)
** Cannot find or open file /progress/wrk/dbname_10.d1, errno = 0. (43)
** Creating missing Data extent /progress/wrk/dbname_10.d1. (1991)
.....
2 inconsistency(ies) fixed. (6951)"
3.) Truncate the bi file with the FORCE option, this is because we cannot be sure if there are pending updates in the Physical and Logical redo phases of roll back recovery:
$ proutil dbname -C truncate bi ?F -G 0
$ [answer yes "y" at the prompt]
4.) Then, truncate this area. This will reset the hi-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 truncated, which another reason for the above cmd in step 3
$ proutil dbname -C truncate area index_sa -G 0
$ [answer yes "y" at the prompt]
5.) Run the unsupported 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 -G 0
$ proutil dbname -C dbrpr
select: 1. Database Scan Menu
then: 1,3,4,5,A,G
DATABASE SCAN MENU
------------------
ON 1. Report Bad Blocks
2. Repair Block Alignment
ON 3. Reformat Bad Blocks
ON 4. Report Bad Records
ON 5. Delete Bad Records
6. Dump Records to RM File
7. Rebuild Free Chain (chain 0)
8. Rebuild RM Chain (chain 1)
9. Rebuild Index Delete Chain (chain 2)
ON A. Apply scan to all areas
G. GO
Scan Backward (Yes/No)? n
6.) (finally!) run idxbuild
$ proutil dbname -C idxbuild ALL -TM 32 -TB 24 -B 1024 -G 0
If the database is bigger than 2GB, then this utility needs to be run with a multi-volume sort file in versions prior OpenEdge 10.1B. Please refer to Solution P55740, "How to scope and define a multi-volume srt file for idxbuild" for more details
7.) Take a full backup:
$ probkup dbname /bakup/dbname.bak1