| Lesson 2 | Overview of Redo Log Processing |
| Objective | Understand redo log functions. |
Oracle Redo Logs
One of the cornerstone features of Oracle Database is its ability to recover data after a failure, such as a disk crash. Redo logs are critical to this process, enabling Oracle to reconstruct committed transactions and maintain data integrity. Redo logs serve as transaction journals, recording every change made to the database in chronological order. This ensures that no committed data is lost, even if the changes haven’t yet been written to the data files.
What Are Redo Logs?
- Definition: Redo logs are files that capture a complete record of all database changes, including inserts, updates, deletes, and structural modifications (e.g., table alterations).
- Purpose: Their primary role is to facilitate data recovery. In the event of a system failure, redo logs allow Oracle to replay committed transactions, ensuring no data loss and restoring the database to a consistent state.
- Transaction Journals: Redo logs function as transaction journals by logging every modification in the order it occurs. This includes both user-initiated changes (e.g., updating a table) and internal database operations.
How Redo Logs Work in Oracle
The redo log process involves a sequence of steps to capture, store, and archive transaction data. Below is an overview of the process, illustrated with key stages:
Disk array mirroring[1] is a crucial hardware-level strategy for protecting Oracle redo logs, ensuring high availability and data integrity. It involves writing the same data to two or more disks simultaneously, creating a redundant copy. This process is typically handled by a storage area network (SAN) or a hardware RAID controller.
-
Writing to the Redo Log Buffer
- Redo entries, which record database changes, are first written to the redo log buffer, a memory area designed for fast, temporary storage.
-
1) Redo entries are written to the redo log buffer. When a transaction issues a COMMIT, the entries are flushed to the online redo log files.
-
Flushing to Online Redo Log Files
- The Log Writer (LGWR) process transfers redo entries from the buffer to the online redo log files on disk. This occurs under specific conditions:
- A transaction is committed.
- The redo log buffer becomes sufficiently full.
- A time-based threshold or checkpoint is reached.
- This ensures that changes are persistently stored, even if not yet applied to data files.
- The Log Writer (LGWR) process transfers redo entries from the buffer to the online redo log files on disk. This occurs under specific conditions:
-
Archiving Redo Logs
- When Oracle switches between online redo log files (e.g., when a log file is full), the Archiver (ARCH) process copies the filled redo log to an archived redo log filesystem. This allows the online redo log to be reused.
-
2) When Oracle switches redo log files, the ARCH process copies the old redo log to an archived redo log filesystem.
-
Long-Term Storage
- As the archived redo log filesystem fills, a user-defined process (e.g., a backup script) copies the archived redo logs to tape or another long-term storage medium for safekeeping.
-
3) A user-defined process copies archived redo logs to long-term storage when the filesystem becomes full.
Disk array mirroring[1] is a crucial hardware-level strategy for protecting Oracle redo logs, ensuring high availability and data integrity. It involves writing the same data to two or more disks simultaneously, creating a redundant copy. This process is typically handled by a storage area network (SAN) or a hardware RAID controller.
Key Oracle Processes
The following background processes are essential to redo log operations:
- Log Writer (LGWR): Transfers redo entries from the buffer to the online redo log files.
- Archiver (ARCH): Copies filled redo log files to the archived redo log filesystem when archive logging is enabled.
Redo Logs in Recovery
Redo logs are vital for Oracle’s recovery mechanisms, ensuring data consistency and preventing loss of committed transactions.
Summary
By functioning as transaction journals, redo logs provide an efficient way to protect data, ensuring that committed changes are never lost and the database can be quickly restored to a consistent state after an unexpected issue.
- Crash Recovery: If the database crashes or shuts down abnormally, Oracle uses redo logs to replay committed transactions that were not yet written to data files. This restores the database to its last consistent state.
- Media Recovery: In cases of data file loss or corruption, Oracle can restore data files from a backup and apply changes from redo logs to bring the database to its most recent committed state.
Summary
- Redo logs act as transaction journals, capturing every database change in sequence.
- They ensure data integrity by preserving committed transactions, enabling recovery from crashes or media failures.
- Redo logs are a cornerstone of Oracle’s robust recovery mechanism, safeguarding data and maintaining database reliability.
By functioning as transaction journals, redo logs provide an efficient way to protect data, ensuring that committed changes are never lost and the database can be quickly restored to a consistent state after an unexpected issue.
[1]
disk array mirroring: Disk array mirroring is a technique for data redundancy where data is synchronously written to two or more physical disks within a disk array. When used with Oracle redo log mirroring, it provides an additional layer of protection for the redo log files, which are crucial for database recovery. This ensures that even if one disk fails, the redo log data remains available on the mirrored disk, allowing for uninterrupted database operation and recovery.