A DP4 application program updates the database in three stages:
Each new or amended record is posted to a buffer, and each deleted record is flagged as 'killed'. The buffer is usually a workfile with the extension .$$$ on disk
In the event of a system failure, changes that have been posted but not committed are lost.
The records in the post buffer are checked. If the commit is successful, the records are written to the transaction log in memory. The roll-back log buffer is updated with the 'before image' of the record, and the database files are logically, though not usually physically updated. Occasionally the roll-back file is restarted to prevent it growing too large. The details of this vary from version to version. When it happens you may notice a brief slight drop in performance.
In the event of a system failure, the last few committed records may be lost. Only complete transactions are recovered (or lost) by a system failure.
You can force a transaction to be secure by using a checkpoint (Secure changes in QAB).
This stage secures the updates made by your program. The transaction log file is secured, so that transactions can be guaranteed to be recoverable.
The database files themselves are NOT secured at every checkpoint. That is, if the system fails immediately following a checkpoint, the database will usually require DBRECOV. When the DBRECOV is run the transactions secured in the log file will be automatically applied to the recovered database. There is no facility, and no need for a facility to force the database files to be physically updated, other than to shut the database down.
In the event that the database is lost and has to be recovered with DBRESTOR, the transaction log can be applied as part of the restore process.
The description above assumes that you have the roll-back logging options selected in the Console/Transaction Logging option in the Setup utility. If transaction logging is disabled a temporary transaction log is used instead, and every so soften the database is secured by physically updating all the files, so that the temorary log can be discarded and restarted.
If rollback logging is disabled (not recommended) then the database is secured by every checkpoint, or every so many commits. This has a severe impact on performance.