Добрый день! Разрабатываю рукописную репликацию справочников.

Репликация односторонняя, т.е. база tgt должна следовать за базой src.
В базе tgt запись в справочники не происходит иначе, как чем через репликацию.

Стратегия принята примерно такая:

все пишущие транзакции в системе - snapshot.

имеется таблица


имеется набор триггеров, заносящих в неё запись при insert и update
(delete пока вовсе не обрабатывается, потом планирую сделать поле пометки, как в dbf).

id в ней - это суррогатный ключ, порождается генератором.

Для маленьких таблиц rec_id всегда = 0, для больших - rec_id = суррогатный ключ изменяемой записи.
Для таблиц, подчинённых большим - rec_id = значение FK ссылки на владельца.

За репликацию отвечает отдельное приложение, подключенное к обеим базам.
Периодически или по пинку от пользователя оно запускает репликацию, к-рая состоит в следующем:

1. стартуется одна транзакция в src и одна - в tgt (обе - snapshot)

2. Смотрим, есть ли в таблице rpl_edition базы src записи, которых нет в такой же таблице базы tgt.
Если есть, то берём всё множество таких записей и упорядочиваем его в порядке ссылки таблиц
(так, чтобы записи, на которую идут ссылки, появились до того, как записи, которые ссылаются).
Циклические и рекурсивные ссылки разрешаются тем, что таблица обрабатывается более одного раза,
но в первый раз поля, образующие цикл, остаются null-ами.
3. По каждой отличающейся записи в rpl_edition проводим соответствующую репликацию, т.е. берём данные
из какой-то таблицы в src и пишем в такую же таблицу в tgt.
4. Все такие же записи вставляются в rpl_edition базы tgt.
5. commit в обоих базах (в src мы ничего не писали)
6. в отдельной транзакции с коротким таймаутом, отдельным тредом стираем все совпадающие записи
в rpl_edition базы src. Если не стёрлось - откатываем её.
7. Повторение п.7 для базы tgt.
8. Отключение триггеров на реплицируемых таблицах: видимо, будет стоять развязка по пользователю, т.е., если пользователь= репликатор, то определённые триггеры отключаются (спасибо Ivan_Pisarevsky), хотя для начала хочу полениться
и сделать просто переменную контекста, которую устанавливаем и тем самым отключаем триггер.

Думал чуть ни неделю над этим алгоритмом. Вроде всё нормально, но покоя в душе нет.
Прошу осудить и кинуть тапком, сказав, какие грабли меня при этом ждут.

Ivan_Pisarevsky, изобретаю потихоньку... А как у вас?

Гаджимурадов Рустам, привычка укладываться в 8.3 :)

Может, dst было бы и правильнее, но уже поздно для данного о(б)суждения.

src может меняться в любой момент времени, отсюда и снапшот.

Я вообще хочу все перевести на снапшоты, ввиду моей
неспособности/лени проанализировать, как всё
будет работать с read committed - слишком много возможных
аномалий нужно предполагать на каждую строчку кода.

Ivan_Pisarevsky, я вне традиции, видимо :)
Если она где-то описана, положи в тапок ссылку
и кинь в меня им.
Что такое z-триггеры? Яндекс промолчал.

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

А как у тебя упорядочиваются скрипты? Пусть у нас есть таблица
со ссылкой на себя. За счёт чего запись А придёт в tgt раньше, чем ссылающаяся
на неё запись Б? Учитывается время вставки? А если придут с меньшим
интервалом, чем разрешение часов? Генератор?

Каков уровень изоляции транзакций? Бывают ли сбои из-за внешних ключей,
особенно на delete?

Ivan_Pisarevsky, вот тут и есть самое непонятное. Раз порядок стейтментов как-то определён и это не таймстамп, то значит генератор. Если генератор, то порядок следования апдейтов в репликации слабо связан с порядком старта и коммита транзакции, которая его создала. Если транзакция А стартовала до старта транзакции Б и финишировала до финиша транзакции Б, значит ли это, что она более ранняя? Если используется генератор, то запрос от транзакции Б может раньше пойти на репликацию, чем запрос от транзакции А. И получится, что транзакция Б - "раньше", чем А. Оттого я и спросил про таймстампы. Вроде из этого ничего страшного не следует, потому что есть ещё блокировка записей. Т.е., если здесь будет какие-то конфликтующие друг с другом изменения, одна из транзакций просто не будет закоммичена. Но я не могу сказать, что полностью уверен в надёжности.