The Oracle Redo Log
One of the most important ideas in Oracle is that your data is safe. It is protected from corruption and also from system crashes.
One of the most important ways that it does this is through the Redo logs.
A Redo log record is written to describe the changes every time some data is changed in the database.
This is so that the system can be recovered after a system failure.
If the system suffers a crash like a power failure, all data in the buffers (memory) will be lost.
The redo logs can be used the re-apply all changes that have been made since the data file were last written to.
On recovery, all committed transactions will be re-applied (basically, the SQL will be re-run). All uncommitted transactions will be rolled back.
Without redo logs, you cannot recover after a system failure.
note. You should not use disk caching on disks with redo logs unless that disk caching controller is battery backed up. This is because if the power failed, Oracle would think that data was written to disk but it may be sitting in the cache and would be lost with the power.
Process of modifying data in the Oracle database:
- A change is made to the buffer cache in the database.
- The transaction completes and commit opperation is triggered.
- Redo data is written to the redo log buffers.
- The LGWR (Log Writer) process writes to redo log files on disk.
- Commit operation is complete once the redo log file has been written.
How the Redo logs are structured.
The Redo logs are made up or 2 or more log files or log groups.
A log group is treated the same as log file but it has redundancy. It is simply multiple copies of the same file.
- The two or more files are used in an alternating fashion
- One log file fills up then the next one starts being written to.
- If archivelogmode is enabled, the first redo log file will be archived.
- If the first Redo log file has not finished being archived by the time the last one fills up, the database will wait and not execute any more transactions until the first Redo log file has been fully archived.