Due to all the Oracle SGA and structural change requirements when generating redo and committing, a lack of CPU resources can also be an issue. Investigate the classic "get more CPU" tactics, such as moving workload away from peak processing times, checking for unnecessary or unusual high-CPU consuming processes, and possibly adding more CPU resources.

Another creative "get more CPU" strategy is to bind a CPU exclusively to the log writer background process. While not all operating systems have this capability, if there is a CPU bottleneck or the log writer process spends too much time context switching,7 and log file sync is the top wait event, binding a CPU exclusively to the log writer background process can provide the extra power you need. For details about how to do this, do an Internet search for "binding process to CPU" and consult your operating system's documentation.

When the top wait event is log file sync, my overriding goal is to reduce commit times. I ask myself, "What can I tweak to encourage Oracle to decrease commit times?" The three general approaches are having Oracle say the commits are complete when they really are not (gulp), reducing the number of members in each online redo log group, and finding ways to reduce the amount of data written when a commit occurs. This translates into my four main Oracle-focused solutions: using the commit write facility, decreasing redo log group member numbers, decreasing the log buffer size, and decreasing the instance parameter _log_io_size.