If Oracle systems did not need the capability to roll back, provide read-consistent views of data, or quickly recover, both undo and redo could be eliminated. Oracle systems would fly! But we would be spending all of our time trying to recover lost data. My point is that data management requires computing resources. In this chapter, we are concerned about one of the largest database management resource consumers: redo generation.

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.