ReSQL.ru
     
powered by simpleCommunicator - 2.0.52     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Синхронизация таблиц
25 сообщений из 118, страница 3 из 5
  3  все
Синхронизация таблиц
    #39949346
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
ilyuha111
тут если есть незакрытая транзакция
это вы сами себе проблем насоздавали из-за dbms_flashback.get_system_change_number, вместо ora_rowscn
...
Рейтинг: 0 / 0
21.04.2020, 14:04
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949347
ilyuha111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ilyuha111
Гость
Stax,
22119463
...
Рейтинг: 0 / 0
21.04.2020, 14:04
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949353
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stax
Участник
ilyuha111
тут если есть незакрытая транзакция в момент обмена (1)
то записей я еще не вижу (2)

не закоммиченные записи ВЫ в оракле не увидите
поетому xtender и предлогает ORA_ROWSCN (в древних COMMITSCN с нюансами)

.....
stax
...
Рейтинг: 0 / 0
21.04.2020, 14:20
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949359
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stax
Участник
ilyuha111
Stax,
22119463

у меня нет практики с Flashback
поетому ничего не могу посоветовать
Вам тестировать, напр запись меняется сутку (с утра update вечером commit)
как синхронизация отработает, устраивает ли ето бизнес

мож достаточно просто ночью все обновить и заморачиваться

....
stax
...
Рейтинг: 0 / 0
21.04.2020, 14:29
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949365
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
ilyuha111
тут если есть незакрытая транзакция в момент обмена (1)

Жаль, что Вас не устраивают технологии, разработанные более 20 лет назад, работающие до сих пор в вендорском enterprise-коде, не нарушающие acid, а главное - легко воспроизводимые.
Давно бы закрыли тему.
...
Рейтинг: 0 / 0
21.04.2020, 14:32
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949378
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Stax
поетому xtender и предлогает ORA_ROWSCN (в древних COMMITSCN с нюансами)

Если бы Саян еще предложил эффективный метод доступа к данным по ora_rowscn - цены бы методу не было :)
...
Рейтинг: 0 / 0
21.04.2020, 14:48
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949381
ilyuha111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ilyuha111
Гость
xtender,
рассматривал ora_rowscn по этой ссылке

http://torofimofu.blogspot.com/2016/12/orarowscn-oracle-11g.html

1 По умолчанию значение SCN, отображаемое в псевдостолбце ora_rowscn, хранится на уровне блока данных (если рандомно обновить 30% большой таблицы по передавать её придется почти целиком )
2 К сожалению, с помощью alter table данное свойство включить нельзя. Нужно пересоздать таблицу:
3 Хранение SCN для каждой строки требует дополнительно 6 байт на строку.(как этот на xe повлияет вроде не должно но малоли)
вот 3 пункта по которым ora_rowscn мне применять очень затратно
...
Рейтинг: 0 / 0
21.04.2020, 14:51
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949388
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
ilyuha111
Хранение SCN для каждой строки требует дополнительно 6 байт на строку.

Не, ну если все настолько плохо и ради экономии Вы готовы на любые затраты - то сразу рисуйте парсер [redo|archive]log-ов.
Будет третий (?) - я лично знаю два - конкурент goldengate-у.
...
Рейтинг: 0 / 0
21.04.2020, 14:58
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949392
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
andrey_anonymous
Stax
поетому xtender и предлогает ORA_ROWSCN (в древних COMMITSCN с нюансами)

Если бы Саян еще предложил эффективный метод доступа к данным по ora_rowscn - цены бы методу не было :)
ну я могу что-нибудь еще навыдумывать, но ты определись какие два из трех выберешь: быстро, дешево, надежно
...
Рейтинг: 0 / 0
21.04.2020, 15:06
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949393
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
ilyuha111
3 Хранение SCN для каждой строки требует дополнительно 6 байт на строку
ваш CHANGE_ID тот же SCN
...
Рейтинг: 0 / 0
21.04.2020, 15:07
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949396
ilyuha111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ilyuha111
Гость
в общем то второй пункт не выполним пересоздать и перезалить все таблицы трудновыполнима
select * from t_Country t WHERE T.ora_rowscn >=61663434930
Description Object owner Object name Cost Cardinality Bytes
SELECT STATEMENT, GOAL = ALL_ROWS 3 5 110
TABLE ACCESS FULL ORGANIZ T_COUNTRY 3 5 110
TABLE ACCESS FULL - это тоже не понятно как решать
...
Рейтинг: 0 / 0
21.04.2020, 15:13
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949402
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-2-
Участник
ilyuha111
TABLE ACCESS FULL - это тоже не понятно как решать
При cardinality=5 решать нужно радикально. Что ora_rowscn, что лог-таблицы - только помеха.
...
Рейтинг: 0 / 0
21.04.2020, 15:19
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949406
ilyuha111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ilyuha111
Гость
-2-,
t_Country это тестовая табличка другие побольше будут
...
Рейтинг: 0 / 0
21.04.2020, 15:22
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949413
ilyuha111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ilyuha111
Гость
-2-,

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

офлан через ftp было работало,стабильно но мелено
...
Рейтинг: 0 / 0
21.04.2020, 15:31
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949424
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stax
Участник
ilyuha111

для большого количества таблиц и клиентов


клиенты ето базы или пользователи?

большое количество ето 100, 1000, или миллионы?

зы
если синхронизация некретична, накатываем что вышло

ночью (при минимальной активности), досихронизуруем (возможно по другому алгоритму)

зыы
прелесть логов в том что их можно офлайново передать и накатить
но и обьемы соответствующие

зыыы
у нас пользуют капризный GG, но он платный
....
stax
...
Рейтинг: 0 / 0
21.04.2020, 16:02
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949438
ilyuha111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ilyuha111
Гость
Stax,

клиентов максимально до 500-600

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


из наблюдений решение которое работает для 20 клиентов не работает для 500 и наоборот :)
...
Рейтинг: 0 / 0
21.04.2020, 16:17
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949441
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stax
Участник
ilyuha111,

может проще решить на прикладном уровне

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

темболее, часто переданные (синхронизированые) уже нельзя изменить без санкции вышестоящих босов

.....
stax
...
Рейтинг: 0 / 0
21.04.2020, 16:24
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949458
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
Stax
может проще решить

Это уже пошло кормление тролля, кмк.
Круг доступных вариантов без привлечения стороннего ПО и в ограничениях XE 11.2, вообще говоря, обозначен.
С учетом ограничений XE как источника изменений (в случае приемника вариантов больше):

- дата изменения + перезаклад на максимально возможную/допустимую длительность транзакции.
- самодельная реализация триггерной репликации на технологической основе mview log - отвергнута ТС, потому что "старая" и вообще разбираться лень
- ora_rowscn - отвергнута ТС, потому что "6 байт на строку" и вообще "full table access"
- парсинг redolog/archivelog - ТС проигнорирована
Не упомянули разве что развитие вариантов триггерной репликации с выходом на:
- AQ
- utl_file
- syslog
- SOAP/REST/...
- EXPPROC

но оно тоже, наверное, не подходит :)

Также не обсуждали замену триггера на OdciIndex при некоторых административных ограничениях, но это уже точно факультативно.
...
Рейтинг: 0 / 0
21.04.2020, 17:02
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949507
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ilyuha111предлагайте варианты без помех
без дополнительно софта
средствами хе
на узких каналах связи
для большого количества таблиц и клиентов

Это надо ждать розового единорога с Экскалибуром во лбу.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
21.04.2020, 17:42
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949529
ilyuha111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ilyuha111
Гость
andrey_anonymous,
- дата изменения + перезаклад на максимально возможную/допустимую длительность транзакции.
зачем закладка если при обмене точно знаю какие транзакции висят не завершенные
- самодельная реализация триггерной репликации на технологической основе mview log - отвергнута ТС, потому что "старая" и вообще разбираться лень
я так понимаю вы имеете ввиду следующий механизм заполонять триммерами точную копию таблицы а через какой то интервал времени проталкивать таблицу по всем клиентам затем очищать таблицу
не подходит так как у кого то выходной ,нет инета, ком вырубили, и прочие проблемы. инициатива обмена идет от клиента тогда когда ему удобно

- ora_rowscn - отвергнута ТС, потому что "6 байт на строку" и вообще "full table access"
нет по причине того что надо пересоздать все таблицы которые участвуют в обмене rowdependencies.
- парсинг redolog/archivelog - ТС проигнорирована
базы noarchivelog


Не упомянули разве что развитие вариантов триггерной репликации с выходом на:
- AQ это не знаю что
- utl_file это было
- syslog это не знаю что
- SOAP/REST/... это не знаю что
- EXPPROC это не знаю что

но оно тоже, наверное, не подходит :)

Также не обсуждали замену триггера на OdciIndex при некоторых административных ограничениях, но это уже точно факультативно.
...
Рейтинг: 0 / 0
21.04.2020, 18:07
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949564
Фотография Stax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stax
Участник
ilyuha111

базы noarchivelog

не понимаю я ето

ps
клиенты кто базы или пользователи (юсеры)?
.....
stax
...
Рейтинг: 0 / 0
21.04.2020, 19:00
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949567
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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>
...
Рейтинг: 0 / 0
21.04.2020, 19:01
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949581
oragraf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oragraf
Участник
ilyuha111
зачем закладка если при обмене точно знаю какие транзакции висят не завершенные
 
"Проблема не в том, что человек смертен, а в том, что он - внезапно смертен."(с) МиМ
Перефразируя классика, проблема в том, что ты не знаешь, когда они завершатся.
ilyuha111
базы noarchivelog
Тут сам бог велел поэкспериментировать.
ТС, послушай анонимуса и не парь мозг.
...
Рейтинг: 0 / 0
21.04.2020, 19:13
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949585
MazoHist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MazoHist
Участник
ilyuha111

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

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

при грамотной реализации - нет
...
Рейтинг: 0 / 0
21.04.2020, 19:19
| Ответить | Цитировать | Написать  
Синхронизация таблиц
    #39949593
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
MazoHistпри грамотной реализации - нет

Значит существуют всего две реализации: грамотная и надёжно работающая.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
21.04.2020, 19:32
| Ответить | Цитировать | Написать  
25 сообщений из 118, страница 3 из 5
  3  все
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Синхронизация таблиц
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&msg=39949567&tid=1881319]:
 0ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 51ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 62ms
get tp. blocked users:
 1ms
others: 21ms
total:  173ms
созд. / загр.: 173ms
x
x
Закрыть


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