Kbase P56238: How to OS copy a production database to another directory and then rename the database
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
1/9/2006 |
|
Status: Verified
GOAL:
How to OS copy a production database to another directory and then rename the database
GOAL:
Considerations when using OS copy to backup a Progress database
GOAL:
OS copy recovery strategy
GOAL:
How to verify an OS backup of the database
FIX:
The following provides a summary of what needs to be considered when creating an OS copy of a production database (prod.db) for the statistics database (stat.db).
BASIC METHOD:
"To OS copy the prod.db to another directory and rename the database stat.db"
(Please note, if you'd like to test this with the sports database, start by creating the prod.db as follows:
$ prodb p sports
$ prostrct convert p # if using Progress 8.x, to make the test database a multi-volume database)
1.) Shut down prod.db
$ proshut p ?by -F
Verify that the production database is indeed shut down with the:
$ proutil p -C busy
or parse the prod.lg file for the (334) message.
Truncate the bi file:
$ proutil p -C truncate bi -G 0
Take a current reflection of the prod.st file as recorded in the prod.db:
$ prostrct list p prod.st
2.) OS copy the production database files:
This is a Windows example, where "D:/bak" is the directory that we're going to place the OS copy of prod.
$ xcopy prod* D:/bak/stat* /V /F
** IMPORTANT NOTE: It is imperative that NOTHING touches the database files during this operation and that all related files are copied **
It is strongly advisable to preserve the date and time stamps of the copy, please refer to your OS documentation as necessary.
3.) With your favourite editor, edit D:/bak/stat.st to reflect:
- the new physical location: D:/bak/
- and the new database name: stat
Please pay special attention to every line in the structure file:
example of one such edited line in D:/bak/stat.st:
BEFORE : d C:\Progress\wrk\prod.d3 f 81920
AFTER : d D:\bak\stat.d3 f 81920
Also make sure that EVERY database file for the production database has been copied to the "D:/bak" directory and is exactly the same size as the original.
The md5 freeware utility is very useful to this end. The MD5 routine creates 2 files from the copy (one at source, then at target after the copy) the contents of the two files, ?source? and ?target?, should be identical. There is a third file created called md5diff. This is a file which will hold any discrepancy between these two files. If md5diff is blank there is no difference in the two check files, however, of course the two check files can be scrutinised manually to be sure.
Otherwise WINZIP or tar and GZIP the database files at source and then once they have been copied to the target directory across the network drives, unzip the archive as appropriate to the method used.
4.) Repair the database structure:
$ prostrct repair stat stat.st
5.) run a single user connection against stat.db to test.
$ pro stat
As an aside, the probkup utility is the only supported backup strategy.
The greater advantage of probkup, is that it can be done while prod.db is online and you can make both full and incremental backups, which saves both time and space. Furthermore, unlike OS copy, probkup will check the source database for corruption at block level before completing.
$ probkup prod NUL
will NOT back the database up, but will verify the database integrity at block level and give you an idea of how much disk space will be needed for the OS backup. You could consider at least including this in the step 1 after bi truncation.
As with any recovery plan, these need to be fully tested and documented to suit your particular needs. We offer a consultancy service to this end, if you would like to make use of it, please contact your Account Manager.