# QAD Progress BI File Growing Huge: Causes and How to Truncate It > Source: https://netray.co/erp-help/qad-progress-bi-file-too-large-truncate-bi-fix > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind error ## System small-erp ## Erp QAD Enterprise Applications (Progress OpenEdge database) ## Module System Administration - Before-Image File ## Query QAD Progress bi file keeps growing huge, how to truncate bi ## Alternate Queries - proutil truncate bi QAD - Progress before image file too large - QAD database disk full bi file - OpenEdge bi cluster size biblocksize ## Applies To QAD Enterprise Applications databases on Progress OpenEdge 10.x through 12.x with variable or fixed length bi extents. ## Steps ### Diagnose and fix a bloated .bi file **Items:** - Check disk usage. Confirm the large file is the database .bi extent and not an after-image, log, or temp file. - In promon, open R&D, Status Displays, and look at the transaction and user displays to find the oldest active transaction and its user. - Identify 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. - End 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. - Let the bi file stabilize. After the long transaction ends, the file will stop growing, although it will not shrink on its own. - Schedule a maintenance window. Shut the database down cleanly with proshut and confirm it stopped without errors. - Run proutil dbname -C truncate bi -bi 16384 -biblocksize 16 to reset the file and set the cluster size and block size. - Restart the database, optionally pre-grow bi clusters with proutil -C bigrow, and monitor growth during the next batch cycle. ## Sections ### How the before-image file works **Body:** 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 **Body:** 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. **Code:** - # 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 **Body:** 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. **Code:** # 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### Why does the bi file not shrink after the transaction ends? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms QAD bi file too large, proutil truncate bi, Progress before image file, OpenEdge biblocksize, bi cluster size, probiw before image writer, QAD database disk full, proutil bigrow, Progress long running transaction, QAD DBA troubleshooting --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json