While the batch, nowait option appears to have a higher commit rate than the immediate, nowait option, I ran a statistical significance test6 to ensure any workload difference could not be attributed to randomness. The statistical significance test clearly indicated (99.7% confidence level) that the batch, nowait option did indeed process more commits per second than the immediate, nowait option.

In this particular experiment, the difference between the batch, wait option and the immediate, wait option was not statistically significant-that is, any difference can be attributed to randomness. Just to ensure there was not a problem with my experiment, I collected four additional samples for the batch, wait option. It appears that whatever performance improvement was gained by batching the redo was offset by the log writer background process's slower synchronous writes. This is plausible because, while Table 8-1 does not show this, the average log file parallel write wait time was around a painfully slow 20 ms.

To summarize, if your application can handle lost committed transactions at the session or instance level, and your top wait event is log file sync, then the commit write facility rocks! Otherwise, don't mess with it and sleep well at night.