Understanding REDOLOG (1) Basic concepts of media recovery and instance recovery

In the oracle world, there are three types of data: undo, redo, and data. While redo should quot; Commit transactions without losing quot;, a mechanism is generated to serve two types of scenarios: instance

In the oracle world, there are three types of data: undo, redo, and data. While redo should quot; Commit transactions without losing quot;, a mechanism is generated to serve two types of scenarios: instance

In the Oracle world, there are three types of data: undo, redo, and data. Redo is a mechanism generated by "no loss of committed transactions" to serve two types of scenarios: instance recovery and media recovery.

Instance recovery objective: to ensure data loss in buffer cache and Database Consistency when the database fails

Media recovery objective: to restore data when data files fail

Redo is organized by thread. For a single instance, there is only one THREAD; For RAC, there may be multiple threads.

The redo log mechanism is private: each instance has its own log buffer. However, in the rac environment, redo log files are shared.

Either way, the first step is to roll back the borrowed redo data (the undo data file is also rolled forward) until the last available redo log or archive log.

Furthermore, oracle's cache mechanism is performance-oriented and is not used for storage. For this purpose, oracle must handle two problems:

1) how to ensure that the committed transactions are not lost?

2) how to balance the instance recovery time?

First problem: Log-Force-at-Commit Mechanism

Logs are written when commit is used. logs are written only when commit complete is returned. Even if "Commit compl" is returned, the logs are not written even when a sudden power failure occurs.

Second problem: checkpoint Mechanism

Data is read by the server process, but not written. The buffer cache write operation is completed by DBWn. DBWn writes part of data to the data file based on workload and whether it is used by other processes, this is random. The checkpoint mechanism is an effective supplement to this situation. When a Check Point occurs, the CKPT process requires DBWn to write all the dirty buffers before an scn back to the data file. After a checkpoint is completed, all data changes before the scn are saved to the disk. If a fault occurs at this time, the previous changes to this event do not need to be considered.