在SQL Server中停止複製大型事務

Question

我有一個關於試圖阻止向發佈者分發給訂閱者的大型事務的問題。假設有人不小心更新了一張包含5000萬條記錄的表中的每條記錄，然後在意識到自己的錯誤時將所有記錄重新設置回來。在這種情況下，這些更改將在事務複製設置中分配給兩個訂戶。在系統上它表示它將會複製到用戶2天，但是克服這個問題的最好方法是什麼？

我已經看到這是可能的，事實上很容易跳過使用交易的xact_seqno,sp_helpsubscriptionerrors和sp_setsubscriptionxactseqno命令。但是，如果將此用於正在積極分發的交易，會發生什麼？有什麼需要停止的嗎？

如果這不是解決問題的最佳方法，那會是什麼？

Answer 1

但是我沒有特別測試過這個： 停止正在進行的事務本身並不一定會導致問題，它會回滾 - 任何類型的事務，包括髮布者在訂閱服務器上的複製事務。這是因爲總是適用於交易的ACID屬性，特別是，A是Atomicity - 事務中的所有內容都發生，或者什麼都不發生。所以停止或失敗的交易將完全回滾。

我不知道有任何其他方式可以停止正在複製的交易，但謹慎使用sp_setsubscriptionxactseqno，您不僅需要確保您的LSN正確無誤，而且無論發生什麼事情，都意味着您是發佈商和訂閱者不再是真正的同步。實際上這可能並不重要，但應該是一個考慮因素。

如果您尚未看看Technet/MSDN（或多或少的同一篇文章取決於你是否喜歡DEVNET的TNET），如果你還沒有準備好，並this blog post on MSDN，這會幫助你。 N.B.需要在訂購者（以及您希望它跳過的每一個訂單）上運行sp_setsubscriptionxactseqno。

另一種方式，沒有其他信息，我建議只是讓它運行。這可能不是理想的，但它是最安全和最少的工作。該系統的任務關鍵和時間依賴性，2天會造成重大問題？

最後，作爲一般建議，如果您不確定要做什麼 - 請將決策權交給您的經理或其他更高層。提出選擇方案，涉及的工作和風險/影響（包括無所作爲的選擇），以及責備（巧妙地和辦公室政治上合適的）做出最初「事故」的人（除非那是你，那麼也許你不會）不想告訴上級）。

Answer 2

沒有影響whatsover成交活躍或not.since這不會影響交易是如何工作的，這只是跳過該交易，並會導致數據完整性問題..

日誌讀取器代理會讀取所有更新的記錄出版商和分銷商在更新DB他們，最後將其標記爲致力於...

現在代理經銷然後應用具有比transaction_timestamp列高時間戳msreplication_subscriptions表中的所有命令

select publisher_database_id, xact_id, xact_seqno, entry_time from msrepl_transactions order by publisher_database_id 

所以基本上我們正在談論，如何讓用戶從另一個命令開始，甚至跳過那些..您可以在用戶數據庫使用以下命令跳過該事務..

sp_setsubscriptionxactseqno [ @publisher = ] 'publisher' 
     , [ @publisher_db = ] 'publisher_db' 
     , [ @publication = ] 'publication' 
     , [ @xact_seqno = ] xact_seqno 

Answer 3

如何重要的是你的數據的完整性，什麼是您的恢復能力？您設置了哪種批量大小的複製？您可以停止調度程序，只讓當前的xact完成，以免對訂戶輸入回滾。 您可以訪問發佈者的表並轉儲事務，但它也會刪除記錄的任何其他更改。之後您可能需要重新調整數據。複製本身應該將更新分成更小的事務數（xact_seqno）。然後你可以從隊列中刪除記錄。確保他們自己的隊列沒有積壓。 50M可能會推動你給分配隊列表的存儲空間的限制，所以一旦你開始用xact_secno清除，確認沒有任何東西仍在寫入。你可以檢查那裏有哪些命令，看看它是來自同一個大規模的更新還是新的活動。並且，準備從其他表中或其他表中刪除所有其他數據複製，或者根據您設置事務的方式從此複製數據複製。在重新啓動複製之前，完成用戶的重新調整計劃。

Answer 4

根據表的大小，刪除/重新添加該文章可能會更快。由於快照使用批量複製將行傳輸給訂閱者，因此它應該非常快。