Добрый день
дано 2 базы база1 база2
в каждой базе есть таблица t_product
поля
id,name,change_id
change_id это счётчик изменений если запись в таблице изменяют или добавляет change_id увенчивается на 1
1, товар 1,2
2, товар 2,3
если изменять наименование товара 1 на товара 5 то будет
1, товар 5,4

на второй базе все именные или доданные записи передаются на базу2 по схеме
база 2 хранит последний номер change_id и забирает из базы 1 все записи где этот номер больше

для change_id есть просто последовательно
create sequence SQ_CHANGE_ID
minvalue 1
maxvalue 999999999999999999
start with 994288686
increment by 1
cache 20
order;
все работает достаточно стабильно но возникают ситуации когда в базе 2 не обновляются данные
это происходить сели одновременно идет обмен и изменения в таблице
т.е
1 доставляются пачка новых записей в таблицу
2 change_id передвигается
3 происходит запрос текущего change_id
4 запрос всех записей > последнего change_id (а их еще нет, так как не произошел коммит)
5 запрос пустой
6 записывается последний change_id
в результате 1 запись теряется

таких таблиц достаточно много > 100 у всех обмен настроен схожим образом
есть какой вариант узнать сколько change_id находиться в открытых транзакциях
или какой другой способ синхронизации

вариант который рассматриваем как основной
1 делаем табличку t_change_id с одним полем и одной записью
2 делаем функцию
create or replace function f_ret_change_id return number is
Result number;
begin
select sq_change_id.nextval into Result
from dual;

update t_change_id
set CHANGE_ID = GREATEST(CHANGE_ID+1, Result);
returning CHANGE_ID into Result;

return(Result);
end f_ret_change_id;

3 на все таблицы участвующие в обмене делаем триггер
CREATE OR REPLACE TRIGGER TR_product_CBIU BEFORE INSERT or UPDATE
ON t_product FOR EACH ROW
BEGIN
:NEW.CHANGE_ID :=f_ret_change_id;

END;
4 теперь последний законченный CHANGE_ID в таблице

возможно тут есть недостатки
если одновременно происходит несколько транзакций с разным временем завершения

mat. view log
не совсем понятно как это использовать на практике
mat. view log используем для ускорения рефреша больших аналитических таблиц
там хранятся изменения между после последнего рефреша
и затираются если рефреш прошел

если есть несколько таблиц обмена (некоторые большие) и есть несколько клиентов куда нужно изменения транслировать
и все это нужно делать средствам которые доступны в XE11.2

oragraf,
нет в этой таблице 1 запись с последним закомиченым CHANGE_ID

удаление из таблиц не делается есть поле логического удаления

unprocessed_ids
тут не совсем понятно как это делать на 100 клиентах
у каждого клиента обмены приходят не регулярно интервал между обмена от 1-2 часа до 1-2 недели у разных клиентов по разному
в некоторых табличках может накопиться до 1М записей
одна строчка между обменами может изменяться несколько раз

не много по другому поставлю вопрос

поле change_id заполняется с помощью последовательности sq_change_id.nextval
клиент при подключении запрашивает последний номер последовательности (last_change_id)
клиент хранит у себя последний номер прошлого обмена old_change_id
затем выгибает строки запросом
select * from t_product whete change_id between old_change_id and last_change_id
после удачного обмена записывает себе last_change_id

если я как нибудь смогу узнать sq_change_id.nextval в незакрытых транзакциях на момент начала обмена (no_comm_change_id)
то я могу передать клиенту этот no_comm_change_id и при следующем обмене
делать select * from t_product whete change_id between no_comm_change_id and last_change_id

далеко не все живут в мире enterprise edition .
эта статья не имеет никакого отношения к теме , ни слова про синхронизацию.
не понятно для чего вы прислали статью 2003 года 17 лет прошло !!!
если у вас есть статья, как на практике применять синхронизацию с использованием mview log присылайте
если опустить ограничение XE я не вижу оптимального решения организации синхронизации через mat. view log если клиентов для обмена более 100.

или пишите по теме или не пишите вообще

xtender,
да согласен идея не удачная
но других пока не нашли

тестируем этот вариант
создаем функцию




которая заполняет CHANGE_ID через триггер





тут узнаем если открытые транзакции с таблицами которые участвуют в обмене



на стороне клиента


храним эти транзакции чтобы перекачать позже

получаем текущий change_id с мастер базы



далее делаем запросу примерно такого вида


собственно получаем либо новые записи либо измененные
завершение обмена записываем новый new_change_id в базу клиента, с ним будем начинать следующий обмен
old_change_id := new_change_id

второй блок обмена
повторяет те же действия но только с таблицами из t_open_tran




вопрос есть ли у этого метода недостатки которые мы не заметили ?

-2-,

да пропускаются записи которые не закончены
для этого и просматривается открытые транзакции на момент обмена

xtender,

пересмотрел все что советовали
большая часть не работает в XE
вторая часть платная
либо все эти снапшоты забьют паять настолько что XE не потянет такой объем
и советы типа
"напиши так как я раньше писал и оно как то работало вот ссылка которая тебе не подойдет"

еще немного вводных
таблиц для обмена больше 100
клиентов примерно столь-же
примерно раз в месяц меняется набор таблиц для обмена или добавляются удаляются новые колонки

качаем эти грабли, потому что они уже как то работают
записи продают при обмене, но это не так критично, чтобы глобально что то переписывать или что то покупать

согласованность особо не нужна, необходимо чтобы при завершении открытой транзакции на момент обмена change_id > START_SCN
если некоторые данные передадутся дважды это не так критично

последний new_change_id это и есть select max(change_id) from t1@b2

"если Вначале идет коммит с большим change_id,а потом с меньшим"
то это не так важно так как обе транзакции попадут в неравенство
единственная проблема это открытые транзакции в момент обмена
change_id у же передвинулся а данные еще не закончены и его нельзя использовать как old_change_id

Stax,

зы
правильно лог и его накат, но ето сложнее

если матвью лог то его нет в XE :(

структура таблиц меняется следовательно надо менять структуру логов и за этим следить
далее если клиентов 100 то 1 запись в справочнике = 100 записей в логе так ?
если надо обновит 100К записей ?

правильно я все понял ?

xtender,

не не совсем понятно зачем
к тому же он больше change_id получился
и еще на ora_rowscn я ни как не могу повлиять
например я могу отключить триггер поставить change_id = 0 что бы эти строки времено не передавались

Stax,

поясните по ручным логам через триггер
я правильно понял механизм или нет ?

вот пример
был обмен
old_change_id = 61582217550
далее мне нужно забрать все записи change_id > 61582217550
их все две и это так и есть, используя change_id я их вижу
ora_rowscn я вижу кучу записей

тут если есть незакрытая транзакция в момент обмена (1)
то записей я еще не вижу (2)
но вижу start_snc в (3)
так что кода нибудь (через час например) когда транзакция закроется я смогу забрать change_id >=61663434929

Stax,
22119463