I am seeing data inconsistency in row count Transactional Replication. Subscriber is having 20 rows extra. The agent profile is used continue on data consistency error. The replication is working fine. I want to know, Do I need to fix remove the extra 20 rows from subscriber? (OR) remove table from replication and add re-initialize the single article? (OR) Shall I leave as it is. Can anyone suggest.
1 Answer
Do I need to fix remove the extra 20 rows from subscriber? (OR) remove table from replication and add re-initialize the single article? (OR) Shall I leave as it is.
That depends on what those 20 rows mean. Were they manually inserted on the Subscriber side intentionally? Or are they bad data / wrong to be in that table. The answer to that question will determine your course of action.
If the rows aren't hurting anything, replication is running fine, and we're inserted intentionally by someone, then leave them. If you don't know where they came from, and are bad data, then you can reinitialize to remove them, assuming your table's Article properties are set to DROP, TRUNCATE, or DELETE.
Note, you don't need to remove a table's Article from replication, in order to reinitialize it. But you can tell it to "Use a new Snapshot" when you reinitialize, if you want a clean slate essentially.
-
1Thanks JD for the response. It helps me. I will check with the users. For new snapshot I hope you mean only for single table not for entire publication. Nov 17 at 16:05
-
@Raja_mssqlDBA No problem! Using a new Snapshot will cause the entire Publication to be re-synchronized but if your Publication is big then yes you can just remove and re-add the table Article from your Publication (as you initially mentioned) and hopefully it lets you reinitialize without using a new Snapshot, which will then only do that 1 table.– J.D.Nov 17 at 16:11