數據庫同步程序如何保證事務裝載高效又完整

數據庫在設計之出，除了滿足數據規範管理，查詢統計方便，數據結構設計方便之外，最大的功能就是保證事務完整性了；當事務提交(commit)時，要保證內部所有交易成功才返回成功，否則要回滾(rollback)，保證所有數據回退到提交之前的狀態。

      無論在證券系統、銀行系統、稅務系統、電信計費系統、電力系統，只要涉及到一個交易多表或者多記錄同時操作，爲了讓多條記錄能夠保持多條聯動，都必須用到事務提交，所以事務是數據庫爲滿足交易數據多條SQL語句執行完全成功或完全失敗而設計的保證交易一致性的SQL語句組合。

      在數據庫同步過程中如何保持事務的完整性呢？如果不考慮執行效率，我們可以很簡單的設計爲，抽取到日誌後，記錄事務流水，轉換流水，裝載事務，修改流水狀態，這樣一個事務的同步就完成了；即使最後一步失敗，我們也可以根據最後事務中不同的DDL和DML語句來分析該語句在備庫的執行狀態，之後再決定繼續執行還是執行下一個事務，這就是斷點

      但是我們在進行數據庫同步項目實施的過程中，不斷出現一個問題：如果事務串行加載，那對於銀行、證券等行業晚上的批處理交易而言，就出現很大效率問題，因爲對於抽取進程，我們一定要把日誌中成功提交的日誌進行同步，對於失敗的交易我們不應該再去進行抽取和分析，但是如果大交易（100萬SQL語句/筆），提交後，會產生大量日誌，我們分析日誌的時候會記錄事務日誌流水，這樣磁盤I/O就產生很大的瓶頸，假設該事物產生的事務日誌爲100W*1024Bytes=1G,如果每秒磁盤IO速度是40M，那麼需要25秒，這就說明當主庫日誌產生後，我們抽取進程通過網絡（假如網絡100M獨享）獲得日誌需要10秒），那麼從日誌抽取到寫入到流水文件至少要35秒時間才把一個大事務寫完成，如果我們再考慮裝載速度，一個事務裝載效率是遠程SQL執行時間+回寫完成狀態時間，如果我們把這個過程最小化：數據庫連接使用長連接，裝載用OCI批量裝載，則裝載SQL執行時間大約爲1000秒，回寫時間25秒，則裝載總用時約爲1025秒，加上抽取的35秒，接近18分鐘，所以對於同步效率要求比較高的金融行業來說，同步災備系統18分鐘就有些慢了，但是這種方式對於事務完整性來說確實很簡單的方法，每次執行都會寫入事務斷點，所以串行效率低但依然很有效，那麼如何合理提高裝載效率呢？

      目前基於交易日誌方式同步的技術在裝載上考慮最多的是並行裝載，其實很簡單，就是把事務按照表來分解爲表級別串行數據，不同的進程來完成不同表的裝載，這樣裝載時間按照就是1000/N，表越多，數據庫裝載效率越高，當然，數據庫連接也越多，佔用備庫資源也越多，但是對於備庫只作爲查詢服務器來說，佔用資源並不會對系統用什麼影響，又何況是晚上的數據庫呢？

      但是雖然這樣提高了裝載效率，事務卻被我們分解成了很多的小交易，都是基於不同表的，那當中間執行出錯情況下，如何保證事務完整性呢？這就要用到從前我們提到的網格斷點來實現（參見《如何保證數據庫同步中目的端交易提交的原子性》），當每個進程執行成功後就會修改自己對應的斷點文件，所以當系統出現異常的時候我們就會檢查所有的斷點文件，這樣數據庫就可以根據斷點情況繼續同步對於不同的DDL和DML語句進行相應的錯誤處理，無斷點的進程會將同步執行完畢，有斷點的會停留在斷點處，等帶人工判斷。