How large is the data and how fast are the links between the databases and each other (and you)? There are a number of ideas:
If the data is small enough that this is practical, run SELECT * FROM <table> ORDER BY <pk>
on each DB, save the results to a tab or comma delimited file (not space aligned as that blows up the resulting file size massively) and compare the resulting output with your preferred diff type utility such as winmerge. That way you are comparing absolutely all the data.
If the databases can see each other (most likely as they are able to operate as replication partners) and the link between them is high enough bandwidth and low enough latency, you could use the linked server functionality (see http://msdn.microsoft.com/en-us/library/ms190479.aspx and related documentation) to and compare compare the contents of the tables in a couple of SQL statements (listing the the rows in <table>
that do not have identical rows in <linked_server>.<db>..<table>
and vice versa) just as you would compare the contents of two local tables. This is a relatively slow option potentially, but could be quite a powerful check to automate.
If you are needing to use checksums because you want to greatly reduce the amount of data needing to be transferred, use HASHBYTES
rather than the CHECKSUM
family of functions as you can use better quality hashes so you are more assured by them coming out equal. This is more CPU intensive, but for large amounts of data you will be I/O bound not CPU bound anyway so will have many cycles going spare (and for small amounts is simply won't matter).
As a middle-ground between comparing all the data character-for-character and comparing a single checksum covering all of the data, you could export SELECT <pk>, HASHBYTES('SHA1', <all-other-fields-concatenated>) ORDER BY <pk>
from each database and compare those results to see if they are identical (or SELECT HASHBYTES('SHA1', <all-other-fields-concatenated>) ORDER BY <pk>
to reduce the amount of data flowing, but having the PK in the output will mean you can identify the rows that differ, if any do, with less further queries). Of course this last option is pointless if the data in the average row is smaller than the resulting hash, in which case the "compare everything" option will be more efficient.