I'll never forget this: I had just accepted Oracle's offer to join their consulting organization, and an old guy1 at my current workplace asked me very seriously, "Why would you want to work for Oracle? Their database is so slow." While I don't remember my response, I do remember thinking, "I don't really care. I just want out of this place!" But as I came to learn, Oracle was slow, and that was because it successfully manages massive amount of data. My previous employer's database (which was really a glorified virtual storage access method file manager) had no concept of read consistency or rolling a transaction back, so it commonly had corrupted files, which meant that we need to take the database offline and try to rebuild the files. I learned data management capabilities came at a price, both financially and in performance.

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.