停止在 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，那'会帮忙的。 注： sp_setsubscriptionxactseqno 需要在订阅服务器上运行（以及您希望它跳过的每一个）。

替代方案，没有其他信息，我建议让它运行。它可能并不理想，但它是最安全和最少的工作。系统是否具有关键任务和时间依赖性，这 2 天会导致严重问题？

最后，作为一般建议，如果您不确定该怎么做 - 将决定交给您的经理或其他上级。提出选项、所涉及的工作和风险/影响（包括什么都不做的选项），并责怪（巧妙地和办公室政治上适当的）造成最初“事故”的人（除非那是你，那么也许你没有”不想告诉上级）。

Answer 2

您的数据完整性有多重要，您的恢复能力如何？您设置复制的批量大小是多少？您可以停止调度程序并让当前的 xact 完成，这样您就不会在订阅者上输入回滚。 您可以访问发布者的表并转储事务，但它也会删除记录的任何其他更改。之后您可能需要重新对齐数据。复制本身应该将更新拆分为更小的事务编号 (xact_seqno)。然后您可以从队列中删除记录。确保他们自己的队列中没有积压。 50M 可能会推动您为分发队列表提供的存储限制，因此一旦您开始通过 xact_secno 进行清除，请确认没有仍在写入的内容。您可以检查那里有哪些命令，看看它是来自同一个大规模更新还是新活动。并且，准备好丢失来自其他表的所有其他数据复制，或者在您执行此操作时（取决于您如何设置事务）。完成后，在重新启动复制之前为订阅者制定重新调整计划。

Answer 3

对任何活动的事务都没有影响。因为这不会影响事务的工作方式，这只会跳过该事务并会导致数据完整性问题..

日志阅读器代理读取发布者中更新的所有记录，并在分发者数据库中更新它们，最后将它们标记为已提交...

现在分发代理会应用时间戳高于 msreplication_subscriptions 表中 transaction_timestamp 列的所有命令

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 4

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