Redo log: Difference between revisions
Tag: section blanking |
|||
| Line 8: | Line 8: | ||
If a database crashes, the [[data recovery | recovery]] process has to apply all transactions, both uncommitted as well as committed, to the data-files on disk, using the information in the redo log files. Oracle must re-do all redo-log transactions that have both a begin and a commit entry, and it must undo all transactions that have a begin entry but no commit entry. (Re-doing a transaction in this context simply means applying the information in the redo log files to the database; the system does not re-run the transaction itself.) The system thus re-creates committed transactions by applying the “after image” records in the redo log files to the database, and undoes incomplete transactions by using the “before image” records in the undo [[tablespace]]. |
If a database crashes, the [[data recovery | recovery]] process has to apply all transactions, both uncommitted as well as committed, to the data-files on disk, using the information in the redo log files. Oracle must re-do all redo-log transactions that have both a begin and a commit entry, and it must undo all transactions that have a begin entry but no commit entry. (Re-doing a transaction in this context simply means applying the information in the redo log files to the database; the system does not re-run the transaction itself.) The system thus re-creates committed transactions by applying the “after image” records in the redo log files to the database, and undoes incomplete transactions by using the “before image” records in the undo [[tablespace]]. |
||
[http://www.quest.com/shareplex-for-oracle/ SharePlex for Oracle Database Replication] uses the redo log and processes it via [[Change Data Capture]] providing 99.999% Maximum Availability, data migrations, high-availability, disaster protection or resource offloading for a ZeroIMPACT™ solution. |
|||
== Implications == |
== Implications == |
||
Revision as of 15:45, 5 June 2011
In the Oracle RDBMS environment, redo logs comprise files in a proprietary format which log a history of all changes made to the database. Each redo log file consists of redo records. A redo record, also called a redo entry, holds a group of change-vectors, each of which describes or represents a change made to a single block in the database.
For example, if a user UPDATEs a salary-value in a table containing employee-related data, the DBMS generates a redo record containing change-vectors that describe changes to the data segment block for the table. And if the user then COMMITs the update, Oracle generates another redo record and assigns the change a "system change number" (SCN).
Usage
Before a user receives a "Commit complete" message, the system must first successfully write the new or changed data to a redo log file.
If a database crashes, the recovery process has to apply all transactions, both uncommitted as well as committed, to the data-files on disk, using the information in the redo log files. Oracle must re-do all redo-log transactions that have both a begin and a commit entry, and it must undo all transactions that have a begin entry but no commit entry. (Re-doing a transaction in this context simply means applying the information in the redo log files to the database; the system does not re-run the transaction itself.) The system thus re-creates committed transactions by applying the “after image” records in the redo log files to the database, and undoes incomplete transactions by using the “before image” records in the undo tablespace.
SharePlex for Oracle Database Replication uses the redo log and processes it via Change Data Capture providing 99.999% Maximum Availability, data migrations, high-availability, disaster protection or resource offloading for a ZeroIMPACT™ solution.
Implications
Given the verbosity of the logging, Oracle Corporation provides methods for archiving redo logs (archive-logs), and this in turn can feed into data backup solutions and standby databases.
The existence of a detailed series of individually logged transactions and actions provides the basis of several data-management enhancements such as Oracle Flashback, log-mining and point-in-time recovery.
For database tuning purposes, efficiently coping with redo logs requires plentiful and fast-access disk.