Any positive value delays OpenEdge from synchronously writing out to disk the last before-image (BI) file records at the end of each transaction. On UNIX systems using shared memory, 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 using shared memory. Otherwise, the default is 0.
Using the Delayed BI File Write (-Mf) parameter 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 OpenEdge 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 the -Mf parameter 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 the -Mf parameter 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.
If the -Mf parameter is set to a positive value, 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 completed transactions can be lost.