Kbase P12847: Database crashes with 3829, crash recovery fails with 865
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/11/2004 |
|
Status: Verified
FACT(s) (Environment):
Progress 8.x
SYMPTOM(s):
rlbladdr 0
rlclbytes 0
rlbiblksize 8192
SYSTEM ERROR: rlbinext: past end of cluster (3829)
SYSTEM ERROR: rlbinext: past end of cluster -2147483648 (3829)
SYSTEM ERROR: rlrdprv: There are no more notes to be read. (865)
Error 865 during database crash recovery
The bi file has reached 2 GB
Excessive .bi growth
CAUSE:
Transaction backouts are achieveded by reading the BI file - a BI file that is created by transactions during run-time. This message reports that the beginning of the BI file was reached before the "transaction begin note" for that transaction was encountered, in other words, 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, as reported by the 3829 error message, where the next bi note would take the clusters over the 2GB limit, due to long running transactions.
There is no safe way to recover from this error.
FIX:
The database needs to be restored from the last known verified backup. The actions that can be taken however, are preventative.
To initially address this issue, restore the last verified backup.
In order to address future occurences of this issue:
If the .bi has reached the 2Gig limit, then this is a known limitation of the product and corrective measures need to be taken to prevent this happening again. Predominantly, finding the transaction(s) that cause the .bi growth and addressing these. There are also parameters -bistall and -bithold which could be considered, that will alert an administrator in future before this happens again.
In case of excessive Bi growth, a promon investigation for example will assist in detecting long transaction durations:
start promon -> R&D -> 1(Status display -> 4(Processes/client) -> 3(Active transaction). A list of users with open active transactions will be displayed, pay special attention to client's start times . A transaction time of over 10 min would be considered unusual and should be investigated, by contacting those users and finding out what they're doing. It may be that some piece of code will be revealed as poorly scoped for transactions. It is this poorly scoped transaction that is locking clusters of the bi preventing them from being re-used.
Again, as it is not necessarily "a procedure" that you're looking for, it is one or more transaction(s) that are causing the .bi file to grow. Another starting point would be to compile your code in the Application Compiler:
Select OPTIONS -> compiler -> "Listing File" = (say) "listing.txt" + check "append". From the output of this action, a map of the code will be created. By analysing this map, you will be able to detect where the blocks start and end and from this you will be able to investigate the transaction scoping of your application, to identify large transactions as likely candidates.
You could also consider implementing the "use statistics with cross reference (-yx)" startup parameter for a period of time which will give a fair idea of where the busiest code is in terms of long execution times and large number of calls (which imply the necessity of revisiting code, considering internal procedures and include files), re-reads (where increasing the -mmax client memory could help).
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 it will not help in overcoming this limit in Progress 8.x. Where in Progress 9.x, the 2Gb limit applies to individual extents when enablelargefiles has not been implimented (introduced in 9.1C for specific platforms).