Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Помогите выбрать схему репликации!  [new]
egik87
Member

Откуда:
Сообщений: 76
Здравствуйте уважаемые! Помогите определиться с тем как лучше организовать репликацию данных.
Ситуация такая:
Имеется n одинаковых баз. Пусть они будут периферийные.
Имеется одна точно такая же база, назовем её главной.

Нужно организовать ОДНОСТОРОННИЙ обмен данными из некоторых таблиц периферийных баз в главную.
Возможность редактирования таблиц должна сохраняться и на периферийных базах и на главной. Таким образом в главной базе в определенных таблицах должна содержаться информация со всех периферийных + та, что уже была в главной и будет добавляться в процессе работы.

Я пробовал настроить мультимастер, все получилось. Добавил свой метод разрешения конфликтов (при репликации безусловно нужно менять значения полей таблиц, приходящих с периферии). Но не устраивает то что репликация двусторонняя:( При создании материализованных представлений (Read-Only) таблица в главной базе не редактируется, что тоже плохо. Как я понял если сделать Updatable Materialized View то изменения опять же будут возвращаться в периферию..
Помогите пожалуйста!
23 июн 10, 11:32    [8985657]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
GL
Member

Откуда: Харьков
Сообщений: 1513
egik87,

Забудьте про Advanced Replication, смотрите в сторону Streams.
23 июн 10, 12:18    [8986158]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
huliGUN
Member

Откуда: Ахметов Сити; Санкт Харьков; Донецк (Киев);
Сообщений: 466
Маловато исходных данных.
А в целом создаете пачку схем по имени переферийных, например, там матвьюшка на таблу в переферийной БД.
Затем пишем пакетик который бы делал сбор данных со всех матвьюшек в нужную таблицу, так как вам это надо.
23 июн 10, 12:46    [8986489]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
egik87
Member

Откуда:
Сообщений: 76
GL
То есть средствами Advanced Replication это сделать не реально? Просто очень не хотелось бы со Streams разбираться:(

huliGUN
В целом руками все написать то можно, но не хотелось бы. Хотелось бы средствами Advanced Replication. А каких данных Вам не хватает?
23 июн 10, 13:13    [8986830]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
egik87
Нужно организовать ОДНОСТОРОННИЙ обмен данными из некоторых таблиц периферийных баз в главную.
Возможность редактирования таблиц должна сохраняться и на периферийных базах и на главной. Таким образом в главной базе в определенных таблицах должна содержаться информация со всех периферийных + та, что уже была в главной и будет добавляться в процессе работы.


Что то не понятно. Нужна односторонняя репликация, или всё же "Возможность редактирования таблиц"? И "точно такая же база" не вяжется с проблемой "изменения опять же будут возвращаться в периферию". Если изменения не реплицируются, то базы разные.

Полагаю, несколько примеров прояснят ситуацию.
23 июн 10, 13:30    [8987026]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
egik87
Member

Откуда:
Сообщений: 76
mcureenab
Извините, видимо это моя ошибка, не понятно описал.
Имеется некая база в центральном офисе. В ней есть допустим таблица "Клиенты" с PrimaryKey в виде обычного инкрементируемого поля id.
Такая же база по структуре но не по данным есть в 3х периферийных офисах. В них соответственно тоже есть таблица "Клиенты" со своими данными, отличными от данных в центральном офисе.
Цель: Объединить все данные с таблиц "Клиенты" с периферийных офисов в таблице "Клиенты" центрального офиса. При этом неизбежно возникновение конфликта, т.к. id будут повторяться. Но это решается написанием своей процедуры урегулирования конфликтов. Так же таблица "Клиенты" в центральном офисе должна быть редактируема, потому что в неё могут вноситься все новые и новые клиенты. ИЗ центрального офиса данные на периферию не должны возвращаться.
То есть в центральном офисе аккумулируется инфа о всех клиентах всех офисов. Надеюсь так понятней.
23 июн 10, 14:02    [8987380]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
egik87
Member

Откуда:
Сообщений: 76
Что если попробовать использовать writeable materialized views? Только я вот инфы по ним найти не могу нормальной.
23 июн 10, 14:40    [8987850]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
egik87,

по моему всё просто. делаем репликацию снимка. источник - в центральном офисе, в филиалах - частичные обновляемые снимки. Если в штабквартире меняются данные не реплицируемые в филиалы, то они туда и не попадут по условиям отбора. Если меняем данные, которые есть в филиале, то уже никуда не денешься, они реплицируются в филиал, иначе это уже не реплика будет.
соответственно в филиале можем менять данные и эти изменения будут реплицированы в штабквартиру.
23 июн 10, 14:50    [8987981]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
egik87
Member

Откуда:
Сообщений: 76
mcureenab
Извините, но видимо я опять не так объяснил. Данные из центрального офиса не должны возвращаться на периферию. Изменятся они или нет. Только с периферии в главный офис. Буду очень благодарен за совет.
23 июн 10, 14:58    [8988102]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
Данные из филиалов сливаются в главный офис и там живут своей жизнью? Репликация этим не занимается. Это больше похоже на обычную загрузку данных. В филиалах транзакции сохраняются в очереди AQ, в штабквартире извлекаются из очередей и накатываются на хранилище данных.
23 июн 10, 15:32    [8988384]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
egik87
Member

Откуда:
Сообщений: 76
Ну очень на это похоже. В идеале данные с периферии должны просто складироваться в главном офисе и не должны там меняться. Просто в эти же таблицы добавляются новые данные пользователями в главном офисе. именно добавляются а не меняются уже имеющиеся. Мне вот казалось что регулярный сбор данных с разных баз это все же к репликации относится.
Разрешите еще отнять немного Вашего времени. При использовании Updatable Materialized Views можно сделать так, чтобы при изменении данных на вьюшке эти изменения не возвращались на мастер?
23 июн 10, 15:46    [8988486]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
egik87,

ну чёты мозг паришь.

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

вот так можно держать данные HQ и филиалов в одной таблице и раздавать их по филиалам.

table A (
   data ...
   owner number
);

В филиале 10.

create view A as select ... from A@HQ where owner = 10 with check option;

insert into A .. values (... , 10);


В филиале 9.
create view A as select ... from A@HQ where owner = 9 with check option;


insert into A ... values (... , 9);

В штабквартире.

insert into A ... values (... , 0);
.
23 июн 10, 16:00    [8988612]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
egik87
Мне вот казалось что регулярный сбор данных с разных баз это все же к репликации относится.


Репликация создаёт полную или частичную КОПИЮ данных.
23 июн 10, 16:06    [8988679]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
huliGUN
Member

Откуда: Ахметов Сити; Санкт Харьков; Донецк (Киев);
Сообщений: 466
egik87
Ну очень на это похоже. В идеале данные с периферии должны просто складироваться в главном офисе и не должны там меняться. Просто в эти же таблицы добавляются новые данные пользователями в главном офисе. именно добавляются а не меняются уже имеющиеся. Мне вот казалось что регулярный сбор данных с разных баз это все же к репликации относится.
Разрешите еще отнять немного Вашего времени. При использовании Updatable Materialized Views можно сделать так, чтобы при изменении данных на вьюшке эти изменения не возвращались на мастер?


Не знаю вашей версии, но все же читаем :
http://download.oracle.com/docs/cd/B10501_01/server.920/a96567/toc.htm

и еще момент : ну предположим сделали вы ОДНУ вьшку со всех комплексов, как вы думаете обновиться ли она при отсутствии связи хотя на один из них?
23 июн 10, 16:09    [8988704]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
egik87
Member

Откуда:
Сообщений: 76
Я видать очень плохо объясняю...
Данные идут Только от периферии. Ничего назад не возвращается. Просто таблица "Клиенты"на главном сервере сервере при использовании Read-Only Materialized Views не редактируема получается, а туда нужно данные добавлять.
Сейчас сделал с Updatable Materialized Views, в принципе то что мне надо. Вот только как я понял из документации изменения во вьюшке должны при этом переходить обратно на мастер сайт. У меня не переходят и меня это устраивает, вот только в чем косяк? в моем понимании документации или в настройке?

К сообщению приложен файл. Размер - 0Kb
23 июн 10, 16:20    [8988844]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
LG
Member

Откуда:
Сообщений: 352
egik87
Здравствуйте уважаемые! Помогите определиться с тем как лучше организовать репликацию данных.


Свяжите БД при помощи HS (db link).
Добавьте (если отсутствует) столбец updated с датой обновления строки в таблице (sysdate) на филиалах и в офисе.
Напишите логику по загрузке данных и настройте job по вызову логики с нужной периодичностью.
Примерно так: раз в минуту/час/день/неделю.... вабираем данные из клиенты@филиал1 где дата изменения строки (updated) больше чем период репликации, вставляем данные куда надо.
23 июн 10, 16:35    [8988995]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
egik87
Member

Откуда:
Сообщений: 76
LG
Спасибо за совет.
Люди, ну неужели средствами Oracle нельзя решить такую простую задачу? Ведь по сути надо всего лишь данные с одинаковых по структуре таблиц разных баз слить в одну базу! :(
23 июн 10, 17:37    [8989567]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
LG
Member

Откуда:
Сообщений: 352
egik87
LG
Спасибо за совет.
Люди, ну неужели средствами Oracle нельзя решить такую простую задачу? Ведь по сути надо всего лишь данные с одинаковых по структуре таблиц разных баз слить в одну базу! :(


Средствами Oracle можно сделать все. Вопрос в трудо затратах, эффективности, масштабируемости ....
23 июн 10, 17:42    [8989613]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
egik87
Member

Откуда:
Сообщений: 76
Отлично! Что смотреть в Streams? Data Replication?
23 июн 10, 17:51    [8989691]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
LG
Member

Откуда:
Сообщений: 352
egik87
Отлично! Что смотреть в Streams? Data Replication?

У этих решений есть достоинства и недостатки, чтобы выбрать одно из них необходимо понимать как это работает.
Это затратно по времени.

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

Репликация нужна при большом кол-ве объектов. Ей удобно рулить из EM. Есть ограничения, например, при изменении структуры реплицируемых объектов необходимо ее "замораживать", менять структуру, "размораживать".
Данные во время "заморозки" менять нельзя.

У стримсов свои заморочки.
23 июн 10, 17:59    [8989754]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
egik87
Member

Откуда:
Сообщений: 76
Ну объектов у меня тоже не мало. И EM я использую. И таблица не одна а больше 30 их, и связи между ними мудреные. И периферийных баз вообще непонятно сколько будет. Поэтому и хотелось использовать какой то готовый инструмент. Параллельно со мной уже пишут руками, точнее пробуют.
23 июн 10, 18:21    [8989888]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
egik87
LG
Спасибо за совет.
Люди, ну неужели средствами Oracle нельзя решить такую простую задачу? Ведь по сути надо всего лишь данные с одинаковых по структуре таблиц разных баз слить в одну базу! :(


Кейсы внятно распиши, тогда станет ясно, решит репликация твою задачу или нет. Типа

1. в филиале завели запись 1, она реплицировалась в штабквартиру. всё

2. в филиале изменили запись 1. всё

3. в штабквартире изменили запись 1. всё

и т.д.

если эти кейсы верны, то твой случай нифига не репликация. точнее не репликация данных, посокльку есть ещё процедурная репликация, которая предназначена для массовых изменений, но по сути настолько гибкая, что может делать самые разные вещи.

Если говорить о проедурной репликации, то получаем такие сценарии:

1. в филиале завели запись 1, на insert сработал триггер, вызвал реплицируемую процедуру, вызов процедуры реплицировался в штабквартиру, процедура создала запись 1 в штабквартире. всё

2. в филиале изменили запись 1. всё

3. в штабквартире изменили запись 1. всё

4. в штабквартире завели запись 1. всё

и вообще репликация может быть как синхронная, т.е. insert записи в БД филиала тут же в текущей транзакции (например в триггере на insert) через DB линк вызывает insert в БД штабквартиры, так и асинхронная (отложенными транзакциями через очереди и т.п.).
23 июн 10, 20:33    [8990321]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
lark
Member

Откуда: Far Far Away
Сообщений: 172
На мой взгляд достаточно просто решается с помощью streams.
Односторонняя репликация если я правильно понял задачу. Будет работать.
Правда не совсем ясно про записи пришедшии из филиалов. Будут ли они меняться?
23 июн 10, 22:29    [8990729]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
wildwind
Member

Откуда: Москва
Сообщений: 1296
mcureenab
Кейсы внятно распиши
Похоже для ТС нужно все более конкретно объяснять.

egik87,

Ситуация. В филиале завели клиента, он с "репликацией" приехал в центральный офис. Через пару месяцев манагер в центр. офисе обнаружил, что неправильно написали фамилию клиента. Что он будет делать? Исправит сам в ценральной базе? Или будет звонить в филиал и материть местного манагера, чтобы тот исправил? В первом случае получится расхождение в данных (клиенту снова пошлют письмо с неправильной фамилией). Во втором случае получается не достигнута цель - автоматизация обмена.

Идите спрашивать у бизнеса.
23 июн 10, 23:45    [8990974]     Ответить | Цитировать Сообщить модератору
 Re: Помогите выбрать схему репликации!  [new]
egik87
Member

Откуда:
Сообщений: 76
lark
Похоже первый совет был самым правильным. Нужно это зделать с помощью streams. Записи менять если и будут то без возврата на периферию.
wildwind
Да никто никуда звонить не будет. И исправлять тоже. Нужен просто список всех клиентов на центральной базе. Обновляемый. Вот и все.

Прошу понять, что тема про офис и клиентов это пример, который отражает суть обмена.

Большое спасибо всем за советы!
24 июн 10, 10:44    [8992231]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить