Добрый день
дано 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




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