Role and principle of Oracle Redo

The role and principle of Redo in Oracle: Oracle uses Redo to ensure that database transactions can be replayed, so that data can be restored after a fault occurs. Redo is crucial for Oracle databases. In the database, the Redo function is mainly implemented through three components: Redo Log Buffer, LGWR background process, and Redo Log File (in the archive mode, the Redo Log File is eventually written as an archive Log File through the ARCn process ). Www.2cto.com Redo Log Buffer is located in SGA and is a memory area used cyclically. It stores information about database changes. This information is stored in the form of Redo Entries (Redo Entries, also known as Redo Records ). Redo Entries contains important information for restructuring and redoing database changes, including INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP. The Redo Entries content is copied from the user's memory space (PGA) by the Oracle database process to the Redo Log Buffer in SGA. Redo Entries occupies sequential space in the memory. Since Redo Log Buffer is used cyclically, Oracle continuously writes the Redo Log Buffer content to the Redo Log File through a background process LGWR, redo Log File is also used cyclically. SQL code SELECT * FROM V $ LOG; SELECT * FROM V $ BACKUP_REDOLOG; Redo principle: we know that user data is often modified in Buffer Cache, oracle uses high-speed cache to improve the performance of data operations. When you modify data in the Buffer Cache, Oracle does not immediately write the changed data to the data file, because the independent discrete write efficiency is very low. So far, disk I/O operations are the most prone to bottlenecks in computer systems. Oracle is designed to reduce IO pressure, after a certain amount of data has been modified, You can efficiently write data in batches. Most traditional databases (including Oracle, of course) follow the no-force-at-commit policy when processing data modifications. That is to say, it is not mandatory to write when submitting. Oracle introduces the Redo mechanism to ensure that data can be restored when a database fails (for example, a power failure, write random and scattered data blocks by sequential log entries. This delay improves data writing performance, such as batch effects. Similar to Redo Log Buffer, Redo Log File is also used cyclically. Oracle allows at least two Log groups. By default, three log groups are created during database creation. Sys @ NEI> select group #, members, status from v $ log; GROUP # members status ------------ ------------------ 1 1 INACTIVE 2 1 CURRENT 3 1 INACTIVE when a log file is full, switch to another Log file, which is called Log Switch. Log Switch triggers a checkpoint, prompting the DBWR process to write the change data protected by full Log files back to the database. Before the checkpoint is completed, log files cannot be reused. Because the Redo mechanism protects data, Oracle can repeat the Redo mechanism to recover data when the database fails. So a very important question is, where should we start recovery? If too many Redo logs are read, the recovery time will inevitably be too long. In the production environment, we must ensure that the recovery time is as short as possible. Oracle uses checkpoints to reduce the recovery time. A checkpoint is only a database event. Its fundamental significance lies in reducing the recovery time. When a Checkpoint occurs at www.2cto.com (the SCN is called Checkpoint SCN), Oracle notifies the DBWR process to change the modified data, that is, the Dirty data before the Checkpoint SCN (Dirty Duer) write Data from the Buffer Cache to the disk. After the checkpoint is completed, the CKPT process updates the control file and Data File Header accordingly, records the checkpoint information, and identifies the change. After the checkpoint is completed, all the data modified before the checkpoint has been written back to the disk. The corresponding redo records in the redo log file are no longer useful for crash/instance recovery. If the database crashes afterwards, you only need to recover from the last completed checkpoint. If the database runs in archive mode (all production databases are recommended to run in archive mode), the log file must be written to the archive log file before reuse, archive logs can be used to recover database faults when the media is restored.