Kbase P34302: System error: Infinite loop in the .bi file.(876) due to bi
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
14/10/2008 |
|
Status: Verified
SYMPTOM(s):
System error: Infinite loop in the .bi file.(876)
No database backup is available
CAUSE:
This error has only been reported a few times and that is due to the rare circumstances under which we should see it. The instance in which it was reported was during the crash recovery process.
One of the phases of crash recovery is to rebuild the ring of bi clusters, find its starting point, and validate their addresses. It is within these clusters that we will find the transaction table thus a list of all the transactions we will resolve during the crash recovery process. One of the components of the cluster verification process is what is called the cluster high water mark. This is the same term used for the block high water mark in the database and the methodology is exactly the same here as well.
Since the cluster high water mark tells us how many valid clusters we are expecting to find in the cluster ring, it would make perfect sense that we would see an error if there was an inconsistency in either the number of clusters we are expecting to find or the address of one of them. When we see the following error, it is the former that we are encountering:SYSTEM ERROR: Infinite loop in the .bi file. (876)
We are basically reading from the first cluster, scanning the ring using the pointers that each cluster has to the next one in the ring.
Here we are searching through the cluster ring and we find a cluster whose address is beyond that of the last cluster we expect to find. This would only occur if there is a physical problem with the bi file, or a bug in crash recovery. Since there is no evidence to support this is a bug, then the usual steps of evaluating potential bi file corruption should be taken. Deleting the lock file would definitely provide the spark needed for this error as it eliminates sequential, single threaded writing to the bi file which we rely so heavily upon. If the lock file has not been deleted, then we would have to lean towards a physical problem with the file in which case forcing in to the db should get you in, followed by the necessary dump and load.
FIX:
If restoring the backup is not an option you will need to force into the database with the force truncate option.
Proutil <db> -C truncate bi -F
Forcing into the database can cause database corruption.
A dump/load of the database will then need to be performed at your earliest convenience.