QAD Progress BI File Growing Huge: Causes and How to Truncate It
QAD Progress bi file keeps growing huge, how to truncate bi
Also searched as
- proutil truncate bi QAD
- Progress before image file too large
- QAD database disk full bi file
- OpenEdge bi cluster size biblocksize
Short answer
The before-image (.bi) file grows when Progress cannot reuse its clusters, usually because a long-running transaction is still open or the cluster size is too small. Find the oldest open transaction, end it, then if the file is still oversized do a clean shutdown and run proutil truncate bi with a sensible cluster size. Never delete the .bi file by hand.
Applies to: QAD Enterprise Applications databases on Progress OpenEdge 10.x through 12.x with variable or fixed length bi extents.
Diagnose and fix a bloated .bi file
- 1Check disk usage. Confirm the large file is the database .bi extent and not an after-image, log, or temp file.
- 2In promon, open R&D, Status Displays, and look at the transaction and user displays to find the oldest active transaction and its user.
- 3Identify the user and the program. A hung QAD client, an unattended batch job, or a stuck background process holding a transaction open is the usual cause.
- 4End the transaction cleanly: ask the user to finish or cancel, or disconnect the session with proshut -C disconnect. Do not kill the database server process.
- 5Let the bi file stabilize. After the long transaction ends, the file will stop growing, although it will not shrink on its own.
- 6Schedule a maintenance window. Shut the database down cleanly with proshut and confirm it stopped without errors.
- 7Run proutil dbname -C truncate bi -bi 16384 -biblocksize 16 to reset the file and set the cluster size and block size.
- 8Restart the database, optionally pre-grow bi clusters with proutil -C bigrow, and monitor growth during the next batch cycle.
How the before-image file works
Progress writes the before image of every change into the .bi file, so that it can undo uncommitted work if a transaction is cancelled or the system crashes. The file is divided into clusters, and a cluster can only be reused once every transaction that wrote to it has ended.
That is why one forgotten transaction can make the file grow without limit. Everything written after the oldest open transaction began must be kept, so the .bi cannot recycle space even though hundreds of other transactions have long since committed.
The file does not shrink when the pressure ends. It stays at its high-water mark until you truncate it, which is why a past incident still shows up as a huge file months later.
Finding the open transaction
Use promon on the running database. The R&D Status Displays include a view of active transactions and users, which shows the transaction number, start time and the user holding it. A transaction several hours old during a quiet period is almost certainly the culprit.
In QAD environments, the usual suspects are users who started an update screen and walked away, a batch report left waiting on an interactive prompt, or a CIM load wrapped in one giant transaction.
Capture the details before disconnecting anyone, so the owner of the program can fix the root cause. Otherwise the same job will balloon the bi again next week.
# Disconnect a specific user number proshut /qad/db/mfgpro -C disconnect 42
# Look at database status quickly prostrct statistics /qad/db/mfgpro
Truncating the bi safely
Truncate bi requires the database to be shut down. The utility first performs crash recovery if needed, then resets the file and lets you set the cluster size (-bi, in kilobytes) and block size (-biblocksize). Larger clusters, often 8192 to 32768, reduce how often Progress checkpoints on busy systems.
Do not delete the .bi file or its extents by hand. Removing it without proper recovery can leave the database unusable and force a restore from backup.
Take a backup first if you have any doubt about the shutdown being clean. If after-imaging is on, remember that truncating bi does not affect the after-image files, but you should confirm your AI archive is current.
# After clean shutdown proutil /qad/db/mfgpro -C truncate bi -bi 16384 -biblocksize 16 # Optionally pre-grow bi clusters before startup proutil /qad/db/mfgpro -C bigrow 8
Tuning to prevent a repeat
Start a before-image writer (probiw) alongside the database so bi writes are handled by a dedicated process, and make sure asynchronous page writers (proapw) are running. Both are standard for busy QAD databases.
Set up monitoring that alerts when any transaction exceeds an age threshold, or when the bi file passes a set size. Catching the problem at two hours is far easier than at two hundred gigabytes.
Review batch design. If a job must update many records, split it into smaller transactions so clusters can be reused as it progresses.
Common pitfalls
- !Deleting the .bi file to free space, which can destroy the ability to recover the database.
- !Truncating bi without fixing the open transaction, so it simply regrows.
- !Killing the database server with kill -9 instead of using proshut, forcing crash recovery and risking more downtime.
- !Leaving the default tiny cluster size on a busy system, causing frequent checkpoints and poor write performance.
- !Ignoring free disk space until the bi extent fills the volume and the database stops.
How an ERP-grounded AI assistant handles this
A QAD-aware assistant can help interpret promon output you paste in, point out the oldest transaction and likely owning program, and draft a monitoring script that alerts on transaction age and bi size. It cannot and should not shut down a database or truncate files by itself. Those steps need a DBA with a verified backup and a maintenance window.
Frequently asked questions
Why does the bi file not shrink after the transaction ends?
Progress reuses space inside the file but never gives it back to the operating system. The file stays at its high-water mark until you shut the database down and run proutil truncate bi, which resets it to its configured starting size.
Is it safe to run truncate bi on production?
Yes, when done properly after a clean shutdown and with a backup in hand. The utility performs crash recovery as needed. What is unsafe is deleting bi files manually or running the command against a database that crashed and has never been recovered.
What cluster size should I use?
A common starting point for active transactional databases is 16384 KB, with a 16 KB block size. Very large or heavily batch-driven systems sometimes go higher. Test against your workload, because too small causes frequent checkpoints and too large increases recovery time slightly.
Can a QAD upgrade cause bi growth?
Yes. Upgrade conversions and data migrations often run big transactions, so the bi file can expand sharply during them. Plan extra disk space for upgrade windows and truncate bi afterwards if the file is far larger than normal operation needs.
Related
QAD "Lock Table Overflow, Increase -L on Server (915)": Cause and Fix
Progress error 915 means the database server ran out of entries in its shared record lock table, which is sized by the -L startup parameter. Either one session holds an enormous number of record locks inside a single transaction, or -L is simply too small for your workload. Find the session first, then raise -L in the database startup parameters and restart the database.
How-toHow to Back Up and Restore a QAD Progress Database with probkup and prorest
Use probkup online to take a consistent full backup of a running QAD database, add incremental backups between fulls, verify the backup with prorest -vp, and restore with prorest into a prepared structure. A file-level copy of a running database is not a valid backup. Pair backups with after-imaging if you need point-in-time recovery.
Error fixQAD Says "Unable to Connect to the Application Server": How to Fix It
This error almost always means the Progress OpenEdge AppServer broker behind QAD is stopped, unreachable over the network, or out of licensed connections, not a database problem. Confirm the broker process is running and healthy in OpenEdge Explorer, check the port and firewall path from the client, then restart the broker with clean agent settings.
How-toHow to Create a Generic Inquiry in Acumatica
Generic Inquiries (GI) are Acumatica's no-code query builder for joining tables, adding filters, and exposing the result as an inquiry screen, dashboard data source, or API endpoint. Open System > Customization > Generic Inquiry, add your base table, define joins and conditions, then run and save. No SQL or customization project is required.
Error fixFix Odoo AccessError: You Are Not Allowed to Access Records
Odoo raises AccessError when a user's security groups do not grant a CRUD right on a model through ir.model.access.csv, or when an ir.rule record rule filters the specific record out for that user or company. Fix it by adding the user to the group named in the error, editing the model's access rights, or reviewing the record rule's domain under Settings > Technical > Security.
How-toHow to Void a Check in Sage 100
Sage 100 voids checks through Accounts Payable > Main > Check and Payment Voiding. Select the bank code, choose the check number, and Sage reverses the Cash Disbursements Journal entry and reopens the invoice it paid. A check that already cleared in Bank Reconciliation or falls in a closed period needs an extra step before it can be voided cleanly.
AI for ERPAI for QAD Adaptive ERP in automotive and industrial manufacturing
Add AI to QAD Adaptive ERP or Enterprise Edition for automotive and industrial manufacturing, grounded on QXtend and QAD's API layer, on-prem or private cloud.
Stuck on QAD Enterprise Applications (Progress OpenEdge database)?
Talk to engineers who work inside QAD Enterprise Applications (Progress OpenEdge database) every week, and who build private AI that answers these questions from your own ERP data.