Kbase P67614: How to recover a missing .db file on a multi-volume database
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/11/2008 |
|
Status: Verified
GOAL:
How to fix a missing .db file on a multi-volume database
GOAL:
How to recover a missing .db file when no backup is available
GOAL:
What to do when the .db goes missing?
FACT(s) (Environment):
Progress 7.x
Progress 8.x
Progress 9.x
OpenEdge 10.x
All Supported Operating Systems
FIX:
In pre 9.x databases, there are most probably also data in the .db extent. If at all possible, go to the last known backup because the following procedure deletes the existing .db extent. Do
ot/ use this method on single volume databases. The dbname.db is essentially the entire database contents.
The sucess of the exectution of this method is 100% dependent on the integrity of the structure file (dbname.st). With a missing dbname.db file, the prostrct list command cannot be run, because it is from the content of this control volume (.db) that the structure file is created. Before proceeding check that the "dbname.st", which is going to be used, is accurate in database volumes physical locations and size specifically.
For database versions Progress 9.x and later:
The "prostrctl builddb" functionality was introduced, which is a 'one step' process to re-create the dbname.db file, provided that you are certain of the dbname.st file exists and has been defined correctly.
$ prostrct builddb dbname
For database versions prior Progress 9.x:
This method involves creating another dummy empty multi-extent database, copying its .db file to the place where the production dbname.db should be, then repairing the control area and timestamps of said volumes.
For the sake of brevity, let's call the directory where the production database (with missing .db file) /dir1 and the dummy directory /dir2
STEPS:
0. Take an OS backup of the database before continuing. This is to establish a baseline that we can roll back to if the following actions fail for whatever reason. Please ensure that /every/ database related file remaining is backed up. It is not possible to run the probkup utility in this instance, due to the missing .db file.
1. Create the dummy database with the same name and structure that the production database should have:
dir2/
prostrct create test dbname.st (with relative paths)
procopy $DLC/empty test
copy test.db /dir1/test.db
2. Repair the Control Area and Time-Stamps of database volumes:
cd /dir1
prostrct repair test dbname.st (with absolute paths to every extent)
prostrct unlock test vbdb.st
proutil test -C truncate bi -G 0
probkup test test.bak
3. If there were data in the original .db file, this has been LOST. Further investigation into the data integrity is needed. It may be possible to dump the affected tables out of an old_backup to repair this data.