在常見的企業數據平台管理中有一項任務是一直困擾SQL Server DBA們的，這就是對數據更新的監控。很多數 據應用都需要捕獲對業務數據表的更新。筆者見過幾種解決方案：
1、在數據表中加入特殊的標志列；
2、 通過在數據表上創建觸發器；
3、通過第三方產品，例如Lumigent的Log Explorer。
其實第1種和第2中方案都不好，因為第1種方法需要在應用程序編碼的時候尤為小心，如果有一段數據訪問邏輯 忘了更新標志位就會導致遺漏某些數據更新，而第2種方法對性能影響過於明顯，因為觸發器的性能開銷是眾所周 知的。第3種方法其實屬於一種叫做Log Audit的方案體系。因為SQL Server同其他關系型數據庫一樣，所有數據操 作都會在日志中記錄，因此通過分析日志就可以獲得完整的數據操作歷史。SQL Server其實早就有內部的API可供 ISV開發者中Log Audit的方案，不過微軟對這套API控制比較嚴格，只有簽署了一堆協議的核心級合作伙伴才能了 解這套API。
因此，現對業務數據更新的跟蹤在SQL Server平台上一直是一件非常頭疼的事情，用戶需要在投入大量開發精 力和投入額外采購成本之間做出選擇。幸運的事，微軟終於在SQL Server 2008中提供了一套半公開的Log Audit機 制，就是我們所說的Change Data Capture，我們後面簡稱CDC。
CDC的工作原理
我們前面說過CDC是通過分析日志獲得數據操作歷史信息的，那麼CDC的工作原理到底是怎麼樣的呢？下圖可以 非常貼切地說明這個功能的原理：
圖1
◆當DML提交到應用數據庫時，SQL Server必須寫入日志，並在緩存中更新數據，然後在檢查點將內存中的數據 刷回數據文件。
◆CDC的內部進程根據CDC的設置，在日志文件中提取更新歷史信息，並將這些個更新信息寫入對應的更新跟蹤 表。
◆DBA或開發人員通過調用CDC的函數來訪問更新跟蹤表，提取感興趣的更新歷史信息，並通過ETL應用程序更新 數據倉庫。
◆理論上面更新跟蹤表事會無限制增長的，因此CDC內部有一個清理進程，在默認情況下更新跟蹤信息在寫入跟 蹤表三天後會被自動清理。
CDC的配置
由於CDC是一項比較高端的功能，因此只有在SQL Server 2008的企業版、開發版和評估版中才能找到CDC功能。
