系統改變號(SCN)的詳解,改變號scn詳解
oracle026系統改變號(SCN)的詳解SCN 系統改變號,是通過某些函數把時間產生某個數;確保資料檔案的一致性,比較先後,新舊;
為什麼使用時間產生數字,因為在比較時間的比較慢,而用數字就相對的塊點,就像shared pool 比較sql的
使用算出的hash值進行比較。
select dbms_flashback.get_system_change_number,
SCN_TO_TIMESTAMP(dbms_flashback.get_system_change_number) from dual;
//擷取目前時間的SCN的值,dual是一張暫存資料表類似於MYSQL的temp表的用處。
1153633 22-12月-14 03.04.02.000000000 上午
控制檔案中有三個SCN:開始SCN 結束SCN 和檔案SCN
檔案SCN是針對於每個資料檔案產生的檔案SCN號
檔案SCN是針對於每個資料檔案產生的結束SCN號
在每個資料檔案前有一個開始SCN
在資料庫正常的時候結束SCN時NULL的 ,而檔案的開始SCN、檔案SCN、和系統SCN號是相同的
當資料庫關閉的時候,系統、檔案、結束、開始都是一樣的,
當非正常關閉,結束SCN為空白,由於沒有及時儲存資訊;當下一次資料開啟的時候。就會
檢查到資料時非正常關閉,就會做資料執行個體的恢複工作:需要redo log部分日誌、控制檔案LRBA、HRBA、ON DISK RBA
當我們把資料檔案換了舊的檔案,當系統檢測到了舊檔案的開始SCN和和結束SCN不一樣就需要進行資料恢複做:
跑日誌:把SCN跑成新的
提升SCN
查看幾個SCN:
select checkpoint_change# from v$database; //系統SCN,存在於每個控制檔案
1148314
select name,checkpoint_change# from v$datafile;//檔案SCN,存在於每個控制檔案
/u01/app/oracle/oradata/jiagulun/system01.dbf 1148314
/u01/app/oracle/oradata/jiagulun/sysaux01.dbf 1148314
/u01/app/oracle/oradata/jiagulun/undotbs01.dbf 1148314
/u01/app/oracle/oradata/jiagulun/users01.dbf 1148314
/u01/app/oracle/oradata/jiagulun/example01.dbf 1148314
select name,last_change# from v$datafile;//結束SCN,存在於每個控制檔案
/u01/app/oracle/oradata/jiagulun/system01.dbf
/u01/app/oracle/oradata/jiagulun/sysaux01.dbf
/u01/app/oracle/oradata/jiagulun/undotbs01.dbf
/u01/app/oracle/oradata/jiagulun/users01.dbf
/u01/app/oracle/oradata/jiagulun/example01.dbf
select name ,checkpoint_change# from v$datafile_header//檔案頭SCN,存在於每個資料檔案的頭部
/u01/app/oracle/oradata/jiagulun/system01.dbf 1148314
/u01/app/oracle/oradata/jiagulun/sysaux01.dbf 1148314
/u01/app/oracle/oradata/jiagulun/undotbs01.dbf 1148314
/u01/app/oracle/oradata/jiagulun/users01.dbf 1148314
/u01/app/oracle/oradata/jiagulun/example01.dbf 1148314
redo記錄檔有一個first SCN 和一個next SCN
first、next 是這個檔案中日誌記錄的範圍
每個日誌的條目都有一個SCN;可以把frist SCN號當做這個檔案第一條記錄的SCN號,把next SCN號當做下一個檔案日誌中記錄的開始SCN號
select * from v$log;
名稱 空值 類型
------------- -- ------------
GROUP# NUMBER //日誌組
THREAD# NUMBER
SEQUENCE# NUMBER //唯一標識
BYTES NUMBER
BLOCKSIZE NUMBER
MEMBERS NUMBER
ARCHIVED VARCHAR2(3)
STATUS VARCHAR2(16) //狀態:active,inactive,current
FIRST_CHANGE# NUMBER //first SCN,而下一個日誌的開始就是上一個日誌的next SCN (在10g的時候是這麼認為的)
FIRST_TIME DATE
NEXT_CHANGE# NUMBER //next SCN(10g不一樣)
NEXT_TIME DATE
1 1 10 52428800 512 1 NO INACTIVE 1108520 21-12月-14 1148313 22-12月-14
2 1 11 52428800 512 1 NO CURRENT 1148313 22-12月-14 281474976710655
3 1 9 52428800 512 1 NO INACTIVE 1087024 21-12月-14 1108520 21-12月-14
做一個實驗:
1. select * from v$log;
1 1 10 52428800 512 1 NO INACTIVE 1108520 21-12月-14 1148313 22-12月-14
2 1 11 52428800 512 1 NO ACTIVE 1148313 22-12月-14 1156305 22-12月-14
3 1 12 52428800 512 1 NO CURRENT 1156305 22-12月-14 281474976710655
2. alter system switch logfile;
3. alter system switch logfile;
4. select * from v$log;
1 1 13 52428800 512 1 NO ACTIVE 1157154 22-12月-14 1157173 22-12月-14
2 1 14 52428800 512 1 NO CURRENT 1157173 22-12月-14 281474976710655
3 1 12 52428800 512 1 NO ACTIVE 1156305 22-12月-14 1157154 22-12月-14
5. select name , last_change# from v$datafile;
/u01/app/oracle/oradata/jiagulun/system01.dbf 1157173
/u01/app/oracle/oradata/jiagulun/sysaux01.dbf 1157173
/u01/app/oracle/oradata/jiagulun/undotbs01.dbf 1157173
/u01/app/oracle/oradata/jiagulun/users01.dbf 1157173
/u01/app/oracle/oradata/jiagulun/example01.dbf 1157173
會探索資料檔案中、資料檔案頭的SCN沒有變化,而日誌中的SCN的值發生了變化。由於在控制檔案中、資料檔案頭的SCN的主要目的是控制
資料檔案的一致性
active表示記錄檔中對應髒緩衝區還未寫入資料庫,不能被覆蓋,也就說明需要進行執行個體恢複。
再做個實驗:
1. alter system flush buffer_cache;//沖刷緩衝區資料
2. select name , checkpoint__change# from v$datafile;
/u01/app/oracle/oradata/jiagulun/system01.dbf 1157173
/u01/app/oracle/oradata/jiagulun/sysaux01.dbf 1157173
/u01/app/oracle/oradata/jiagulun/undotbs01.dbf 1157173
/u01/app/oracle/oradata/jiagulun/users01.dbf 1157173
/u01/app/oracle/oradata/jiagulun/example01.dbf 1157173
3. select * from v$log;
1 1 13 52428800 512 1 NO INACTIVE 1157154 22-12月-14 1157173 22-12月-14
2 1 14 52428800 512 1 NO CURRENT 1157173 22-12月-14 281474976710655
3 1 12 52428800 512 1 NO INACTIVE 1156305 22-12月-14 1157154 22-12月-14
上面的資料你會發現當把buffer cache中資料flush掉以後,控制檔案、資料檔案中的SCN都沒有變化,只有記錄檔中的狀態變了
是由於原本緩衝區的髒資料被清空了,那麼它所對應的日誌可以變成可以覆蓋的了,也就是inactive了
而且在檔案頭部、控制檔案中的SCN的值是記錄著記錄檔中的ACTIVIE/CURRENT的SCN的值等於最老的redo log中的active的日誌
其實控制檔案中的SCN是用來定位哪個檔案跑日誌,而在控制檔案中的LRBA是確定從哪裡開始跑日誌
注意:增量檢查點並不會去更新資料檔案頭,以及控制檔案中資料庫SCN以及資料檔案條目的SCN資訊,而只是每3秒由CKPT進程去 更新控制檔案中的low cache rba資訊,也就是檢查點的位置。
那麼他們是在什麼時候會進行更新呢?
結束SCN時在資料庫正常關閉的時候進行更新
其他的SCN是在記錄檔的狀態從active變成inactive的時候才進行更新的,上面的測試可以證明
fast_start_mttr_target:這個參數是用來設定執行個體在恢複的時間,因為在個值將會影響DBWR的寫資料庫頻率,
把恢複的時間縮短,說明髒資料少了,那是因為寫的頻率大。
1、SCN的意義?system change number 時間 先後、新舊 select dbms_flashback.get_system_change_number, SCN_TO_TIMESTAMP(dbms_flashback.get_system_change_number) from dual;
2、常見的SCN 控制檔案 系統SCN select checkpoint_change# from v$database; 檔案SCN select name,checkpoint_change# from v$datafile; 結束SCN select name,last_change# from v$datafile; 檢查點資訊 增量檢查點並不會去更新資料檔案頭,以及控制檔案中資料庫SCN以及資料檔案條目的SCN資訊,而只是每3秒由CKPT進程去 更新控制檔案中的low cache rba資訊,也就是檢查點的位置。
select CPDRT,CPLRBA_SEQ||'.'||CPLRBA_BNO||'.'||CPLRBA_BOF "Low RBA",CPODR_SEQ||'.'||CPODR_BNO||'.'||CPODR_BOF "On disk RBA",CPODS,CPODT,CPHBT from x$kcccp;
CPDRT列是檢查點隊列中的髒塊數目. CPODS列是on disk rba的scn CPODT列是on disk rba的時間戳記 CPHBT列是心跳
資料檔案頭部 開始SCN select name,checkpoint_change# from v$datafile_header; 資料區塊頭部ITL事務槽 日誌change vector中 跑日誌、空跑日誌 復原段事務表中 記錄檔頭部 first、next select recid,sequence#,first_change#,next_change# from v$log_history where rownum<6; select * from v$log; select * from v$archived_log 3、執行個體恢複 只是需要redo log:active、current 執行個體恢複判斷依據 示範SCN變化
如果發生了執行個體崩潰,只需要在記錄檔中找到檢查點位置(low cache rba),從此處開始應用所有的重做記錄檔,就完成了前滾操作。執行個體崩潰後,再次啟動資料庫,oracle會到控制檔案中讀取low cache rba,這就是檢查點位置。從此處開始應用重做日誌,應用到on disk rba的位置。on disk rba是磁碟中重做記錄檔的最後一條重做記錄的rba。
4、fast_start_mttr_target
相關操作
select checkpoint_change# from v$database
alter system checkpoint
alter system switch logfile
select name,checkpoint_change# from v$datafile
select name,checkpoint_change# from v$datafile_header
select * from v$log;
begin for i in 1..10000 loop insert into t2 values(1,'xkj'); commit; end loop; end; select * from t2
alter system flush buffer_cache |