Oracle redo is pure overhead, but it's this overhead that enables all sorts of advanced recovery options like point-in-time, table-level, system change number (SCN), and transaction-level. Ensuring this overhead does not negatively impact performance can be challenging at times. Fortunately, the redo process is fairly straightforward (create redo, allocate space, copy the redo, write the redo). and there are a number of very specific wait events. And on top of this, there are a number of advanced Oracle features directly created to deal with unique redo requirements. Redo-related performance issues can be especially tense because they are usually deeply application and IO subsystem related. Making changes to the application and the IO subsystem is something no one desires, but if Oracle's redo requirements are exceeding the capacity of the IO subsystem, sometimes all three perspectives must be intimately involved with solving the problem.

This completes the three Oracle internals chapters! The next chapter begins a journey into understanding what kind of impact we can expect from our proposed performance-increasing solutions.

2 Simply issuing a commit command when no object change occurred will not trigger the log writer to write. This is easy to test. Create a tight PL/SQL loop containing two lines: a commit and a 1-second sleep. Let this run while operating system tracing the log writer background process. You will not see the log writer issue a write request. However, if you add a third line into the tight PL/SQL loop that performs some type of subsecond DML loop, after 60 seconds, you will see the log writer issue about 60 write calls.