Доброго дня всем!
Если будет время, посмотрите, нет ли каких-то нехороших моментов в моем подходе.

Стоит задача отправлять на удаленную (не DB2) систему данные, которые были изменены с момента предыдущей отправки.
Данные для передачи представляют собой соединение нескольких таблиц, одна из которых базовая и своим идентификатором определяет изменившуюся позицию.
Напрямую использовать CAPTURE нецелесообразно. Посмотрел в сторону MQT, изменения для которой накапливаются в STAGING таблице.
Из этих изменений нужны только идентификаторы позиций, а остальные данные вытаскиваются по ним из таблиц более сложным запросом в подготовленном для целевой системы виде.
Проверил, все работает вроде как надо.

Мои объекты, чтобы понятно, о чем речь:
MV_ITEMS - MQT
MV_ITEMS_STAGE - промежуточная (staging) таблица для MQT
V_ITEMSXML - вью с подготовленными для целевой системы данными

Чтобы взять изменения на целевую систему, планирую делать так:

--1) предотвращаем изменения в таблицах, которые влияют на выборку, через запрет доступа в промежуточную таблицу
SET INTEGRITY FOR "GOODS"."MV_ITEMS_STAGE" OFF READ ACCESS;
commit;

--2) забираем данные, которые перехвачены
SELECT * FROM V_ITEMSXML v WHERE EXISTS(SELECT * FROM "GOODS"."MV_ITEMS_STAGE")
AND v.IDITEM IN (SELECT s.IDITEM FROM "GOODS"."MV_ITEMS_STAGE" s);

--3) разрешаем изменения после того, как взяли их
SET INTEGRITY FOR "GOODS"."MV_ITEMS_STAGE" ALLOW WRITE ACCESS IMMEDIATE CHECKED;

--4) распространяем изменения (которые уже взяли) на MQT, при этом очищается промежуточная таблица
REFRESH TABLE "GOODS"."MV_ITEMS";
commit;

Запрет на запись в staging в 1 делаю для того, чтоб, пока выбираю перехваченные данные, не добавляли новые, поскольку при refresh все они будут очищены (можно просто блокировать доступ, не коммитя после 1, но тогда на время селекта 2 все будут висеть в ожидании на изменение, а так будут получать отказ)