35、SCN號的理解

與checkpoint相關的SCN號有四個，其中三個存在控制檔案中，一個存放在資料檔案頭中。
system chekpoint SCN,datafile checkpoint SCN,start SCN,end SCN.

start SCN是放在資料檔案頭中的。

[@more@]

系統檢查點scn(v$database(checkpoint_change#))
資料檔案檢查點（v$datafile(checkpoint_change#)）
資料檔案終止scn(v$datafile(last_change#))

資料檔案中存放的檢查點
啟動scn (v$datafile_header(checkpoint_change#)

1、系統檢查點scn
當一個檢查點動作完成之後，就把系統檢查點的SCN儲存到控制檔案中。
select checkpoint_change# from v$database
2、資料檔案檢查點scn
當一個檢查點動作完成後，Oracle就把每個資料檔案的scn單獨存放在控制檔案中。
select name,checkpoint_change# from v$datafile
3、啟動scn
Oracle把這個檢查點的scn儲存在每個資料檔案的檔案頭中，這個值稱為啟動scn，
因為它用於在資料庫例項啟動時，檢查是否需要執行資料庫恢復。
select name,checkpoint_change# from v$datafile_header
4、終止scn
每個資料檔案的終止scn都儲存在控制檔案中。
select name,last_change# from v$datafile
在正常的資料庫操作過程中，所有正處於聯機讀寫模式下的資料檔案的終止scn都為null.
5、在資料庫執行期間的scn值
在資料庫開啟並執行之後，控制檔案中的系統檢查點、控制檔案中的資料檔案檢查點scn
和每個資料檔案頭中的啟動scn都是相同的。控制檔案中的每個資料檔案的終止scn都為null.

在安全關閉資料庫的過程中，系統會執行一個檢查點動作，這時所有資料檔案的終止scn
都會設定成資料檔案頭中的那個啟動scn的值。在資料庫重新啟動的時候，
Oracle將檔案頭中的那個啟動scn與資料庫檔案檢查點scn進行比較，
如果這兩個值相互匹配，oracle接下來還要比較資料檔案頭中的啟動scn和控制檔案
中資料檔案的終止scn。如果這兩個值也一致，就意味著所有資料塊多已經提交，所有
對資料庫的修改都沒有在關閉資料庫的過程中丟失，因此這次啟動資料庫的過程
也不需要任何恢復操作，此時資料庫就可以開啟了。當所有的資料庫都開啟之後，
儲存在控制檔案中的資料檔案終止scn的值再次被更改為null，
這表示資料檔案已經開啟並能夠正常使用了。

第一步，如果各資料檔案頭部SCN不等於控制檔案中記錄的相應檔案的SCN，那麼要進行介質恢復（“例如冷備替換資料檔案、資料檔案offline了又online”？），否則做第二步，各資料檔案頭部scn是否等於控制檔案中記錄的相應檔案的結束scn，若不相等便會要求執行緒恢復（並行伺服器時）/崩潰恢復（單例項時）（當db down、shutdown abort時，便會出現這種scn不一致的情況）。

------------------------------------------
澄清幾個概念
1)系統當前SCN並不是在任何的資料庫操作發生時都會改變,SCN通常是在事務提交或回滾時改變,但平時也會改變
2)在控制檔案,資料檔案頭,資料塊,日誌檔案頭,日誌檔案change vector中都有SCN,但其作用各不相同資料檔案頭中包含了該資料檔案的checkpoint SCN,表示給資料檔案最近一次執行檢查點操作時的SCN.日誌檔案頭中包含了low scn,next scn,表示給檔案包含有從low scn到next scn的redo record.控制檔案中包含了每個資料檔案的checkpoint SCN,stop SCN,每個日誌檔案的low scn,next scn.控制檔案中checkpoint scn同資料檔案頭中checkpoint scn相同,除非資料檔案被手工替換掉.控制檔案中的low scn,next scn同日志檔案中low scn和next scn相同在資料庫正常執行時,控制檔案中對應資料檔案的stop SCN都是最大值.在正常關閉資料庫的情況下,在關閉前會執行一次檢查點工作當oracle會將資料緩衝區上的內容全部寫回到磁碟中,然後更新控制檔案中對應資料檔案的stop SCN,使其等於checkpoint SCN

但在異常當機的情況下,由於最後一次檢查點未進行或進行中間被中止,因而在控制檔案,就存在部分的資料檔案stop SCN為最大值,在資料庫重新啟動後,會檢查控制檔案中對應每個資料檔案的stop SCN,如果stop SCN不等於控制檔案中對應每個資料檔案的checkpoint SCN,就會使用日誌檔案redo從checkpoint SCN開頭到stop SCN為止的全部資料庫操作.在定位到底是使用哪一個redo log檔案時,就用到了日誌檔案頭中的low scn,next scn,也就是說要使用的redo log 的low scn ,next scn必須包含資料檔案重做所須的change vector.

在確定了哪個資料檔案須redo後,oracle會比較change vector中的SCN和資料檔案資料塊中的SCN,如果change vector的SCN小於資料塊的scn,則跳過此change vector,否則redo
資料塊中ITL中還有SCN,但它的作用是用於產生一致性讀快照

=================================================

參考:

2.10. 深入瞭解SCN
2.10.1. SCN的概念
SCN是順序遞增的一個數字，在Oracle 中用來標識資料庫的每一次改動，及其先後順序。SCN的最大值是0xffff.ffffffff。
2.10.2. SCN的管理方式
Oracle對SCN的管理，分為單節點和RAC兩種方式。
單節點的instance中
單節點的instance中，SCN值存在SGA區，由system commit number latch保護。任何程式要得到當前的SCN值，都要先得到這個latch。
RAC/OPS環境中
Oracle透過排隊機制(Enqueue)實現SCN在各並行節點之間的順序增長。具體有兩種方法：
Lamport演算法：又稱麵包房演算法，先來先服務演算法。跟很多銀行採用的排隊機制一樣。客戶到了銀行，先領取一個服務號。一旦某個視窗出現空閒，擁有最小服務號的客戶就可以去空閒視窗辦理業務。
Commit廣播演算法：一有commit完成，最新的SCN就廣播到所有節點中。
上述兩種演算法可以透過調整初始化引數max_commit_propagation_delay來切換。在多數系統 (除了Compaq Tur64 Unix)中，該引數的預設值都是700釐秒(centisecond)，採用Lamport演算法。如果該值小於100釐秒，Oracle就採用廣播演算法，並且記錄在alert.log檔案中。
2.10.3. 幾種重要的SCN
Commit SCN
當使用者提交commit命令後，系統將當前scn賦給該transaction。這些資訊都反映在redo buffer中，並馬上更新到redo log 檔案裡。
Offline SCN
除了System tablespace以外的任何表空間，當我們執行SQL>alter tablespace … offline normal命令時，就會觸發一個checkpoint，將記憶體中的dirty buffer寫入磁碟檔案中。Checkpoint完成後，資料檔案頭會更新checkpoint scn和offline normal scn值。其中資料庫檔案頭的checkpoint scn值可透過查詢列x$kccfe.fecps得到。
如果執行SQL>alter tablespace …offline命令時採用temporary或 immediate選項，而不用normal選項時，offline normal scn會被設成0。這樣當資料庫重啟後透過resetlog方式開啟時，該表空間就無法再改回線上狀態。
Checkpoint SCN
當資料庫記憶體的髒資料塊(dirty blocks)寫到各資料檔案中時，就發生一次checkpoint。資料庫的當前checkpoint scn值存在x$kccdi.discn中。Checkpoint scn在資料庫恢復中起著至關重要的作用。無論你用何種辦法恢復資料庫，只有當各個資料庫檔案的checkpoint scn都相同時，資料庫才能開啟。
雖然引數“_allow_resetlogs_corruption”可以在checkpoint scn不一致時強制開啟資料庫，但是這樣的資料庫在open後必須馬上作全庫的export，然後重建資料庫並import資料。
Resetlog SCN
資料庫不完全恢復時，在指定時間點後的scn都無法再應用到資料庫中。Resetlog時的scn就被設成當前資料庫scn，redo log也會被重新設定。
Stop SCN
Stop scn記錄在資料檔案頭上。當資料庫處在開啟狀態時，stop scn被設成最大值0xffff.ffffffff。在資料庫正常關閉過程中，stop scn被設定成當前系統的最大scn值。在資料庫開啟過程中，Oracle會比較各檔案的stop scn和checkpoint scn，如果值不一致，表明資料庫先前沒有正常關閉，需要做恢復。
High and Low SCN
Oracle的Redo log會順序紀錄資料庫的各個變化。一組redo log檔案寫滿後，會自動切換到下一組redo log檔案。則上一組redo log的high scn就是下一組redo log的low scn。
在檢視v$log_history中，sequence#代表redo log的序列號，first_change#表示當前redo log的low scn，列next_change#表示當前redo log的high scn。
SQL> col recid format 9999
SQL> col requence# format 9999
SQL> col first_change# format 9,999,999,999,999
SQL> col next_change# format 9,999,999,999,999
SQL> select recid,sequence#,first_change#,next_change# from v$log_history where rownum<6;
RECID SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
----- ---------- ------------------ ------------------
484 484 1,928,645,840,091 1,928,645,840,436
485 485 1,928,645,840,436 1,928,645,840,636
486 486 1,928,645,840,636 1,928,778,045,209
487 487 1,928,778,045,209 1,929,255,480,725
488 488 1,929,255,480,725 1,930,752,214,033
2.10.4. SCN號與oracle資料庫恢復的關係
SCN號與oracle資料庫恢復過程有著密切的關係，只有很好地理解了這層關係，才能深刻地理解恢復的原理，從而才能很好地解決這方面的問題。
SCN與CHECKPOINT
CKPT程式在checkpoint發生時，將當時的SCN號寫入資料檔案頭和控制檔案，同時通知DBWR程式將資料塊寫到資料檔案。
CKPT程式也會在控制檔案中記錄RBA(redo block address),以標誌Recovery需要從日誌中哪個地方開始。與checkpoint相關的SCN號有四個，其中三個存在控制檔案中，一個存放在資料檔案頭中。
這四個分別是：
1.System Checkpoint SCN
當checkpoint完成後，ORACLE將System Checkpoint SCN號存放在控制檔案中。我們可以透過下面SQL語句查詢：
select checkpoint_change# from v$database;
2.Datafile Checkpoint SCN

當checkpoint完成後，ORACLE將Datafile Checkpoint SCN號存放在控制檔案中。我們可以透過下面SQL語句查詢所有資料檔案的Datafile Checkpoinnt SCN號。
select name,checkpoint_change# from v$datafile;
3.Start SCN號
ORACLE將Start SCN號存放在資料檔案頭中。
這個SCN用於檢查資料庫啟動過程是否需要做media recovery.
我們可以透過以下SQL語句查詢：
select name,checkpoint_change# from v$datafile_header;
4.End SCN號
ORACLE將End SCN號存放在控制檔案中。
這個SCN號用於檢查資料庫啟動過程是否需要做instance recovery.
我們可以透過以下SQL語句查詢：
select name,last_change# from v$datafile;
在資料庫正常執行的情況下，對可讀寫的，online的資料檔案，該SCN號為NULL.
我們作個小的試驗，內容如下：
在執行檢查點程式之前SCN號如下：
System Checkpoint SCN 4609061
--select checkpoint_change# from v$database;
Datafile Checkpoint SCN 4609061
--select name,checkpoint_change# from v$datafile;
Start SCN 4609061
--select name,checkpoint_change# from v$datafile_header;
End SCN 空
--select name,last_change# from v$datafile;
執行alter system checkpoint。後的SCN號如下：
System Checkpoint SCN 4609630
--select checkpoint_change# from v$database;
Datafile Checkpoint SCN 4609630
--select name,checkpoint_change# from v$datafile;
Start SCN 4609630
--select name,checkpoint_change# from v$datafile_header;
End SC 空
--select name,last_change# from v$datafile;
SCN不連續原因可能如下：
1.當發生日誌組切換的時候
2.當符合LOG_CHECKPOINT_TIMEOUT，LOG_CHECKPOINT_INTERVAL，fast_start_io_target,fast_start_mttr_target引數設定的時候
3.當執行ALTER SYSTEM SWITCH LOGFILE的時候
4.當執行ALTER SYSTEM CHECKPOINT的時候
5.當執行alter tablespace XXX begin backup，end backup的時候
6.當執行alter tablespace ,datafile offline的時候;
2.10.4.1. SCN號與資料庫啟動
在資料庫啟動過程中，當System Checkpoint SCN、Datafile Checkpoint SCN和Start SCN號都相同時，資料庫可以正常啟動，不需要做media recovery.三者當中有一個不同時，則需要做media recovery。如果在啟動的過程中，End SCN號為NULL，則需要做instance recovery。ORACLE在啟動過程中首先檢查是否需要media recovery，然後再檢查是否需要instance recovery。
2.10.4.2. SCN號與資料庫關閉
如果資料庫的正常關閉的話，將會觸發一個checkpoint，同時將資料檔案的END SCN號設定為相應資料檔案的Start SCN號。
當資料庫啟動時，發現它們是一致的，則不需要做instance recovery。在資料庫正常啟動後，ORACLE會將END SCN號設定為NULL。如果資料庫異常關閉的話，則END SCN號將為NULL.
2.10.4.3. 為什麼需要System checkpoint SCN號與Datafile Checkpoint SCN號
為什麼ORACLE會在控制檔案中記錄System checkpoint SCN號的同時，還需要為每個資料檔案記錄
Datafile Checkpoint SCN號？
原因有二：
1.對只讀表空間，其資料檔案的Datafile Checkpoint SCN、Start SCN和END SCN號均相同。
這三個SCN在表空間處於只讀期間都將被凍結。
2.如果控制檔案不是當前的控制檔案，則System checkpoint會小於Start SCN或END SCN號。記錄這些SCN號，可以區分控制檔案是否是當前的控制檔案。
2.10.4.4. Recovery database using backup controlfile
當有一個Start SCN號超過了System Checkpoit SCN號時，則說明控制檔案不是當前的控制檔案，因此在做recovery時需要採用using backup controlfile。這是為什麼需要記錄SystemCheckpoint SCN的原因之一。
這裡需要一提的是，當重建控制檔案的時候，System Checkpoint SCN為0，Datafile Checkpoint SCN的資料來自於Start SCN。根據上述的描述，此時需要採用using backup controlfile做recovery。