Oracle9i, 10g RAC中管理SCN演算法不同導致的資料問題

SCN概念

SCN 是Oracle 用來跟蹤資料庫內部變化發生的先後順序的機制，可以把它想象成一
個高精度的時鐘，每個Redo日誌條目，Undo Data Block，Data Block 都會有SCN
號。 Oracle的Consistent-Read， Current-Read， Multiversion-Block都是依賴
SCN 實現。SCN是順序遞增的一個數字，它的最大值是0xffff.ffffffff 。

對SCN的管理，可以分為單例項和RAC : 

單節點的instance中，SCN值存在SGA區，由system commit number latch保護。
任何程式想要得到當前的SCN值，都要先得到這個latch。

RAC環境中，Oracle透過排隊機制(Enqueue)實現SCN在各並行節點之間的順序增長。
具體有兩種方法：

Lamport演算法： 在所有節點間的通訊內容中都攜帶SCN， 每個節點把接收到的SCN和本
機的SCN對比，如果本機的SCN 小，則調整本機的SCN和接收的一致，如果節點間通訊
不多，還會主動地定期相互通報。 故即使節點處於Idle 狀態，還是會有一些Redo
log 產生。Oracle9i及10.1 RAC預設採用這種方式。

Commit廣播(Broadcast)演算法： 在每個Commit操作之後，節點要向其他節點廣播SCN，
雖然這種方式會對系統造成一定的負載，但是確保每個節點在Commit之後都能立即查
看到SCN. Oracle10g r2 RAC預設採用這種方式。

上述兩種演算法可以透過調整初始化引數max_commit_propagation_delay來切換。在
Oracle9iRAC中 , 該引數的預設值都是700釐秒(centisecond)，採用Lamport演算法。
如果該值小於100釐秒，Oracle就採用廣播演算法，並且記錄在alert.log檔案中，
Oracle10g R2 RAC預設為 0，採用commit廣播演算法,10g R2 RAC的alert log 類似：

Sun Nov  7 02:07:56 2010
ALTER DATABASE OPEN
This instance was first to open
Picked broadcast on commit scheme to generate SCNs
Sun Nov  7 02:08:01 2010
LGWR: STARTING ARCH PROCESSES

這兩種演算法各有優缺點，Lamport演算法雖然負載小，但是節點間會有延遲(提交了但
是還沒有傳遞給其他節點)，commit廣播演算法雖然有負載，但是沒有延遲。 Oracle
10g R2 RAC 預設選用的是BroadCast演算法。

 

網路資料：

--------------------------------------------------------------------

這幾天我有一個客戶的資料庫出現了這樣的情況，在一個3節點的RAC上，其中一
個節點上修改的資料，馬上在另外一個節點上查，發現有千分之5左右的資料沒有
更新，要過一會才能查到正確的結果。這造成了應用軟體的業務邏輯錯誤。

透過分析，發現是SCN的傳播機制導致。由於Oracle 9i預設的傳播模式是lamport
演算法，SCN在例項間傳遞是透過GCS MESSAGE來傳遞的，因此就會造成一定的延時。
LAMPORT演算法可以減少例項間同步SCN所造成的效能問題，但是在變更十分頻繁的系
統中，可能出現上述的問題。因此在這種情況下，客戶首先把這個應用全部部署
在一個節點上，以避免業務邏輯的問題。如果無法透過應用調整來解決，那麼就
必須調整MAX_COMMIT_PROPAGATION_DELAY來改變傳播演算法了。

一般來說這個引數在9i和10.1的預設值是700（TRU64除外）也就是7秒鐘，實際上
這是一個上限了，因為lck每隔3秒鐘會有一個例行的資訊包交換，一般情況下，
3秒鐘肯定會完成一次scn傳播。這個引數，如果設定為0-99，那麼資料庫會選擇
Broadcast-On-Commit演算法，由LGWR來傳播SCN。一般來說我們可以設定為0-99或
者保留原有的值不懂，沒有十分可靠的分析證據的情況下，建議不要設定100-700
之間的值。

10.2開始，lgwr傳播SCN的演算法有了很大的改進，因此10.2預設使用
Broadcast-On-Commit，這個引數的預設值也變為0.
--------------------------------------------------------------------