1. 系統SCN號
查詢系統SCN號的方法:
select dbms_flashback.get_system_change_number from dual
commit后系統SCN號會增長,但是即使沒有commit操作,因為有許多后臺進程在運行,所以系統SCN號也會增長。
2. 檢查點SCN
有4種檢查點SCN,其中除了文件頭中的啟動SCN外,其他三種保存在控制文件中。可以通過:alter system set events ‘immediate trace name controlf level 10’導出控制文件到udump目錄的跟蹤文件,來查看控制文件的內容。
1) 系統檢查點SCN(區別于上面的系統SCN,chekpoint發出后這些SCN號才受影響,如發出:alter system checkpoint),當一個檢查點動作完成后,Oracle就把系統檢查點的SCN存儲到控制文件中,查詢方法:
Select checkpoint_change# from v$database
2) 數據文件檢查點SCN
當一個檢查點動作完成后,Oracle就把每個數據文件的SCN號單獨存放在控制文件中,查詢方法:
Select checkpoint_change# from v$datafile
3) 文件頭中的啟動SCN
Oracle把這個檢查點的SCN號存儲在每一個數據文件的文件頭中。主要用于數據庫實例啟動時,檢查是否需要執行數據庫恢復。查詢方法:
Select name,chekpoint_change# from v$datafile_header
4) 終止SCN
每個數據文件的SCN號都存儲在控制文件中,查詢方法:
Select name,last_change# from v$datafile
在正常的數據庫操作過程中,所有處于聯機讀寫模式下的數據文件的終止SCN都為NULL。
3. 幾個檢查點SCN號的關系
1) 幾個檢查點SCN都相同:在數據庫打開并運行之后,控制文件中的系統檢查點SCN、控制文件中的數據文件檢查點SCN及每個數據文件頭中的啟動SCN都是相同的,控制文件中的每個數據文件的終止SCN都是NULL。
2) 數據庫正常關閉時,系統會執行一個檢查點動作,這時所有數據文件的 終止SCN號會設置為數據文件頭的那個啟動SCN。數據庫重新啟動時,Oracle將數據文件頭中的啟動SCN與數據文件檢查點SCN比較,如果這兩個值匹配,Oracle接下來再比較數據文件頭中的SCN和控制文件中數據文件的終止SCN,如果這個值也匹配,就意味著所有數據塊已經提交,因此數據庫不需要進行恢復,此時數據庫直接打開。當所有的數據文件都打開之后,終止SCN再次被設置為NULL,表示數據文件已經打開并能夠正常使用了。
3) 數據庫非正常關閉(或稱為實例崩潰)時,終止SCN不會被設置,依然為NULL,這可以通過把數據庫啟動至mount狀態查詢出來。這樣Oracle通過這個信息就可以知道實例上次運行時崩潰了,檢查點沒有執行。這樣重新啟動時,Oracle會執行實例恢復工作,即先執行前滾、回滾操作,再把數據庫打開。
4) 數據文件檢查點SCN及系統檢查點SCN比文件頭啟動SCN大:這時的情況是:系統發生介質故障,數據文件被以前的備份代替,控制文件中的數據文件檢查點SCN肯定比文件頭中的啟動SCN要大,這樣Oracle就知道要對這個文件進行介質恢復。這時要通過下面語句恢復數據庫:
recover database ……
5) 系統檢查點SCN比數據文件SCN及文件頭啟動SCN大:
有些表空間是只讀的,這時控制文件中的系統檢查點SCN號會不斷增長,而數據文件SCN號和文件頭中的啟動SCN號會停止更新(直到表空間又設置為可讀寫),顯然這時系統檢查點SCN號會大于數據文件SCN和文件頭啟動SCN。
6) 系統檢查點SCN及數據文件SCN比文件頭啟動SCN小:
在數據庫恢復時,控制文件可能不是最新的,即把一個較早的控制文件還原為當前的控制文件,然后再執行恢復操作,這時控制文件中的系統檢查點SCN和數據文件SCN可能比文件頭的啟動SCN小。這時恢復數據庫要用下面命令:
recover database using Backup Controlfile或其他的恢復語句
查詢系統SCN號的方法:
select dbms_flashback.get_system_change_number from dual
commit后系統SCN號會增長,但是即使沒有commit操作,因為有許多后臺進程在運行,所以系統SCN號也會增長。
2. 檢查點SCN
有4種檢查點SCN,其中除了文件頭中的啟動SCN外,其他三種保存在控制文件中。可以通過:alter system set events ‘immediate trace name controlf level 10’導出控制文件到udump目錄的跟蹤文件,來查看控制文件的內容。
1) 系統檢查點SCN(區別于上面的系統SCN,chekpoint發出后這些SCN號才受影響,如發出:alter system checkpoint),當一個檢查點動作完成后,Oracle就把系統檢查點的SCN存儲到控制文件中,查詢方法:
Select checkpoint_change# from v$database
2) 數據文件檢查點SCN
當一個檢查點動作完成后,Oracle就把每個數據文件的SCN號單獨存放在控制文件中,查詢方法:
Select checkpoint_change# from v$datafile
3) 文件頭中的啟動SCN
Oracle把這個檢查點的SCN號存儲在每一個數據文件的文件頭中。主要用于數據庫實例啟動時,檢查是否需要執行數據庫恢復。查詢方法:
Select name,chekpoint_change# from v$datafile_header
4) 終止SCN
每個數據文件的SCN號都存儲在控制文件中,查詢方法:
Select name,last_change# from v$datafile
在正常的數據庫操作過程中,所有處于聯機讀寫模式下的數據文件的終止SCN都為NULL。
3. 幾個檢查點SCN號的關系
1) 幾個檢查點SCN都相同:在數據庫打開并運行之后,控制文件中的系統檢查點SCN、控制文件中的數據文件檢查點SCN及每個數據文件頭中的啟動SCN都是相同的,控制文件中的每個數據文件的終止SCN都是NULL。
2) 數據庫正常關閉時,系統會執行一個檢查點動作,這時所有數據文件的 終止SCN號會設置為數據文件頭的那個啟動SCN。數據庫重新啟動時,Oracle將數據文件頭中的啟動SCN與數據文件檢查點SCN比較,如果這兩個值匹配,Oracle接下來再比較數據文件頭中的SCN和控制文件中數據文件的終止SCN,如果這個值也匹配,就意味著所有數據塊已經提交,因此數據庫不需要進行恢復,此時數據庫直接打開。當所有的數據文件都打開之后,終止SCN再次被設置為NULL,表示數據文件已經打開并能夠正常使用了。
3) 數據庫非正常關閉(或稱為實例崩潰)時,終止SCN不會被設置,依然為NULL,這可以通過把數據庫啟動至mount狀態查詢出來。這樣Oracle通過這個信息就可以知道實例上次運行時崩潰了,檢查點沒有執行。這樣重新啟動時,Oracle會執行實例恢復工作,即先執行前滾、回滾操作,再把數據庫打開。
4) 數據文件檢查點SCN及系統檢查點SCN比文件頭啟動SCN大:這時的情況是:系統發生介質故障,數據文件被以前的備份代替,控制文件中的數據文件檢查點SCN肯定比文件頭中的啟動SCN要大,這樣Oracle就知道要對這個文件進行介質恢復。這時要通過下面語句恢復數據庫:
recover database ……
5) 系統檢查點SCN比數據文件SCN及文件頭啟動SCN大:
有些表空間是只讀的,這時控制文件中的系統檢查點SCN號會不斷增長,而數據文件SCN號和文件頭中的啟動SCN號會停止更新(直到表空間又設置為可讀寫),顯然這時系統檢查點SCN號會大于數據文件SCN和文件頭啟動SCN。
6) 系統檢查點SCN及數據文件SCN比文件頭啟動SCN小:
在數據庫恢復時,控制文件可能不是最新的,即把一個較早的控制文件還原為當前的控制文件,然后再執行恢復操作,這時控制文件中的系統檢查點SCN和數據文件SCN可能比文件頭的啟動SCN小。這時恢復數據庫要用下面命令:
recover database using Backup Controlfile或其他的恢復語句
?
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
