Oracle例項恢復

oracle例項恢復原理

首先從事物說起，當執行update開啟乙個事物的時候，首先需要在buffer cache中找到可用的塊（block）更新資料，然後構造cr塊，將update之前的資料放入到undo中，同時會在log buffer內寫日誌，log buffer內資料每隔3秒通過lgwr程序將往redo log寫日誌，在這個過程更改的資料還在記憶體中，產生髒資料，直到dbwr程序將髒資料寫入到磁碟，如果髒資料還未寫入磁碟，髒資料中包括提交或未提交的，這個時候由於掉掉或其他原因導致資料庫意外宕機，主機恢復後重啟資料庫，oracle會由smon程序自動進行例項恢復為什麼會發生例項恢復，這得提到oracle的scn，在oracle中存在4個scn，system scn，datafile scn，結束scn和datafile header scn，在oracle正常關閉的情況下，資料庫會產生完全檢查點，會通過dbwr程序將髒塊寫到磁碟，更新著4個scn值相同，在非正常關閉的情況下，當資料庫啟動到mount狀態時，oracle會發現last scn並不是等於其它3個scn，而是等於null，這表示oracle在shutdown時沒有進行checkpoint，下次開機必須進行crash recovery（例項恢復）。 oracle的scn什麼時候會發生變化，上述在log buffer內寫日誌的時候，會產生增量檢查點，增量檢查點並不會去更新資料檔案頭，以及控制檔案中資料庫scn以及資料檔案條目的scn資訊，而只是每3秒由ckpt程序去更新控制檔案中的low cache rba資訊（rba含義redo block adress），也就是檢查點的位置。系統scn、資料檔案scn、資料檔案頭部scn的值真正發生變化的時候是在redo檔案由active變為inactive時，才會更新，這3個值等於active, current中最老的乙個日誌檔案的頭部的first scn，（redo日誌檔案各狀態解釋：current表示當前正在使用的日誌檔案，active表示日誌檔案中對應的髒塊還沒有寫到磁碟中，而inactive則表示日誌檔案中對應的所有髒塊都寫到了磁碟）

oracle例項恢復的起點與終點，以實驗為例說明：

1、首先在測試資料庫建立測試資料提交，在buffer cache產生髒塊

create table test（id number,name varchar2(22)）

insert into test values(1,'hh')

commit

2、做一次控制檔案轉儲

sql> alter session set events 'immediate trace name controlf level 12';

session altered.

3、非正常關閉資料庫

shutdown abort

4、啟動資料庫，做一次控制檔案轉儲

sql> alter session set events 'immediate trace name controlf level 12';

session altered.

5，檢查對比兩次轉儲檔案內容

第一次轉儲資訊：

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)

04/06/2017 23:27:11

db name "tss"

database flags = 0x50404001 0x00001200

controlfile creation timestamp 04/06/2017 23:27:11

incmplt recovery scn: 0x0000.00000000

resetlogs scn: 0x0000.00000001 resetlogs timestamp 04/06/2017 23:27:11

prior resetlogs scn: 0x0000.00000000 prior resetlogs timestamp 01/01/1988 00:00:00

redo version: compatible=0xb200400

#data files = 8, #online files = 8

database checkpoint: thread=1 scn: 0x0000.0022eb8b

threads: #enabled=1, #open=1, head=1, tail=1

可知這時資料庫的檢查點scn： 0x0000.0022eb8b，轉化為10進製：2288523

sql> select to_number('22eb8b','******xx') from dual;

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:65

low cache rba:(0x76.ab2.0) on disk rba:(0x76.b43.0)

on disk scn: 0x0000.0022f1cd 10/27/2017 15:17:00

resetlogs scn: 0x0000.00000001 04/06/2017 23:27:11

heartbeat: 958525302 mount id: 2083188020

檢查點程序資訊記錄了low cache rba及on disk rba的值

low cache rba含**釋：0x76表示sequence號，ab2表示塊號，on disk rba內值含義相同

所以此時low cache rba對應的sequence為118 ，block號為2738，on disk rba對應的sequence為118 ，block號為2883

資料庫啟動後轉儲的控制檔案資訊

* 2017-10-27 15:18:08.577

* session id:(16.3) 2017-10-27 15:18:08.577

* client id:() 2017-10-27 15:18:08.577

* service name:() 2017-10-27 15:18:08.577

* module name:(sqlplus@single (tns v1-v3)) 2017-10-27 15:18:08.577

* action name:() 2017-10-27 15:18:08.577

thread 1 checkpoint: logseq 118, block 2, scn 2288523

cache-low rba: logseq 118, block 2738

on-disk rba: logseq 118, block 2884, scn 2290131

start recovery at logseq 118, block 2738, scn 0

從上述alert log我們可以知道，oracle做instance recovery的起點是logseq 118, block 2738；終點是logseq 118, block 2884 從第一次控制檔案的dump檔案我們可以看到控制檔案裡記錄的low cache rba是(0x76.ab2.0，轉換過來就是low cache rba的logfile sequence是118，logfile block number是2738。」這和alert log裡記錄的instance recovery的起點一致，即instance recovery的起點就是low cache rba；

資料庫啟動後控制檔案的dump檔案資訊記錄的on-disk rba的 logseq 118, block 2884，與alert日誌completed crash recovery恢復記錄的logseq 118, block 2884一致，即instance recovery的終點就是on-disk rba

Oracle例項恢復

Oracle例項恢復

Oracle 例項恢復詳解 MTTR

（2010 07 14）Oracle例項恢復詳解

Oracle例項恢復

Oracle例項恢復

Oracle 例項恢復詳解 MTTR

（2010 07 14）Oracle例項恢復詳解

相關推薦