Kbase P21246: AI roll forward fails with 831 832 833 and roll forward retry fails with 1028
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
6/7/2005 |
|
Status: Verified
FACT(s) (Environment):
Progress 9.1D
Progress 9.1C
Progress 9.1B
Progress 9.1A
SYMPTOM(s):
The database was last changed <date>. (831)
** The after-image file expected <date/time>. (832)
** Those dates don't match, so you have the wrong copy of one of them. (833)
Error 1028 restoring AI files for database
Unable to roll forward an AI on restored or hotspare database
Unable to roll forward retry an AI on restored or hotspare database
No corruption in the AI files
Backup or prorested database has not been touched
No errors reported in cutting the probkup
No errors reported in restoring the backup
No errors reported in rolling forward AI
Incomplete error message set in rolling forward AI
Error 1028 reported when rolling forward
SYSTEM ERROR: Physical redo, BKUPDCTR=<number>, note updctr=<number>. (873)
SYSTEM ERROR: Physical redo, BKUPDCTR=, note updctr=. (1028)
SYSTEM ERROR: Roll forward of file <filename> did not complete normally (1046)
Progress 9.1D05
CAUSE:
bug# 20030226-012
CAUSE:
BUG# 20030210-002
CAUSE:
When rolling forward a specific ai.n, the open database code does an index block clean up and writes two notes into the bi file of the backup database:
- One note updates the block and increments the update counter, for example, from 1211 to 1212.
- The other note updates the master block with a new time stamp.
The new time stamp then failed the roll forward (ai.n) because after it opened this ai.n, it found the time stamp stored in that file didn't match the new time stamp in the master block. There should have been some messages printed for this error, but these very likely went to screen instead of log file.
When the roll forward retry of the ai.n was then executed, the retry operation ignored the time check, read notes from the AI file then applied each of these after the retry point. Once it reached that index block mentioned above, it found that the block update counter was already 1212, and this then triggered the (1028) error.
In older versions of Progress, when a transaction finished, sometimes it needed to clean the index chain, this, in some cases, would take a long time and stop other users' activities. To solve this problem, the clean operation was delayed until the next user touched this index. This means that currently, the user who caused the clean up, leaves without doing anything but the subsequent user will pay the "clean up of the index chain" penalty. Although this sounds unfair, it appears to the user as an improvement in performance and only the users on that index are affected. As RFUTIL is also a user in the database, it also has to pay this penalty sometimes (notice this index clean operation happens randomly). In the case of roll forward an index chain cleanup is not necessary and may cause (831), (832) and (833) errors during a roll forward or (1028) error during the roll forward retry.
This has been addressed by stopping the index chain cleanup when RFUTIL connects to the database and new error messages will be written to the database log file.
There is nothing wrong with the .AI files generated or the restored backups. The only issue is with rfutil. The new version of rfutil will allow the roll forward of AI files using the original backups.
FIX:
This issue was addressed in Progress 9.1D06. Apply the latest Service Pack or update to the latest commercial release.
If applying the latest Service Pack is not immediately viable, then take the following action:
1.) Make a new full probkup of the production database,
2.) Restore it as a NEW hotspare database,
3.) Roll forward AI files from this new starting point.