low cache rba,on disk rba資料庫恢復過程

low cache rba

　　就是CKPT記錄的DBWR寫出的進度,也就是更新到控制檔案和資料檔案的進度記錄,對於增量檢查點，因為我們都知道,當checkpoint發生的時候，ckpt程式會通知dbwn程式去寫出dirty buffer,但是需要特別注意的是ckpt程式通知dbwn程式後，並不需要等待dbwn寫到當前觸發檢查點那個時候的scn後，再去更新當前控制檔案和資料檔案的scn(當然ckpt是有心跳的，通過心跳ckpt程式可以監視dbwn寫的進度)，而是將當前剛剛寫完的dirty buffer(寫多少算多少，寫完那個算那個)對應的scn更新到資料檔案和控制檔案當中，我們都知道修改的data buffer會被移動到checkpoint queue中，當然這個dirty buffer是在checkpoint queue中按照low rba的先進先出的順序寫出的，無論後來對這個buffer做了多少次修改，他在queue中的寫出順序是不會被改變的。那麼每3秒鐘，ckpt還會去更新控制檔案和資料檔案的heartbeat值。那麼實際上每隔3秒,也會觸發檢查點，但是，這樣的操作並沒有被oracle正式作為一種檢查點的觸發方式列入文件 ,因為這個3秒記錄的是dbwr的寫的進度而不是通知讓dbwr去寫出。

　　on disk rba就是LGWR的寫進度

　　如果資料庫carsh了，low cache rba是恢復的起點，on disk rba是恢復的終點。

　　分析：

　　dbwr成功寫完後並不會把當前的此刻scn資訊寫到控制檔案中，只有CKPT才更新控制檔案和資料檔案頭，dbwr只要成功將dirty data寫入資料檔案就是成功， CKPT只要能將最新DBWR寫完的SCN更新到控制檔案和資料檔案頭就算成功。但是由於CKPT程式不是實時更新dbwr寫完的scn到控制檔案中，而是採用每3妙更新一次的策略，因此最後有ckpt程式寫進控制檔案的scn資訊有可能不是當前dbwr剛剛寫完的scn值。這點應該注意，也就是說dbwr寫的進度與ckpt程式更新控制檔案的進度是不同的。

 

異常關閉資料庫

shutdown abort; startup mount;

轉儲控制檔案

alter session set events 'immediate trace name controlf level 12'; alter database open;

***************************************************************************

DATABASE ENTRY

***************************************************************************

 (size = 316, compat size = 316, section max = 1, section in-use = 1,

  last-recid= 0, old-recno = 0, last-recno = 0)

 (extent = 1, blkno = 1, numrecs = 1)

 07/31/2010 16:35:48

 DB Name "ENMO"

 Database flags = 0x00404000 0x00001000

 Controlfile Creation Timestamp  07/31/2010 16:35:49

 Incmplt recovery scn: 0x0000.00000000

 Resetlogs scn: 0x0000.00089c75 Resetlogs Timestamp  07/31/2010 16:35:52

 Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp  03/14/2008 18:46:22

 Redo Version: compatible=0xa200300

 #Data files = 4, #Online files = 4

 Database checkpoint: Thread=1 scn: 0x0000.00119459

 Threads: #Enabled=1, #Open=1, Head=1, Tail=1

此時記錄資料庫的檢查點SCN是119459，這是16進位制，10進位制是1152089。

 

繼續檢查，在檢查點程式記錄部分，獲得如下資訊，這裡就包含了Low Cache RBA和On Disk RBA的資訊，也記錄了Dirty Buffer的數量是48：

***************************************************************************

CHECKPOINT PROGRESS RECORDS

***************************************************************************

 (size = 8180, compat size = 8180, section max = 11, section in-use = 0,

  last-recid= 0, old-recno = 0, last-recno = 0)

 (extent = 1, blkno = 2, numrecs = 11)

THREAD #1 - status:0x2 flags:0x0 dirty:48

low cache rba:(0x27.6c.0) on disk rba:(0x27.f9.0)

on disk scn: 0x0000.001195a5 09/10/2010 14:55:25

resetlogs scn: 0x0000.00089c75 07/31/2010 16:35:52

heartbeat: 729376761 mount id: 570757625

把這裡的RBA資訊簡單分析一下：

	RBA資訊	Log Sequence	Blcok Number
Low Cache RBA	0x27.6c.0	0x27 = 39	6c=108
On Disk RBA	0x27.f9.0	0x27=39	F9=249

 

在啟動資料庫時，進行恢復產生了一個跟蹤檔案，記錄了恢復的過程，恢復從39號日誌檔案的第108塊恢復至249塊，正是以上資料庫關閉之前的RBA地址範圍：

*** SESSION ID:(158.4) 2010-09-10 14:56:11.738

Successfully allocated 2 recovery slaves

Using 545 overflow buffers per recovery slave

Thread 1 checkpoint: logseq 39, block 2, scn 1152089

  cache-low rba: logseq 39, block 108

    on-disk rba: logseq 39, block 249, scn 1152421

  start recovery at logseq 39, block 108, scn 0

----- Redo read statistics for thread 1 -----

Read rate (ASYNC): 70Kb in 0.20s => 0.34 Mb/sec

Total physical reads: 4096Kb

Longest record: 8Kb, moves: 0/243 (0%)

Change moves: 2/29 (6%), moved: 0Mb

Longest LWN: 53Kb, moves: 0/6 (0%), moved: 0Mb

Last redo scn: 0x0000.001195a4 (1152420)

----------------------------------------------

資料庫恢復的檢查點起點是SCN 1152089，也就是控制檔案中記錄的資料庫最後完成的檢查點，On-Disk RBA的SCN是1152421，轉換為16進位制也就是1195A5，也和控制檔案中記錄的On Disk SCN完全相符。

資料庫的恢復SCN範圍也就由此確定，即SCN範圍：1152089~1152241。

 

啟動資料庫之後，查詢一下日誌資訊，可以看到39號日誌檔案正是執行恢復的日誌檔案，其SCN範圍處於1152088和1172422之間，一個日誌就滿足了之前恢復的SCN範圍，恢復完成之後日誌切換，當前使用了40號日誌：

SQL> select * from v$log;

 

GROUP# THREAD#  SEQUENCE#    BYTES MEMBERS ARC STATUS   FIRST_CHANGE# FIRST_TIME

------ ------- ---------- -------- ------- --- -------- ------------- ------------

     1       1         40 52428800       1 NO  CURRENT        1172422 10-SEP-10

     2       1         38 52428800       1 NO  INACTIVE       1131823 10-SEP-10

     3       1         39 52428800       1 NO  INACTIVE       1152088 10-SEP-10

 

至此我們清晰地看到了資料庫恢復從Low Cache RBA至On Disk RBA的過程。

         注意到Oracle在恢復過程中，首先讀取日誌，從最後完成的檢查點開始，應用所有的重做記錄，這個過程叫前滾（rolling forward）,也就是crash recovery過程，完成前滾之後，資料庫可以被開啟並提供訪問和使用。

         此後進入例項恢復的第二個階段，Oracle回滾未提交事務。Oracle使用兩個特點來增加這個恢復階段的效率，這兩個特點是fast-start on-demand rollback和fast-start parallel rollback（這些特點是fast-start fault recovery的組成部分，僅在oracle8i之後的企業版中可用）。

        使用fast-start on-demand rollback特點，Oracle自動允許在資料庫開啟之後開始新的事務，這通常只需要很短的crash recovery時間。如果一個使用者檢視訪問被異常終止程式鎖定的記錄，Oracle回滾哪些新事務請求的記錄，也就是說，因需求而回滾。因而，新事務不需要等待漫長的事務回滾時間。在fast-start on-demand rollback中，後臺程式SMON充當一個排程員，使用多個伺服器程式並行回敬一個事務集。

         fast-start parallel rollback主要對於長時間執行的未提交事務有效，尤其是並行insert,update和delete等操作。SMON自動決定何時開始並行回滾並且自動在多個程式之間分散工作。

         fast-start parallel rollback的一個特殊形式是內部事務恢復（intra-transaction recovery）。在內部事務恢復中，一個大的事務可以被拆分，分配給幾個伺服器程式並行回滾。可以通過初始化引數fast_satrt_parallel_rollback來控制並行回滾，改引數有3個引數值。

        false:禁用fast-start parallel rollback.

       low:限制恢復程式不能超過2倍的cpu_count.

        high:限制恢復程式不能超過4倍的cpu_count.

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23071790/viewspace-691263/，如需轉載，請註明出處，否則將追究法律責任。