In this Article "OS Copy" also applies to OS disk mirroring, VSS, VM snapshot Volume snapshot or any other Third Party Tool utilities are used to provide data redundancy as part of a backup and recovery strategy.
Let's assume a copy of an
offline production after-image enabled database needs to be used in a Test environment without After-Imaging enabled.
When an
Enterprise Database license is not in use, this is the only option which can be used to take non-progress backups.
Method 1: When AI files are copied as part of the the OS backup:[PRODUCTION]
1. Shut the database down then truncate the BI file:
$ proshut dbname -by
$ proutil dbname -C truncate bi
2. Make the OS copy then transfer the OS copy to the TEST environment.
While the OS copy is running;
a. Ensure that nothing is accessing the production database (eg cron jobs, single user sessions, OpenEdge processes or utilities)
b. Ensure that the database files have all been copied in their entirety (md5 checksum or similar)
c. Ensure every database file, including AI extents if in use are part of the copy.
0. CD to the directory where the Database Control Area (dbname.db file) was OS copied.
1. Take a snapshot of the Control Area structure information:
$ prostrct list dbname dbname.st
2. EDIT dbname.st to change the path of every database extent to where they were copied physically on disk for the TEST copy (ie their current location)
3. Update the Control Area to reflect the new database extent locations then update and verify the snapshot:
$ prostrct repair dbname dbname.st
$ prostrct list dbname dbname.st
4. Disable After-Imaging:
$ rfutil dbname -C aimage end
5. Truncate the BI file
$ proutil dbname -C truncate bi
6. Remove these ai files by running the following command for each ai file until they are all removed (ie until the message "Database contains no ai areas. (6954)")
$ prostrct remove dbname ai
7. Take a new snapshot of the Control Area and view the resulting .st file to ensure:
- The AI files are no longer evident.
- The full paths list the correct location for every database extent.
$ prostrct list dbname dbname.st
Method 2: When AI files are not copied as part of the the OS backup:[PRODUCTION]
1. Shut the database down then truncate the BI file:
$ proshut dbname -by
$ proutil dbname -C truncate bi
2. Make the OS copy then transfer the OS copy to the TEST environment.
While the OS copy is running;
a. Ensure that nothing is accessing the production database (eg cron jobs, single user sessions, OpenEdge processes or utilities)
b. Ensure that the database files have all been copied in their entirety (md5 checksum or similar)
c. Ensure every database file, including AI extents if in use are part of the copy.
{TEST Environment]
0. CD to the directory where the Database Control Area (dbname.db file) was OS copied.
1. Take a snapshot of the Control Area structure information:
$ prostrct list dbname dbname.st
2. EDIT dbname.st to
a. change the path of every database extent to where they were copied physically on disk for the TEST copy (ie their current location)
b. DELETE (or comment out) each of the structure file references to the AI files
example:
# a <path>\dbname.a1 f 204800
3. Rebuild the Control Area to reflect the new database extent locations:
a. Delete or rename the dbname.db file
$ mv dbname.db REN_dbname.db
b. Rebuild the Control Area
$ prostrct builddb dbname dbname.st
c. Take a new snapshot of the Control Area and view the resulting .st file to ensure:
- The AI files are no longer evident.
- The full paths list the correct location for every database extent.
$ prostrct list dbname dbname.st
4. Disable After-Imaging:
$ rfutil dbname -C aimage end
It is advised to test, verify and document the method chosen.
