We’ve looked at various failure scenarios and different paths, and now we’ve finally made it to the COMMIT. Here, Oracle will flush the redo log buffer to disk, and the picture will look like Figure 9-4.

Figure 9-4.  State of the system after a COMMIT

The modified blocks are in the buffer cache; maybe some of them have been flushed to disk. All of the redo necessary to replay this transaction is safely on disk, and the changes are now permanent.

If we were to read the data directly from the datafiles, we probably would see the blocks as they existed before the transaction took place, as DBWn most likely has not yet written them.

That’s OK—the redo log files can be used to bring those blocks up to date in the event of a failure.

The undo information will hang around until the undo segment wraps around and reuses those blocks. Oracle will use that undo to provide for consistent reads of the affected objects for any session that needs them.

Commit and Rollback Processing

It is important to understand how redo log files might impact us as developers. We will look at how the different ways we can write our code affect redo log utilization.

We’ve already seen the mechanics of redo earlier in the chapter, and now we’ll look at some specific issues. You might detect many of these scenarios, but they would be fixed by the DBA as they affect the database instance as a whole.

We’ll start with what happens during a COMMIT and then get into commonly asked questions and issues surrounding the online redo logs.