Kbase P5352: How to simulate a .bi grow to 2GB for testing purposes
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/15/2008 |
|
Status: Verified
GOAL:
How to simulate a .bi grow to 2GB
GOAL:
How to force the before image file to hit the 2 Gig limit
GOAL:
4GL code to make the .bi file grow to 2 GB
GOAL:
Script to grow .bi to 2Gig for testing recovery plan
GOAL:
Script to test and document a -bithold -bistall and the proquiet bithreshold methodology before rollout to production
FIX:
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 implimentation:
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:
- - - - - - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - - - -
DEF VAR t AS INT NO-UNDO.
DEF VAR i AS INT NO-UNDO.
DO TRANSACTION:
REPEAT:
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*/
THEN DO:
t = TIME.
PAUSE 0.
DISPLAY Customer.Name WITH CENTERED TITLE "Let's grow that BI...".
END.
END.
END.
- - - - - - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - - - -
The following Progress Solutions may assist in troubleshoot excessive bi growth:
15124 , 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 occurence. 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.
P3771, "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)
P11835, "How to monitor before-image growth with Virtual System Tables"
Which provides an example of using the _Logging VST to report bi occupation.
P16887, "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)