Redo log

From Wikipedia, the free encyclopedia

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 an employee-table, 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).

[edit] Structure

A single transaction may involve multiple changes to data blocks, so it may have more than one redo record.

Redo log files contain redo entries for both committed and uncommitted transactions.

Oracle redo log files contain the following information about database changes made by transactions:

• indicators specifying when the transaction started
• a transaction-identifier
• the name of the data object updated (for example, an application table)
• the “before image” of the transaction (the data as it existed before the changes)
• the “after image” of the transaction (the data as it appeared after the transaction made the changes)
• commit-indicators that record whether and when the transaction completed

[edit] 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.

When 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. (Redoing 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.

[edit] 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.