Did this article resolve your question/issue?



How to simulate a .bi grow to 2GB for testing purposes


TitleHow to simulate a .bi grow to 2GB for testing purposes
URL NameP5352
Article Number000138801
EnvironmentProduct: Progress
Version: 9.x
Product: OpenEdge
Version: 10.x, 11.x
OS: All supported versions
Question/Problem Description
How to simulate a .bi grow to 2GB ?
How to force the before image file to hit the 2 Gig limit ?
ABL code to make the .bi file grow to 2 GB 
Script to grow .bi to 2Gig for testing recovery plan
Script to test and document a -bithold -bistall and the proquiet bithreshold methodology before rollout to production
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
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:

i = i + 1.
CREATE Customer.
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)
Last Modified Date11/20/2020 7:37 AM
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.