Kbase P25998: Explaining why 1119 error during ONLINE PROBACKUP or PROBKUP -norecover
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
14/11/2006 |
|
Status: Verified
SYMPTOM(s):
SYSTEM ERROR: wrong BI blk, read from (1119)
1119 error during ONLINE backup
1119 error during probkup -norecover
Database has multiple bi extents
BI Blocksize may not be the default biblocksize
BI Cluster size may not be the default cluster size.
Database may have been created by procopying $DLC/emptyX into a pre-existing database where the bi blocksize or bi cluster size of the original database is not consistent with the bi blocksize or cluster size of the database being copied into it.
Error 1119 re-appears during backup operation after having truncated the bi file and further activity causes the bi file to grow again.
CAUSE:
There is a set of conditions that must apply for this error to occur.
SYSTEM ERROR: wrong BI blk, read from (1119)
The error means there is corruption in the bi file.
If the following conditions do NOT apply, then there probably is corruption in the bi file and truncating the bi should fix the problem. If the error is on a probkup -norecover of a hot spare database, then truncating the bi is not recommended, as it will likely interrupt the ai roll forward. In this case, re-sync the hot spare from the latest probkup of the production database and associated ai files.
If the following conditions DO apply to the customer's situation, then the fix detailed below needs to be implemented.
CONDITIONS:
1) Database must have a multi-extent bi, with at least one fixed length extent.
2) The customer must have changed the -biblocksize from the default at some time in the past. (use promon to check the biblocksize: R&D -> 1. Status Displays -> 9. BI Log. or view the log file)
3) ONLINE probkup or probkup with the -norecover option fails with this error 1119, however, probkup with server down (off line) works fine as does the "procopy" utility.
4) Database may have been created by procopying $DLC/emptyX into a pre-existing database where the bi blocksize or bi cluster size of the original database is not consi