我们正在尝试在SQL Server 2005数据库上设置复制。在过去的一年里，我们遵循了一些指示，一切都很好。最近，它开始失败(开发环境，所以我们每周重建数据库..并应用复制)。
我们遵循一组步骤，快照生成…并应用于复制的数据库。所有的罚款。没有错误。
然后向源数据库添加新行，然后砰!错误。
命令尝试:如果@@trancount> 0，回滚tran(事务序列号:0x000004BE00000558000100000000，命令ID: 1)错误消息:应用复制命令时，在订阅服务器上找不到该行。(来源:MSSQLServer，错误号:20598)
我们正在插入一行，但它抱怨该行不在订阅者上。不过，这是对的。我们希望它将插入复制到订阅者…
当我们对源和目标执行SELECT COUNT(*)时，行数是相同的，直到我们执行INSERT，此时源增加，但目标保持不变....
你知道我们可以从哪里开始找吗?
呃…这个错误很糟糕。当您说插入了一行时，我假定您是在发布服务器上插入的。这是行不通的;复制按顺序下发命令。也就是说，它不会复制插入缺失行的事实，直到它越过当前的错误。
我们从这里开始。在错误消息中，我们看到一个事务序列号。我们可以用它来确定缺失行的主键。在分发服务器上，有一个名为sp_browsereplcmd的存储过程。您可以为@xact_seqno_start和@xact_seqno_end参数插入事务序列号。您还将在存储过程中看到command_id参数;这对应于错误消息中的命令ID。尝试只使用指定的这些参数执行过程。它应该向您提供它试图在订阅者上执行的命令。从那里，您可以告诉要尝试更新或删除的行的主键。然后可以在订阅服务器上插入带有该主键的行，复制将继续进行。
或者，您可以从该订阅者中删除该项目，重新添加该项目，并重新初始化该项目。它在服务器上有点紧张，但不那么繁琐。
这是由于发行者数据库上的数据损坏，当我们运行DBCC检查数据库允许数据丢失时，我们面临相同的复制错误。
最后我们试着像
那样做RCA1)。通过在脱机模式下执行CHKDSK检查存储错误2)。清除表，如果它有很多数据。在我们的例子中，我们有4000万行。
在我们的案例中，这个问题在清除数据后就消失了