Purpose of Instance Recovery

Instance recovery ensures that the database is in a consistent state after an instance failure. The files of a database can be left in an inconsistent state because of how Oracle Database manages database changes.

A redo thread is a record of all of the changes generated by an instance. A single-instance database has one thread of redo, whereas an Oracle RAC database has multiple redo threads, one for each database instance.

When a transaction is committed, log writer (LGWR) writes both the remaining redo entries in memory and the transaction SCN to the online redo log. However, the database writer (DBW)process writes modified data blocks to the data files whenever it is most efficient. For this reason, uncommitted changes may temporarily exist in the data files while committed changes do not yet exist in the data files.

If an instance of an open database fails, either because of a SHUTDOWN ABORT statement or abnormal termination, then the following situations can result:

• Data blocks committed by a transaction are not written to the data files and appear only in the online redo log. These changes must be reapplied to the database.

• The data files contains changes that had not been committed when the instance failed. These changes must be rolled back to ensure transactional consistency.

Instance recovery uses only online redo log files and current online data files to synchronize the data files and ensure that they are consistent.

例項恢復的目的

例項恢復可確保資料庫在一個例項失敗後仍能回到一個一致的狀態。由於oracle資料庫對資料檔案更改的管理方式所致，資料庫的檔案可以處於不一致的狀態。

重做執行緒是對例項生成的所有更改的記錄。單例項資料庫擁有一個重做執行緒，而一個Oracle RAC資料庫擁有多個重做執行緒——每個資料庫例項有一個。

當事務提交時，日誌寫入器(LGWR)將記憶體中的重做條目和事務SCN同時寫入聯機重做日誌。但是，資料庫寫入器(DBWn)程式只在最有利的時機將已修改的資料塊寫入資料檔案。由於這個原因，未提交的更改可能會暫時存在於資料檔案中，而已提交的更改也可能還不在資料檔案中。

如果某個開啟的資料庫的例項失敗，或者由於SHUTDOWN ABORT語句或異常終止，則可能會導致下列情況：

l由某事務已提交的資料塊更新還未寫入資料檔案，而僅寫入了聯機重做日誌中。這些更改必須重新應用到資料庫。

l資料檔案包含例項失敗時尚未提交的更改。這些更改必須回滾，以確保事務一致性。

例項恢復只使用聯機重做日誌檔案和當前線上的資料檔案，以同步資料檔案，並確保它們一致。

When Oracle Database Performs Instance Recovery

Whether instance recovery is required depends on the state of the redo threads. A redo thread is marked open in the control file when a database instance opens in read/write mode, and is marked closed when the instance is shut down consistently. If redo threads are marked open in the control file, but no live instances hold the thread enqueues corresponding to these threads, then the database requires instance recovery.

Oracle Database performs instance recovery automatically in the following situations:

• The database opens for the first time after the failure of a single-instance database or all instances of an Oracle RAC database. This form of instance recovery is also called crash recovery. Oracle Database recovers the online redo threads of the terminated instances together.

• Some but not all instances of an Oracle RAC database fail. Instance recovery is performed automatically by a surviving instance in the configuration.

The SMON background process performs instance recovery, applying online redo automatically. No user intervention is required.

Oracle資料庫何時執行例項恢復

是否需要例項恢復取決於重做執行緒的狀態。在資料庫例項被開啟為讀/寫模式時，重做執行緒在控制檔案中被標記為開啟，而當例項被一致關閉時，重做執行緒被標記為關閉。如果重做執行緒在控制檔案中被標記為開啟，但沒有活動的例項持有對應於這些執行緒的執行緒佇列，則資料庫將需要例項恢復。

oracle資料庫在以下情況下自動執行例項恢復：

·單例項資料庫或Oracle RAC資料庫的所有例項失敗後第一次開啟資料庫。這種形式的例項恢復也稱為崩潰恢復。Oracle資料庫一起恢復所有已終止例項的聯機重做執行緒。

·只是Oracle RAC資料庫中的某些、但不是所有例項失敗。例項恢復將由配置中的某個存活例項自動進行。

SMON後臺程式自動執行例項恢復並應用聯機重做記錄。而不需要任何使用者干預。

Importance of Checkpoints for Instance Recovery

Instance recovery uses checkpoints to determine which changes must be applied to the data files. The checkpoint position guarantees that every committed change with an SCN lower than the checkpoint SCN is saved to the data files.

Figure 13-5 depicts the redo thread in the online redo log.

Figure 13-5 Checkpoint Position in Online Redo Log

Description of "Figure 13-5 Checkpoint Position in Online Redo Log"

During instance recovery, the database must apply the changes that occur between the checkpoint position and the end of the redo thread. As shown in Figure 13-5, some changes may already have been written to the data files. However, only changes with SCNs lower than the checkpoint position are guaranteed to be on disk.

例項恢復檢查點的重要性

例項恢復使用檢查點來確定必須將哪些更改應用到資料檔案。檢查點位置始終保證所有比其SCN低的檢查點所對應的已提交更改都已儲存到資料檔案。

圖13-5描述了聯機重做日誌中的重做執行緒。

圖13-5聯機重做日誌中的檢查點位置

例項恢復期間，資料庫必須應用檢查點位置和重做執行緒結尾之間發生的更改。如圖13-5所示，某些更改可能已經寫入資料檔案。但是，只有其SCN低於檢查點位置的更改，才保證已被寫到了磁碟上。

Instance Recovery Phases

The first phase of instance recovery is called cache recovery or rolling forward, and involves reapplying all of the changes recorded in the online redo log to the data files. Because rollback data is recorded in the online redo log, rolling forward also regenerates the corresponding undo segments.

Rolling forward proceeds through as many online redo log files as necessary to bring the database forward in time. After rolling forward, the data blocks contain all committed changes recorded in the online redo log files. These files could also contain uncommitted changes that were either saved to the data files before the failure, or were recorded in the online redo log and introduced during cache recovery.

After the roll forward, any changes that were not committed must be undone. Oracle Database uses the checkpoint position, which guarantees that every committed change with an SCN lower than the checkpoint SCN is saved on disk. Oracle Database applies undo blocks to roll back uncommitted changes in data blocks that were written before the failure or introduced during cache recovery. This phase is called rolling back or transaction recovery.

Figure 13-6 illustrates rolling forward and rolling back, the two steps necessary to recover from database instance failure.

Figure 13-6 Basic Instance Recovery Steps: Rolling Forward and Rolling Back

Description of "Figure 13-6 Basic Instance Recovery Steps: Rolling Forward and Rolling Back"

Oracle Database can roll back multiple transactions simultaneously as needed. All transactions that were active at the time of failure are marked as terminated. Instead of waiting for the SMON process to roll back terminated transactions, new transactions can roll back individual blocks themselves to obtain the required data.