In my performance firefighting classes, I leave the redo log buffer section for the very end. I know that if the class moves slowly, the one section I can appropriately and quickly move through is the one on redo internals. The reason is that once you are comfortable with buffer cache and shared pool internals, the redo log buffer technology, architecture, and diagnosis seem straightforward. The real challenge with redo is not in diagnosing and analyzing the problem, but finding the solution, because redo-related problems can be very difficult to implement. It is common to require the IO subsystem capacity to be increased, as well as make significant application architectural changes. Both can be excruciatingly painful.

My objective in this chapter is to clearly present the relevant architectural pieces of the redo log buffer, the performance challenges we commonly face, and how we can alter the situation in our favor. Because the diagnosis is fairly straightforward, we'll spend more time on the solutions, which is where you'll be spending most of your time when redo becomes the point of contention.

Every commit issued2 and current mode buffer change (consistent read buffers do not have their changes recorded) must be recorded for recovery purposes. And the moment we are concerned with recovery, serialization becomes of critical importance. It's the combination of change recording and serialization that can force Oracle to place tremendous requirements on the operating system. When redo-related operating resources become scarce, response time begins to skyrocket, and the contention can be easily diagnosed by performing a wait-event analysis or a response-time analysis. If you perform the OraPub 3-circle analysis, within a few minutes, the performance story will be blatantly apparent.