In pre Progress 9.x databases, there are most probably application 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 not use this method on single volume databases. The dbname.db is essentially the entire database contents.
The success of the execution of this method is 100% dependent on the integrity of the structure file (dbname.st) used. With a missing dbname.db file, PROSTRCT LIST 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.
To reconstruct the Control Area for database versions Progress 9.x and later:
PROSTRCT 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
If the database is enabled for OpenEdge Replication, refer to Article What effect does builddb have on a replication enabled database?
For multi-volume database versions prior Progress 9.x:
This method can also be used on post Progress 9.x databases, but with the 'one-step' PROSTRCT DBUILDDB it is redundant.
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:
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 a dummy database with the same name and structure that the production database should have to get a new .db file:
cd 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 dbname.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.
