Kbase P29214: Error 864 during physical redo during crash recovery when st
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/10/2003 |
|
Status: Unverified
FACT(s) (Environment):
Windows 2000
FACT(s) (Environment):
Progress 9.1B
SYMPTOM(s):
Error 864 during physical redo during crash recovery when starting database
rlmemchk: transaction table mismatch. (864)
Server rebooted without database shutdown
-F previously used to force truncate of bi file
No dump and load done after -F used
CAUSE:
The 864 indicates bi corruption. During the redo-phase, the memory-resident and disk-resident data are reconstructed by performing a forward scan of the records in the before-image log and repeating or "redoing" any changes that were never written to the disk-resident copy of the database. This is possible because write-ahead logging ensures that a record of each change exists on disk in the undo-redo log. At the end of the redo-phase, the database state (in the three parts as mentioned previously) has been restored to that which existed just before the failure occurred.
However, in this case here the redo mechanism has found an inconsistency between the transaction information for a specific record and what the bi details for that transaction are.
This will be a result of a proutil truncate bi -F having previously been done without the required dump and load afterwards, then the server machine being rebooted without the database being shutdown.
FIX:
Restore from backup.
-F has already been used once on the database and since its use was instrumental in causing the 864 in the first place, its use again would be highly inadvisable, though possible. Cf.
Consequences of using the -F startup option