Kbase 19059: How to troubleshoot Excessive Before Image File Growth
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
03/03/2004 |
|
Status: Verified
GOAL:
How to troubleshoot Excessive Before Image File Growth
GOAL:
How can I stop the BI file from growing excessively
FIX:
The "normal" 2 gig limit on file size exists because we use the function lseek() to position a file to the correct spot for reading and writing. Lseek() takes a signed 32-bit integer as the argument for file position, therefore each individual file or extent in a database is limited by this.
The situation with bi files is somewhat different. A single file bi log is limited by the 2 gig file size limit described above.
A multi-volume bi log can be composed of several extents whose total size may exceed 2 gigabytes. However, within the bi notes there are records that contain 32-bit byte addresses of other bi notes within the bi log. These will not work correctly if more than 2 gigabytes of space is used in bi extents. They will point to the wrong location. So it may be possible (but incorrect) for the files to grow beyond 2 gigabytes of space.
If this happens then crash recovery and transaction rollback will not work correctly. Because of this you should be concerned if your .bi seems to be growing excessively.
Excessive Bi file growth typically occurs when a transaction is started and remains active or open for a long period of time.
This is because the Bi file is organized in sections called clusters.
As each cluster is filled with Bi notes, the Bi file is extended to provide more clusters. To minimize Bi file growth, clusters are re-used, but only when all Transactions to which the Bi notes belong, are committed to the database and closed.
As Bi notes are written serially to the Bi file then clusters can only be re-used serially. This means it only takes one active transaction to remain open for Progress to keep adding new clusters as other users open and close transactions.
There are two main causes of long duration transactions:
Use of ESQL or ODBC.
The way in which the application is coded.
"A transaction is a unit of work which must complete in its entirety or not at all"
* Sometimes data is imported from a file in one transaction, best to do it as one transaction per record.
* Sometimes the scope of the transaction is too big. This can be split into smaller transactions
* Sometimes the size of the transaction is a function of the size of the underlying database. As the Database gets bigger so does the transaction.
* Sometimes a transaction is started at login and does not end until logout, possibly extending for the entire day.
* Sometimes users start a transaction and then leave to do something else, or they wait for the next caller to ring.
In case of excessive Bi growth, start promon; R&D; 1(Status display); 4(Processes/client...); 3(Active transaction). You should see a list of users with open active transactions. A transaction time of over 10 min would be unusual.
Users who have open transactions can be traced using promon as above and asked about those time spans.
Finding these users, knowing exactly why their transaction take so long and cutting this transaction short is often the best solution to fixing excessive Bi growth.
Starting from Version 8.3, using the Recovery log Threshold (-bithold) startup parameter sets the maximum size to which BI files can grow.
Once the threshold is reached, the database performs an emergency shut down. This mechanism ensures that there will be enough disk space to perform database recovery.