Delayed BI File Write (-Mf)
- Last Updated: February 11, 2026
- 2 minute read
- OpenEdge
- Version 13.0
- Documentation
Delayed BI File Write (-Mf)
| Operating system and syntax | UNIX / Windows |
|
||
|---|---|---|---|---|
| Use with | Maximum value | Minimum value | Single-user default1 | Multi-user default |
| DBS | 32,768 | 0 | 0 | 3 |
- n
- Value in seconds of the delay before the database engine synchronously writes to disk the last before-image file records at the end of each transaction. It also specifies the interval that the broker process wakes up to make sure all BI file changes have been written to disk. The default is 3 for single-user batch jobs and for multi-user databases. Otherwise, the default is zero (0).
Use
Delayed BI File Write (-Mf) to improve performance
on a heavily loaded system. Using -Mf does not reduce
database integrity. However, if there is a system failure, it is
possible the last few completed transactions will be lost (never
actually written to the BI file).
When running with full integrity, at the end of each transaction the database engine does a synchronous write to disk of the last BI file block. This write guarantees that the completed transaction is recorded permanently in the database. If the user is notified that the transaction has completed and the system or database manager crashes shortly afterwards, the transaction is not lost.
Do not set -Mf on
a lightly loaded system with little database update activity. Under
these conditions, the extra BI write is very important and does
not impact performance. On a heavily loaded system, however, the
BI write is less important (the BI block will be written to disk
very soon anyway), and has a significant performance penalty. Setting -Mf to
delay this extra BI write saves one write operation per transaction,
which can significantly improve performance. The extra BI file write
is delayed by default for batch jobs.
The last BI file record is only guaranteed to be written out to disk when a user logs out, or when the server or broker process terminates normally. On multi-user systems, the n argument determines the maximum length of time in seconds during which a completed transaction can be lost.
To modify this parameter while the database is online, use PROUTIL INCREASETO.
You can use this parameter to support continuous operation of the database. For more information, see Change database parameters while the database is running.