Kbase P8415: Explanation of Error 873 "Error SYSTEM ERROR: Physical redo, BKUPDCTR=;number, note updctr=number. (
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
31/10/2008 |
|
Status: Verified
SYMPTOM(s):
Error starting the database server
Error connecting single user session
SYSTEM ERROR: Physical redo, BKUPDCTR=<number>, note updctr=<number>. (873)
The number reported in the error message for "BKUPDCTR" is smaller than the number reported in the "note updctr"
Server machine had crashed due to power failure
FACT(s) (Environment):
Progress 7.x
Progress 8.x
Progress 9.x
OpenEdge 10.x
All Supported Operating Systems
CAUSE:
The first number reported is the update counter of the database block. The second number is the update counter of the block recorded in the bi note when the block was modified. When the block update counter is less than that of the bi note update counter a situation occurred where changes should have been applied to the block during the REDO phase of crash recovery were not. This occurs because the REDO phase of crash recovery started with a cluster that was not old enough.
FIX:
Start the database with the "-G" startup parameter. The "-G" startup parameter should only be used in situations where the second number in the error message "note updctr" is larger than the first number "BKUPDCTR".
The "-G" startup parameter specifies the number of seconds before the Progress RDBMS will reuse a BI cluster. When issuing "-G 180" on the startup of the database, the Progress RDBMS will not to reuse space in the bi cluster until it has been closed for at least 180 seconds. When the database flushes modified blocks from the buffer pool, setting the "-G" parameter to 180 allows the Operating System to take as long as 180 seconds to pick up the modified blocks on disk; otherwise it is expect that the Operating System will accomplish this within 60 seconds. The default value for the "-G" parameter is 60 seconds.
Setting the "-G" parameter to a value of 1800 tells the crash recovery process to start processing notes within the bi cluster that closed at least 30 minutes prior the crash. Normally, specifying "-G 1800" will cause crash recovery to start with the oldest cluster in the bi file.
The "-G" is used to adjust how much a bi cluster should age before the space is reused. Specifying the "-G" parameter will cause the bi file to grow larger then normal during the crash recovery process. To start the database using a higher value for -G. The "-G" value is specified in seconds.
Syntax:
proserve dbname -G 180
If setting the -G parameter results in crash recovery failing in the same way, then a cluster was reused during forward processing that was needed to recover the database in the event of a crash and the database cannot be recovered. The only options at this point are to restore from backup and apply the appropriate AI file, or if a backup is not available, force access to the database immediately followed by a dump and load of its contents.