Revert to site-specific DR plan which may include:
a. Failover the target replication database. First ensure that all available AI files have been applied. See Article
b. Restore from the previous backup taken prior to the "PROSTRCT repair" and roll forward the after image files (if enabled).
If the backup is not a feasible option, there are
two databases that now need correcting, however it is important to understand at this point that once accessible, the content of the database will need to be reviewed. Under these circumstances it all depends what operations were taking place on each of the two databases when they were running at the time.
The following outlines a procedure of last resort.The Original Database
1. Ensure that the structure file reflects the fully qualified path to every database extent of the originating database then correct inconsistencies between the creation date and the open date in the database file header block and the master block:
$ echo y | prostrct unlock dbname dbname.st
2. Try to access the database, but it is more than likely that there will be issues with the BI file. For example:
SYSTEM ERROR: Two clusters in the .bi file have the same rlcounter. (874)
Skip crash recovery.
$ echo y | proutil <db-name> -C truncate -F
The original database will now be accessible with the damaged flag set and AI disabled.
** Your database was damaged. Dump its data and reload it. (37)
After-imaging disabled by the FORCE parameter. (4790)
The original database should be first be scanned for physical data integrity inconsistencies and if any are found they should be corrected.
Then the logical data integrity needs to be ascertained. For example if a large purge operation was taking place on the OS copied database, it is likely that this data will no longer be available on the original database. The damaged flag can eventually be removed by running a full index build or a dump and load to a new database.
The OS Copied DatabaseIdeally, once the originating database has been restored/repaired take a new OS copy and run PROSTRCT repair correctly. Refer to Article:
Should the copied database have to be made accessible, and it may be worth doing as an exercise for data recovery that may still be in the OS copy that are no longer available in the originating database, the same steps for the originating database need to be carried out with one very important first Step:
Re-run prostrct repair first1. Open the dbname.st file and correct every line to reflect the fully qualified path to every database extent that was copied then save it and update the file list of the Control Area (.db) file
$ prostrct repair dbname dbname.st
$ prostrct list dbname dbname.st
2. Correct inconsistencies between the creation date and the open date in the database file header block and the master block:
$ echo y | prostrct unlock dbname dbname.st
3. Skip crash recovery
$ proutil dbname -C truncate bi -F
The copied database will now be accessible with the damaged flag set and AI disabled.
