Добрый день.

Предположим, у меня есть необходимость организовать небольшую одностороннюю репликацию из Oracle SE 11.2 в Oracle SE 11.2.
Базы физически рядышком, сеть между ними хорошая.

в исходной базе - Две схемы, два-три десятка таблиц в каждой.
Первая схема (оперативная)около 5 ГБ, вторая(архивная) около 120 ГБ.
Обе потихоньку растут, оперативная примерно на 1 ГБ в год, архивная примерно на 10-20 ГБ в год.
Первая база - не моя, поэтому никакие DDL мне в ней не разрешены.

Требования: обеспечить максимально быструю (в идеале - онлайн) репликацию данных оперативной схемы, и раз в сутки - архивной.

Сейчас у меня есть ДБлинк с таргетной БД на исходную, с правами "на чтение", и я в ней (в таргетной) врукопашную наворотил процедуры обновления таблиц оперативной схемы данных через этот ДБлинк. Процедуры эти отрабатывают по расписанию. Расписание выставлено "раз в 2 минуты", быстрее не получилось - дельту я отслеживать не могу по причине того, что первая БД - чужая, соответственно триггеры я создавать в ней не могу. Поэтому приходится все таблицы всякий раз транкейтить и обновлять полностью. Время обновления всех этих таблиц варьируется от 30 секунд как раз до двух минут в какие-то пиковые периоды, поэтому и была выбрана такая периодичность.

Начальство в принципе довольно, но т.к. это решение не масштабируемо, хочу реализовать какой-нить другой, более масштабируемый и быстрый, вариант.

Какие есть варианты реализации? Мне не нужно промышленное интеграционное решение. Интересует самописный вариант, который обеспечит вышеуказанные требования.

перед каким выбором ставит меня оракл в этом случае сегодня? или голденгейт, или сами себе пишите триггеры/используйте third party etl tools на тех же триггерах?

Сорри, последняя строка из другой темы :-)

jan2aryQuest999,

Oracle Streams

Oracle Streams: SE1/SE: no capture from redo.

в исх. БД кол-во переключений REDO в час - от 2 до 10. Ждать придется же ?

Alexander Ryndin1) Streams - deprecated, начиная с 11.2 . В будущем его могут полностью выпилить.
2) В Streams на SE нет захвата из redo, но есть sync capture. Это internal триггеры. Захват real time

Лучшее решение - это GoldenGate.

GG стоит денюшек, а их, как известно, нет. Здоровья Вам, хорошего настрое...сорри, поехал по шаблону.

"SYNC capture и internal триггеры" - а можете по-простому, для моего начальства, описать концепцию ?
Или ткнуть, где хорошо описано.

Alexander Ryndin Т.е. если захват изменения и его сохранение не может быть произведено (переполнена или тормозит очередь),то само изменение не может быть выполнено.


Если я верно понимаю, то возникают риски появления тормозов в т.ч. (по указанным в скобках причинам) в исходной БД ?

И подозреваю, что для настройки этого механизма я должен иметь права DBA в исходной БД ?

Alexander RyndinQuest999пропущено...


Если я верно понимаю, то возникают риски появления тормозов в т.ч. (по указанным в скобках причинам) в исходной БД ?

И подозреваю, что для настройки этого механизма я должен иметь права DBA в исходной БД ?1. Да
2. Не обязательно DBA, но довольно обширными правами

Спасибо, не подходит категорически.
Еще идеи будут ?

dbpatchQuest999, что первая БД - чужая, соответственно триггеры я создавать в ней не могу.

перед каким выбором ставит меня оракл в этом случае сегодня? или голденгейт, или сами себе пишите триггеры/используйте third party etl tools на тех же триггерах?

какое-то противоречие. т.е. триггеры создать не могу, но дблинк - могу,
так правов нет, но gg (который фактически дает чуть ли не права DBA) - поставить можно.

что мешает договориться с владельцем базы и поставить классические MVIEW LOGS с целью обеспечения fast refresh, а не какие-то самострельные - не понятно.

вот пример для простых смертных про mview fast refresh over dblink

https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:9489297400346775376#9507501000346495836


P.S. и даже триггеры - их-же можно поставить в отдельную схему...
Фраза про ГГ была включена в исходный пост ошибочно, о чем я сразу же и написал.
Какие права нужны, чтобы ставить ГГ - не в курсе, ГГ не подходит однозначно по причине дороговизны, в эту тему не углубляемся.

Далее. Насчет mview fast refresh over dblink - Договориться с владельцем исходной базы не получится по определению, создавать свои обьекты , в том числе и матвьюлоги, я в ней не могу. Тоже не обсуждается.

По поводу дблинка - Права ДБА в данном случае нужны для второй базы, а не для первой. Вторую базу делал сам, поэтому права ДБА как бы есть.

Прошу внимательнее читать тему перед тем, как что-то советовать.

dbpatchQuest999Прошу внимательнее читать тему перед тем, как что-то советовать.
Спасибо за нравоучение, их тут ну очень не хватает, да.

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

Выход тут простой - заводим другую схему, в ней ставим свои объекты, все счастливы, никто никому не мешает.


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


В том и проблема, что база не моя и делать я в ней ничего не могу. Еще раз прошу - читайТЕ внимательнее, прежде чем что-то советовать, вежливый Вы наш.

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

Выход тут простой - заводим другую схему, в ней ставим свои объекты, все счастливы, никто никому не мешает.



У владельца той, исходной, базы, есть система контроля версий.
Мониторинг чужих объектов тоже присутствует. Присутствуют и сильные неприязненные отношения с нашей организацией, из-за плохой нестабильной работы этой БД, и любой чужой объект в этой БД, пусть даже в другой схеме, вызовет обвинения его создателя(т.е. меня) во всех смертных грехах, касающихся и даже не касающихся этой БД.
Я не думал, что это всё надо тут так подробно описывать, но, видимо, по-другому понимания не найти.
Еще раз - есть исходная ЧУЖАЯ база и ДБлинк на чтение, через который я могу тянуть из нее данные.
Просьба предложить в этой связи механизм репликации лучше, чем нынешний.

Dimitry SibiryakovdbpatchА с маразмами вида "база моя, не пущать никого, ибо мне так захотелося, усе все поняли?" -
это вам там пожалуй нужно в какой другой форум, медицинский

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


Вот, наконец-то забрезжил свет в конце тоннеля :-)

Новых идей нет, тему можно закрывать.