oracle介質恢復和實例恢復總結

前幾天解決一個控制文件版本過舊的問題，由此引發我對oracle恢復的諸多思考。

1、控制文件恢復，這中間到底做了哪些事情？

2、recover database在什么時候使用，后面的參數又有什么意義？

3、介質恢復和實例恢復的區別是什么，恢復過程又是怎樣的？

4、oracle 的redo中到底記錄了哪些東西？

5、為什么要用alter database open resetlogs？

6、控制文件中幾個scn號之間的關系呢？

7、oracle判斷控制文件過舊的機制？

8、RBA是什么時候產生的？

9、增量檢查點和完全檢查點區別？

10、........

各種SCN概念介紹

在說明這些個問題之前，先說一下oracle實例恢復和介質恢復吧。我們知道oracle的啟動分為3個階段，那么在open階段需要進行一致性檢查（當然也可以繞過）。在一致性檢查中涉及到4個scn號，分別是：

①系統SCN：system checkpoint SCN，系統每發生一次checkpoint，就會把current_scn更新到系統全局scn；

②控制文件記錄的數據文件頭SCN：控制文件中記錄的數據文件頭的scn號 ；

③數據文件自己頭部的SCN（start SCN）：指的是數據文件物理意義上的scn號

④控制文件中記錄的數據文件結束SCN，即end SCN：在oracle正常運行時，這個值為空，而在控制文件中記錄的這個值是無窮大（16進制:0xfffffffff...）；在oracle正常關閉時，會把current_scn更新到end SCN。所以當oracle非正常關閉時，這個end SCN是來不及更新的，再次啟動數據時會發現控制文件中記錄的這個值是無窮大。

在數據文件頭和控制文件中都記錄著完全檢查點計數checkpoint cnt，每發生一次完全檢查點，這個值加1。cnt的遞增和scn的更新是在完全檢查點發生的，下面會說到full checkpoint。

介質恢復和實例恢復的區別是什么，恢復過程又是怎樣的？

所謂實例恢復又叫做崩潰恢復。數據庫在突然崩潰的那一剎那，可能會發生已經提交的數據沒有寫入到磁盤，可能沒有提交的數據已經寫入到磁盤。那么這些數據都是不正常的，要保證一致性，就要對這些數據進行恢復。實例恢復是由smon進程完成的，不需要人為操作。

①已經提交的數據沒有寫入到磁盤，需要前滾

更改的操作已經提交了，那么其對應的數據塊的修改過程必然寫入到redo，重做即可。問題是哪些redo需要重做呢？上面說到在每一次ckpt rba之前的日志信息對應的臟數據是一定會被寫入到磁盤的，在次之后的日志信息對應的臟數據是沒有寫入到磁盤的。那么我們的恢復就是最后一次的checkpoint RBA到最后一次日志寫入磁盤的on_disk rba這之間的redo。這兩個rba在控制文件中都有記錄。

②沒有提交的數據已經寫入到磁盤，需要回滾

上面已經說到，如何找到需要回復的redo，在這段redo中存在著事物對數據修改的undo信息，拿到這段undo信息恢復即可。

當你發現你的數據文件是備份的，那么從數據文件備份那一刻到當前數據庫這段期間的數據改變都會丟失，此時便需要介質恢復。此時就不能用rba信息來確定需要的redo了，而是以當前數據文件頭的scn開始，到當前redo最新的scn為結束點，找到這段redo重做即可，也有可能會用到歸檔。（之前和同事討論是不是以當前數據文件頭的scn為開始點，我的想法是在這個scn之前產生的所有redo是否都已經體現在數據文件中了？）

控制文件中幾個scn號之間的關系呢？

在數據庫open的過程中,Oracle要進行兩次檢查 (實際情況要復雜很多，這里只是簡要說明。也許只有Oracle的開發人員才知道到底要做哪些事情～～～).

第一次檢查數據文件頭中的Checkpoint cnt是否與對應控制文件中的Checkpoint cnt一致.

如果相等 (注：其實如果相等，則System Checkpoint SCN = Datafile Checkpoint SCN = Start SCN，當然只讀表空間除外), 進行第二次檢查.

第二次檢查數據文件頭的開始SCN和對應控制文件中的結束SCN是否一致

如果結束SCN等于開始SCN,則不需要對那個文件進行恢復 (注：如果不等，即Stop SCN為無窮大，則需要Istance Recovery).

(編者注：這里的open過程的說法和我前面轉載的關于SCN的文章不盡相同，但是我個人理解第一次就是做是否需要Media Recovery的檢查；第二次就是做是否需要做Instance Recovery的檢查。第一步如果文件版本不一致，就開始做Media Recover，根據相應的SCN確定需要的log；如果不需要Media Recovery，則檢查是否需要Instance Recovery，如果Stop SCN的值為無窮大，則需要，而且要提交redo logs直到最新的那一個)

RBA是什么時候產生的？

當database buffer cache里的1個buffer 被修改時, 也就是被變臟時就會產生日志, 而這些日志為被寫入到Log buffer cache(日志緩存里), ?那么這些日志在日志緩存里的位置就是RBA了.而臟buffer會把對把對應的RBA記錄在自己的頭部信息中, 當這個臟buffer要被回滾時, server process就可以根據RBA找到對應的日志了。而1個buffer的RBA并不是唯一的。由于1個buffer可以在不同的時間段被多次修改, 就會產生多次日志, 而這些日志會被寫入到log buffer cache中的不同的位置。所以往往1個buffer里面記錄著多個RBA。

增量檢查點和完全檢查點

首先讓我們先來總結一下用戶修改塊時，Oracle內部都發生了什么：

1、如果塊不在Buffer cache，將塊讀入Buffer cache

2、先生成重做記錄，并記入日志緩存，在用戶提交時寫到日志文件中

3、在Buffer cache中修改塊

4、在Buffer cache中設置塊的臟標志位，標志塊變成臟塊，同時在檢查點隊列末尾增加一個新節點，記錄這個新臟塊的信息，信息包括：臟塊在Buffer cache中的位置，在步驟2時生成的與此臟塊對應的重做記錄位置。

5、用戶提交后，將相應的重做記錄從重做緩存寫入日志文件。

在8i之前，Oracle定期的鎖住所有的修改操作，刷新Buffer cache中的所有臟塊，這種刷新臟塊的方式被稱為完全檢查點，這極大的影響了效率。

完全檢查點工作方式是先記下當前的scn, 將此scn之前所有的臟塊一次性寫完，再將該scn號同步更新控制文件和數據文件頭。在8i之后只有以下兩種情況會發生完全檢查點：

1、手工執行alter system checkpoint的命令；

2、數據庫正常shutdown (immediate,transcational,normal)。

所謂增量檢查點說白了，就是

1、CKPT每3秒一次的檢查DBWn寫進度并在控制文件中記錄檢查點位置(checkpoint position)和更新heartbeat信息

2、CKPT定期觸發DBWn去寫checkpoint queue中的臟數據

日志切換觸發的是normal checkpoint，而不是大家所說的增量checkpoint，只不過log switch checkpoint的優先級非常低，當一個log switch checkpoint發生的時候它并不會立即的通知DBWn進程去寫數據文件，但是當有其它原因導致checkpoint或者是寫入數據文件的RBA超過log switch checkpoint的checkpoint RBA的時候，這次的log switch checkpoint將會被標記成完成狀態，同時更新控制文件和數據文件頭。

觸發dbwr的條件不只是ckpt，所以ckpt必須要每個3秒去檢查dbwn寫進度，然后把檢查點位置更新到控制文件。那么控制文件會認為在這個檢查點位置之前的所有redo都已經體現到數據文件。在oracle正常運行時，你會發現發生的都是增量檢查點進程，除非人為操作。而且在轉儲的數據文件頭和控制文件的trace中，相關scn信息是不會變化的。

Oracle 從8i開始引入了檢查點隊列(checkpoint queue)的概念，用于記錄數據庫里面當前所有的dirty buffer的信息，這些dirty buffer的信息按被修改的時間先后存放在checkpoint queue里面(當塊首次被更改時，塊會立即被加進檢查點隊列)，所涉及的條目主要包含RBA (Redo Block Address，重做日志里面用于標識事務期間數據塊在重做日志里面發生更改的編號)和數據塊的數據文件號和塊號。

不論數據塊(buffer)更改幾次，它在checkpoint queue里面的位置始終保持不變，checkpoint queue也只會記錄它最早的RBA(這個最早的RBA其實就是Low RBA，也就是數據塊第一次被修改時所對應的RBA)，從而保證最早更改的數據塊能夠盡快從內存寫入數據文件。DBWR每到一定的時機，就會被觸發 (DBWn并不是只有當檢查點發生的時候才寫，它大約有10幾種條件觸發寫操作)，沿著檢查點隊列的順序刷新臟塊，同時CKPT進程，會監控著檢查點隊列 的長度，當檢查點隊列的長度達到一定限制時(具體有幾個參數來確定checkpoing queue的長度，下面會提到比如log_checkpoint_timeout,fast_start_mttr_target等)，CKPT會通知 DBWR寫臟塊。CKPT會根據幾個參數的設置和I/O的速度以及繁忙程度，計算出來一個Target rba(目標rba)，DBWn會沿著檢查點隊列，按照dirty buffer的Low RBA順序將所有Target rba之前對應的臟塊從內存寫入數據磁盤文件。當CKPT通知完DBWn Target rba后，CKPT的任務就結束了。他并不會等待DBWn寫完所有的Target rba之前的臟塊。因此這里CKPT只是起到了一個通知DBWn進程寫入的作用。

當完全檢查點發 生的時候，Oracle一方面通知DBWn進行下一批寫操作，另一方面是將這個觸發檢查點時刻DBWn當前剛寫完dirty buffer對應的SCN寫入數據文件頭和控制文件，這個SCN就是checkpoint scn。但Oracle考慮到檢查點SCN的間隔還是太大了，因為檢查點的觸發條件有限，周期可能比較長，有些情況下比如檢查點需要5分鐘左右才觸發，那 這個時候系統crash再重新啟動就意味著很可能系統需要5分鐘左右才能啟動。于是Oracle采用了一個heartbeat的概念，以3秒的頻率將 DBWn寫的進度反應到控制文件中，這樣系統crash重新啟動的時候將從更近的一個時間點開始恢復。Oracle這么做的目的就是要縮短崩潰恢復時間！ 因此CKPT另外一個任務就是每3秒，檢測一次DBWn的寫進度。DBWn 是沿著檢查點隊列寫臟塊，由于這里有一個順序的關系，所以DBWn的寫的進度就是可衡量的，寫到哪個buffer的時候該buffer的首次變化時候的 scn(對應了LRba)就是當前所有數據文件block的上面最新scn，但是由于無法適時的將DBWn的進度記錄下來，所以Oracle選擇了一些策 略。 其中就包括CKPT進程的檢查點位置更新和心跳，所以說CKPT每3秒鐘查看一下DBWn沿檢查點隊列寫到了哪里,并且將這個位置設置為檢查點位置 (checkpont position)。也就是說檢查點位置之前的塊，都是已被DBWn刷新到磁盤上的塊。因此我們可以理解為，CKPT進程每3秒會根據DBWn寫的進度設置并記錄一個檢查點位置，也就是說這個檢查點位置就是由DBWn的在往Target RBA寫過程中的進度決定的(如果沒有dirty buffer產生，那么就不會更新檢查點位置信息)。因 此CKPT每3秒會將檢查點位置對應的數據塊的rba (low cache rba-表示Instance Recovery時開始恢復的日志條目)更新和記錄到控制文件的CHECKPOINT PROGRESS RECORDS區域，當然同時被記錄進控制文件的還有heartbeat等其他信息。DBWn將檢查點隊列里面的dirty buffer寫入到數據文件后，檢查點的位置也要相應地往后移。

檢查點位置(checkpoint position)實際上就可以直接理解為是一個rba，他指向著重做日志文件中的某條重做記錄。在此檢查點位置前的重做記錄，其對應的buffer cache中的dirty buffer已經被寫進了數據文件，在此位置后的重做記錄，所對應數據臟塊有可能還在內存中。如果發生了實例崩潰，只需要在日志文件中找到檢查點位置 (low cache rba)，從此處開始應用所有的重做日志文件，就完成了前滾操作。實例崩潰后，再次啟動數據庫，oracle會到控制文件中讀取low cache rba，這就是檢查點位置。從此處開始應用重做日志，應用到on disk rba的位置。 on disk rba是磁盤中重做日志文件的最后一條重做記錄的rba。 如 果某條重做記錄的rba高于on disk rba，那說明此重做記錄還沒有被寫進日志文件中，崩潰發生時，他是不可能被恢復的。on dis k rba是oracle前滾操作的終點。比這個更高的rba，都應該還駐留在log buffer中。還沒有被LGWR寫入日志文件。所以是不能被用于恢復的。

在DBWn寫dirty buffer這個檢查點過程中，Oracle也可以繼續產生dirty buffer，DBWn也不是一次要把所有dirty buffer全部寫到磁盤(不同于完全檢查點的地方)，這樣就提高了檢查點的效率，使得數據庫要做恢復的時候從這個最新位置開始做恢復，而不是從數據文件 中的checkpoint scn(上一個完全檢查點位置) 開始做恢復，這樣將縮短恢復時間。

EI企業智能 可信智能計算服務 TICS 數據湖治理中心 DGC 智能數據

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。