How to troubleshoot inconsistencies in Publisher and subscriber content in replication

During transactional replication, there are times when data between the Publisher and Subscriber is inconsistent for a variety of reasons, often due to one of several reasons:

An agent ran an error or the agent process crashed

A larger publication uses backup restores instead of snapshot replication initialization, and the data is modified by the publisher after the backup

Non-Distribution Agent thread modifies subscriber's data

The above three scenarios are the most common cause of inconsistencies between the Publisher and subscriber data. One of the third reasons is often the most, in which case, it is generally possible to reinitialize the subscription to solve the problem, but for larger subscriptions, or too far apart between the publication and subscription, causing network broadband problems, Then reinitialize the subscription is not such an appealing proposition. Therefore, it is better to use data Contrast analysis tool to compare data with difference, and to update only those data that are not synchronized with the source.

Such tools include data-comparison tools like Redgate and xSQL, or you can use the data comparison tool that is available with Visual Studio, and I'll show you how to solve the problem with a simple demo.

DEMO

Now that I've built a publisher and subscriber, the Publisher Careyson-sql publishes the SalesOrderDetail entire table of the sample database AdventureWorks, and the Subscriber sqlazur\sql2012 subscribes to the table. As shown in Figure 1.

Figure 1. Basic Replication Information

At this point, I am deleting data artificially at the subscriber, resulting in inconsistent data between the Publisher and Subscriber, as shown in Figure 2.

Figure 2. Manually deleting data at the subscriber causes inconsistencies

We'll come back to the server-side verification subscription, as shown in Figure 3.

Figure 3. Verifying subscriptions