2012-03-29 66 views
4

我正在尋找一種最佳實踐或示例,說明如何能夠爲給定的SQL Server 2008 R2數據庫上的所有更新事件生成事件。爲了更具描述性,我正在開發一個POC,我將本質上將更新事件發佈到一個隊列(本例中爲RabbitMq),然後可以由各種消費者使用。這將是通過事件採購實現CQRS只查詢數據模型的第一部分。通過放置任何人都可以訂閱這些事件以便複製到任意數量的僅限查詢的數據模型中。這部分清晰明確。我遇到的問題是確定從SQL服務器生成事件的最佳方法。我已經給出了一些想法,比如監視事務日誌和SSIS。但是,我不完全確定這些選項是否可以提供建議或者甚至是可行的。從SQL服務器生成事件

有沒有人對這類事情有過任何經驗,或者對如何去探索這樣的冒險有任何想法?任何幫助或指導將不勝感激。

+0

你用什麼來將東西存儲到SQL Server中? – 2012-03-29 07:35:37

回答

9

不能監控日誌,因爲即使如果你就可以瞭解它,你有日誌的問題被回收你有機會讀它之前。除非日誌以某種方式被標記爲不被截斷,否則將被重用。例如,啓用事務複製時,日誌將被鎖定,直到被複制代理讀取,並且只有,然後被截斷。

SSIS是一個非常廣泛的概念,並且說'使用SSIS來檢測變化'類似於說'我將使用編程語言來解決我的問題'。詳細信息是如何使用SSIS?無論是否使用SSIS,都無法可靠地檢測任意模式上的數據更改。即使是專門設計用於檢測更改的數據模型也存在問題,特別是在檢測刪除時。

但是,有可行的替代方案。您可以部署Change Data Capture並委派給引擎本身來跟蹤更改。消費這些檢測到的變化並將它們發佈給消費者(通過RabbitMQ,如果這是你的想象) SSIS將擅長的東西。但是你必須明白,SSIS對於連續性,實時任務來說並不好。它的設計是爲了批量定期運行,所以當SSIS作業運行時,您的更改通知消費者將會收到高峯通知,並且延遲很長(分鐘)。

對於實時方法,更好的解決方案是Service Broker。一種可能性是SEND來自觸發器的Service Broker消息,但我不會推薦它。一個更好的設計是讓應用程序自己發佈SEND的更改 - 在進行數據修改時明確地顯示消息。對於其他SQL Server使用者(包括SQL Server Express),使用SQL Server 2012可能爲multicast Service Broker messages。 SSB消息傳遞完全是事務性的(如果事務回滾,則不發送消息),並且不需要與消息存儲資源管理器一起進行兩階段提交。但要通過RabbitMQ進行廣播,您需要橋接通信,即。 RECEIVE SSB消息並將它們轉換爲RabbitMQ通知。

+0

完美!正是我在找什麼。我不相信SSIS是我的解決方案,因爲我需要更多的實時數據。 (不是100%實時但接近)。讓應用程序發佈更改將是理想的。但是,我們目前有許多不同的切入點,以不同的語言和不同級別的支持。改變所有這些可能被認爲太繁重。我將首先調查Change Data Capture,因爲它似乎最符合我所尋找的內容。謝謝! – RockyMountainHigh 2012-03-29 18:03:00