Kbase P5373: AI roll forward fails with SYSTEM ERROR: rlrdprv: There are no more notes to be read. (865) 2GB limi
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
12/11/2008 |
|
Status: Verified
SYMPTOM(s):
AI roll forward fails with error 865
SYSTEM ERROR: rlrdprv: There are no more notes to be read. (865)
SYSTEM ERROR: The broker is exiting unexpectedly, beginning Abnormal Shutdown. (5292)
drexit: Initiating Abnormal Shutdown
SYSTEM ERROR: Releasing regular latch. latchId: 4 (5028)
User 0 died holding 1 shared memory locks. (2522)
After-image (AI) roll forward fails
The before image (.bi) file extents total 2 Gigabytes
The sum of the bi extents have hit the 2GB limit
FACT(s) (Environment):
Progress 8.2x
Progress 8.3x
All Supported Operating Systems
CAUSE:
The After-image (.ai) roll forward fails because the *end* of the before-image (.bi) file, which is written to during the roll forward recovery operation, is reached before the backout of an active transaction was completed, as indicated by error message 865. In other words, a note could not be written to the ai.
Transaction backouts are accomplished by reading the BI file - a BI file that is created by the roll forward. The message reports that the beginning of the BI file was reached before the transaction begin note for that transaction was encountered, thus the transaction could not be backed out.
What causes this to happen can be manyfold, but typically as a result of reaching system/Progress limits. There is no way to recover from this error.
FIX:
To initially address this issue, Progress strongly recommends restoring the last backup.
There are preventative actions that can be taken, in order to address future occurences of this issue.
It is most likely that it is the .bi had reached the 2GB limit, then this is a known limitation of the product. The "2GB limit" applies to the SUM of bi extents in Progress 8.x, more extents can be added to split the bi extents accross discs, and to improve peformance, for example, but will not help overcome this limit in Progress 8.x.
Corrective measures need to be taken to prevent this from happening again. Predominantly, finding the transaction(s) that cause the .bi growth and addressing these, but there are also parameters -bistall and -bithold that can be implemented to alert an administrator before this happens again.