This Article discusses the major distinctions between two Progress files (
.lbi and
.bi) that share similar names but have very different architectures.
Error messages used to support this discussion:
SYSTEM ERROR: bfundo -- code. (15)
SYSTEM ERROR: A/R block doesn't match caller's. Transaction inconsistency. (6028)
SYSTEM ERROR: lbi fread error, errno = 22. (2610)
SYSTEM ERROR: Attempt to undo an action with an unknown action code: 0. (5174)
These errors occur due to an internal inconsistency with the lbi file, (local before image file), which is a temporary file created by and for all clients connected to the database.
Error
A/R block 6028, is reporting that there is a transaction discrepancy when one of the AR units (that are recorded in the .lbi file) is not where it is expected to be.
Similarly, when the
bfundo Error 15 is seen, the AVM is in the process of trying to back out an accept/reject (AR) unit, which is simply a sub transaction.
The
lbi read Error (2610) is typically caused by exceeding the 2GB client temp files limit, associated with the 5174 error, while undo (backing out) a transaction, for example after trapping a stop condition.
Each unit, or subtransaction is individually "undo-able". it is very important to distinguish between transactions in the lbi file versus those of the database bi file to understand this.
Difference between the .lbi and .bi files:There is absolutely no connection between local before image and database before image files.
- The database .bi file keeps track of the whole transaction, which may contain a series of sub transactions. Consider a customer and all their respective orders in a database as an example. The bi file sees the creation of the customer and all orders placed for that customer as one transaction - assuming that the customer is being entered for the first time.
- The lbi file on the other hand, sees the creation of the customer as well as the creation if each record as an individual "undo-able" entity and it marks the start of one of these sub transactions at each REPEAT/FOR-EACH/DO TRANS/....END block in the 4GL. The lbi file marks the start of a sub transaction with what is known as an accept/reject unit (A/R unit).
What is an A/R unit?An
A/R unit is the mechanism by which the AVM keeps track of a client's transactions in the lbi (local before image file). These units are similar to before image notes in their purpose; however these units are logged in a very different manner. Basically there is not a 1 to 1 relationship between an A/R unit and transaction. Each sub transaction is logged in its own A/R unit, and there is no dependency on BEGIN or END notes in the local before image file.
What's happening when these errors are thrown:When these errors are seen, the AVM is either in the process of:
- backing out AR units and has found an unknown action to backout, or
- reading AR units and has found that the unit that is read is not where it is expected to be.
This is somewhat similar to an invalid note in the bi file and the potential causes of that apply directly here: Either that the lbi file itself is corrupted, or the disk that it resides on is having a problem of some sort, or hitting the 2GB lbi product limit.
One cause could be that the client is running low on space in the directory they are writing the temp files to (local directory by default if not using the -T). If this is the case then either move the files with the -T or free up some space in the local directory. Another could be non-Progress software touching the lbi file at the time it was being read. Typically this is due to AntiVirus Software not adding the working directory or directory defined in the -T client startup parameter to it's exclusions.
These errors are not to be considered BI corruption - the lbi file is specific to the client session and is eliminated when the client process ends, either normally or abnormally and is not used at all during database crash recovery.
The most important distinction to be made, is that the database.bi file sees the main transaction as the start/end point of the transaction, while the lbi file sees each component of the transaction (subtransaction) as separate entities and distinguishes between them by keeping track of the accept/reject (AR) units.
