我有兩個地理上分開的SQL Server 2005實例。使用事務複製將重要數據庫從主要位置複製到次要位置。如何確保SQL Server複製正在運行？
我正在尋找一種方法，可以監控此複製，並在失敗時立即收到警報。
我們曾經有過兩個實例之間的網絡連接關閉一段時間的場合。由於複製不會發生，而且我們也不知道，所以事務日誌會被清空並填充磁盤，從而導致主數據庫中斷。
我的谷歌搜索前一段時間導致我們監測MSrepl_errors表，並警告有什麼條目，但這根本不起作用。最後一次複製失敗（昨晚因此問題），錯誤僅在重新啓動時觸擊該表。
是否有其他人監視複製，你是如何做到的？
只是額外的一點點信息：
看來，昨晚的問題是，日誌讀取器代理死亡，並沒有再次啓動。我相信此代理負責讀取事務日誌並將記錄放入分發數據庫中，以便它們可以在輔助站點上覆制。
由於此代理在SQL Server內部運行，因此我們無法簡單地確定process正在Windows中運行。
我們收到了發送給我們的合併複製失敗的電子郵件。我沒有使用事務複製，但我想你可以設置類似的警報。
最簡單的方法是通過複製監視器進行設置。
轉到複製監視器並選擇特定的發佈。然後選擇警告和代理選項卡，然後配置要使用的特定警報。在我們的例子中，它是複製：代理失敗。
對於此警報，我們將響應設置爲執行發送電子郵件的作業。這項工作也可以做一些工作，包括什麼失敗的細節等。
這適用於提醒我們這個問題，以便我們可以馬上解決它。
您可以定期檢查數據是否正在發生變化，儘管這可能會因應用程序而異。
如果你有某種形式的審計列車表，這是非常定期更新（即我們的主要產品已列出導致數據全部行動基地的審計表被更新或刪除），那麼你可以在查詢該表兩臺服務器並確保您返回的結果是相同的。例如：
SELECT CHECKSUM_AGG(*)
FROM audit_base
WHERE action_timestamp BETWEEN <time1> AND BETWEEN <time2>
其中和是舍入值以允許聯繫數據庫的不同延遲。例如，如果您在過去一小時十點進行檢查，則可能會檢查從最後一小時開始到本小時開始的項目。您現在有兩個小值，您可以在某處傳送並進行比較。如果它們不同，那麼在複製過程中最有可能出錯的是 - 檢查/比較是否會向您發送郵件和短信，以便您檢查並解決需要注意的任何問題。
通過使用SELECT CHECKSUM_AGG（*），每個表的數據量非常小，因此檢查的帶寬使用將是微不足道的。您只需確保您的檢查在適用於服務器的負載中不會太昂貴，並且您不檢查可能是開放複製事務的一部分的數據，因此可能在此時會有所不同（因此檢查審計跟蹤幾分鐘，而不是現在在我的例子中），否則你會得到太多的虛假警報。
根據您的數據庫結構，上述可能不切實際。對於在檢查時間範圍內不是隻讀（不更新或刪除）的表（如上面的審計跟蹤），計算出可以安全比較的內容，同時避免誤報可能既複雜又昂貴，如果實際上並不可能做到可靠。
如果您尚未擁有滾動插入表，您可以製作一個小表（只包含索引時間戳列），並定期添加一行 - 您可以製作滾動插入表存在，因此您可以檢查表的更新正在被複制。您可以刪除比檢查窗口更早的數據，所以表格不應該變大。只測試一個表並不能證明所有其他表正在複製（或者對於這個問題，其他表都是），但在這個表中找到錯誤將是一個很好的「canery」檢查（如果該表沒有更新在副本中，那麼其他人可能不是）。
這種檢查具有獨立於複製過程的優勢 - 您不等待複製過程在日誌中記錄異常，而是主動測試一些實際數據。
您是否有關於實際構成故障的信息？通常當備份在晚上運行時，帶寬會立即阻止複製。沒關係，只要它趕上了，所以我們不需要警報。我想這是一個平衡的行爲... – Damovisa 2009-06-17 00:29:22
說實話，我們還沒有完全弄清楚這一點。有時會觸發警報，但最終複製將成功完成。大多數情況下，當我們的快照正在生成時（我們每週都這樣做），我們會發出虛假警報。當特定的合併代理程序運行並失敗時，警報是真實的並且有意義（通常無法連接到發佈程序類型問題）。 – 2009-06-17 01:08:28