Для этих целей есть вот така штуковина Veridata .

Идея работы в следующие:

1) Рядом с каждой из двух баз данных сажают агента (можно и на отдельном сервере).
2) С сервера агентам дается команда бежать по проверяемой таблице, брать неключевые поля, считать по ним контрольную сумму и пересылать их вместе с первичным ключом на сервер. Из практики: сканирование таблицы делается обычно в один поток, чтобы эта нагрузка не создавала помех работе пользователей и могла выполняться круглосуточно.
3) Сервер накапливает в оперативной памяти Первичный ключ+Контрольнную сумму с каждого из двух серверов. Сортирует накопленные данные (они занимают немного памяти, поскольку там именно контрольные суммы, а не сами данные). Сравнивает пары строк пришедших с каждого сервера баз данных.
4) Все различающиеся строки выдергиваются на сервер Veridata целиком и результат сравнения уже реальных строк записывается в репозиторий.
5) Через заданное количество различающиеся строки повторно выдергиваются по первичному ключу и повторно сравниваются. Делается это для того, чтобы отловить in-flight данные, которые отличались лишь потому, что в репликации есть некоторая задержка. Если строки различаются и после повторной проверки, то они попадают в отчет.
6) Результатом работы является веб-отчет + XML-отчет (его используют для пересинзронизации данных).

Проверяли на очень больших объемах - схема вполне себе рабочая. Вот тут есть подробности .

SintetikAlexander RyndinДля этих целей есть вот така штуковина Veridata .

вещь наверное хорошая если используется бесплатная самописная или встроенная в базу репликация. Но если приобретается промышленный CDC, да его еще и проверять надо, то спрашивается зачем нужен такой CDC?
Прикинь как бы вы продавали GG, если бы за ним еще и подчищать нужно было бы за дополнительные деньги?Проверять нужно, если заказчик серьезный. Никто ведь не отменял
1) Баги в софте
2) Кривые руки
Кроме того, Veridata еще и генерит данные для ресинхронизации.