The role of redo

Redo and undo are important features of Oracle to ensure the recoverability and undo of transactions. This chapter discusses the Oracle redo mechanism.
1. Role of redo
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 will eventually be written as an archive log file ).
In the SGA of Oracle, there is a shared memory, called redo log buffer.

The 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. When necessary, redo entries is used for database recovery.
The redo entries content is copied from the user's memory space by the Oracle database process to the redo log buffer in SGA. Redo entries occupies sequential space in the memory. Because redo log buffer is used cyclically, oracle constantly writes the redo log buffer content to the redo log file through a background process lgwr.

When you modify data in the buffer cache, Oracle does not immediately write the modified data to the data file, because the efficiency will be very low, so far, the busiest part of the computer system is the disk I/O operations. Oracle aims to reduce the number of I/O operations. after a certain amount of modified data is reached, 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 in case of database faults (such as power outages, write random and scattered data blocks by sequential log entries. This delay improves the performance of writing data in batches.
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.
SQL> select group #, members, status from V $ log;

Group # members status
------------------------------------
1 1 inactive
2 1 Current
3 1 inactive
When a log file is fully written, it is switched to another log file, which is called a 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. A very important question is, where should the recovery start?
If too many redo logs are read, the recovery time is 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. Review the content mentioned in chapter 1st: a checkpoint is only a database event. Its fundamental significance lies in reducing the recovery time.
When a checkpoint occurs (at this time, the SCN is called the checkpoint SCN), Oracle notifies the dbwr process to change the modified data, that is, the dirty data before the checkpoint SCN (dirty buffer) 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.

 

 

• Provides Oracle management/troubleshooting/optimization/installation/RAC/Backup Recovery technical services, and professional Oracle training and consulting services.
• Professional forums http://www.inthirties.com
• Technical blog http://blog.csdn.net/inthirties
• Personal site http://blog.inthirties.com