От каких условий зависит активация указанной к репликации таблицы?
Несколько раз пробовал настроить update-anywhere репликацию, но то неактивно определение таблицы у Capture на стороне master-сервера, то в другой раз неактивно определение у Capture на стороне реплики (последний раз указывал "не использовать ASNLOAD").
Создаю пустую таблицу с двумя полями (Prim.Key естественно) на мастере. Такую же создаю на сервере, который будет репликой (то, что Центр репликации создаст таблицу для реплики меня не совсем устраивает). Обе таблицы изначально пусты - первоначальной загрузки мне пока не надо, вернее и без загрузки пока не выходит.

Где и чего я не догоняю?

Вопрос теперь несколько в другом:
DISABLE_REFRESH в IBMSNAP.REGISTER стоит =1 , т.е. full refresh у меня отключен.
asn.ibmsnap_subs_membr.loadx_type = 1 - ранее для того члена подписки на который записи с другой стороны не попадали было равно NULL, вот и поменял на 1, как это было для настроек в другую сторону, где все работало ОК.
Тем не менее, в ibmsnap_applytrail для тех транзакций, которые "не пропихиваются", появляются записи с ошибкой ASN1016I, т.е. Apply для репликаций в эту сторону все равно почему-то ждет, что ей нужно сделать full refresh.
У меня DB2 8.1 fixpack 9.
Куда еще копать , чтобы Apply оставила свои мысли по поводу full refresh и просто стала применять транзакции, которые "висят" в соответствующей CD-таблице ?

Пробовал еще устанавливать в asn.ibmsnap_pruncntl
synchpoint = x'00000000000000000000' и synchtime = CURRENT TIMESTAMP, но в таком случае в ibmsnap_applytrail ошибки ASN1016I перестают появлятся, но ситуция не меняется - в одну сторону (с мастра на реплику) транзакции прокачиваются, а обратно (с реплики на мастера) нет.
При возврате значений NULL этим полям все возврщается к ситуации с ASN1016I.

P.S.
В предыдущем моем эксперименте при настройке репликации пустой тестовой таблицы ситуация была зеркально наоборот, т.е. с реплики на мастер транзакции проходили, а с мастера на реплику нет. Решил начать все с нуля, вот - далеко не ушел...

В чем хрень-то ???

Спасибо за отклик. Решил таки провести первоначальный рефреш.

Видимо первоначальное обновление супер важный момент для Apply - где-то чего-то она синхронизирует у себя в мозгах (хоть я и не засек где и чего), но сделав для member-ов DISABLE_REFRESH=0, перезапуск Capture и Apply, потом DISABLE_REFRESH обратно = 1, еще раз перезапуск (оба изменеия DISABLE_REFRESH при отключенных Capture и Apply) - ВСЕ ЗАРАБОТАЛО! Хоть и ibmsnap_subs_membr.loadx_type было все время при этом выставлено в 1.

P.S.
Накопившиеся до момента включения обновления непрошедшие транзакции в cd-таблицах канули в лету. Поэтому делать эту процедуру с обновленим надо в самом начале запуска системы в работу, чтоб потом гемороя не иметь.

В том-то и дело , что в сторону Q-репликации я уже смотрел, тока вот лицензии нет на DB2 Information Integrator :-(

Вот и пришлось переориентироваться в срочном порядке...