|
|
|
Двухсторонняя репликация 3 (триггеры и Constraintы)
|
|||
|---|---|---|---|
|
#18+
Добрый день! Спасибо за ответы на предыдущие два моих вопроса. Я разобрался и у меня заработало. Но, как всегда водится, у меня появился третий вопрос. Предположим, что я реплицирую набор таблиц табл1 и табл 2 из базы1 в базу 2. Таблицы реплицируются как Updatable snapshots Данные между таблицами обновляются. Потом, я создаю на базе 2 триггер на вставку, следующего содержания create or replace trigger client_histories_ins before insert on client_histories for each row Begin -- Отключение триггера в случае репликации if dbms_reputil.from_remote = true then return; end if; :new.navi_user:=user; :new.navi_date:=SYSDATE; end client_histories_ins; Почему-то получается так, что триггер срабатывает для каждой записи, которая приходит из базы1. Т.е. отключение не срабатывает. Вопрос 1. Как сделать, чтобы срабатывало? Как вообще быть с триггерами на стороне базы 2? Теперь я создаю Constraint на foreign key между табл1 и табл 2. Теперь при попытке обновления возникает ошибка ORA-02292 Oracle (Integrity constraint ... violated ) Оно и понятно. Просто обновление в таблицах происходит по методу COMPLETE, он пытается удалить все записи из таблицы и не может, потому что ему мешает Constraint. Можно, конечно, делать обновление по методу FAST, но конфликт внешних ключей все равно может возникнуть. Вопрос2 Что мне делать в такой ситуации? Мне нужно, чтобы на стороне базы 2 был частичный набор записей со стороны 1 и нужно чтобы там были триггеры и Constraintы. Наверняка, ведь, кто-то из вас сталкивался с такой проблемой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2003, 12:40 |
|
||
|
Двухсторонняя репликация 3 (триггеры и Constraintы)
|
|||
|---|---|---|---|
|
#18+
1. По-моему, такой триггер вообще не будет выполнять то, что хотелось, по следующей причине: про обновлении снапшота отключается заполнение его логов - таблиц USLOG$_, следовательно твои изменения будут потеряны при следующей обновлении. Еще: при FAST-рефреше запись обновляется следующим макаром: сперва удаляется, а потом вставляется запись, пришедшая с мастера. 2. Посмотри в сторону ограничений с отложенной проверкой целостности, т.н. deferrable constraints. При обновлении Оракл сперва делает все constraint'ы deferred у всех снапшотов, входящих в обновляемую группу (refresh group). Естественно, которые позволяют ему это сделать, т.е. те constraint'ы, при создании которых было указано, что они deferrable. Кстати, при репликации можно напороться и на голом месте, на нарушение уникальности. Поскольку порядок прихода записей не регламентируется, может получиться следующее: с мастера сперва пойдет попытка вставить запись с существующим значеним уникального поля, и только потом удаление прежней записи. Выход - опять же deferred constraint, уже unique, постоенный по неуникальному индексу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2003, 14:07 |
|
||
|
|

start [/forum/topic.php?fid=52&tid=1991494]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
160ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
22ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 424ms |

| 0 / 0 |
