Lesson 8	Redo Logs
Objective	Explain how Oracle redo logs provide crash recovery

Why redo logs are needed

Another type of file that you will find as part of your database is the redo log file. Redo logs enable Oracle software to recover from a server crash, and they allow for up-to-the-minute recovery if a database needs to be restored from a backup. Whenever you issue a transaction that changes data in a database, the change is written both to the datafiles and to the redo log files, but not neccessarilly at the same time. Look through the following series of images to see how this happens:

redo log file process in Oracle

1) Here is the initial state. You can see that Jenny Gennick holds the title of Manager.

2) Someone issues the UPDATE statement shown above promoting Jenny to the partnership.

3) The first thing that happens is that Oracle reads the data block containing Jenny's record into memory

5) Oracle places information about the change made into the redo log buffer. From here it will be written to disk.

6) If the server crashes now, this change will be lost. That is OK, because the transaction has not been committed yet.

7) The application that issued the UPDATE now issues a COMMIT

8) Oracle ensures that the associated redo information is physically written to the redo log file.

9) Oracle also writes a commit record to the redo log file for this transaction

10) Only now does Oracle return control back to the application, and indicate that the commit was successful.

11) At this point, if the server crashes, Oracle can redo the change based on the information contained in the redo log file.

12) Later and this could be much later, the updated data block will be written back to the datafile.

As you can see, Oracle does not immediately write changes to the datafiles .

Oracle does not write all changes immediately

What is the need for redo log files?
Why does not Oracle just write all changes to disk immediately?
How can writing the data twice, once to the redo logs and once to the datafiles, be efficient?

The answer is that the changes are not written to the datafiles one at a time. Oracle maintains a memory area called the database buffer cache^[1], that contains the most recently accessed database blocks. A large database buffer cache increases the odds that any given block will already be in memory needed, reducing the need for disk I/O. When a program issues an UPDATE statement, Oracle makes the change in memory because that's much faster than writing the same data back to disk.
Your program can then continue to do other work. Your changes are eventually written to disk, because Oracle maintains a background process that continuously writes updated blocks back to disk. This use of a memory buffer keeps performance reasonable when a large number of users are updating the database all at once. The overhead involved in writing changes to the redo log is not as bad as you would think. First, the redo log is written sequentially. There are never any locking issues to worry about. Second, only the changes to a block are written, not the entire block itself.

However, when you commit a transaction, Oracle does guarantee that the changes for that transaction are written to the redo log, and that the commit or COMMIT has been recorded as well. If the server crashes, any changes in memory are lost. However, changes written to the redo log are not lost, because they are already on disk. When you restart the Oracle software, it checks the redo log, and reapplies (or redoes) to datafiles any committed transactions that were lost during the crash. Click on the following link to read about the Redo Logs .

[1] database buffer cache: The purpose of the database buffer cache: is to hold as many data blocks in memory as possible in order to minimize the number of reads that an instance needs to perform.