Kbase 17967: SYSTEM ERROR: Infinite loop in the .bi file. (876)
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
26/05/1998 |
|
SYSTEM ERROR: Infinite loop in the .bi file. (876)
This error has only been reported one time to this point, 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.
SDA 5/26/98