The fast_commit option, which is a derived DBMS Server parameter, allows the server to execute commits without forcing data pages to the database. This reduces I/O in the server and improves response time.

Without fast commit, all update transactions must do the following when a commit is executed:

This ensures that the data is committed and the data in the database has been written to disk when a system crash occurs immediately following a commit.

With fast commit, a server can perform a commit by writing a commit record to the log file and forcing it to disk. The actual data pages are not written to the database disk until an optimal time to do so is reached. If necessary, the committed transactions can be recovered from the log file that was written to disk.

Fast commit can greatly improve transaction response time and throughput and greatly reduce direct I/O to the database. All update transactions gain some benefit from using fast commit because control is returned to the application while database writes are processed asynchronously. Applications that tend to update the same group of records many times gain a big increase in throughput when using fast commit because writes to the database are delayed until many transactions have actually been committed. This allows the system to write out many updates with few I/O operations.

However, using fast commit can also increase recovery times. If the system crashes, all committed transactions that have not yet had their data written to the disk must be recovered. To control this recovery time, adjust the consistency point frequency.