Ivan_Pisarevsky, да не в дырках дело. Вот какой сценарий
может быть проблемным:

началась транзакция А, да призадумалась
началась транзакция Б (read committed)
транзакция Б запросила генератор и получила 1
транзакция А запросила генератор и получила 2
транзакция А вставила запись АА в таблицу data
транзакция А вставила в таблицу скриптов репликации ('insert into data запись АА ',2)
транзакция А завершилась
транзакция Б вставила запись ББ в таблицу data
-- где запись ББ ссылается на АА
транзакция Б вставила в таблицу скриптов репликации ('insert into data запись ББ',1),
транзакция Б завершилась

Просыпается мафия репликатор.
select * from таблица_скриптов order by id

По порядку она отправляет в другую базу сначала запись ББ, потом запись АА.
Запись ББ не вставляется, т.к. нарушение FK.

Вот такой кошмарный сценарий рисуется мне.
Вроде как от него должно защитить то, что значения генератора не берутся заранее,
транзакция - снапшот, а таблицы я сортирую по ссылкам друг на друга.

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

практика показывает, что ничего страшного не случается.
А вот это обнадёживает :)

NickDee, вариант с монопольной блокировкой базы или таблицы
мне не нравится.
Шавлюк Евгений, ваш вариант тоже не нравится из-за необходимости
лишних действий при б/р.

NickDee, в моей задаче вроде не предвидятся конфликты записей, т.к. база tgt не пишет в справочники. Поэтому для меня блокировка выглядит слишком уж тяжёлой ношей.

kdv, не совсем легко понять вас, но если я правильно понял, то вроде Dimitry Sibiryakov уже развенчал такой вариант.

NickDee, можно обернуть каждую таблицу во вьюху, где прятать этих невидимок.

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

Ivan_Pisarevsky, да уж поздно рыпаться - много сделал уже. Хотя на сайт Сибирякова заходил, ценник действительно демократичный. Сторонний продукт - всегда риск, что вдруг кастомизация окажется в чём-то недостаточной и начнёшь вокруг этого продукта плясать с бубном. Ну и другие причины, например, у нас есть уже свой сервер приложений, ну озадачим его ещё одним видом деятельности. Плюс к тому, я умею делать, чтобы метаданные для репликатора росли вместе со структурой базы. Плюс к тому, кастомный алгоритм назначения ид-ов. Плюс к тому, репликация должна идти не с нуля, а заменяет уже существующий алгоритм, который отчасти справляется с задачей, часть данных уже закачаны, и т.д., и т.п.

Я не буду создавать стейтменты в виде текста, буду раскладывать данные по полям, но в целом для меня самое важное то, что последовательность действий _можно_ передавать с одного сервера на другой и это работает. Это не было очевидно.

Всех с прошедшими!
Fr0sT-Brutal,

началась транзакция A
А:insert into data values (AA)
А:триггер data_after_insert
gen_id(g_replication,1)->1
insert into replication_script values ('insert into data values (AA)',1)


началась транзакция Б
Б:insert into data values (ББ)
Б:триггер data_after_insert
gen_id(g_replication,1)->2
insert into replication_script values ('insert into data values (ББ)',2)
Б:commit

просыпается репликатор, видит запись 2 и отправляет её в другую БД

А:commit
просыпается репликатор, видит запись 1 и отправляет её в другую БД

Ничего, что они записи не по порядку номеров, да и вообще не пойми как?
На данный момент я уже этим вопросом не парюсь.
Репликацию написал, на тестировании посмотрим.