Здесь нет простого способа "проверить" значения дельты. 260 задач репликации обрабатываются независимо друг от друга; независимо от составления транзакций в исходной системе.
Это означает, что если таблицы A и B обновляются в одной транзакции, но реплицируются в отдельных задачах в HANA, данные будут записаны в HANA в отдельных транзакциях. Данные в HANA будут отставать от исходной системы.
Обычно эта разница должна длиться относительно короткое время (может быть, несколько секунд), но, конечно, если вы выполняете агрегационные запросы и хотите видеть текущие действительные суммы и т. Д., Это приводит к неверным данным. .
Один из способов справиться с этим - реализовать запросы таким образом, чтобы это учитывать, например, фильтрация данных, которые были изменены полчаса назад (или дольше), и исключение более новых данных.
Обратите внимание, что, поскольку репликация через LogReader не связана с обработкой транзакций исходной системы, эта проблема «запаздывания данных» заложена концептуально, и ее нельзя избежать, как правило.
Все, что можно сделать, - это уменьшить объем отставать и справляться с различиями в восходящей обработке.
Именно эта проблема является одной из причин того, почему удаленный доступ к данным обычно предпочтительнее репликации для таких случаев, как операционная отчетность. И если вам действительно нужна загрузка данных (например, чтобы избежать дополнительной нагрузки на исходную систему), то подход ETL / ELT к хранилищам данных (DWH / BW-подобный) значительно улучшает структуру.
Фактически, текущие настройки S / 4 HANA и BW / 4 HANA обычно используют комбинацию запланированных загрузок данных и произвольной выборки новых данных через операционные дельта-очереди из исходной системы.
person
Lars Br.
schedule
04.02.2020
