Kbase P18147: Prorest throws error 1147 during database restore
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
9/24/2009 |
|
Status: Verified
SYMPTOM(s):
Prorest throws error 1147 during database restore
CRC check error reading backup block <block-num> (1147)
mvexpand: Error expanding database block. (6702)
prorest with -vp option produces errors.
FACT(s) (Environment):
Progress 8.x
Progress 9.x
OpenEdge 10.x
All Supported Operating Systems
CAUSE:
The restore utility encountered a tape block (the size of which is determined by the -bf parameter on the PROBKUP command) whose CRC value did not match the CRC value that was calculated during the restore.
Progress PROBKUP checks every database block it reads into the buffer and calculates a CRC value for the buffer (size = -bf). The CRC value is stored on the backup media at the beginning of each tape block. During the PROREST, those values are re-calculated and compared to the value that resides in the tape block. Any mismatch of these values is reported by the 1147 error. This does indicate that the backup contains corruption and Progress cannot guarantee integrity.
There is nothing to suggest at this time that the (1147) error is caused by a Progress bug. The error is more likely caused by a faulty tape controller or corrupted UNIX buffer. If this error becomes readily duplicated, one way to narrow down the cause is to use PROBKUP to the disk drive and PROREST that copy. If this works, it will indicate that PROBKUP does work and that there is no data
corruption in the database. The -red flag was added as a feature to handle exactly these cases when the tape controller experienced problems.
FIX:
Option 1. Find an earlier backup that can be restored without any errors. This is the only option that will guarantee that the restored database is free of any new corruption.
To avoid this problem in the future it is recommended to incorporate the use of the -red(redundancy) flag to PROBKUP as well as -vp (partial verify) or -vf(full verify) to the PROREST utilities. A -red 1 would make exactly two copies of each block in the database. Although this does not guarantee that the database can be restored successfully. The best way to guarantee that the database can be restored successfully is to run PROREST with a -vp. This does not require any database downtime, like -vf, and it does a CRC check of each backup block to determine its validity. It also required no additional disk resources; it is
performed in memory only.
Set the tape drive to be a fixed block size prior to running "probkup" and "prorest" commands (using "tape") has been seen as the solution when using some tape drives.
Option 2. Continue with the restore of the backups and make note of each blocknum that occurs in an error. Each blocknum that was reported is unrecoverable. All data that resided in these blocks is Lost, and database integrity cannot be guaranteed.
- Once restore completed, then either dump and load or run dbrpr.
note: dbrpr is a non-documented, non-supported option to proutil. This option is recommended typically as a last resort and is not recommended as an alternative to going to backups, except when absolutely necessary.
- To run dbrpr:
command> proutil dbname -C dbrpr
In the Database Repair main menu, select option 1 to enter the Scan Menu.
From the Scan menu, select options 1, 3, 4, 5, 7, and 8 then Go.
This will search for bad blocks and bad records, as well as rebuild the RM and Free Chain. If errors are received, this utility will zero out the offending block, record or fragment. (This means data loss). For every bad record, 1 record will be lost , a bad fragment is 1/2 of a record (either head or tail of a record), and a bad block will result in the loss of 32 or more records. Upon completion of dbrpr, a full index rebuild is required.