When redo is involved in a performance issue, as shown in Figure 8-11, it is common to see multiple redo-related wait events. Focus on the top event, and then work your way down, while considering expected performance improvement, ease of solution implementation, supportability, and so on. For example, while log file parallel write is the top wait event, simply increasing the redo log buffer size will eliminate most of the log buffer space waits. To make a shockingly strong case for redo problems, by classifying all redo-related waits, you can say that over 99% of all the wait time is associated with redo!

Figure 8-11. Shown is a common v$system_event interval report clearly indicating severe redo-related performance problems, with instance processes waiting 40% of their wait time on the log writer background process to complete a write.

Figure 8-11 also shows that to Oracle, the average log writer background process write call takes over 200 ms! Here is an example of where OraPub's 3-circle analysis shines. Instead of the usual, "It's the application SQL" or "The IO subsystem is operating poorly," at this point, all we confidently know is that Oracle's sequential IO write requirements have exceeded the IO subsystem's capacity. And, as I'll detail shortly, we can develop solutions from an Oracle, application, and operating system perspective. This is how you build a more cooperative solution and avoid the usual adverse and destructive finger-pointing sessions.