我有一个问题，即试图阻止发布者分发给订阅者的大型交易。假设有人不小心更新了包含5000万条记录的表中的每条记录，然后在意识到错误后，将所有记录设置回来。在这种情况下，更改将在事务复制设置中分发给两个订户。在系统上，它表示将向用户复制2天，但是解决这个问题的最佳方法是什么？
我已经看到使用事务xact_seqno，sp_helpsubscriptionerrors和sp_setsubscriptionxactseqno跳过命令是可能的，实际上非常容易。但是，如果将其用于正在分发的交易，会发生什么？有什么需要停止的吗？
如果这不是解决问题的最佳方法，那会是什么？
答案 0 :(得分：0)
我没有特别测试过这个，但是： 停止正在进行的事务本身不一定会导致问题，它将回滚 - 任何类型的事务，包括来自发布服务器的订阅服务器上的复制事务。这是因为ACID属性始终适用于事务，特别是 A 是Atomicity - 事务中的所有事情都发生，或者什么也没发生。因此，停止或失败的交易将完全回滚。
我不知道有任何其他方法可以阻止复制事务，但是谨慎使用sp_setsubscriptionxactseqno，不仅要确保LSN正确无误，而且无论发生什么，它都意味着你发布者和订阅者不再真正同步。在实践中，这可能无关紧要，但它应该是一个考虑因素。
如果你还没看过Technet / MSDN（或多或少同一篇文章取决于你是否更喜欢devnet的Tnet），如果你还没有，{{} 3}}，那会有所帮助。
注：需要在订阅者（以及您希望跳过的每个订阅者）上运行sp_setsubscriptionxactseqno。
替代方案，没有其他信息，我建议的是让它运行。它可能不是理想的，但它是最安全和最少的工作。系统是否具有关键任务性和时间依赖性，2天将导致重大问题？
最后，如果您不确定该怎么做，作为一般建议 - 将决定权交给您的经理或其他高层。提出选项，涉及的工作和风险/影响（包括无所事事的选择），以及责备（巧妙地和办公室 - 政治上合适的）最初发生“意外”的人（除非那是你，然后也许你不要'我想告诉高层人员。）
答案 1 :(得分：0)
对活动或不活动的事务没有影响。因为这不会影响事务的工作方式，这只会跳过该事务并导致数据完整性问题。
日志阅读器代理读取发布者中更新的所有记录，并在分发者数据库中更新它们，最后将它们标记为已提交......
现在，分发代理程序将应用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
答案 2 :(得分：0)
您的数据完整性有多重要，您的恢复能力如何？您设置复制的批量大小是多少？您可以停止调度程序，只需让当前的xact完成，这样就不会在订阅者上输入回滚。 您可以访问发布者的表并转储事务，但它也会删除记录的任何其他更改。您可能必须在之后重新对齐数据。复制本身应该将更新拆分为较小的事务编号（xact_seqno）。然后您可以从队列中删除记录。确保他们自己没有积压队列。 50M可能会推动您为分发队列表提供的存储限制，因此一旦您开始通过xact_secno清除，请确认没有任何仍在写入的存储。您可以检查那里的命令，看看它是来自同一个大规模更新还是新活动。并且，准备好在您执行此操作时丢失来自其他表或其他表的所有其他数据复制（取决于您设置事务的方式）。并且在重新启动复制之前完成订阅后的重新调整计划。
答案 3 :(得分：0)
根据表的大小，删除/重新添加该文章可能会更快。由于快照使用批量复制将行传输到订阅者，因此它应该非常快。