Oracle例項恢復（Instance Recovery）之前滾（Rolling Forward）和回滾（Rolling Back）

關於oracle例項恢復的一些理解，一直都有誤區，今天透過檢視相關資料和與同學探討，發覺了自己的錯誤，探討結果如下：
例項恢復：當資料庫非正常關閉的時候（斷電或者shu abort等等非一致性關閉），當你從新啟動資料庫的時候，資料庫相關程式自動進行例項恢復，無須人工干預，

一. 什麼時候需要例項恢復     在shutdown normal or shutdown immediate下，也就是所謂的clean shutdown，checkpoint也會自動觸發，並且把SCN紀錄寫回。當發生checkpoint時，會把SCN寫到四個地方：三個地方於control file內：
（1）SYSTEM CHECKPOINT SCN
（2）Datafile checkpoint SCN
（3）Stop SCN     ---就是在例項一致性關閉的時候，更新一個在datafile header內： Start SCN

正常open的狀態下一致性的資料庫，SYSTEM CHECKPOINT SCN，Datafile checkpoint SCN和資料檔案頭Start SCN的這三個SCN是一致，並且儲存在control file中的stop scn就會恢復為NULL值，

1.1 Clean shutdown 時
當clean shutdown 時，checkpoint會進行，並且此時datafile的start scn和控制檔案裡的stop scn會相同，等到open時，Oracle檢查datafile header中的start scn和存於control file中的datafile的scn是否相同，如果相同，接著檢查datafile header中的start scn和control file中stop scn是否相同，如果仍然相同，資料庫就會正常開啟，否則就需要recovery。        等到資料庫開啟後，儲存在control file中的stop scn就會恢復為NULL值，此時表示datafile是open在正常模式下了。

1.2 非正常shutdown
   如果不正常SHUTDOWN (shutdown abort)，則mount資料庫後，會發現stop scn並不是等於其它位置的scn，而是等於NULL，這表示Oracle在shutdown時沒有進行checkpoint，下次開機必須進行crash recovery（例項恢復），注意一點：
（1）啟動資料庫時，如果發現STOP SCN = NULL，表示需要進行crash recovery；
（2）啟動資料庫時，如果發現有datafile header的START SCN 不等於儲存於CONTROLFILE的DATAFILE SCN，表示需要進行Media recovery

二. 例項恢復的具體過程：

當資料庫突然崩潰，而還沒有來得及將buffer cache裡的髒資料塊重新整理到資料檔案裡，同時在例項崩潰時正在執行著的事務被突然中斷，則事務為中間狀態，也就是既沒有提交也沒有回滾。這時資料檔案裡的內容不能體現例項崩潰時的狀態。這樣關閉的資料庫是不一致的。下次啟動例項時，Oracle會由SMON程式自動進行例項恢復。例項啟動時，SMON程式會去檢查控制檔案中所記錄的、每個線上的、可讀寫的資料檔案的END SCN號。
資料庫正常執行過程中，該END SCN號始終為NULL，而當資料庫正常關閉時，會進行完全檢查點，並將檢查點SCN號更新該欄位，所以可以透過END SCN號是否為null來判斷是不是需要例項恢復。        而崩潰時，Oracle還來不及更新該欄位，則該欄位仍然為NULL。當SMON程式發現該欄位為空時，就知道例項在上次沒有正常關閉，於是由SMON程式就開始進行例項恢復了。 SMON程式進行例項恢復時，會從控制檔案中獲得檢查點位置。於是，SMON程式到聯機日誌檔案中，找到該檢查點位置，然後從該檢查點位置開始往下，應用所有的重做條目，從而在buffer cache裡又恢復了例項崩潰那個時間點的狀態。這個過程叫做前滾，前滾完畢以後，buffer cache裡既有崩潰時已經提交還沒有寫入資料檔案的髒資料塊，也還有事務被突然終止，而導致的既沒有提交又沒有回滾的事務所弄髒的資料塊。前滾一旦完畢，SMON程式立即開啟資料庫。但是，這時的資料庫中還含有那些中間狀態的、既沒有提交又沒有回滾的髒塊，這種髒塊是不能存在於資料庫中的，因為它們並沒有被提交，必須被回滾。開啟資料庫以後，SMON程式會在後臺進行回滾。    有時，資料庫開啟以後，SMON程式還沒來得及回滾這些中間狀態的資料塊時，就有使用者程式發出讀取這些資料塊的請求。這時，伺服器程式在將這些塊返回給使用者之前，由伺服器程式負責進行回滾，回滾完畢後，將資料塊的內容返回給使用者。

三. 為什麼資料庫的例項恢復是先前滾再回滾

回滾段實際上也是以回滾表空間的形式存在的，既然是表空間，那麼肯定就有對應的資料檔案，同時在buffer cache 中就會存在映像塊，這一點和其他表空間的資料檔案相同。
當發生DML操作時，既要生成REDO（針對DML操作本身的REDO Entry）也要生成UNDO（用於回滾該DML操作，記錄在UNDO表空間中），但是既然UNDO資訊也是使用回滾表空間來存放的，那麼該DML操作對應的UNDO資訊（在BUFFER CACHE生成對應中的UNDO BLOCK）就會首先生成其對應的REDO資訊（UNDO BLOCK's REDO Entry）並寫入Log Buffer中。        這樣做的原因是因為Buffer Cache中的有關UNDO表空間的塊也可能因為資料庫故障而丟失，為了保障在下一次啟動時能夠順利進行回滾，首先就必須使用REDO日誌來恢復UNDO段（實際上是先回復Buffer Cache中的髒資料塊，然後由Checkpoint寫入UNDO段中），在資料庫OPEN以後再使用UNDO資訊來進行回滾，達到一致性的目的。        生成完UNDO BLOCK's REDO Entry後才輪到該DML語句對應的REDO Entry，最後再修改Buffer Cache中的Block，該Block同時變為髒資料塊。        實際上，簡單點說REDO的作用就是記錄所有的資料庫更改，包括UNDO表空間在內。

總結：今天最重要的一點我知道了，所謂的前滾，是應用redo來恢復buffer cache的資料，將buffer cache恢復到crash之前狀態，所以此時buffer cache 中既有崩潰時已經提交還沒有寫入資料檔案的髒資料塊，也還有事務被突然終止，而導致的既沒有提交又沒有回滾的事務所弄髒的資料塊（也就是沒有commit，但是dbwr已經將改變重新整理到底層磁碟），還有一點是控制檔案中還有一個 end scn，用來記錄資料庫正常關閉的時候的資料庫檔案頭的scn,並且可以透過這個scn是否為null來判斷需或者不需例項恢復。

保持資料一致性和完整性，是每一款成功商業資料庫軟體都必須要做到的基本要求。從故障中恢復，保證ACID原則，保證事務完整性，一直是Oracle資料庫核心功能組成部分。本篇主要介紹Oracle例項意外終止（斷電或者強制關閉）之後，重新啟動時發生的恢復過程，也可以稱作“前滾和回滾”。

基礎知識說明

為了更明確的說明問題，筆者首先介紹一下本文涉及到的一些重要知識。

資料庫例項失敗

我們經常說的資料庫伺服器failure是有多層含義的。Oracle資料庫是一個由多程式元件共同構成的結構體系。最重要的部分包括監聽器、Oracle資料庫例項兩個部分，當然還包括各類檔案，更廣義的還有硬體和作業系統OS。不同部分的Failure現象和處理方法都有所不同。本文所闡述的過程是Oracle例項失敗後的自動恢復過程。

在例項失敗的時候，往往是突然性的終止。此時Oracle資料庫可能在進行一系列完成或者未完成的事務。例項失敗恢復，就是要將這些狀態進行還原，恢復到資料完整性的狀態。

寫日誌（Redo Log）在先機制

Oracle資料庫是採用“日誌在先”機制的。當我們對資料庫資料進行修改時，並不是立即將修改寫入到檔案中，而是寫入到共享記憶體SGA空間中的Buffer Cache裡。同時，將修改的日誌不斷的寫入到SGA中另一塊Log Buffer快取中。有一個後臺程式LGWn不斷的將Log Buffer快取中的日誌內容寫入到online redo log檔案中。

寫入Log Buffer快取和LGWn寫入檔案的過程是非同步進行的。觸發LGWn工作的時點有幾個：

ü 使用者進行直接的commit操作；

ü 日誌進行切換；

ü 距離上次LGWn寫入操作超過三秒；

ü Redo Buffer資料超過1/3或者超過1M大小；

ü DBWn啟動，將Buffer Cache中的髒資料寫入到檔案中；

而資料檔案寫入程式DBWn工作的觸發點，則比較平緩和低頻率。

ü 當Buffer Cache中缺少用於寫入資料的clean block的時候，DBWn會開始將一些髒塊“Dirty Block”寫入到檔案中，清理出一些可以使用的Clean Block；

ü 週期性的CheckPoint寫入，當CKPT程式進行檢查點打入的時候，DBWn會啟動進行寫入；

綜合DBWn和LGWn工作的特點，我們可以得到日誌檔案的幾個特點：

首先，日誌檔案的寫入是很頻繁的。LGWn會不斷將日誌資訊從Log Buffer中寫入Online Redo Log；

其次，在日誌檔案上，可以有三個型別的事務事件。

1、事務結束，已經被commit，之後打過checkpoint檢查點。這種事務記錄在Log File上，但是變化資訊已經被DBWn寫入進資料檔案；

2、事務結束，已經被commit，之後沒有打入checkpint檢查點。這種情況下，Log File已經寫入了日誌專案，資料檔案可能包括髒資料，也可能沒有寫入髒資料；

3、事務未結束，沒有commit。這種時候，資料塊Dirty Block上面是有事務槽資訊，表示未結束事務，是不會將資料寫入到資料檔案中。但是，日誌Log Buffer可能將部分未提交的DML操作專案寫入到Log File中；

檢查點Checkpoint

檢查點Checkpoint是資料庫一致性檢查的一個標記。簡單的說，就是在這個點上，Oracle保證各個檔案（資料、控制、日誌等）是一致的。檢查點的作用就是在進行例項恢復的時候，告訴SMON程式，這個點之前的內容不需要進行恢復。

前滾和回滾介紹

“前滾和回滾”是Oracle資料庫例項發生意外崩潰，重新啟動的時候，由SMON進行的自動恢復過程。下面透過模擬例項和講解介紹這個過程。

失敗前場景說明

日誌中記錄過程如下：

1、事務A進行之後，結束commit。之後系統進行了一次checkpoint A；

2、Checkpoint之後，進行事務B，結束commit；

3、進行事務C，C事務量較大，其中進行了一定量的Redo Log檔案寫入。之後系統斷電；

1、系統啟動過程，進入例項恢復階段

當例項意外中斷的時候，各型別檔案，包括控制檔案、資料檔案和日誌檔案上，會存在不一致的問題。這種不一致主要體現在SCN值的差異上。

例項在啟動的時候，經過三階段（nomount、mount和open）。在open之前，會進行這種不一致現象的檢查，如果出現不一致，要啟動SMON程式的恢復流程。

SMON是Oracle例項的一個後臺程式，主要負責進行系統監控恢復。進行恢復的依據主要是Redo Log記錄。

2、前滾程式

SMON首先找到最後SCN記錄的Redo Log File。尋找最後一個打入的Checkpoint。

順序找到CheckPoint A之後，表示A之前的所有事務都是完全寫入到資料檔案中，不存在不一致性問題。恢復過程從Checkpoint A開始，Oracle開始依據重做日誌Redo Log的系列條目，進行推進。

首先遇到了事務B資訊，由於事務B已經commit，所以事務B所有相關的Redo Log條目已經全都寫入到Redo Log File中。所以，按照日誌繼續條目推進，完全可以重演replay，並且應用apply事務B的全部過程。

這樣，事務B全部實現，最終將透過DBWn完全寫入到資料檔案中。所以，例項失敗之前提交commit的事務B，完全恢復。

進入事務C的範疇，由於一部分事務C的Redo Log條目已經進入Redo Log File中，所以在進行前滾的時候，一定會replay到這部分的內容。不過，這部分內容中不可能出現commit的標記。所以，前滾的結果一定是遇到例項突然中斷的那個時點。此時replay的結果是，事務C沒有提交。這樣結束了前滾過程，進入回滾階段。

3、回滾過程

對事務C，要進行回滾過程，釋放所有相關資源。從Undo空間中尋找到舊版本SCN的資料塊資訊，來進行SGA中Buffer Cache資料塊恢復。

4、說說恢復過程的損耗

很多時候，由於我們事務規模較大，當出現例項崩潰的時候，重啟所需要的時間很多。有一種經驗說法是，事務有多長，前滾和回滾所消耗的時間有多長×2。而且，如果不能完成SMON恢復過程，資料庫是不能算作正常的Open的。

SMON的恢復過程是Oracle強制進行的一個過程，即使恢復中發生斷電或者其他中斷失敗事件。Oracle在下一次啟動的時候，還是會繼續這個過程，只有耐心等待。

透過檢查一些內部檢視（X$檢視），可以觀察到恢復程式和速度，但是絲毫不能影響到最終恢復的過程。

這個過程雖然可以保證資料一致性，但是也帶來了系統不能啟動，影響生產環境的問題。我們可以透過兩個方式進行緩解：

首先，我們在設計開發系統時，要保證事務規模的可控性，不要讓事務規模在技術層面上過大。避免一旦發生崩潰，大規模強制回滾的發生；

其次，一旦出現了這個強制回滾，要注意對生產環境的影響。可以採用備庫standby進行頂替，讓主庫安靜的慢慢恢復；

官方文件地址：

Overview of Instance Recovery

Instance recovery is the process of applying records in the to data files to reconstruct changes made after the most recent . Instance recovery occurs automatically when an administrator attempts to open a database that was previously shut down inconsistently.

例項恢復概述

例項恢復是將聯機重做日誌中的記錄應用到資料檔案，以重建最近檢查點之後所做更改的過程。當管理員嘗試開啟一個之前以不一致方式關閉的資料庫時，會自動執行例項恢復。

				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  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  is committed,  writes both the remaining redo entries in memory and the transaction SCN to the . However, the 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 . 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. 
			
 See Also: 
					
								 and  
							
								"Introduction to Data Concurrency and Consistency"

						
							例項恢復的目的
						
							例項恢復可確保資料庫在一個例項失敗後仍能回到一個一致的狀態。由於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. 
					
 See Also: 
							
										 to learn about instance recovery in an Oracle RAC database

								
									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. 
							
								 depicts the redo thread in the online redo log. 
							
									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 , 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. 
							
 See Also: 
									
 to learn how to limit instance recovery time

										
											例項恢復檢查點的重要性 
										
											例項恢復使用檢查點來確定必須將哪些更改應用到資料檔案。檢查點位置始終保證所有比其SCN低的檢查點所對應的已提交更改都已儲存到資料檔案。 
										
											圖13-5描述了聯機重做日誌中的重做執行緒。 
										
											圖13-5聯機重做日誌中的檢查點位置 
										
											例項恢復期間，資料庫必須應用檢查點位置和重做執行緒結尾之間發生的更改。如圖13-5所示，某些更改可能已經寫入資料檔案。但是，只有其SCN低於檢查點位置的更改，才保證已被寫到了磁碟上。 
										
										Instance Recovery Phases 
									
										The first phase of instance recovery is called  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 . 
									
										 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 
										
										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. 
									
 See Also: 
											
														 to learn more about undo data 
													
														 for a discussion of instance recovery mechanics and tuning

例項恢復階段

例項恢復的第一階段稱為快取恢復或前滾，這涉及將聯機重做日誌中記錄的所有更改重新應用到資料檔案。因為回滾資料記錄在聯機重做日誌中，前滾也會重新生成相應的撤消段。

前滾會遍歷各個必要的聯機重做日誌，以將資料庫推進到一個更前的一致時間點。前滾之後，資料塊包含記錄在聯機重做日誌檔案中的所有已提交更改。這些檔案可能還包含未提交的更改，要麼是在例項失敗前儲存到資料檔案中的，或者是在快取恢復過程中引入的。

前滾之後，任何未提交的更改必須被撤消。oracle資料庫使用檢查點位置，保證每個低於其SCN的已提交更改都已儲存到磁碟。oracle資料庫應用撤消塊，以回滾資料塊中在例項失敗前寫入的或快取恢復過程中引入的未提交更改。這一階段稱為回滾或事務恢復。

圖 13-6 說明了前滾和回滾，這是恢復資料庫例項失敗的兩個必要步驟。

oracle資料庫可以根據需要同時回滾多個事務。例項失敗時的所有活動事務被標記為終止。新事務可以自己回滾個別塊以獲取所需的資料，而不必等待SMON程式來回滾這些已終止的事務。

3.8.1 例項恢復

對於單例項的系統，例項恢復一般是在資料庫例項異常故障後資料庫重啟時進行，當資料庫執行了SHUTDOWN ABORT或者由於作業系統、主機等原因當機重啟後，在執行ALTER DATABASE OPEN的時候，就會自動做例項恢復。而在RAC環境中，如果某個例項當機了，那麼剩下的例項將會代替宕掉的例項做例項恢復。除非是所有的例項都當機了，這樣的話，第一個執行ALTER DATABASE OPEN的例項將會做例項恢復。這也是在RAC環境中，REDO LOG是例項私有的元件，但是REDO LOG的檔案必須存放在共享儲存上的原因。

一、 RAC中的例項恢復

一個單例項資料庫或者RAC資料庫所有例項失敗之後，第一個開啟資料庫的例項會自動執行例項恢復。這種形式的例項恢復稱為Crash恢復。一個RAC資料庫的一部分但不是所有例項失敗後，在RAC中倖存的例項自動執行失敗例項的恢復稱為例項恢復。一般而言，在崩潰或關機退出之後第一個開啟資料庫的例項將自動執行崩潰恢復。

根據Crash恢復和例項恢復的不同，由倖存例項或者第一個重啟的例項讀取失敗例項生成的聯機Redo日誌和UNDO表空間資料，使用這些資訊確保只有已提交的事務被寫到資料庫中，回滾在失敗時候活動的事務，並釋放事務使用的資源。

														
																[ZFZHLHRDB1:oracle]:/oracle>crsctl stat res -t 
															
																-------------------------------------------------------------------------------- 
															
																NAME           TARGET  STATE        SERVER                   STATE_DETAILS       
															
																-------------------------------------------------------------------------------- 
															
																Local Resources 
															
																-------------------------------------------------------------------------------- 
															
																ora.DATA.dg 
															
																               ONLINE  ONLINE       zfzhlhrdb1                                   
															
																               ONLINE  ONLINE       zfzhlhrdb2                                   
															
																ora.LISTENER.lsnr 
															
																               ONLINE  ONLINE       zfzhlhrdb1                                   
															
																               ONLINE  ONLINE       zfzhlhrdb2                                   
															
																ora.LISTENER_LHRDG.lsnr 
															
																               ONLINE  ONLINE       zfzhlhrdb1                                   
															
																               ONLINE  ONLINE       zfzhlhrdb2                                   
															
																ora.asm 
															
																               ONLINE  ONLINE       zfzhlhrdb1               Started             
															
																               ONLINE  ONLINE       zfzhlhrdb2               Started             
															
																ora.gsd 
															
																               OFFLINE OFFLINE      zfzhlhrdb1                                   
															
																               OFFLINE OFFLINE      zfzhlhrdb2                                   
															
																ora.net1.network 
															
																               ONLINE  ONLINE       zfzhlhrdb1                                   
															
																               ONLINE  ONLINE       zfzhlhrdb2                                   
															
																ora.ons 
															
																               ONLINE  ONLINE       zfzhlhrdb1                                   
															
																               ONLINE  ONLINE       zfzhlhrdb2                                   
															
																ora.registry.acfs 
															
																               ONLINE  ONLINE       zfzhlhrdb1                                   
															
																               ONLINE  ONLINE       zfzhlhrdb2                                   
															
																-------------------------------------------------------------------------------- 
															
																Cluster Resources 
															
																-------------------------------------------------------------------------------- 
															
																ora.LISTENER_SCAN1.lsnr 
															
																      1        ONLINE  ONLINE       zfzhlhrdb1                                   
															
																ora.cvu 
															
																      1        ONLINE  ONLINE       zfzhlhrdb1                                   
															
																ora.lhrdb.db 
															
																      1        ONLINE  ONLINE       zfzhlhrdb1               Open                
															
																ora.oc4j 
															
																      1        ONLINE  ONLINE       zfzhlhrdb1                                   
															
																ora.raclhr.db 
															
																      1        ONLINE  ONLINE       zfzhlhrdb2               Open                
															
																      2        ONLINE  ONLINE       zfzhlhrdb1               Open                
															
																ora.scan1.vip 
															
																      1        ONLINE  ONLINE       zfzhlhrdb1                                   
															
																ora.zfzhlhrdb1.vip 
															
																      1        ONLINE  ONLINE       zfzhlhrdb1                                   
															
																ora.zfzhlhrdb2.vip 
															
																      1        ONLINE  ONLINE       zfzhlhrdb2                                   
															
																[ZFZHLHRDB1:oracle]:/oracle>srvctl stop instance -d raclhr -i raclhr1 -o abort 
															
																[ZFZHLHRDB1:oracle]:/oracle>srvctl status db -d raclhr 
															
																Instance raclhr1 is not running on node zfzhlhrdb1 
															
																Instance raclhr2 is running on node zfzhlhrdb2

abort掉例項1後：

例項一的告警日誌：

														
																Thu Oct 13 15:51:30 2016 
															
																Shutting down instance (abort) 
															
																License high water mark = 60 
															
																USER (ospid: 4194780): terminating the instance 
															
																Instance terminated by USER, pid = 4194780 
															
																Thu Oct 13 15:51:32 2016 
															
																Instance shutdown complete

例項二的告警日誌：

														
																Thu Oct 13 15:51:31 2016 
															
																Reconfiguration started (old inc 4, new inc 6) 
															
																List of instances: 
															
																2 (myinst: 2) 
															
																Global Resource Directory frozen 
															
																* dead instance detected - domain 0 invalid = TRUE 
															
																Communication channels reestablished 
															
																Master broadcasted resource hash value bitmaps 
															
																Non-local Process blocks cleaned out 
															
																Thu Oct 13 15:51:31 2016 
															
																LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived 
															
																Thu Oct 13 15:51:31 2016 
															
																LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived 
															
																Set master node info 
															
																Submitted all remote-enqueue requests 
															
																Dwn-cvts replayed, VALBLKs dubious 
															
																All grantable enqueues granted 
															
																Post SMON to start 1st pass IR 
															
																Thu Oct 13 15:51:31 2016 
															
																Instance recovery: looking for dead threads 
															
																Submitted all GCS remote-cache requests 
															
																Post SMON to start 1st pass IR 
															
																Fix write in gcs resources 
															
																Reconfiguration complete 
															
																Beginning instance recovery of 1 threads 
															
																parallel recovery started with 7 processes 
															
																Started redo scan 
															
																Completed redo scan 
															
																read 18 KB redo, 14 data blocks need recovery 
															
																Started redo application at 
															
																Thread 1: logseq 235, block 68352 
															
																Recovery of Online Redo Log: Thread 1 Group 1 Seq 235 Reading mem 0 
															
																  Mem# 0: +DATA/raclhr/onlinelog/group_1.362.916601361 
															
																  Mem# 1: +DATA/raclhr/onlinelog/group_1.361.916601361 
															
																Completed redo application of 0.01MB 
															
																Completed instance recovery at 
															
																Thread 1: logseq 235, block 68389, scn 9725527 
															
																14 data blocks read, 14 data blocks written, 18 redo k-bytes read 
															
																Thu Oct 13 15:51:33 2016 
															
																minact-scn: Inst 2 is now the master inc#:6 mmon proc-id:25100420 status:0x7 
															
																minact-scn status: grec-scn:0x0000.00000000 gmin-scn:0x0000.009417d9 gcalc-scn:0x0000.009417e3 
															
																minact-scn: master found reconf/inst-rec before recscn scan old-inc#:6 new-inc#:6 
															
																Thread 1 advanced to log sequence 236 (thread recovery) 
															
																Redo thread 1 internally disabled at seq 236 (SMON) 
															
																Thu Oct 13 15:51:34 2016 
															
																Thread 2 advanced to log sequence 265 (LGWR switch) 
															
																  Current log# 4 seq# 265 mem# 0: +DATA/raclhr/onlinelog/group_4.349.916601715 
															
																  Current log# 4 seq# 265 mem# 1: +DATA/raclhr/onlinelog/group_4.348.916601715 
															
																Thu Oct 13 15:51:35 2016 
															
																Archived Log entry 493 added for thread 1 sequence 235 ID 0x441b1480 dest 1: 
															
																Thu Oct 13 15:51:35 2016 
															
																ARC0: Archiving disabled thread 1 sequence 236 
															
																Archived Log entry 494 added for thread 1 sequence 236 ID 0x441b1480 dest 1: 
															
																Thu Oct 13 15:51:35 2016 
															
																Archived Log entry 495 added for thread 2 sequence 264 ID 0x441b1480 dest 1: 
															
																minact-scn: master continuing after IR

About Me

...............................................................................................................................

● 本文整理自網路

● 本文在itpub（http://blog.itpub.net/26736162）、部落格園（http://www.cnblogs.com/lhrbest）和個人微信公眾號（xiaomaimiaolhr）上有同步更新

● 本文itpub地址：http://blog.itpub.net/26736162/abstract/1/

● 本文部落格園地址：http://www.cnblogs.com/lhrbest

● 本文pdf版及小麥苗雲盤地址：http://blog.itpub.net/26736162/viewspace-1624453/

● 資料庫筆試面試題庫及解答：http://blog.itpub.net/26736162/viewspace-2134706/

● QQ群：230161599 微信群：私聊

● 聯絡我請加QQ好友(646634621)，註明新增緣由

● 於 2017-06-02 09:00 ~ 2017-06-30 22:00 在魔都完成

● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解

● 版權所有，歡迎分享本文，轉載請保留出處

...............................................................................................................................

拿起手機使用微信客戶端掃描下邊的左邊圖片來關注小麥苗的微信公眾號：xiaomaimiaolhr，掃描右邊的二維碼加入小麥苗的QQ群，學習最實用的資料庫技術。

例項恢復（Instance Recovery）之前滾（Rolling Forward）和回滾（Rolling Back）

Oracle例項恢復（Instance Recovery）之前滾（Rolling Forward）和回滾（Rolling Back）

Overview of Instance Recovery

Purpose of Instance Recovery

When Oracle Database Performs Instance Recovery

Importance of Checkpoints for Instance Recovery

Instance Recovery Phases

3.8.1 例項恢復

相關文章