The function of Oracle:redo in layman's

The function of Oracle:redo in layman's

Oracle uses redo to ensure that transactions in the database can be replayed, so that data can be restored after a failure. Redo is critical for Oracle databases.

In the database, the functions of Redo are mainly implemented by 3 components: Redo log Buffer, LGWR background process, and Redo log file (in archive mode, the Redo log files will eventually be written out as archive logs).

In Oracle's SGA, there is a piece of shared memory, as shown in Redo Log buffer,6-1.

Figure 6-1 Oracle Instance

The Redo Log buffer, located in the SGA, is a circular memory area that holds information about database changes. This information is stored in the form of redo entries (Redo Entries) (Redo Entries is also often referred to as Redo Records). Redo entries contains important information about refactoring and redo database changes, including INSERT, UPDATE, DELETE, CREATE, Alter, or drop. Redo entries is used for database recovery when necessary.

The contents of the Redo entries are copied from the user's memory space by the Oracle database process into the Redo Log buffer in the SGA. Redo entries occupies contiguous sequential space in memory, and because Redo log buffer is used in a loop, Oracle continuously writes the contents of Redo log buffer to the Redo log file through a background process LGWR.

When the user modifies the data in the buffer cache, Oracle does not immediately write out the modification data to the data file because it is inefficient, so far the busiest part of the computer system is the I/O operation of the disk, and Oracle does this to reduce the number of IO When the modified data reaches a certain amount, it can be written out efficiently and in bulk.

Most traditional databases (including, of course, Oracle) follow the NO-FORCE-AT-COMMIT policy when processing data modifications. That is, the write is not enforced at the time of submission. In order to ensure that data is recoverable in the event of a database failure, such as a power outage, Oracle introduces a redo mechanism that delays the writing of random, scattered chunks of data by writing sequential, sequential log entries. This delay allows the data to be written out to gain a performance boost for batch effects.

Similar to Redo log buffer, the Redo log file is also used for recycling, and Oracle allows a minimum of two log groups. By default, 3 log groups are established when the database is created.

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 full, it switches to another log file, which is called log switch. Log switch triggers a checkpoint that causes the DBWR process to write a full log file-protected change data back to the database. The log file cannot be reused until the checkpoint is complete.

Due to the redo mechanism's protection of data, Oracle can perform data recovery through redo replay when the database fails. So a very important question is, where should the recovery begin?

If there are too many redo to read, it will inevitably lead to a long recovery time, and in a production environment we must ensure that the recovery time is as short as possible. Oracle reduces recovery time through checkpoints (Checkpoint). Review what is mentioned in chapter 1th: The checkpoint is just a database event, and its fundamental significance is to reduce recovery time.

When the checkpoint occurs (the SCN at this time is known as the checkpoint SCN), Oracle notifies the DBWR process to write the modified data, which is the dirty data (Dirty buffer) before the checkpoint SCN, to the disk from the buffer cache. After the checkpoint is complete, the CKPT process updates the control file and the data file header accordingly, records the checkpoint information, and identifies the change.

After the checkpoint is complete, the data that was modified before this checkpoint has been written back to the disk, and the corresponding redo record in the redo log file is no longer useful for crash/instance recovery. If the database crashes later, then recovery only needs to be resumed from the last checkpoint that was completed. If the database is running in archive mode (all production databases are recommended to run in archive mode), log files must be written out to the archive log file before reuse, and archived logs can be used to recover database failures when the media is restored.

The function of Oracle:redo in layman's