The title of this section is a little misleading because the contention is centered on commit times taking an unacceptably long period. When this occurs, the top wait event will be log file sync. If users occasionally commit, they may not feel like performance is slow (the good news). However, users who frequently commit, especially when a rapid committing piece of code is involved, will certainly feel the effect and have a considerable amount of their wait time associated with the log file sync wait event.

A challenge in effectively dealing with log file sync waits is that there are many causes for this wait event. For example, it can occur because of rapid application commits (there is overhead in each commit request), the log writer has too much redo to write per commit (requiring more time to complete each write), or large amounts of redo per transaction (requiring more time to complete the write). Whatever the reason, the general solution is understanding the problem arises when a commit occurs and that commits are simply taking too long.

As Figure 8-7 shows, when the commit times are taking too long, it is common for other redo-related wait events to occupy the top few wait slots. The most common second top event will be log file parallel write.