oracle介质恢复的内部过程--推断与参考
這個(gè)是兩年前蔡子楠學(xué)習(xí)oracle總結(jié)的東西,不算什么新東西,僅作為個(gè)人的一個(gè)記錄,也歡迎大家一起學(xué)習(xí)討論。
oracle數(shù)據(jù)庫的介質(zhì)恢復(fù)過程相對非常復(fù)雜,oracle畢竟作為一個(gè)大系統(tǒng),設(shè)計(jì)是相當(dāng)復(fù)雜和龐大的。鄙人結(jié)合對controlfile,redo log,datafile等文件的dump內(nèi)容進(jìn)行分析,試圖深入的了解oracle的介質(zhì)恢復(fù)過程。雖不能從正向了解內(nèi)部工作機(jī)制,但是從逆向推斷也能做個(gè)大致了解,以此增強(qiáng)對oracle的使用信心吧。
從這里開始吧:
1,獲取media-recovery-start SCN.
檢查所有數(shù)據(jù)文件頭,選擇最小的checkpoint SCN值作為start SCN。
假如獲取到的checkpoint SCN值在數(shù)據(jù)文件的offline的SCN范圍內(nèi),則采用offline-end的SCN。
2,checkpoint structure檢查thread啟動(dòng)數(shù)量
media-recovery SCN中的checkpoint structure檢查在該SCN點(diǎn)有幾個(gè)thread線程啟動(dòng)了。
3,分配log buffer
為第二步中的每個(gè)啟動(dòng)的thread分配log buffer。
4,打開log文件
? --如果log文件在線,系統(tǒng)將會(huì)自動(dòng)打開;
? --如果已經(jīng)歸檔,將會(huì)提示管理員輸入log文件名稱。
5,分配獨(dú)占型media recovery lock
為每個(gè)需要執(zhí)行media recovery的數(shù)據(jù)文件分配一個(gè)excusive(獨(dú)占)media recovery lock。
6,對每個(gè)數(shù)據(jù)文件設(shè)置fuzzy bit
7,checkpoint bitvec 決定了初始啟動(dòng)的thread。
8,thread線程讀取相應(yīng)的redo,并應(yīng)用于數(shù)據(jù)庫。
9,Media recovery發(fā)生檢查點(diǎn):
???? --應(yīng)用redo文件過程中,需要轉(zhuǎn)換redo文件,每當(dāng)轉(zhuǎn)換時(shí)都會(huì)發(fā)生Media Recovery checkpoints。
???? --當(dāng)數(shù)據(jù)文件的STOP SCN達(dá)到時(shí),也會(huì)發(fā)生Media Recovery checkpoints,數(shù)據(jù)文件頭的checkpoint也會(huì)被推進(jìn)到該值。
10,完成media checkpoint
所有的thread完成其對應(yīng)的redo日志應(yīng)用,達(dá)到數(shù)據(jù)文件的有限STOP SCN值,完成了media recovery;
media recovery fuzzy bit被清除,或者叫做重置為(0x0000.00000000 day/month/year hh24:mi:ss);
接著更新數(shù)據(jù)文件頭和控制文件,表明了數(shù)據(jù)庫整體一致。
文檔參考:記著開始時(shí)從google找到一篇介紹oracle internal的文章作為了參考,并結(jié)合著dump文件的內(nèi)容才有此體會(huì)。要感謝一些那位“默默無聞”的作者。
總結(jié)
以上是生活随笔為你收集整理的oracle介质恢复的内部过程--推断与参考的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: C#中的平台调用(P/Invoke)
- 下一篇: Delphi常见的运行期Access V