|
|
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
Здравствуйте, Уважаемые все . бьюсь неделю - не получается сделать. перерыл все форумы и доки Multimaster репликация не подходит (нужна однонаправленная репликация). Дано: 1. 8.1.7. EE, NoArchiveLog Mode, n-баз разбросанных географически / вносятся изменения (DML) в локальные базы (уже ведутся snapshot log) 2. узкий еле дышащий канал спутниковой связи на 64К 3. центральная база 8.1.7. EE Noarchive Требуется :нужно, чтобы эти изменения отображались в центральной базе. но изменения в центральной базе не должны отображаться на локальных. как можно сделать одностороннюю репликацию с n-количества узлов в одну базу? есть ли готовое решение ? можно ли сделать snapshot из n баз ? ведь IMHO snapshot можно создать только из одной таблицы. задача достаточно распространенная. если у кого есть опыт, плиз поделитесь, буду рад тоже потом помочь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2003, 15:09:42 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
А в чем, собственно, проблема? У тебя есть мастер-сайт, несколько снапшот-сайтов. Создается поддержка репликации так, как описано в Replication Management API Reference, за некоторыми отличиями: мат.представления не включаются в группу(-ы) обновления, явно или неявно. Может быть на снапшот-сайтах будет асинхронная репликация, может быть не следует создавать задания на SCHEDULE PUSH и SCHEDULE PURGE - будешь сам выполнять. Что еще? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2003, 15:26:26 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
to Tim Lynx: А можно сделать совсем по тупому, хотя бы временно: job-ы в центральной базе просто выставить в состояние broken - отложенные транзакици нужно будет периодически удалять ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2003, 15:45:54 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
To Denis Popov: Я думаю так не получится. Т.к. в локальных базах должна быть информация, которая не должна быть доступна на других локальных базах. а центральная должна содержать данные со всех локальных базах. To Softbuilder@inbox.ru: В смысле реализуется схема multimaster и отключить jobs на центральном мастере? хорошая мысль. я попробую. а как тогда отключить связи между локальными базами. это же неизбежно приведет к репликации между ними в обход центральной базы. кстати, по поводу multimaster. хочу уточнить для себя. в этой реализации тоже имеется наподобии мастер базы aka master definition site, который устанавливается при создании мастер-группы? thanx for responce ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2003, 07:38:39 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
А исходя из чего ты делаешь вывод, что данные с одного локального сайта попадут на другой? Реализуй схему, когда мат.представления никогда не обновляются, а только "проталкивают" данные на мастер-сервер, о чем я и говорил в предыдущем письме. Т.е. групп обновления нет вообще, а, стало быть, и отключать задания не надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2003, 10:44:50 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
To Denis Popov: Имеется ввиду такая реализация - мастер находится на центральном сервере, а обновляемые snapshots находятся на локальных серверах? что значит "проталкиваются" ? еще раз внимательно перечитаю REPLICATION MANGER API REFERENCE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 07:22:27 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
to Tim Lynx: "хочу уточнить для себя. в этой реализации тоже имеется наподобии мастер базы aka master definition site, который устанавливается при создании мастер-группы?" это единственное различие между базами в мульти-мастер репликации - то что один master definition. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 08:56:06 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
To softbuilder: Спасибо. Я построил пробную систему из четырех узлов. /* 4 instance на одном сервере : 3 "локальных" и один "центральный" */ заработало. осталось отключить связи между "локальными" думаю теперь какой метод красивее этот или тот, который советует Denis popov. и еще теперь небольшая проблема - изящно забрать накопленные snapshot log'и с локальных серверов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 12:04:03 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
в принципе можно обойтись и без мат.вьюх. На локалньных базах, на таблицах висят триггера(на INSERT,UPDATE,DELETE) которые собирают изменения в виде скриптов(типа 'INSERT INTO ...') в таблицу буффер на центральной базе. На центрально базе раз минут в 10 срабатывает джоб, который эти скрипты прогоняет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 15:31:22 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
в принципе можно обойтись и без мат.вьюх. На локалньных базах, на таблицах висят триггера(на INSERT,UPDATE,DELETE) которые собирают изменения в виде скриптов(типа 'INSERT INTO ...') в таблицу буффер на центральной базе. На центрально базе раз минут в 10 срабатывает джоб, который эти скрипты прогоняет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2003, 15:31:28 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
В документации написано, что Оракл настоятельно не рекомендует использовать materialized view aka snapshots для больших таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 12:23:18 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
Хм, а точную ссылку на данное утверждение можно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2003, 12:58:20 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
To Denis Popov: See документацию из Knowlege Xpert for Oracle Administration. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 15:18:05 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
А каков точный адрес, по меню Knowledge Expert for Oracle Administration? У меня версия 6.1.1. Но больше всего меня интересует ссылка на фразу от самой компании Oracle, что она "настоятельно не рекомендует использовать materialized view ... для больших таблиц." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2003, 15:34:15 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
To Denis Popov: Возможно погорячился, назвав сотрудников Quest Software сотрудниками Оракл (хотя возможна утечка :-) ). у меня версия 6.1. в разделе репликация. Лучше процитировать : Oracle snapshots are an excellent method to replicate data from a small table in one database to another. Typically you will create a snapshot log on the table to be replicated in the source database and create a snapshot from the target database. If you desire, you can replicate from one user in an instance to another user in the same instance. Our advice is that if you plan to replicate large amounts of data across databases, if practical, you should be using Oracle Advanced Replication. Do NOT use snapshots for replicating large volumes of data! While Oracle has introduced dramatic performance improvements in both snapshots and advanced replication, there are still many occasions where an entire table requires to be refreshed if snapshots are utilized. хотя возможно они и не правы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2003, 08:41:13 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
возникла идея. сделать в центральной базе n-схем (по количеству узлов) каждая схема- snapshot содержимого на узле. а потом повесить по триггеру на snapshot-таблицу чтобы данные из n-таблиц стекались в одну таблицу. неужели это глупая мысль ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2003, 09:39:46 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
Я, откровенно говоря, озадачен: а на чем как не на shapshot'ах, сиречь materialized views, базируется Advanced Replication? У меня одно предположение: в этой фразе содержится призыв перехода на новые версии Оракла, поскольку даже в родной документации на 9i есть фраза про то, что "Performance improvements make refreshing materialized views faster in release 9.0": http://technet.oracle.com/docs/products/oracle9i/doc_library/release2/server.920/a96567/wnrep.htm#969714 В самом Knowlege Xpert for Oracle Administration 6.1.1 я наткнулся на фразу из Advanced Replication Overview: If you are replicating large tables, we strongly recommend that you utilize Oracle Advanced Replication in preference to Oracle Snapshots. Oracle8 transaction rates are rated at between 30 and 50 transactions per second. If your site has a requirement for higher transaction volumes, you should consider 3rd party products which can process 100s of transactions per second. Мне всерьез было бы очень интересно узнать подробнее про такие продукты. Ты уже отказался от мультимастерной репликации, раз думаешь о создании подобных схем на мастер сайте? А "кто на ком стоял", т.е. кто должен являться инициатором обновления данных? Требуется ли с мастер-сайта реплицировать на локальные сервера, к примеру, какие-то общие справочники? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2003, 11:39:13 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
"Я, откровенно говоря, озадачен: а на чем как не на shapshot'ах, сиречь materialized views, базируется Advanced Replication?" Расширенная репликация с мульти-мастер репликацией никак не связана с shapshot-ми. В случае асинхронной например, есть понятие отложенных транзакций. Но это совсем другое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2003, 11:44:09 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
Да, действительно, про мультимастер я забыл. Но эти типы репликации: мастер-мастер, мастер-локальный сайт а также смешанный, рассматриваются как и Advanced Replication, так и в Replication Management API Reference. И почему разработчики Knowlege Xpert советуют воспользоваться именно Advanced Replication мне непонятно. Если, конечно, речь не идет о разных версиях Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2003, 12:07:24 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
To Denis Popov: нет я не отказался. я хочу детально изучить различные методы, протестировать, и внедрять в продакшн. всем же известно, что с продакшном шутки очень плохи. сейчас я рассматриваю твой предложенный метод. Вообще - инициатор обновлений - локальные базы - т.к. там в основном должна начаться /*ведется*/ активная транзактивная активность /*извиняюсь за каламбур*/. там потому что расположены оперативные подразделения. а центральная должна просто показывать все содержимое этих баз на местах. считай warehouse. даже изменяться не будут данные в центральной базе. т.е. задача обратная классической /*когда главная база из офиса тиражируется на местах*/. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2003, 07:10:49 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
Есть еще вариант решения проблемы. У меня было так напрошлой работе сделано. Сделать двойной идентификатор (id, node_id) .Node_id - это уникальный номер узла. Потом когда создаешь снапшоты, то в условии ставишь чтобы node_id равнялось только этому узлу и у тебя на мастере будут все данные, а на сайтах те что они только ввели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2003, 18:56:01 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
хм... я думаю, что вряд ли девелоперы согласятся изменять в продакшне структуру n-цать таблиц на n-цати узлах . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2003, 15:59:35 |
|
||
|
как ? с n- узлов репликация в одну базу. ослеживать измения.
|
|||
|---|---|---|---|
|
#18+
Еще один вопрос. Правда ли ?, обновляемые Snapshots инициируют обновление в мастер таблице. иными словами, если пользователь обновил snapshot то, изменения попадают в мастер - таблицу. Или это я не так понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2003, 07:22:48 |
|
||
|
|

start [/forum/topic.php?fid=52&fpage=2771&tid=1990270]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
293ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 234ms |
| total: | 623ms |

| 0 / 0 |
