The batch option can be used with either the nowait or wait options. The batch option improves performance by allowing redo entries to build up-that is, to accumulate in the redo log buffer even after a commit is issued. Normally, every commit forces the log writer background process to flush the log buffer and write to the current online redo log group. There is overhead in this activity, so by reducing its frequency, the overhead is obviously reduced. If an application or a specific application session frequently commits, this option can be used to reduce the effective commit rate instead of modifying the application code (though personally, I would much rather have the code optimized to begin with).

The nowait option can also be used with either the immediate or batch options. Normally, the log writer background process writes synchronously, which means the operating system will not return control to the log writer until the write has been physically completed. Of course, the underlying IO subsystem could also be caching the write and telling the operating system the write has been physically completed when it has not. Asynchronous writes are typically many times faster than synchronous writes, resulting in a substantial performance improvement.

We would expect the combined batch and nowait options to perform the best, as the redo entries can be remain buffered longer in the log buffer, resulting in more efficient writes, and the log writer background process can perform asynchronous writes, resulting in a near immediate commit command response time. Just to give you a taste of how well the commit write facility can work, I performed a simple experiment. Table 8-1 shows the results.