oracle的resetlogs機制淺析
author：skate
time：2010/09/07
oracle的resetlogs機制淺析
alter database open resetlogs 這個命令我想大家都很熟悉了，那有沒有想過這個resetlogs選項為什麼要用？什麼時候用？
它的原理機制是什麼？他都起哪些作用？
我們都知道資料在啟動時候是要做一致性檢查的，oracle在open階段要做兩次檢查
1. 檢查資料檔案頭的檢查點計數（checkpoint cnt）是否和控制檔案的檢查點計數（checkpoint cnt）一致。目的是確認資料檔案
是否來自同一版本，而不是從備份中恢復的。如果這一步檢查透過，就進行第二步檢查
2. 檢查資料檔案頭的開始scn和控制檔案中記錄該檔案的結束scn是否一致。如果資料檔案頭的開始scn和控制檔案中該檔案的結束scn
相等，那說明這個資料檔案就不需要恢復，否則就要恢復檔案
如果以上兩步檢查都透過，那就可以正常開啟資料庫，鎖定資料檔案，同時將控制檔案中每個資料檔案的結束scn設定無窮大。
我們在某些條件下開啟資料，會提示讓用resetlogs選項open資料庫，為什麼要用resetlogs呢？它是幹嘛用的呢？問號一大堆了吧,
下面來具體分析下。
resetlogs的作用
防止陳舊的資料進入資料庫（保證資料庫的一致性），這也就是為什麼在用resetlogs開啟資料庫，一定要立即對資料庫做個全備。
在控制檔案，data file header，redo log header裡儲存”resetlogs data“，當open resetlogs被執行時，可以透過這些內容檢查一致性。
什麼時候用resetlogs
1. 不完全恢復
2. 用備份的控制檔案恢復
3. 新建立的控制檔案來恢復
resetlogs的原理機制
resetlogs是如何來保證開啟資料庫是一致的呢？
1）在open resetlogs時，oracle要對比檢查控制檔案和資料字典file$,如果一個資料檔案在file$中存在，但在控制檔案中不存在，
那在控制檔案中將建立一個這個檔案條目（MISSINGnnn ‘nnn’是十進位制的file_id）,同時這個檔案被標記為離線並需要恢復。如果
實際中這個檔案存在的話，可以透過如下sql更改到正確的檔名。
sql> alter database rename file 'MISSINGnnn' to '
然後資料檔案被恢復，online。
2）如果一個資料檔案存在控制檔案中，而不在資料字典file$中，那麼直接把控制檔案中這個檔案的記錄條目刪除（oracle認為file$文
件是正確的，要以它為準）
3）當用舊的備份控制檔案恢復的時候，如果有資料檔案不在控制檔案中註冊（會提示控制檔案比較舊的錯誤），那就不得不重建資料檔案
，以使資料檔案註冊到控制檔案中，然後系統會自動利用redo/archivelog恢復這個資料檔案。
在保證控制檔案和file$檔案內容一致之後，oracle還有做如下檢查才能open resetlogs
4）資料檔案的版本要小於當前資料庫的版本（counter）
5）offline的資料檔案必須被online或者直接drop
6）所有的資料檔案不能設定fuzzy bit，所有的資料檔案要有相同的檢查點（checkpoint SCN）
到目前為止，open resetlogs的前提條件都已經滿足，resetlogs究竟做了哪些工作呢？（重新使用redo log）
1）所有的online logfile 的資訊重新被放置在控制檔案中。並且還要為有效的thread挑選一個logfile檔案作為current logfile
2）log header被更新為log seq#
3）所有的online的資料檔案頭被新的checkpoint和新的‘resetlogs data’更新，offline的資料檔案被標記為需要媒體恢復。
resetlogs data：當前的scn和counter被稱作”resetlogs data“
如果oracle資料庫一致性檢查失敗的，那資料庫是不允許被open的，即 open resetlogs不成功。但也不是絕對不能open，可以透過隱含引數“_allow_resetlogs_curruption”,
繞過oracle的一致性檢查，但這樣會引起資料庫的不一致（檔案可能有不同的scn或有fuzzy
bit設定），如果open後，資料庫一定要rebuild （建議ANALYZE TABLE ...VALIDATE STRUCTURE
CASCADE;或者imp/exp ）
-------end------
另一篇SCN文章：
http://space.itpub.net/12361284/viewspace-346
Checkpoint和SCN的解析
年初的時候拜讀完了eygle寫的《深入潛出》這本書，感覺收穫很大。正好可以總結一下SCN和checkpoint這兩個東東。
Checkpoint
很多人都把checkpoint的概念給複雜化了，其實checkpoint這個概
念引入的真正意義就是用來減少在資料庫恢復過程中所花的時間(instance
recovery),那麼checkpoint是又誰來做的呢？我們都知道資料庫中有個CKPT程式，這個是個可選程式，但是真正執行檢查點的任務並不是
有ckpt來完成的，而是ckpt在更新控制檔案和資料檔案頭的有關資訊後，通知DBWn程式，產生一個檢查點，在產生檢查點的時候，DBWn程式會將
buffer cache中的髒資料(當前online redo
log對應的髒資料)，寫入我們的資料檔案當中。那麼這個時候如果資料庫此時崩潰（比如我們做個shutdown
abort），那麼在進行例項恢復的時候就可以不需要當前online redo
log的內容了，會很快就做完。因此ckpt程式只是個輔助程式，他的任務更多的是用來在系統做checkpoint的時候更新控制檔案和資料檔案頭中的
資訊。其實在oracle
8i的時候呢，ckpt的任務一般都是由lgwr程式來完成，到了8i以後，隨著CKPT程式的引入，lgwr的工作負擔就減輕了很多(commit的速
度加快了)
那麼如何來產生檢查點呢？
有三種方法，可以透過
1.alter system checkpoint
2.alter system switch logfile
3.DBWn程式寫出髒塊
SCN
在Oracle中理解為一個內部同步時鐘，是系統改變號的縮寫（system change number）,在中
我們可以透過dbms_flashback包來查詢當前系統的改變號：select
dbms_flashback.get_system_change_number from
dual;一般來講SCN主要是用來標識資料庫所做的所有改變，這個SCN的改變是隻能前進，不能回退，除非我們打算重建庫，資料庫中的SCN永遠不會歸
0，一般來說SCN的前進觸發是由commit來進行的，除了這些據我觀察每隔3秒種系統也都會重新整理一次SCN.
需要注意的是：
1.CKPT
一定是是在checkpoint發生的時候將資料庫當前的SCN更新入資料庫檔案頭和控制檔案當中，同時DBWn程式將buffer
cache中的髒資料塊（dirty block）寫到資料檔案當中(這個髒資料也一定是當前online redo log保護的那一部分)。
2.同時CKPT程式還會在控制檔案當中記錄(redo block address)RBA，這個地址用來標誌恢復的時候需要從日誌中的那個位置開始。
在Oracle資料庫中和checkpoint相關的SCN總共有4個
1.System checkpoint SCN (存在於控制檔案)
在系統執行checkpoint後，Oracle會更新當前控制檔案中的System checkpoint SCN。
我們可以透過
select checkpoint_change# from v$database:
來檢視
2.Datafile checkpoint SCN (存在於控制檔案)
由
於控制檔案中記錄了Oracle中各個資料庫檔案的位置和資訊，其中當然也包括了Datafile checkpoint
SCN，因此在執行checkpoint的時候，Oracle還會去更新控制檔案中所記錄的各個資料檔案的datafile checkpoint
SCN.
我們可以透過
select checkpoint_change# from v$datafile;
來檢視
3.Start SCN (存在於各個資料檔案頭)
在執行checkpoint時，Oracle會更新存放在各個實際的資料檔案頭的Start SCN（注意絕對不會是控制檔案中），這個SCN存在的目的是用於檢查資料庫啟動過程中是否需要做media recovery(介質恢復)
我們可以透過
select checkpoint_change# from v$datafile_header;
4.End SCN(存在於控制檔案)
最
後一類SCN,End SCN他也是記錄在控制檔案當中，每一個所記錄的資料檔案頭都有一個對應的End SCN,這個End
SCN一定是存在於控制檔案當中。這個SCN存在的絕對意義主要是用來去驗證資料庫啟動過程中是否需要做instance
recovery。我們可以透過
select name,last_change# from v$datafile
那麼其實在資料庫正常執行的情況下，對於read/write的online 資料檔案這個SCN號為#FFFFFF(NULL).
下面來聊一聊SCN號於資料庫的啟動
1.
在資料庫的啟動過程中，當System Checkpoint SCN=Datafile Checkpoint SCN=Start
SCN的時候，Oracle資料庫是可以正常啟動的，而不需要做任何的media recovery。而如果三者當中有一個不同的話，則需要做media
recovery
2.那什麼時候需要做instance
recovery呢？其實在正常open資料庫的時候，oracle會將記錄在控制檔案中的每一個資料檔案頭的End
SCN都設定為#FFFFFF(NULL)，那麼如果資料庫進行了正常關閉比如(shutdown or shutdown
immediate)這個時候，系統會執行一個檢查點，這個檢查點會將控制檔案中記錄的各個資料檔案頭的End
SCN更新為當前online資料檔案的各個資料檔案頭的Start SCN,也就是End SCN=Start
SCN,如果再次啟動資料庫的時候發現二者相等，則直接開啟資料庫，並再次將End
SCN設定為#FFFFFF(NULL),那麼如果資料庫是異常關閉，那麼checkpoint就不會執行，因此再次開啟資料庫的時候End
SCN<>Start SCN這個時候就需要做例項恢復。
說了那麼多更新SCN操作什麼的，這個更新操作到底是由誰做的呢？其實剛才已經說過了，就是我們的CKPT程式，他不僅僅會更新SCN，而且還會通知DBWn做他的事情。
再說一下System Checkpoint SCN和Datafile Checkpoint SCN,這兩個SCN都是記錄在控制檔案當中的。但是這兩個SCN有什麼作用呢？
logzgh有段論述，我自己的想了一下，還是學習一下他的結論：
1.對只讀表空間，其資料檔案的Datafile Checkpoint SCN、Start SCN和END SCN號均相同。這三個SCN在表空間處於只讀期間都將被凍結。
2.
如果控制檔案不是當前的控制檔案(其實就是說，想比當前redo log的SCN來講，控制檔案已經過時了)，則System checkpoint
SCN會小於Start SCN(Start
SCN是來自實際的資料檔案頭，有比較依據)。記錄這些SCN號，可以區分控制檔案是否是當前的控制檔案。當有一個Start
SCN(從當前各個線上資料檔案中獲得)號超過了System Checkpoit
SCN號時，則說明控制檔案不是當前的控制檔案，因此在做recovery時需要採用using backup
controlfile。這是為什麼需要記錄SystemCheckpoint SCN的原因之一。
當我們重建控制檔案的時候，重建方式分兩種（resetlogs 和 noresetlogs）
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 了
**********************************************
透過試驗說明checkpoint cnt 和checkpoint scn的關係
1.在不同條件下轉儲控制檔案
|
Session altered. SQL> alter tablespace system begin backup; Tablespace altered. SQL> alter session set events 'immediate trace name CONTROLF level 10'; Session altered. SQL> alter system checkpoint; System altered. SQL> alter session set events 'immediate trace name CONTROLF level 10' Session altered. SQL> alter tablespace system end backup; Tablespace altered. SQL> alter session set events 'immediate trace name CONTROLF level 10'; Session altered.
|
notes:
alter session set events 'immediate trace name CONTROLF level 10';
用於轉儲控制檔案.
2.獲得以下跟蹤檔案資訊(僅研究system表空間記錄,請注意紅色部分):
a.正常情況下轉儲控制檔案
|
***************************************************************************
|
b.執行Begin backup以後的
我們注意到Checkpoint cnt增加了1，此處觸發了一次表空間檢查點.
|
***************************************************************************
|
c.執行手工檢查點
我們注意到,此時Checkpoint cnt增加，但是scn不再改變
|
***************************************************************************
|
d.End backup後的情況
此時資料檔案頭的凍結被取消,scn開始變化
|
***************************************************************************
|
Checkpoint cnt用於保證在正常操作中使用的資料檔案是當前版本
在恢復時防止恢復資料檔案的錯誤版本.Checkpoint cnt是一直遞增的,即使表空間處於熱備份模式.
由於表空間的建立時間不盡相同,所以不同表空間/資料檔案的Checkpoint cnt通常是不同的.
我們知道:
在資料庫open的過程中,Oracle要進行兩次檢查.
第一次檢查資料檔案頭中的Checkpoint cnt是否與對應控制檔案中的Checkpoint cnt一致.
如果相等,進行第二次檢查.
第二次檢查資料檔案頭的開始SCN和對應控制檔案中的結束SCN是否一致
如果結束SCN等於開始SCN,則不需要對那個檔案進行恢復.
對每個資料檔案都完成檢查後,開啟資料庫.同時將每個資料檔案的結束SCN設定為無窮大.
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14377/viewspace-1057524/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 轉：oracle的resetlogs機制淺析Oracle
- oracle的resetlogs機制Oracle
- MVVM機制淺析MVVM
- 淺析java的反射機制Java反射
- java中的反射機制淺析Java反射
- js執行機制淺析JS
- Libco Hook 機制淺析Hook
- PostgreSQL MVCC快照機制淺析SQLMVC
- NX實現機制淺析
- Android Binder機制淺析Android
- JavaScript執行機制淺析JavaScript
- 淺析雙親委派機制
- 淺析JavaScript的事件迴圈機制JavaScript事件
- JavaScript的事件迴圈機制淺析JavaScript事件
- 微信小程式的require機制淺析微信小程式UI
- 微前端無界機制淺析前端
- 淺析前端頁面渲染機制前端
- 淺析注意力(Attention)機制
- 淺析 PHP7 的垃圾回收機制PHP
- 淺析Dubbo的SPI擴充套件機制套件
- 淺析Android中的訊息機制Android
- 淺析Vue 中 $nextTick 機制Vue
- Timer機制原始碼淺析原始碼
- Linux系統呼叫機制淺析Linux
- 淺析java記憶體管理機制Java記憶體
- GC垃圾回收機制： 淺析與理解GC
- Vue元件渲染機制原始碼淺析Vue元件原始碼
- rebuild index online的鎖機制淺析RebuildIndex
- IO多路複用與epoll機制淺析
- webrtc QOS筆記四 Nack機制淺析Web筆記
- oracle的TAF淺析Oracle
- 簡單案例淺析JS執行緒機制JS執行緒
- 淺析Lua指令碼：MySQL Proxy工作機制指令碼MySql
- 淺析Windows的訪問許可權檢查機制Windows訪問許可權
- 淺析Java虛擬機器結構與機制[轉]Java虛擬機
- 淺析Java多執行緒程式設計機制Java執行緒程式設計
- 技術淺析：前端沙箱資料安全保護的機制前端
- 淺析eBay聯盟營銷的上下文廣告機制