When the .bi is repeatedly pushing the 2GB limit in Progress 8.x or nearly fills the entire allocated .bi space in Progress 9.x, measures need to be taken in order to prevent the issue from re-occuring. Isolation of the transaction(s) that is causing this to occur is a proper course of action.
It is worth noting that the -bistall parameter should only be used if the database is under constant management in order that the "stall" can be handled immediately.
A couple of pointers to bear in mind when tweaking the implementation:
1. Keep the threshold <1GB. This will both:
- help to manage the log space within a 2Gb limit for the bi file during crash recovery, especially for v8 databases and in the case of databases without largefiles enabled in v9.1c and above and
- limit the time that crash recovery will take, in the event that the database shuts down before the long running transaction locking the bi-cluster chain has finished.
2. Keep the filesize within your available file system space, during crash recovery, you must budget for the bi file needing as much as twice the current size
To test the -bithold -bistall proquiet bithreshold measures implemented, to address the next occurence of excessive .bi growth, against a sports2000 database, the following code could be used in a test environment, for example:
DEF VAR t AS INT NO-UNDO.
DEF VAR i AS INT NO-UNDO.
i = i + 1.
ASSIGN Customer.Name = "breakbi" + string(i)
Customer.salesrep = "B" + string(i)
Customer.state = "MA"
customer.comment = FILL('S',30000). /*making big records speed it up*/
IF t <> TIME
AND TIME MODULO 3 = 0 /*To monitor every 3 s*/
t = TIME.
DISPLAY Customer.Name WITH CENTERED TITLE "Let's grow that BI...".
The following Progress Articles may assist in troubleshooting excessive bi growth: Why is my bi file growing so large
Which, explains in some detail the most common reasons for .bi file growth and actions that you need to take to avoid their occurrence. Knowing exactly why a user's transaction is taking so long, then cutting this transaction short is often the best solution to fixing excessive Bi growth.
000020575 "How can the -bithold -bistall and the proquiet bithreshold be implemented?"
Which, clarifies these parameters by way of example. When the "stall" happens, the db administrator can handle the issue immediately (and action the 19059 investigation) "How to monitor before-image growth with Virtual System Tables"
Which provides an example of using the _Logging VST to report bi occupation. "How to identify users with long running transactions."
While the -bithreshold has been lifted, you may consider this suggestion in finding the possible cuplrit(s)