(轉)SCN號與oracle資料庫恢復的關係

tonyzhou_cn發表於2012-06-23
SCN號與oracle資料庫恢復的關係
SCN號與oracle資料庫恢復過程有著密切的關係,只有很好地理解了這層關係,才能深刻地理解恢復的原理,從而才能很好地解決這方面的問題。
SCN與CHECKPOINT
CKPT程式在checkpoint發生時,將當時的SCN號寫入資料檔案頭和控制檔案,同時通知DBWR程式將資料塊寫到資料檔案。
CKPT程式也會在控制檔案中記錄RBA(redo byte address),以標誌Recovery需要從日誌中哪個地方開始。與checkpoint相關的SCN號有四個,其中三個存在控制檔案中,一個存放在資料檔案頭中。
這四個分別是:
1.System Checkpoint SCN
當checkpoint完成後,ORACLE將System Checkpoint SCN號存放在控制檔案中。我們可以透過下面SQL語句查詢:
select checkpoint_change# from v$database;
2.Datafile Checkpoint SCN
當checkpoint完成後,ORACLE將Datafile Checkpoint SCN號存放在控制檔案中。我們可以透過下面SQL語句查詢所有資料檔案的Datafile Checkpoinnt SCN號。
select name,checkpoint_change# from v$datafile;
3.Start SCN號
ORACLE將Start SCN號存放在資料檔案頭中。
這個SCN用於檢查資料庫啟動過程是否需要做Media Recovery.
我們可以透過以下SQL語句查詢:
select name,checkpoint_change# from v$datafile_header;
4.End SCN (Stop SCN)號
ORACLE將End SCN號存放在控制檔案中。
這個SCN號用於檢查資料庫啟動過程是否需要做Instance Recovery.
我們可以透過以下SQL語句查詢:
select name,last_change# from v$datafile;
在資料庫正常執行的情況下,對可讀寫的,online的資料檔案,該SCN號為NULL.
我們作個小的試驗,內容如下:
在執行檢查點程式之前SCN號如下:
System Checkpoint SCN 4609061
--select checkpoint_change# from v$database;
Datafile Checkpoint SCN 4609061
--select name,checkpoint_change# from v$datafile;
Start SCN 4609061
--select name,checkpoint_change# from v$datafile_header;
End SCN空
--select name,last_change# from v$datafile;
執行alter system checkpoint。後的SCN號如下:
System Checkpoint SCN 4609630
--select checkpoint_change# from v$database;
Datafile Checkpoint SCN 4609630
--select name,checkpoint_change# from v$datafile;
Start SCN 4609630
--select name,checkpoint_change# from v$datafile_header;
End SCN null
--select name,last_change# from v$datafile;
SCN不連續原因可能如下:
1.當發生日誌組切換的時候
2.當符合LOG_CHECKPOINT_TIMEOUT,LOG_CHECKPOINT_INTERVAL,fast_start_io_target,fast_start_mttr_target引數設定的時候
3.當執行ALTER SYSTEM SWITCH LOGFILE的時候
4.當執行ALTER SYSTEM CHECKPOINT的時候
5.當執行alter tablespace XXX begin backup,end backup的時候
6.當執行alter tablespace ,datafile offline的時候;
SCN號與資料庫啟動
在資料庫啟動過程中,當System Checkpoint SCN、Datafile Checkpoint SCN和Start SCN號都相同時,資料庫可以正常啟動,不需要做media recovery.三者當中有一個不同時,則需要做media recovery。如果在啟動的過程中,End SCN號為NULL,則需要做instance recovery。ORACLE在啟動過程中首先檢查是否需要media recovery,然後再檢查是否需要instance recovery。
SCN號與資料庫關閉
如果資料庫的正常關閉的話,將會觸發一個checkpoint,同時將資料檔案的END SCN號設定為相應資料檔案的Start SCN號。
當資料庫啟動時,發現它們是一致的,則不需要做instance recovery。在資料庫正常啟動後,ORACLE會將END SCN號設定為NULL。如果資料庫異常關閉的話,則END SCN號將為NULL.
為什麼需要System checkpoint SCN號與Datafile Checkpoint SCN號
為什麼ORACLE會在控制檔案中記錄System checkpoint SCN號的同時,還需要為每個資料檔案記錄
Datafile Checkpoint SCN號?
原因有二:
1.對只讀表空間,其資料檔案的Datafile Checkpoint SCN、Start SCN和END SCN號均相同。
這三個SCN在表空間處於只讀期間都將被凍結。
2.如果控制檔案不是當前的控制檔案,則System checkpoint會小於Start SCN或END SCN號。記錄這些SCN號,可以區分控制檔案是否是當前的控制檔案。
Recovery database using backup controlfile
當有一個Start SCN號超過了System Checkpoit SCN號時,則說明控制檔案不是當前的控制檔案,因此在做recovery時需要採用using backup controlfile。這是為什麼需要記錄SystemCheckpoint SCN的原因之一。
這裡需要一提的是,當重建控制檔案的時候,System Checkpoint SCN為0,Datafile Checkpoint SCN的資料來自於Start SCN。根據上述的描述,此時需要採用using backup controlfile做recovery。
重建控制檔案,重建方式分兩種(resetlogs和noresetlogs)(此段內容來自:http://space.itpub.net/12361284/viewspace-346

1.使用resetlogs選項時,System Checkpoint SCN為被歸為0,而其中記錄的各個資料檔案的Datafile Checkpoint SCN則來自於Start SCN(也就是說可能會從冷備份的資料檔案的資料檔案頭中獲取)。根據上述的描述,此時需要採用using backup controlfile做recovery.因此情況是System Checkpoint SCN=0 < Start SCN = Datafile Checkpoint SCN。
2.使用noresetlogs選項時,有一個前提就是:一定要有online redo log的存在。否則就要使用resetlogs選項。這個時候控制檔案重建好時,其system checkpoint SCN=Datafile Checkpoint SCN=Lastest Checkpoint SCN in online redo log,我們可以看到Datafile Checkpoint SCN並沒有從Start SCN中讀取。而是讀取了最新的日誌檔案中的SCN作為自己的資料。此時重建的控制檔案在恢復中的作用跟最新的控制檔案類似,System Checkpoint SCN(已經讀取最新的redo log的checkpoint SCN資訊)可能會>Start SCN(因為資料檔案可能會從冷備份中恢復),恢復時就不需要加using backup controlfile子句了。
關於backup controlfile的補充:backup controlfile只有備份時刻的archive log資訊,並沒有DB crash時刻的archive log資訊,所以並不會自動應用online redo log,而是提示找不到序號為Lastest Archive log sequence + 1的archive log,儘管你可以手動指定online redo log來實現完全恢復,但因為一旦使用了using backup controlfile子句,Oracle就視為不完全恢復,必須open resetlogs!實際上,假如你有舊的控制檔案又不想resetlogs,那很簡單,使用舊的控制檔案mount然後backup to trace,然後手工建立控制檔案,使用reuse database ... noresetlogs .這樣就可以recover database自動恢復並open database而不用resetlogs了(記住:必須有所有的online redo logs才可以這樣!)。
 

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

相關文章