現在有這樣的環境
一台web Server一個是純JAVA APP 程序
數據庫兩台做成RAC的形式 web Server與APP 程序都通過oci(rac)的方式連接
數據庫
出了這樣的怪問題webServer更新或是插圖入一條數據後面緊跟著的在APP中就查詢不到等到用工具查詢就沒有問題
初步懷疑
RAC方式下面的數據庫兩個instance的同步沒做好？
查詢相關資料發現在與MAX_COMMIT_PROPAGATION_DELAY有關
最大提交傳播時延（MAX_COMMIT_PROPAGATION_DELAY簡稱MCPD）在ORACLE RAC(或OPS)環境中才使用表示在RAC系統中一個instance系統提交產生的最新系統改變碼（SCN）能夠以多快的速度反應到另一個instance中
舉例說明RAC系統有AB兩個實例（instance）AB本地系統改變碼為SCNA更新數據DATA提交 LGWR操作完成後A本地系統改變碼為SCN經過不大於MAX_COMMIT_PROPAGATION_DELAY時間後B系統本地改變碼才變為SCN
Global Cache Services 將刷新RAC中的SCN不管SCN是否及時刷新後續的數據查詢都不會因此產生數據庫錯誤但在此時間內有可能查詢結果不是最新數據產生讀一致性（read consistency）問題
RAC環境中的所有實例此參數值必須相同
ORACLEi後建議常用的兩個值是和（默認）其他數值皆不建議其實這兩個數值就代表了RAC環境中兩種SCN 產生機制
Lamport Scheme和 Broadcast on Commit scheme
設置為默認值表示采用Lamport SchemeSCN改變不會完全同步同步將在 秒鐘內完成而不是總等待秒鐘後才完成如果系統比較空閒同步可能在秒（甚至更短時間）內完成不管系統多繁忙同步時間也不可能超過秒不難理解采用此模式整個RAC系統的運行效率較高
設置為表示采用Broadcast on Commit schemeSCN改變完全同步每當commit時（即LGWR 寫redo log時）
－ LGWR發送消息更新全局SCN（global SCN）
－ LGWR 發送消息給每個活動的實例更新其本地SCN（local SCN）
有資料說只要MCPD < 系統將采用Broadcast on Commit scheme
Lamport Scheme能夠適應絕大部分應用的要求只有個別實時性特別高的業務才需要Broadcast on Commit scheme通過分析不難理解Broadcast on Commit scheme將需要更多的系統資源
From:http://tw.wingwit.com/Article/program/Oracle/201311/16600.html
