Kbase P25872: problems with performing a probkup on the standby database using the norecover parameter.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
06/06/2005 |
|
Status: Unverified
SYMPTOM(s):
Problems with performing a probkup on the standby database using the norecover parameter.
Only way to correct this is to truncate the before-image file but this is not recommended P21864
After truncating the .bi on the hotspare, probkup -norecover completes sucessfully
Same cron job completes probkup norecover of test database sucessfully
probkup -norecover without scripts as root user produces same result, error 1119 after ai's have been rolled forward on hotspare
uttrace()
utcore()
drexit()
msgout()
msgnCB()
msgCB()
dsmFatalMsgnCallBack()
bkRead()
mvBiTlBackup
SYSTEM ERROR: wrong BI blk, read <dbkey> from <dbkey> (1119)
SYSTEM ERROR: wrong BI blk, read 24833 from 12416 (1119)
The last backup was not completed successfully. (1553)
Multiple bi extents
User account peforming backup has rw on database files 666
Error 1119 appears every time a probkup -norecover is executed after ai's have been roll forwarded.
Hardware and tape device examined for faults
probkup -norecover after ai's rolled forward to DISK instead of tape give same result, error 1119
System logs clean
-biblocksize is not the default (8KB) blocksize
-biclustersize is not the default (524KB) clustersize
CAUSE:
During a probkup operation with the -norecover option, the bi files are backed up as well as the database files.
It is during the read operation of the bi file that the process goes awry according to the stack trace listed above. The 1119 message is indicating that Progress tried to verify that the block that was requested was the block that was read and that the verification failed.
This could either indicate that there is corruption in the dbkey or block on disk or that the wrong block was read into the buffer. As this message specifically relates to the bi files, if there were indeed bi corruption, then one wouldn't be able to truncate the bi file without the -F option. In this case however, it is possible so we can safely assume that there is no corruption.
When the bi blocksize was changed, a misconfiguration of the bi blocks results which the backup utility is detecting (erroroneously) as corruption. See Solution P25998 for more detail.
FIX:
To recover from this scenario repeating for evey probkup -norecover on the target (hotspare) database once new ai files have been rolled forward since:
a. End AI on production DB
b. Truncate bi on production DB:
+ proutil dbname -C truncate bi
+ prostrct remove dbname bi # this must be repeated once for each bi extent defined
+ prostrct add dbname bi.st # where bi.st is a structure file containing the redefinition of the bi extents
+ then set the biblocksize to the size that you required:
proutil dbname -C truncate bi -biblocksize <blocksize>
proutil dbname -C truncate bi -bi <clustersize>
c. Probkup production DB
d. Start AI on production DB
e. Prorest to standby DB from production probkup tape (step c)
f. Roll-forward AI files
g. Test probkup -norecover