BI file growing Fastly.

[Arunselvan]

Hi All,

I am using Open Edge 10.2b

BI file in Database has grown around 500 mb in last 10 mins.

What would be the reason and what i have to do about it?

Regadrs,
Arun

 

[Cringer]

That's indicative of a transaction that isn't resolving meaning there's loads of stuff to remember in case it's rolled back. Is there still a long running transaction going on on the db? Once the BI has grown it stays at that level, so it's possible the offending transaction is over. It is possible to truncate the BI when the db is offline, but that isn't something that should be being done routinely as it will just grow again in time. If your BI regularly gets bigger than you'd like, then there is likely to be a transaction scoping issue in the code. Look out for transactions where the user is being asked for input, or there are errors on screen as this is a big culprit. Or widely scoped transactions that update a lot of records. Ideally you want your transactions to be really tight, with as few updates as possible. Obviously the problem with that approach is if you do need to roll back, you only roll back a small amount of data. So you do need to take that into consideration.

 

[Arunselvan]

Hi Cringer,
Thank you for your reply.
Yes There is an active transaction which is running nearly for 5 hours.

What are all the problems could occur when Bi is growing larger?

Regards,
Arun

 

[Cringer]

The main problem is that if the BI runs out of disk (or runs out of extents if you don't have a variable one set) your db will stop. Other than that it's probably not a problem, but you should work out why this transaction has been running for 5 hours. No transaction should last that long without being investigated.

 

[Arunselvan]

Thank you Cringer.

 

[RealHeavyDude]

Actually it can get worse: When the database can not write to the before image any more it shuts itself down abnormally leaving itself in a crashed state. Next thing that would happen if you re-start the database is that it would start with crash recovery ( re-doing transaction that have been committed but not written onto disk yet and un-doing transaction that were still open when the database was shut down ). This crash recovery itself needs to write to the before image because - you'll never know - there can be a crash during crash recovery. In the end this can mean that you can't bring up your database anymore because the before image has reached its limit and crash recovery can't be performed. In the worst case you might even end up restoring your last good backup and rolling forward your after image.

Therefore one should be carefully monitoring unexpected before image growth.

 

[Rob Fitzpatrick]

Find out what code is being run by the client with the 5-hour transaction. On the machine where the client runs you can use the proGetStack command, with the process ID of the client. For example if the client's PID is 12345, you type proGetStack 12345 (at a command prompt in Unix or in proenv on Windows) and it produces a file called protrace.12345. This file contains the client's ABL call stack, persistent procedures, classes, etc.

Note that on Unix proGetStack issues a "kill -SIGUSR1" command, so you must have sufficient privilege to run it, i.e. you must be that user or root.