ReSQL.ru
     
powered by simpleCommunicator - 2.0.52     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Синхронизация таблиц
25 сообщений из 118, страница 4 из 5
  4  все
Синхронизация таблиц
    #39949614
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Dimitry Sibiryakov

MazoHistпри грамотной реализации - нет

две реализации: грамотная и надёжно работающая.
Не порите чушь, ей больно.
Грамотная и надежно работающая реализация не требует размножения записей в логе. Она требует, в случае множественных реплик, простого publish-subscribe механизма.
...
Рейтинг: 0 / 0
21.04.2020, 20:17
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949642
ilyuha111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ilyuha111
Гость
 
andrey_anonymous
ilyuha111
- самодельная реализация триггерной репликации на технологической основе mview log - отвергнута ТС, потому что "старая" и вообще разбираться лень
я так понимаю вы имеете ввиду следующий механизм заполонять триммерами точную копию таблицы

Я имею ввиду механизм, работающий в оракеле 25+ лет, детально описанный в статье 17-летней давности и который Вы отказались даже изучить.
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
--Транзакция 1
insert into dropme_t(id, cmnt) values (1,'Row1: delayed'); -- Не коммитим запись до времени
 
1 row inserted

select * from cdc_dropme_t -- данное изменение пока видно только текущей транзакции
 
RID                CH_DT
------------------ -----------
AAAk3AAAMAAAACEAAA 01.01.4000 

select * from repsite1_dropme_t; -- На приеме пока пусто
 
   ID CMNT                                                                             MOD_DATE             REPL_DATE
----- -------------------------------------------------------------------------------- -------------------- --------------------

select * from repsite1_sync_log;
 
MOD_DATE             STATUS     RUN_DATE
-------------------- ---------- --------------------
 
SQL> 

--Транзакция 2:

insert into dropme_t(id, cmnt) values (2,'Row2: immediate');
 
1 row inserted

commit; -- пропустим запись вперед.
 
Commit complete

SQL> 
 
--Транзакция 3:
exec SYNC_DROPME_T.syncronize('repsite1');
 
PL/SQL procedure successfully completed

select * from dropme_t; 
 
   ID CMNT                                                                             MOD_DATE
----- -------------------------------------------------------------------------------- --------------------
    2 Row2: immediate                                                                  21.04.2020 18:42:48

select * from repsite1_dropme_t;-- Итог репликации: запись №2, созданная в 18:42:48
 
   ID CMNT                                                                             MOD_DATE             REPL_DATE
----- -------------------------------------------------------------------------------- -------------------- --------------------
    2 Row2: immediate                                                                  21.04.2020 18:42:48  21.04.2020 18:43:51

select * from repsite1_sync_log;
 
MOD_DATE             STATUS     RUN_DATE
-------------------- ---------- --------------------
21.04.2020 18:43:51  success    21.04.2020 18:43:52
 
SQL> 

--Транзакция 1:
SQL> commit;
 
Commit complete

 
SQL> 

--Транзакция 3: повторим вызов

exec SYNC_DROPME_T.syncronize('repsite1');
 
PL/SQL procedure successfully completed

select * from dropme_t;
 
   ID CMNT                                                                             MOD_DATE
----- -------------------------------------------------------------------------------- --------------------
    1 Row1: delayed                                                                    21.04.2020 18:41:32
    2 Row2: immediate                                                                  21.04.2020 18:42:48

select * from repsite1_dropme_t; -- А вот и "задержавшаяся" запись доехала до реплики
 
   ID CMNT                                                                             MOD_DATE             REPL_DATE
----- -------------------------------------------------------------------------------- -------------------- --------------------
    2 Row2: immediate                                                                  21.04.2020 18:42:48  21.04.2020 18:43:51
    1 Row1: delayed                                                                    21.04.2020 18:41:32  21.04.2020 18:45:50

select * from repsite1_sync_log;
 
MOD_DATE             STATUS     RUN_DATE
-------------------- ---------- --------------------
21.04.2020 18:43:51  success    21.04.2020 18:43:52
21.04.2020 18:45:50  success    21.04.2020 18:45:50

SQL> select * from cdc_dropme_t; -- И что у нас в mview-логе?
 
RID                CH_DT
------------------ --------------------
AAAk3AAAMAAAACEAAA 21.04.2020 18:45:50
AAAk3AAAMAAAACFAAA 21.04.2020 18:43:51
 


--Транзакция 4 -- А вот и второй сайт приехал реплицироваться.

SQL> select * from repsite2_dropme_t;
 
   ID CMNT                                                                             MOD_DATE             REPL_DATE
----- -------------------------------------------------------------------------------- -------------------- --------------------
 
SQL> exec SYNC_DROPME_T.syncronize('repsite2');
 
PL/SQL procedure successfully completed
 
SQL> select * from repsite2_dropme_t;
 
   ID CMNT                                                                             MOD_DATE             REPL_DATE
----- -------------------------------------------------------------------------------- -------------------- --------------------
    1 Row1: delayed                                                                    21.04.2020 18:41:32  21.04.2020 18:48:49
    2 Row2: immediate                                                                  21.04.2020 18:42:48  21.04.2020 18:48:49
 
SQL> select * from repsite2_sync_log; -- синхронизация прошла за одну операцию
 
MOD_DATE             STATUS     RUN_DATE
-------------------- ---------- --------------------
21.04.2020 18:48:49  success    21.04.2020 18:48:49
 
SQL> 

 и контрольный в голову: в логе без перемен. Когда отработают все нуждающиеся - можно будет почистить по ch_dt
SQL> select * from cdc_dropme_t;
 
RID                CH_DT
------------------ --------------------
AAAk3AAAMAAAACEAAA 21.04.2020 18:45:50
AAAk3AAAMAAAACFAAA 21.04.2020 18:43:51
 
SQL>




1 судя по всему CH_DT это дата ЗАВЕРШЕНИЕ транзакции я правильно понял ?
подскажите как можно ёё получить в XE если эмулировать через триггеры
2 "и контрольный в голову: в логе без перемен. Когда отработают все нуждающиеся - можно будет почистить по ch_dt"
и когда наступит этот момент никто не знает так же как ни кто не знает когда завершиться транзакция
3 скорей всего в этой процедуре SYNC_DROPME_T.syncronize('repsite1') вы используете что то вроде CH_DT >=RUN_DATE и связку лога с табличкой по ключу +- и результат этот запросы отстреливаете через бдлинк в базу клиента


спасибо за разъяснение, гораздо проще чем в статье, не хватает еще команды создания лога.
но я ограничен средствами ХЕ

на данный момент внедряем на клиенте механизм
dbms_flashback.get_system_change_number + V$TRANSACTION
результат будет через неделю выложу тут пока бета-тетеры противоречий не нашли
...
Рейтинг: 0 / 0
21.04.2020, 20:54
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949683
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
ilyuha111

1 судя по всему CH_DT это дата ЗАВЕРШЕНИЕ транзакции я правильно понял ?
подскажите как можно ёё получить в XE если эмулировать через триггеры

Нет.
Это ключевой атрибут, позволяющий решить поставленную задачу и по сути не имеющий никакого отношения к каким-либо датам транзакций.
Его вообще можно реализовать через sequence и назвать как-нибудь типа "bundle_id", но только когда поймете лежащую в основе гениально простую идею.
Хинт: обратите внимание на начальное и конечное значение этого атрибута.

Что касается XE: обратите внимание на тот факт, что в демо нет выборки из MLOG$_DROPME_T или вызовов dbms_mview.
Вся демка реализована "с нуля" в предельно урезанном варианте, только показать, что "оно работает", минут за полчасика.
Я к тому, что ни одной enterprise-фичи в демке не использовано.

ilyuha111

2 "и контрольный в голову: в логе без перемен. Когда отработают все нуждающиеся - можно будет почистить по ch_dt"
и когда наступит этот момент никто не знает так же как ни кто не знает когда завершиться транзакция

Неверно.
Этот момент легко отслеживается. Вернее, в любой момент времени можно однозначно сказать, какие именно записи лога можно удалить. Делается это по-разному. В том варианте, который я показал - выборкой "минимального из максимальных" repsite%_sync_log. В более общем варианте - из каталога "подписчиков", где каждый из них и отмечает что он уже забрал, а что - еще нет.

ilyuha111

3 скорей всего в этой процедуре SYNC_DROPME_T.syncronize('repsite1') вы используете что то вроде CH_DT >=RUN_DATE и связку лога с табличкой по ключу +- и результат этот запросы отстреливаете через бдлинк в базу клиента

Алгоритм в статье.
И нет, dblink - совершенно не обязателен.
Нет никаких проблем использовать этот механизм, к примеру, для выгрузки пакета изменений в файл и пересылки его электропочтой/флешкой на удаленный сайт с плохой связью.
Я когда-то использовал данный подход для асинхронного уведомления тарификатор(ов) об изменениях в абонентских данных (баланс, услуги и т.п.), позже допилили до самодельного AQ (во времена 9i/10g AQ был недоступен/платной опцией).
Т.е. никаких препятствий для реализации на XE нет.

Что касается v$transaction.
Первое, что следует знать - эти представления не гарантируют consistency, потому как не являются честными view.
В принципе, мне этого более чем достаточно, чтобы не завязывать на них транзакционную логику.
...
Рейтинг: 0 / 0
21.04.2020, 21:30
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949727
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
andrey_anonymousОна требует, в случае множественных реплик, простого publish-subscribe механизма.

Остаётся только решить простенькую задачу отличения уже отреплицированных записей от ещё
нереплицированных для каждого подписчика отдельно. Что, внезапно, решается их размножением.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
21.04.2020, 22:19
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949736
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Dimitry Sibiryakov

andrey_anonymousОна требует, в случае множественных реплик, простого publish-subscribe механизма.

Остаётся только решить
22120152
...
Рейтинг: 0 / 0
21.04.2020, 22:36
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949745
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
ilyuha111
на данный момент внедряем на клиенте механизм
dbms_flashback.get_system_change_number + V$TRANSACTION
вы все-таки упорно хотите стрельнуть себе в ногу...ну-ну...



andrey_anonymous,

про ora_rowscn можно и упростить доступ и сделать эдакий самодельный mview log без пересоздания исходных таблиц с rowdependencies: достаточно создать отдельную таблицу лог с включенным rowdependencies и пулять туда rowid исходной таблицы.
 
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
create table my_dml_log(
   table_name varchar2(30),
   rid        rowid
) rowdependencies;

create or replace procedure p_dml_log(table_name in varchar2, rid rowid) as
begin
   insert into my_dml_log(table_name, rid)
   values(table_name, rid);
   -- etc...
end;
/
create table test1 (a int);
create table test2 (b int);
create table test3 (c int);
create or replace trigger tr_dml_test1
  after insert or update on test1
  for each row
begin
   p_dml_log('TEST1', :new.rowid);
end;
/
create or replace trigger tr_dml_test2
  after insert or update on test2
  for each row
begin
   p_dml_log('TEST2', :new.rowid);
end;
/
create or replace trigger tr_dml_test3
  after insert or update on test3
  for each row
begin
   p_dml_log('TEST3', :new.rowid);
end;
/
begin
   insert into test1 values(1);
   commit;
   insert into test2 values(2);
   commit;
   insert into test3 values(3);
   commit;
   insert into test1 select level from dual connect by level<=10;
   commit;
   update test1 set a=-a where a>5;
   commit;
end;
/
select l.*, l.ora_rowscn from my_dml_log l;


"TABLE_NAME""RID""ORA_ROWSCN""TEST1""AAAxFRAAMAAAAZ2AAA""111473320""TEST2""AAAxFSAAMAAAAcOAAA""111473324""TEST3""AAAxFTAAMAAAAcWAAA""111473328""TEST1""AAAxFRAAMAAAAZ2AAB""111473331""TEST1""AAAxFRAAMAAAAZ2AAC""111473331""TEST1""AAAxFRAAMAAAAZ2AAD""111473331""TEST1""AAAxFRAAMAAAAZ2AAE""111473331""TEST1""AAAxFRAAMAAAAZ2AAF""111473331""TEST1""AAAxFRAAMAAAAZ2AAG""111473331""TEST1""AAAxFRAAMAAAAZ2AAH""111473331""TEST1""AAAxFRAAMAAAAZ2AAI""111473331""TEST1""AAAxFRAAMAAAAZ2AAJ""111473331""TEST1""AAAxFRAAMAAAAZ2AAK""111473331""TEST1""AAAxFRAAMAAAAZ2AAG""111473335""TEST1""AAAxFRAAMAAAAZ2AAH""111473335""TEST1""AAAxFRAAMAAAAZ2AAI""111473335""TEST1""AAAxFRAAMAAAAZ2AAJ""111473335""TEST1""AAAxFRAAMAAAAZ2AAK""111473335"


Можно добавить туда еще поле insert_time, для отсечки/чистки по дате с запасом.
...
Рейтинг: 0 / 0
21.04.2020, 22:54
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949746
ilyuha111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ilyuha111
Гость
andrey_anonymous,
до коммита
RID CH_DT
------------------ -----------
AAAk3AAAMAAAACEAAA 01.01.4000

после коммита
RID CH_DT
------------------ --------------------
AAAk3AAAMAAAACEAAA 21.04.2020 18:45:50


у меня нет решения как это реализовано
в статье это скорей всего MLOG $ _.SNAPTIME $$ но оно там просто есть а как его заполнили не написано
...
Рейтинг: 0 / 0
21.04.2020, 22:56
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949760
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
ilyuha111
у меня нет решения как это реализовано
в статье это скорей всего MLOG $ _.SNAPTIME $$ но оно там просто есть а как его заполнили не написано

Really?!

авторBasically the refresh operation consists of 3 phases:
1. Setup.
During this phase the PL/SQL RPC dbms_snapshot.set_up is called from the
snapshot site. Setup has to verify if the snapshot being refreshed is a
ROWID or primary key snapshot. Then it is necessary to verify if a
fast-refresh can be performed. Afterwards the snaptime$$ column is
updated in the snapshot log mlog$_t1 of the altered rows to its own
refresh date and time for the first snapshot that refreshes . This value
does not change until the rows are eventually purged from the log.

2. Refresh Operation.
2.1 Call dbms_snapshot.verify_log and determine if a fast-refresh can
take place. After dbms_snapshot.set_up is called a second check is made
by calling the PL/SQL RPC dbms_snapshot.verify_log which is also called
from the snapshot site to ensure that each refreshing snapshot can use
the snapshot log. In order for the snapshot log to be used the timestamp
of oldest/oldest_pk column in mlog$ must be older than the time of last
refresh.

2.2 Delete the rows that are no longer in the master table.

2.3 Applying modifications from the master.

3. Wrap-up.
The PL/SQL RPC dbms_snapshot.wrap_up called from the snapshot site checks
if the least recently updated snapshot has refreshed and therefore the
snapshot log entries can be purged.
If the log gets purged and an error occurs after this routine the next
time this snapshot refreshes, it will need to be entirely reinstantiated.
Then it is checked if registration of the snapshot is required on the
master. This is only the case if the snapshot id was increased/changed at
some point.

Кроме общего устройства и назначения отдельных компонент механизма, много букв посвящено разбору вопросов эксплуатации - какие они, эти вопросы, бывают и как с ними работать.
Надо просто читать не по диагонали - текст информационно насыщенный, не маркетинговый буллшит.
...
Рейтинг: 0 / 0
21.04.2020, 23:25
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949767
ilyuha111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ilyuha111
Гость
andrey_anonymous,

Наверно не так выразился, я не понял как эмулировать это изменения средствами хе тригера вставляют
Дату начала транзакции
...
Рейтинг: 0 / 0
21.04.2020, 23:40
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949780
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
ilyuha111
andrey_anonymous,
Наверно не так выразился, я не понял как эмулировать это изменения средствами хе тригера вставляют
Дату начала транзакции

Блин, ну битами по байтам же написано - триггер бьет default-значение, а Refresh в фазе setup должен провести update этого атрибута с default на текущее значение (sysdate или новым значением sequence), зафиксировав, таким образом, свой "улов".
Вот так просто.
Тупо, как валенок и надежно, как автомат Калашникова.
Поскольку атрибут монотонно возрастает, то прочие операции refresh смело используют его в своем фильтре between.

...обратите, кстати, внимание на предложение xtender по ведению аналогичного лога на базе ora_rowscn - Саян, как обычно, изящен.
ora_rowscn тоже монотонно возрастает, отвечая всем требованиям к snaptime$$, и при этом update в фазе setup проводить не потребуется.
...
Рейтинг: 0 / 0
22.04.2020, 00:02
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949782
Фотография Кобанчег
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кобанчег
Участник
andrey_anonymous
парсинг redolog/archivelog - ТС проигнорирована
А зачем изобретать велосипеды с парсингом, если механизм Database Change Notification примерно этим и занимается (DBMS_CQ_NOTIFICATION или в прошлом DBMS_CHANGE_NOTIFICATION).
Он ипользуется мехнизм задач, чтоб отправлять изменения асинхронно, но если все джобы отключить, сделать изменения, а потом снова включить, то все изменения будут отправлены.
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
drop table t;
drop table t_log;

create table t(id int);
create table t_log(time varchar2(5));

create or replace procedure t_callback(ntfnds in cq_notification$_descriptor) is
begin
  insert into t_log values (to_char(sysdate, 'mi:ss'));
  commit;
end;
/

declare
  reginfo  cq_notification$_reg_info;
  v_cursor sys_refcursor;
  regid    number;
begin
  reginfo := cq_notification$_reg_info('t_callback',
                                       dbms_cq_notification.qos_query, -- notification type qrcn
                                       0, -- registration persists until unregistered
                                       0, -- notify on all operations
                                       0 -- notify immediately
                                       );

  regid := dbms_cq_notification.new_reg_start(reginfo);

  open v_cursor for
    select dbms_cq_notification.cq_notification_queryid, t.* from t;
  close v_cursor;

  dbms_cq_notification.reg_end;
end;
/

alter system set job_queue_processes = 0;

-- making changes and committing

alter system set job_queue_processes = 1;

-- all changes (notifications) are logged

Вроде джобы на XE есть и notifications тоже хотя насчет последнего я не уверен. :)
...
Рейтинг: 0 / 0
22.04.2020, 00:04
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949786
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Кобанчег
Database Change Notification примерно этим и занимается

Я десять раз подумал бы, прежде чем поставить подобное решение на непатченную БД и заметные объемы.
Хотя это, возможно, просто моя паранойя - поделитесь практическим опытом применения, if any.
...
Рейтинг: 0 / 0
22.04.2020, 00:19
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949793
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
andrey_anonymous
Вот так просто.

Вот теперь до меня дошло. Контрольный вопрос: вызовы syncronize() сериализованы или она может вызываться параллельно для разных реплик?
...
Рейтинг: 0 / 0
22.04.2020, 00:39
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949800
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Dimitry Sibiryakov
andrey_anonymous
Вот так просто.

Вот теперь до меня дошло. Контрольный вопрос: вызовы syncronize() сериализованы или она может вызываться параллельно для разных реплик?

Между репликами имеет смысл сериализовывать update_snaptime$$, прочие операции можно выполнять параллельно.
Если применить вместо snaptime$$ ora_rowscn - то сериализация refresh между репликами не потребуется.
...
Рейтинг: 0 / 0
22.04.2020, 00:58
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949804
Фотография Кобанчег
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кобанчег
Участник
andrey_anonymous
Кобанчег
Database Change Notification примерно этим и занимается

Я десять раз подумал бы, прежде чем поставить подобное решение на непатченную БД и заметные объемы.
Хотя это, возможно, просто моя паранойя - поделитесь практическим опытом применения, if any.
Я может что-то упустил, но заметные объемы и Oracle XE - это взаимо противоречащие понятия.

В механизме уведомлений под капотом создается следующая задача
Код: plsql
1.
2.
3.
4.
5.
SQL> select job_action from dba_scheduler_jobs where job_name like 'AQ$_PLSQL_NTFN%';

JOB_ACTION
--------------------------------------------------------------------------------
DBMS_AQADM_SYS.REGISTER_DRIVER


 
DBMS_AQADM_SYS.REGISTER_DRIVER
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
  PROCEDURE REGISTER_DRIVER IS
    LOOPVAR       BOOLEAN;
    DEQ_TIMEOUT   NUMBER;
  BEGIN
     LOOPVAR := TRUE;
     GET_PARAMETER_VALUE('_srvntfn_job_deq_timeout', DEQ_TIMEOUT);

     WHILE (LOOPVAR = TRUE)
     LOOP 
        DEQ_EXEJOB(LOOPVAR, DEQ_TIMEOUT);

        IF (LOOPVAR = TRUE) THEN
           CHECK_FOR_EXIT(LOOPVAR);
        ELSE
           DECR_SRVNTFN_PROC(LOOPVAR);
        END IF;

     END LOOP;

  END REGISTER_DRIVER;



Если более детально - задача создается при возникновении уведомления, после его обработки смотрит были ли другие изменения и начинает их обрабатывать если надо.
Если ничего не было - то по таймауту задание исчезает. Потом при изменениях появится новое.

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

Более того, в итоге под капотом вызываются сишные функции и этот механизм встроен в сам движок Оракла и никаких триггеров.
Если высокая интенсивность DML, то как раз это будет создавать меньше overhead чем разнообразные поделки с триггерами.
...
Рейтинг: 0 / 0
22.04.2020, 01:11
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949809
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Кобанчег
под капотом вызываются сишные функции

Под капотом там банальный AQ.
Системные триггеры пулят в очередь, Archivelog не при делах.
Положите job_queue_process'ы - будет пухнуть Queue Table, принудительное похудание которой имеет свою специфику - на 11g не помню, но на 10g можно было влететь в нежданный блудняк.
Поднимаете job_queue_process - он начинает обрабатывать очередь (подписчик).
Как следствие, overhead по хранению там приличный, механизмы publish/subscribe похожи, хотя интерфейсы малость избыточны, да еще и не совсем понятный механизм собственно отлова событий - через регистрацию запросов - эффективность которого мне не очевидна.
Из плюсов - можно сразу подписать на события очереди с реплик.
Из минусов - специфическая эксплуатация, было несколько AQшных багов (к вопросу о непатченной XE) + возможные баги собственно нотификаций.

Если уж идти на AQ, то делать свой отлов изменений и пакетировать их по много штук в одно сообщение - снизится нагрузка на очереди как таковые.
...
Рейтинг: 0 / 0
22.04.2020, 01:28
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949816
Фотография Кобанчег
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кобанчег
Участник
andrey_anonymous
Кобанчег
под капотом вызываются сишные функции

Под капотом там банальный AQ.
Системные триггеры пулят в очередь
С этим спору нет, изменения выгребаются из AQ_SRVNTFN_TABLE% queue_table.
andrey_anonymous
Если уж идти на AQ, то делать свой отлов изменений и пакетировать их по много штук в одно сообщение - снизится нагрузка на очереди как таковые.
Так весь цимес в том, что не надо делать свои велосипеды.
Как верно было замечено "Системные триггеры пулят" и пакетируют покомитно. В одном коммите может быть уйма изменений.
Под "механизм собственно отлова событий" и подразумевалось "под капотом вызываются сишные функции".

AQ and jobs это лишь обслуживающие механизмы, чтоб обеспечить асинхронность уведомлений и убрать всякую нагрузку на основной процесс.
...
Рейтинг: 0 / 0
22.04.2020, 02:12
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949817
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
Кобанчег
механизм Database Change Notification
в данном конкретном случае это дикий оверкилл. Асинхронность - это здорово, но, как следствие, страдает консистентность и вообще упорядоченность. Он все-таки задуман для того, чтобы самому пулять что-то куда-то. Мы, конечно, сами используем его, но для другого - уведомление приложений среднего слоя об изменении настроек, и в целом, по опыту механизм рабочий, но не самый надежный.

Кобанчег
Если высокая интенсивность DML, то как раз это будет создавать меньше overhead чем разнообразные поделки с триггерами.
зависит от... Да и трудно будет посчитать оверхэд разнесенных процессов. Но главное, что страдает надежность.
...
Рейтинг: 0 / 0
22.04.2020, 02:13
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949818
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
Кобанчег
AQ and jobs это лишь обслуживающие механизмы
добавление кучи прокладок убивает KISS ;)
...
Рейтинг: 0 / 0
22.04.2020, 02:15
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949820
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
Есть еще такая хрень:
Bug 14765437 : DATABASE CHANGE NOTIFICATION RETURNS INCORRECT ROWID
 DETAILED PROBLEM DESCRIPTION : database change notification returns incorrect rowid for rows which are chained/migrated
WORKAROUND INFORMATION : reorg table so that there are not changed rows.
Status 84 - Closed, not feasible to fix
...
Рейтинг: 0 / 0
22.04.2020, 02:24
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949821
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Кобанчег
AQ and jobs это лишь обслуживающие механизмы, чтоб обеспечить асинхронность уведомлений и убрать всякую нагрузку на основной процесс.

Смешно, да.
Нагрузка на основной процесс в виде записи в queue table никуда не делась в сравнении с уже обсуждавшимися вариантами - только тут дополнительно требуется создать объект, затем его сериализовать, отписать сопроводиловку и лишь после этого сложить в табличку очереди.
Про обертки над обработчиком Саян, в принципе, уже написал - в рамках обсуждаемой темы это скорее зло и никакие "сишные функции" не отменят этого факта.
В конце концов, можно применить native compilation и получить те же "сишные функции" из pl/sql, которые тоже будут вызываться ядром :)
...
Рейтинг: 0 / 0
22.04.2020, 02:27
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949822
Фотография Кобанчег
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кобанчег
Участник
xtender
Асинхронность - это здорово, но, как следствие, страдает консистентность и вообще упорядоченность.
Под асинхронностью в данном конкретном случае понимается что уведомления обрабатываются вне основного процесса.
Непонятно какая консистентность страдает.
Упорядоченность точно не нарушается поскольку сообщения выгребаются поочередно.
xtender
Он все-таки задуман для того, чтобы самому пулять что-то куда-то.
Не очень понял о чем речь. В callback процедуре можно как угодно обрабатывать изменения.
xtender
по опыту механизм рабочий, но не самый надежный
Интересен конкретный пример ненадежности.
Или use case потери изменения (только не от кривости callback процедуры :)).
...
Рейтинг: 0 / 0
22.04.2020, 02:27
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949824
Фотография Кобанчег
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кобанчег
Участник
andrey_anonymous
Смешно, да.
Лааадно, не надо так воспринимать в штыки.
CDC тоже норм механизм если его уметь готовить, я ж не отрицаю.
andrey_anonymous
В конце концов, можно применить native compilation и получить те же "сишные функции" из pl/sql, которые тоже будут вызываться ядром :)
Но-но, давайте не будем уходить в эти дебри.
Native compilation так же далеко по производительности от C как остров святой Елены от цивилизации.
...
Рейтинг: 0 / 0
22.04.2020, 02:38
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949825
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
Кобанчег,

Чтобы без лишних слов и споров, давай ты сделаешь полный рабочий пример на нескольких таблицах, а я просто над ним побалуюсь. Например, буду в одной транзакции сразу несколько таблиц буду менять?
...
Рейтинг: 0 / 0
22.04.2020, 02:38
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949826
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
Особенно интересно, что будет в твоей таблице-логе при этом.
...
Рейтинг: 0 / 0
22.04.2020, 02:40
| Ответить | Цитировать | Написать  
25 сообщений из 118, страница 4 из 5
  4  все
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Синхронизация таблиц
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&msg=39949800&tid=1881319]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 66ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 50ms
get tp. blocked users:
 1ms
others: 14ms
total:  170ms
созд. / загр.: 170ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]