Oracle Recovery Internal principle: Redo Log

Redo logs describe all changes to a block of data. This section mainly describes some of the operations when the database is opened to write logs.

3.1 Atomic Modifications

The most basic operation of a database is to modify a block of data in an atomic way. When the foreground process wants to modify one or several blocks of data, it first obtains an exclusive access to the cache that contains the block in the data buffer. Then build the change vector. The redo log buffer allocates space to save the redo record. The redo buffer is in the SGA, and the LGWR process periodically writes the redo record in the redo log buffer to the redo log file to free up space. When the redo log is full, LGWR will have to do log switching. Note allocating space in the redo log buffer also allocates space in the Redo log file. After the redo log buffer space is allocated, the foreground process is responsible for building the redo record before modifying the data block in the data buffer. Then the database change is completed when the redo record in the redo log buffer is written to the redo file. Restore guarantees that the changes recorded in the redo log will be applied to the data file (unless it is not fully restored).

3.2 Write Log first

Write log priority is a buffer execution protocol that coordinates the order in which dirty data is written to the data file and writes redo log records to the redo log file. According to the Write Log priority protocol, the LGWR process must first write the corresponding redo log to the redo log file before the DBWR process writes dirty data to the data file.

Note that the Write log priority protocol is independent of the Write log protocol with the commit (see 3.3).

Also note that the write-log precedence protocol applies only to the case where the dirty data in the data buffer is written to the data file, and does not apply to direct path writes (as caused by direct path reading).

The Write Log priority protocol guarantees that no change in the data file is recorded in the Redo log file, at the cost of failure.

The write-Log priority protocol also guarantees that all blocks of data are written to disk before the redo log is written and guaranteed to be rolled back, making it possible to roll back all modifications if the commit fails. The redo information here is actually the redo information of the rollback segment.

Write-priority protocols guarantee the atomicity of transactions in the database transaction layer.

3.3 Transaction Submission

When a transaction commits, a SCN is assigned and a redo log record containing that SCN submission is established. The commit process does not end when some redo records (including commit-corresponding redo records) are written to the redo log file on disk in the transaction. A commit therefore forces the log to flush to disk-at least until the redo record of the commit, which is what is commonly said to be log-force-at-commit.

Recovery is designed to refresh redo logging to redo logs at the time of a transaction commit without refreshing all the dirty data that the transaction modifies in order to guarantee transactional persistence even if it fails. This is what is usually said of No-datablock-force-at-commit.

3.4 Thread Checkpoint Events

When a thread checkpoint event occurs, dirty data that is protected by a redo record in the redo record of the thread that is less than the specified value is flushed to the data file. When finished, the thread checkpoint structure of the thread in the control file is updated.

When the thread checkpoint event begins, it first obtains a SCN, initializing a checkpoint structure. All dirty data in the data buffer of the instance is then labeled as a checkpoint. DBWR writes the dirty data of these identities to the data file in phases. When all dirty data is written to the data file, the SCN in the checkpoint structure is updated to the previously obtained SCN, and the checkpoint is used to update the checkpoint record in the control file for that thread.

A thread checkpoint event might or may not push the database checkpoint. When there is only one open thread, the new thread checkpoint is also the new checkpoint for the database. If there are multiple open threads, and the current thread is the database checkpoint online, the current thread's checkpoint event pushes the database checkpoint. Because the new checkpoint SCN is recently allocated, it is likely to be larger than the checkpoint SCN of other open threads, and the database checkpoint SCN will advance to the new minimum thread checkpoint SCN. However, if the current thread's original checkpoint is not a database checkpoint, then the checkpoint event for that thread does not push the database checkpoint.

As the database checkpoint advances, the count of checkpoints on the head of each data file also grows. Also, as long as each data file is not in a hot backup or has no higher checkpoint SCN (such as a new data file or a newly restored data file), the checkpoint on the header of the data file will advance to the same point as the new database checkpoint, and the data file headers will be written to disk. Also, the checkpoint of the record in the control file of the data file is also updated to the new database checkpoint SCN.