您現(xiàn)在的位置：OracleSCN實現(xiàn)機制總結(jié)
OracleSCN實現(xiàn)機制總結(jié)
SCN（System Chang Number）作為oracle中的一個重要機制，在數(shù)據(jù)恢復(fù)、Data Guard、Streams復(fù)制、RAC節(jié)點間的同步等各個功能中起著重要作用。理解SCN的運作機制，可以幫助你更加深入地了解上述功能。
在理解SCN之前，我們先看下oracle事務(wù)中的數(shù)據(jù)變化是如何寫入數(shù)據(jù)文件的：1、事務(wù)開始；2、在buffer cache中找到需要的數(shù)據(jù)塊，如果沒有找到，則從數(shù)據(jù)文件中載入buffer cache中；3、事務(wù)修改buffer cache的數(shù)據(jù)塊，該數(shù)據(jù)被標(biāo)識為“臟數(shù)據(jù)”，并被寫入log buffer中；4、事務(wù)提交，LGWR進(jìn)程將log buffer中的“臟數(shù)據(jù)”寫入redo log file中；5、當(dāng)發(fā)生checkpoint，CKPT進(jìn)程更新所有數(shù)據(jù)文件的文件頭中的信息，DBWn進(jìn)程則負(fù)責(zé)將Buffer Cache中的臟數(shù)據(jù)寫入到數(shù)據(jù)文件中。
經(jīng)過上述5個步驟，事務(wù)中的數(shù)據(jù)變化最終被寫入到數(shù)據(jù)文件中。但是，一旦在上述中間環(huán)節(jié)時，數(shù)據(jù)庫意外宕機了，在重新啟動時如何知道哪些數(shù)據(jù)已經(jīng)寫入數(shù)據(jù)文件、哪些沒有寫呢（同樣，在DG、streams中也存在類似疑問：redo log中哪些是上一次同步已經(jīng)復(fù)制過的數(shù)據(jù)、哪些沒有）？SCN機制就能比較完善的解決上述問題。
SCN是一個數(shù)字，確切的說是一個只會增加、不會減少的數(shù)字。正是它這種只會增加的特性確保了Oracle知道哪些應(yīng)該被恢復(fù)、哪些應(yīng)該被復(fù)制。
這四個分別是：1.System Checkpoint SCN當(dāng)checkpoint完成后，ORACLE將System Checkpoint SCN號存放在控制文件中。我們可以通過下面SQL語句查詢：select checkpoint_change# from v$database；2.Datafile Checkpoint SCN當(dāng)checkpoint完成后，ORACLE將Datafile Checkpoint SCN號存放在控制文件中。我們可以通過下面SQL語句查詢所有數(shù)據(jù)文件的Datafile Checkpoinnt SCN號。
select name，checkpoint_change# from v$datafile；3.Start SCN號ORACLE將Start SCN號存放在數(shù)據(jù)文件頭中。
這個SCN用于檢查數(shù)據(jù)庫啟動過程是否需要做Media Recovery.我們可以通過以下SQL語句查詢：select name，checkpoint_change# from v$datafile_header；4.End SCN （Stop SCN）號ORACLE將End SCN號存放在控制文件中。
這個SCN號用于檢查數(shù)據(jù)庫啟動過程是否需要做Instance Recovery.我們可以通過以下SQL語句查詢：select name，last_change# from v$datafile；在數(shù)據(jù)庫正常運行的情況下，對可讀寫的，online的數(shù)據(jù)文件，該SCN號為NULL. SCN號與數(shù)據(jù)庫啟動在數(shù)據(jù)庫啟動過程中，當(dāng)System Checkpoint SCN、Datafile Checkpoint SCN和Start SCN號都相同時，數(shù)據(jù)庫可以正常啟動，不需要做media recovery.三者當(dāng)中有一個不同時，則需要做media recovery.如果在啟動的過程中，End SCN號為NULL，則需要做instance recovery.ORACLE在啟動過程中首先檢查是否需要media recovery，然后再檢查是否需要instance recovery. SCN號與數(shù)據(jù)庫關(guān)閉如果數(shù)據(jù)庫的正常關(guān)閉的話，將會觸發(fā)一個checkpoint，同時將數(shù)據(jù)文件的END SCN號設(shè)置為相應(yīng)數(shù)據(jù)文件的Start SCN號。
當(dāng)數(shù)據(jù)庫啟動時，發(fā)現(xiàn)它們是一致的，則不需要做instance recovery.在數(shù)據(jù)庫正常啟動后，ORACLE會將END SCN號設(shè)置為NULL.如果數(shù)據(jù)庫異常關(guān)閉的話，則END SCN號將為NULL.為什么需要System checkpoint SCN號與Datafile Checkpoint SCN號為什么ORACLE會在控制文件中記錄System checkpoint SCN號的同時，還需要為每個數(shù)據(jù)文件記錄Datafile Checkpoint SCN號？
原因有二：1.對只讀表空間，其數(shù)據(jù)文件的Datafile Checkpoint SCN、Start SCN和END SCN號均相同。
這三個SCN在表空間處于只讀期間都將被凍結(jié)。
2.如果控制文件不是當(dāng)前的控制文件，則System checkpoint會小于Start SCN或END SCN號。記錄這些SCN號，可以區(qū)分控制文件是否是當(dāng)前的控制文件。
Recovery database using backup controlfile當(dāng)有一個Start SCN號超過了System Checkpoit SCN號時，則說明控制文件不是當(dāng)前的控制文件，因此在做recovery時需要采用using backup controlfile.這是為什么需要記錄SystemCheckpoint SCN的原因之一。
這里需要一提的是，當(dāng)重建控制文件的時候，System Checkpoint SCN為0，Datafile Checkpoint SCN的數(shù)據(jù)來自于Start SCN.根據(jù)上述的描述，此時需要采用using backup controlfile做recovery.那系統(tǒng)是如何產(chǎn)生一個最新的SCN的？實際上，這個數(shù)字是由當(dāng)時的timestamp轉(zhuǎn)換過來的。每當(dāng)需要產(chǎn)生一個最新的SCN到redo記錄時，系統(tǒng)獲取當(dāng)時的timestamp，將其轉(zhuǎn)換為數(shù)字作為SCN.可以通過函數(shù)SCN_TO_TIMESTAMP（10g以后）將其轉(zhuǎn)換回timestamp：select dbms_flashback.get_system_change_number， SCN_TO_TIMESTAMP（dbms_flashback.get_system_change_number） from dual；也可以用函數(shù)timestamp_to_scn將一個timestamp轉(zhuǎn)換為SCN：select timestamp_to_scn（SYSTIMESTAMP） as scn from dual；如果你想把DATE類型轉(zhuǎn)換成TIMESTAMP類型，就使用CAST函數(shù)。
select cast（sysdate as timestamp） from dual；
Oracle SCN 實現(xiàn)機制總結(jié)author：潤明 2012-2-4 QQ：226399587 /runming918 SCN（System Chang Number）作為oracle中的一個重要機制，在數(shù)據(jù)恢復(fù)、Data Guard、Streams復(fù)制、RAC節(jié)點間的同步等各個功能中起著重要作用。理解SCN的運作機制，可以幫助你更加深入地了解上述功能。
在理解SCN之前，我們先看下oracle事務(wù)中的數(shù)據(jù)變化是如何寫入數(shù)據(jù)文件的：1、事務(wù)開始；2、在buffer cache中找到需要的數(shù)據(jù)塊，如果沒有找到，則從數(shù)據(jù)文件中載入buffer cache中；3、事務(wù)修改buffer cache的數(shù)據(jù)塊，該數(shù)據(jù)被標(biāo)識為“臟數(shù)據(jù)”，并被寫入log buffer中；4、事務(wù)提交，LGWR進(jìn)程將log buffer中的“臟數(shù)據(jù)”寫入redo log file中；5、當(dāng)發(fā)生checkpoint，CKPT進(jìn)程更新所有數(shù)據(jù)文件的文件頭中的信息，DBWn進(jìn)程則負(fù)責(zé)將Buffer Cache中的臟數(shù)據(jù)寫入到數(shù)據(jù)文件中。
經(jīng)過上述5個步驟，事務(wù)中的數(shù)據(jù)變化最終被寫入到數(shù)據(jù)文件中。但是，一旦在上述中間環(huán)節(jié)時，數(shù)據(jù)庫意外宕機了，在重新啟動時如何知道哪些數(shù)據(jù)已經(jīng)寫入數(shù)據(jù)文件、哪些沒有寫呢（同樣，在DG、streams中也存在類似疑問：redo log中哪些是上一次同步已經(jīng)復(fù)制過的數(shù)據(jù)、哪些沒有）？SCN機制就能比較完善的解決上述問題。
SCN是一個數(shù)字，確切的說是一個只會增加、不會減少的數(shù)字。正是它這種只會增加的特性確保了Oracle知道哪些應(yīng)該被恢復(fù)、哪些應(yīng)該被復(fù)制。
這四個分別是：1.System Checkpoint SCN當(dāng)checkpoint完成后，ORACLE將System Checkpoint SCN號存放在控制文件中。我們可以通過下面SQL語句查詢：select checkpoint_change# from v$database；2.Datafile Checkpoint SCN當(dāng)checkpoint完成后，ORACLE將Datafile Checkpoint SCN號存放在控制文件中。我們可以通過下面SQL語句查詢所有數(shù)據(jù)文件的Datafile Checkpoinnt SCN號。
select name，checkpoint_change# from v$datafile；3.Start SCN號ORACLE將Start SCN號存放在數(shù)據(jù)文件頭中。
這個SCN用于檢查數(shù)據(jù)庫啟動過程是否需要做Media Recovery.我們可以通過以下SQL語句查詢：select name，checkpoint_change# from v$datafile_header；4.End SCN （Stop SCN）號ORACLE將End SCN號存放在控制文件中。
這個SCN號用于檢查數(shù)據(jù)庫啟動過程是否需要做Instance Recovery.我們可以通過以下SQL語句查詢：select name，last_change# from v$datafile；在數(shù)據(jù)庫正常運行的情況下，對可讀寫的，online的數(shù)據(jù)文件，該SCN號為NULL. SCN號與數(shù)據(jù)庫啟動在數(shù)據(jù)庫啟動過程中，當(dāng)System Checkpoint SCN、Datafile Checkpoint SCN和Start SCN號都相同時，數(shù)據(jù)庫可以正常啟動，不需要做media recovery.三者當(dāng)中有一個不同時，則需要做media recovery.如果在啟動的過程中，End SCN號為NULL，則需要做instance recovery.ORACLE在啟動過程中首先檢查是否需要media recovery，然后再檢查是否需要instance recovery. SCN號與數(shù)據(jù)庫關(guān)閉如果數(shù)據(jù)庫的正常關(guān)閉的話，將會觸發(fā)一個checkpoint，同時將數(shù)據(jù)文件的END SCN號設(shè)置為相應(yīng)數(shù)據(jù)文件的Start SCN號。
當(dāng)數(shù)據(jù)庫啟動時，發(fā)現(xiàn)它們是一致的，則不需要做instance recovery.在數(shù)據(jù)庫正常啟動后，ORACLE會將END SCN號設(shè)置為NULL.如果數(shù)據(jù)庫異常關(guān)閉的話，則END SCN號將為NULL.為什么需要System checkpoint SCN號與Datafile Checkpoint SCN號為什么ORACLE會在控制文件中記錄System checkpoint SCN號的同時，還需要為每個數(shù)據(jù)文件記錄Datafile Checkpoint SCN號？
原因有二：1.對只讀表空間，其數(shù)據(jù)文件的Datafile Checkpoint SCN、Start SCN和END SCN號均相同。
這三個SCN在表空間處于只讀期間都將被凍結(jié)。
2.如果控制文件不是當(dāng)前的控制文件，則System checkpoint會小于Start SCN或END SCN號。記錄這些SCN號，可以區(qū)分控制文件是否是當(dāng)前的控制文件。
Recovery database using backup controlfile當(dāng)有一個Start SCN號超過了System Checkpoit SCN號時，則說明控制文件不是當(dāng)前的控制文件，因此在做recovery時需要采用using backup controlfile.這是為什么需要記錄SystemCheckpoint SCN的原因之一。
這里需要一提的是，當(dāng)重建控制文件的時候，System Checkpoint SCN為0，Datafile Checkpoint SCN的數(shù)據(jù)來自于Start SCN.根據(jù)上述的描述，此時需要采用using backup controlfile做recovery.那系統(tǒng)是如何產(chǎn)生一個最新的SCN的？實際上，這個數(shù)字是由當(dāng)時的timestamp轉(zhuǎn)換過來的。每當(dāng)需要產(chǎn)生一個最新的SCN到redo記錄時，系統(tǒng)獲取當(dāng)時的timestamp，將其轉(zhuǎn)換為數(shù)字作為SCN.可以通過函數(shù)SCN_TO_TIMESTAMP（10g以后）將其轉(zhuǎn)換回timestamp：select dbms_flashback.get_system_change_number， SCN_TO_TIMESTAMP（dbms_flashback.get_system_change_number） from dual；也可以用函數(shù)timestamp_to_scn將一個timestamp轉(zhuǎn)換為SCN：select timestamp_to_scn（SYSTIMESTAMP） as scn from dual；如果你想把DATE類型轉(zhuǎn)換成TIMESTAMP類型，就使用CAST函數(shù)。
select cast（sysdate as timestamp） from dual；
