Lately I've noticed more companies using replication to copy data to remote sites. Another common replication scenario involves copying data from a source to a destination location before a company switches over to a new server or storage area. Often replication occurs over VPNs and sometimes over slower network links. Should a replication not work correctly and synchronizations not finish or actually fail, the systems administrator or data owner might be unaware of the problems until users complain about obsolete or missing data. I've written a batch script, ReplicationTest, which makes dealing with such difficulties easier by notifying administrators and data owners of data-variation problems that occur during replication and that warrant further investigation. Let's delve into the workings of the script.
The Problem: Compare Source and Destination Files
Often, data on the master or source location is in a writeable state, whereas the remote (i.e., destination) location is read-only. Therefore, changes to files at the source location might not always instantly be reflected at the destination location until after replication finishes. If you take a snapshot of the directory size and number of files on the source, these values could be different on the destination location until replication to the destination is triggered by changes or time-of-day scheduled copy operations. Consequently, comparing the source and destination locations at any point in time might reveal small differences in the directory size and file count between the two areas, even if replication is working correctly. However, if the size and file count on the master and destination locations differ significantly, you'd probably need to investigate further to determine whether you have a replication configuration problem or a network link that can't adequately support replication traffic. . . .
