|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
Да и вообще, траблшутинг этой штуки на порядки сложнее и муторнее всех остальных вариантов. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 02:48 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
xtender Особенно интересно, что будет в твоей таблице-логе при этом. Ну тогда берем пример из доки и делаем replace chnf_callback на t_callback. t_callback Код: 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.
Create database tables to hold records of notification events received Код: 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.
Потом Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
Хотя я не очень понял что требуется от меня, ты и сам прекрасно мог бы это скопипастить. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 02:57 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
Кобанчег, где scn или метка изменения, по которой другие базы будут забирать изменения с...? xtender рабочий пример на нескольких таблицах , а я просто над ним побалуюсь. Например, буду в одной транзакции сразу несколько таблиц буду менять? xtender Особенно интересно, что будет в твоей таблице-логе при этом. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 03:09 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
xtender что будет в твоей таблице-логе при этом. Использовать все это счастье ради ведения таблицы-лога, серьезно?! Я рассматривал лишь вариант доставки lcr непосредственно до целевой реплики - это хоть как-то оправдывает идею ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 03:33 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
xtender, Так норм? Код: plsql 1. 2. 3. 4. 5. 6.
+ в callback Код: plsql 1. 2.
За сим спешу откланяться. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 03:35 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
andrey_anonymous вариант доставки ... непосредственно до ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 03:39 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
Кобанчег xtender, Так норм? Код: plsql 1.
. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 03:45 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
andrey_anonymous, Собственно, я про это и говорил, что механизм qcn не совсем для этого, но у тс как заявлено до 500 удалённых баз, которые ещё и недоступны периодически, что приводит к необходимости вытягивания измененных данных самими целевыми базами. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 03:49 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
andrey_anonymous, Неверно. Этот момент легко отслеживается. Вернее, в любой момент времени можно однозначно сказать, какие именно записи лога можно удалить. Делается это по-разному. В том варианте, который я показал - выборкой "минимального из максимальных" repsite%_sync_log. В более общем варианте - из каталога "подписчиков", где каждый из них и отмечает что он уже забрал, а что - еще нет. тут есть некоторые практические проблемы 1 пока все не скачают лог чистить нельзя, но вот есть объекты на побережье которые на пол года закрываются и соответственно ничего не качают держать логи не чищеными по пол года будет грустно, поэтому была идея множить записи (1=100) 2 некоторые объекты закрываются и качать не будут и нужно вручную исключать их из подписчиков, это задача операторов, но пока их не пнешь ничего не измениться ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 10:57 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
Для случая XE, КМК, дешевле заливать каждый час/10 мин TTS со справочниками, чем парится с репликацией ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 11:33 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
Vadim Lejnin Для случая XE, КМК, дешевле заливать каждый час/10 мин TTS со справочниками, чем парится с репликацией авторOracle® Database Express Edition Licensing Information 11g Release 2 (11.2) … 2 Feature Availability … 2.1 Options and Major Features Not Included The following options and major features are not included with Oracle Database XE: …
... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 12:31 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
ilyuha111, я просил бы Вас все-таки разобраться с цитированием на форуме - очень сложно читать. ilyuha111 тут есть некоторые практические проблемы 1 пока все не скачают лог чистить нельзя, но вот есть объекты на побережье которые на пол года закрываются и соответственно ничего не качают держать логи не чищеными по пол года будет грустно, поэтому была идея множить записи (1=100)
ilyuha111 Это тоже можно обыграть, установив предельный срок хранения логов. Подписчик, пытающийся синхронизироваться по истечении такого срока, получит exception на фазе setup и должен перейти к процедуре полной пересинхронизации. Критерии подобного поведения есть в статье (самая старая запись лога должна быть старше самого свежего ключа синхронизации конкретного подписчика). В статье также описаны процедуры принудительного отлучения подписчика от репликации и зачистки логов. Просто надо изучить тему в подробностях - все эти вопросы уже 25+ лет как рассмотрены и так или иначе решены. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 12:49 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
xtender ну приехали... Совсем не норм. Все остальные свистопердлеки допиливаются будь на то необходимость. Моей ошибкой было начать предоставлять детальный код. Если сам захочешь разобраться - разберешься. В качестве доказательства ненадежности был предоставлен баг для версии 11.2.0.3 на солярке. С таким же успехом я могу предоставить на несколько порядков больше багов про параллельное выполнение. И что? Ты перестанешь его использовать? У дырявого Оракла баги есть чуть больше чем везде. Вон даже в самых базовых вещах типа внешних ключей бывает такое 10009012 . Я думал говоря про "ненадежность" тут будет беседа экспертов про архитектурные уязвимости, а увидел только "мы этого не знаем - потому это плохо". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 13:36 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
Кобанчег Если сам захочешь разобраться - разберешься. Кобанчег Моей ошибкой было начать предоставлять детальный код. Кобанчег В качестве доказательства ненадежности был предоставлен баг для версии 11.2.0.3 на солярке. Кобанчег Я думал говоря про "ненадежность" тут будет беседа экспертов про архитектурные уязвимости, а увидел только "мы этого не знаем - потому это плохо". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 14:11 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
xtender Кобанчег Моей ошибкой было начать предоставлять детальный код. Тут абсолютно неразумно реализовывать логику в callback proc и полагаться что у всех у них все пройдет гладко. При таких вводных DIY с индексированным логом изменений типа показанного тобой смотрится достаточно предпочтительно. Кстати может я пропустил, но не было сказано кто такие клиенты. По всей вероятности это не базы. Если б их были десятки и драйвер JDBC (или .net), то можно было бы использовать другие уведомления . :) При таком раскладе для конкретной DatabaseChangeRegistration регистрируются клиентские листенеры и получают уведомления. xtender Я думал ты предоставишь код, а я предоставлю пару примеров, когда "консистентность и упорядоченность" нарушаются. Например, когда твой коллбэк для более ранней, но крупной транзакции, закончится позже более поздних, но коротких. Соответственно, более ранние изменения станут видны позже. DBMS_AQADM_SYS.REGISTER_DRIVER не приступит к обработке следуюшего изменения не закончив текущее. На одно уведомление не может быть более чем одной запущенной задачи AQ$_PLSQL_NTFN. Ну это все мои исследования, нигде в интернетах не попадался детыльный анализ внутренностей. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 14:57 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
Кобанчег ТС желал change_id, для этих целей элементарно используется registration_id. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
"REGID""EVENT_TYPE""XID""ORA_ROWSCN""301""7""08000A000F9C0000""111582628""301""7""0A0001007C340100""111582636""301""7""08000300159C0000""111582641" ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 15:10 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
xtender, То я херню сказал, это же айдишник из метаданных. Придется прибегать к тяжелой артиллерии в виде identity/sequence. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 15:21 |
|
Синхронизация таблиц
|
|||
---|---|---|---|
#18+
Кобанчег ТС желал change_id, для этих целей элементарно используется registration_id. Ни один атрибут, сформированный транзакцией, проводящей dml, использован быть не может. Тут подойдут либо ora_rowscn централизованной таблицы-лога (nfevents), либо генерация последовательности при выборке сообщений из очереди. Сейчас уже не помню, как именно гребутся сообщения из неприоритезированной очереди. Если иначе чем из mlog$ - то возможны инверсии. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2020, 15:24 |
|
|
start [/forum/topic.php?fid=52&gotonew=1&tid=1881319]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
159ms |
get topic data: |
12ms |
get first new msg: |
8ms |
get forum data: |
2ms |
get page messages: |
106ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 330ms |
0 / 0 |