CDC и рассинхронизация

Как решается проблема если вдруг обнаруживается расхождение в данных между источником и приемником если данные синхронизируются при помощи CDC?

У нас IBM CDC перегоняет данные с DB2 z на Netezza, как-то умудрились получить рассинхронизацию, дока на этот случай предлагает сделать refresh т.е. truncate и полную перезаливку данных, есть differintiate refresh, но к сожалению он не доступен для Netezza.

К сожалению механизма чекпоинтов или аналогичного я не смог найти.
На ум приходит делать еще дополнительно сверку количества строк по итогам дня, и если что перезаливать день ETL средством. Но если проблему пропущенных инсертов можно будет решить, то расхождения по содержанию нет. А если начать сравнивать построчно, то теряется весь смысл внедрения CDC для размазывания нагрузки по времени.

День добрый, а можете пояснить, мне просто интересно, помочь пока не знаю как...

- Как вы налетели на рассинхрон?
- Как ваша среда выглядит (DB2z -> CDCz -> CDCn -> NZ) ?
- Это именно CDC или CDD, то есть есть через DS заливаете?
- Вы, я так понимаю, хотите какой-то контроль прикрутить?

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

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

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

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

Sintetik,

действительно, Note: Differential Refresh is not available for InfoSphere CDC for Netezza databases engines.

Насчёт того, что проблему расхождений по содержанию нельзя решить с помощью ETL - ну не знаю, не у вас DataStage был - тогда какие проблемы? Но да, выгрузить исходную табличку придётся целиком - большая таблица-то?

И как вы поймали рассинхрон, можно узнать, а также в чём он заключается?

Спасибо.

Hunterik
День добрый, а можете пояснить, мне просто интересно, помочь пока не знаю как... - Как вы налетели на рассинхрон? - Как ваша среда выглядит (DB2z -> CDCz -> CDCn -> NZ) ? - Это именно CDC или CDD, то есть есть через DS заливаете? - Вы, я так понимаю, хотите какой-то контроль прикрутить?

1. не известно, на исходной системе было много недокументированных транзакций-откатов + остановка сервиса CDC, повторить невозможно, просто в какой то момент увидели разницу. Такое впечатление что сервис на источнике пропустил часть лога. Но логи не затираются по кругу.
2. именно так
3. CDC 10.2.1
4. если нет гарантированной доставки стоит вопрос о применимости CDC

Hunterik
Sintetik, Насчёт того, что проблему расхождений по содержанию нельзя решить с помощью ETL - ну не знаю, не у вас DataStage был - тогда какие проблемы? Но да, выгрузить исходную табличку придётся целиком - большая таблица-то? И как вы поймали рассинхрон, можно узнать, а также в чём он заключается? Спасибо.

У меня, но если включать DS, то тогда зачем CDC?
Таблица немаленькая, сотни миллионов записей и это только пилот, потом будут миллиарды.

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

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

Sintetik, тогда привлекайте IBM, раз у вас пилот и пошла такая пьянка.

Может, вам там скажут, что вы сделали не так, ведь вполне возможно, что дело в каких-то настройках, если же дело в продукте... Расскажите потом.

Очень интересно. =)

Sintetik
Alexander Ryndin Для этих целей есть вот така штуковина Veridata. вещь наверное хорошая если используется бесплатная самописная или встроенная в базу репликация. Но если приобретается промышленный CDC, да его еще и проверять надо, то спрашивается зачем нужен такой CDC? Прикинь как бы вы продавали GG, если бы за ним еще и подчищать нужно было бы за дополнительные деньги?

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

Alexander Ryndin
Никто ведь не отменял 1) Баги в софте

в нашем случае тогда проще сам софт отменить, и все делать через ETL, он отрабатывает гарантированно, по крайне мере если валится, то не получается что частично данные прошли, а частично нет. У тебя по ссылке в комментах правильно написали - если нет изменения структуры, то должно работать железно, технология старая и отлаженная.