在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

根据表的大小，删除/重新添加该文章可能会更快。由于快照使用批量复制将行传输给订阅者，因此它应该非常快。