rout.pdc - таблица, принимающая имена таблиц, над которыми произошли изменения
routd.pdc - таблица, принимающая детализацию изменений
routsrv.pdc - таблица серверов, для которых предназначена данная репликация.
routins.trg - триггер, делающий запись в routsrv, при добавлении в rout на основании servers.outflag=1
servers.pdc - список серверов, участвующих в репликации

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

repl.prc - процедура, разворачивающая входящие репликации из таблиц rin и rind в DML и записывающая статус в rt
usl.pdc - скрипт для создания рабочей таблицы (справочник услуг), которая подлежит репликации
usl_rout.trg - триггер над таблицей usl, который фиксирует все измения таблицы в служебные таблицы ROUT, ROUTD

Кроме того, выполнять процедуру REPL разрешено только одному юзеру, 'repl'
и всем пользователям, кроме 'repl' запрещено менять справочники на ведомых серверах
и рабочие таблицы с реплицируемыми данными на ведущих. Это в моем случае определяется по ID строк,
которые уникальны для каждого сервера.

Вроде, все указал. Если есть вопросы - пишите, а они точно будут. Исходников клиентской шняги, которая принимает таблицы rout/routd и загружает в rin/rind, запускает хранимую REPL, а потом выгружает rt для подтверждения выполнения репликации я героически потерял. Но, думаю воспроизвести ее труда не составит.

Присоединённый файл ( Кол-во скачиваний: 29 )
 2007_07_04_Repl.rar 5,57 Kb

Здорово, только я ненашел routins.trg, и самое главное repl.prc,...

Добавлено через 6 минут и 45 секунд
а и еще, что это за servers.outflag=1

А routins.trg я действительно забыл. Вот он:

 значит версия была лучше

Имелось ввиду значение поля outflag = 1 в таблице servers. Т.е. смысл в том, что для сервера, помеченного этим флагом генерируются репликации. Просто у меня много серверов и соответственно кому-то нужно синхронизировать одну часть данных, кому-то она вообще не нужна, даже таблиц таких нет. И для постепенного включения репликаций хорошо. Или если сбой где-то произошел, то выключить и разруливать потихоньку.

Понятно, вкл/выкл.

Как происходит обработка входящих репликаций,  по идее она должна обрабатываться в виде очереди, Т.е. пока успешно не обработали одну репликацию не переходим к следующей. Так ли это?

Добавлено через 5 минут и 31 секунду
Вроде как получается что за раз обрабатывается весь журнал, и если есть хотя бы одна ошибка делаем откат на начало журнала, или нет?

Да, верно.
Данные из таблиц ROUT и ROUTD загружаются в таблицы RIN и RIND соответственно. После чего за выполнение репликаций отвечает хранимая REPL. Она то и выполняет все операции в порядке очереди. Очередь устанавливается последовательностью R_ID. Т.е. когда фиксируются репликации в таблицы (см. пример триггера над таблицей USL), R_ID будет определено последовательностью SEQR_ID. В этой же последовательности их и обработает потом хранимая REPL.
Кстати, вот она сама:
На других серверах, как я уже говорил, значения первичных ключей не пересекаются, т.к. там тоже будут существовать такие последовательности, но уже с другим интервалом. Например:

При возникновении ошибки в процедуру REPL, обработка прекращается до вмешательства человека. На начальном этапе это неизбежно будет (стадия отладки и тестирования). Теперь у меня это уже больше года работает нормально. Я и забыл, когда туда лазил. Вот сейчас пришлось вспоминать, как это работает.

Как загружаются данные в таблицы Rin, Ring?
Просто очищаем RIN, затем все строки заливаем из ROUT?

Добавлено через 7 минут и 22 секунды
При такой схеме возникает некая избыточность данных. В обеих базах данные дублируются. Если реплицировать нужно справочники - проблем нет. А если таблицы в которые ежедневно добавляются сотни тысяч записей, как все это будет работать, корректно ли, быстро ли? 

Можно не очищать, просто дописывать.
Из RIN данные можно удалять только тогда, когда выполнятся все условия:
1. Репликация выполнена, т.е. Rin.rf = 0 (или существует запись в Rt)
2. Удаленный сервер знает, что репликация уже выполнена, иначе он должен снова ее выгрузить. Если память не изменяет, то это у мну routsrv.flag

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

Скорость, да несколько хромает. Обычно такие задачи у меня работают ночью. Синхронизируется 14 серверов с 1-м сервером. Средний поток изменений от одного сервера к другому - примерно 200,000..1,500,000 репликаций. За ночь успевает. Но бывает и больше, тогда может и к обеду следующего дня завершиться.

Насчет корректности: все работает корректно. Пока рассогласований небыло.

Имхо, мне самому не очень сейчас это нравится в плане быстродействия. Иногда хочется быстрее. Если время найду, я давно порывался это переделать, правда мысли пока еще не оформились окончательно. Может твоя критика и поможет мне.

Это сообщение отредактировал(а) Dimich - 4.7.2007, 14:36

Опять репликация?
Как ты дописываешь?

Может быть лучше в таблицу Rout, добавить поле Статус репликации, 0 - не завершена, 1 - завершена?
Как думаешь?

Или у тебя в таблицу RT добавляются только те записи, репликация по которым прошла успешно, а затем при очистке журнала репликации, удаляются только те которые есть в RT?

Не понял вопроса. Какие записи получил от удаленного сервера, те и дописываю. В таблицах есть primary key по R_ID (ID репликации), поэтому уже существующие, если такие оказались, будут отвергнуты в любом случае.
Более подробный алгоритм такой: читаю файл, делаю insert строки.
Можно к примеру SQL Loader прикрутить, если надо.



Можно наверное и так сделать. Почему бы и нет. Будет экономия. Я уже и вспомнить не могу, чем я руководствовался, когда делал так.

Да, кстати, вспомнил еще: когда будешь обрабатывать дробные числа и даты, имей в виду, что скорее всего дробное число будет иметь не десятичную точку, а запятую. Это я сперва по глупости решил как Replace (',', '.', value). Но гораздо лучше использовать nls_numeric_characters

Также нужно обратить внимание на формат дат. При неверной настройке они имеют свойство записываться некрасиво. Это я решил, используя в тригерах форматирование при выводе дат: to_char(date, 'dd/mm/yyyy hh:mi:ss')

Это сообщение отредактировал(а) Dimich - 5.7.2007, 06:55

имхо, вы все гоните. если б мои кодеры начали переписывать стандартную функциональность оракла, уволил бы всех нах.

Гоним, не спорю.

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


Sqlninja, а вообще реально сделать dblink с базой, с которой нет связи? Ну, чтобы, можно было данные, например на дискете туда-сюда носить? Или как тогда можно запустить репликации (сети нет т.е., интернет есть, но не стабильный, т.е. может прерываться или каждые 5 минут или же стабильно отсутствовать в течение нескольких суток. В этот период хотелось бы использовать запасной канал, например соседнюю фирму, если у них в этот момент все работает, или пригородный автобус). Какие модули и компоненты оракла за это отвечают? Может быть надо что-то доустановить или у сторонних разработчиков есть такой функционал? Мне все разжевывать не надо, просто вкратце идеи нужны, в какую сторону копать?

Заранее спасибо.

можно делать экспорт шаблона внедрения (deployment template) на внешний носитель, и если нет связи, передавать его. мне про нет связи рассказывать не надо, у меня сеть была по всей Украине, и есть пару офисов стоящих реально в поле.