SQL Replication error - row was not found at the Subscriber

We are trying to setup replication on a SQL Server 2005 database. We have followed some instructions for the past year, and all has been fine. Recently, it started failing (Development environment, so every week we rebuild the database.. and apply replciation).

We follow a set of steps, snap shot gets generated.. and applied to the replicated database. All fine. No errors.

We then add a new row to the source database, and bang! Error.

Command attempted: if @@trancount > 0 rollback tran (Transaction sequence number: 0x000004BE00000558000100000000, Command ID: 1) Error messages: The row was not found at the Subscriber when applying the replicated command. (Source: MSSQLServer开发者_高级运维, Error number: 20598)

We're inserting a row, but it's complaining that the row isn't on the subscriber. That's right, though. We want it to replicate the insert to the subscriber...

When we do a SELECT COUNT(*) on both the source and the destination, the row count is the same, until we do the INSERT, at which point, the source incriments, but the destination remains the same....

Any ideas where we can start looking?

Ugh... this error sucks. When you say that you inserted a row, I assume that you inserted it at the publisher. That's not going to work; replication delivers commands serially. That is, it won't replicate the fact that you inserted the missing row until it gets past your current error.

So, here's where we start. In the error message, we see an transaction sequence number. We can use that to determine the primary key of the missing row. At the distributor, there's a stored procedure called sp_browsereplcmds. You can plug in the transaction sequence number in for both the @xact_seqno_start and @xact_seqno_end parameters. You'll also see a command_id parameter in the stored procedure; this corresponds to the Command ID in your error message. Try executing the procedure with just those parameters specified. It should give you the command that it's trying to execute at the subscriber. From there, you can tell the primary key of the row that it's either trying to update or delete. You can then insert a row with that primary key at the subscriber and replication will move on.

Alternatively, you could drop this article from this subscriber, re-add it, and re-initialize that article. It's a bit more intense on the server, but is a lot less fiddly.

This is due to data corruption on publisher database,we faced the same replication errors,when we ran DBCC check DB with allow data loss.

Finally We tried doing RCA like

1.) Checking for storage errors by doing CHKDSK in offline mode 2.)Purging the table if it has a lot of data ..in our case we had 40 million rows.

The issue was gone after doing Purging data in our case