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.

Figure 8-7. Shown is OSM report swpctx.sql, which is a v$system_event wait event report. This report indicates a classic wait event situation with severe log file sync contention. Notice the second top wait event is the typical paired event, log file parallel write.

Solving log file synchronization issues can be painful. First of all, it's a server process (and rarely, but possibly, the database writer background process) that posts the log file sync wait event, not the log writer background process. While there may be a technical reason for the log writer to post a log file sync, in a real production system, I have never seen this occur. This means our solution will nearly always be focused on the server process, which is running application code. Remember that our overall strategy is to reduce commit times.