landyrsync забирает архивлоги(новые), которые появляются после заполнения redo на primary
т е ваш стендбай в идеале будет отставать на один(текущий) redo
процесс записи архивлога может открыть архивлог на запись для копирования
заполненного redo/ Если в этот момент запустится rsync он может забрать не до конца
записанный архивлог, соответственно при накате вы получите ошибку
Поэтому rsync должен забирать только новые закрытые архивлоги

вместо rsync, с его проблемами, проще использовать штатные возможности RMAN
Чтобы избежать ограничение на 10 дней резервного сервера, (бо даже RDBMS в режиме recover считается работающей базой), можно поднять урезанный по ресурсам экземпляр на боевой системе, и накатывать по cron с его помощью копию боевой базы, размещенной на дисковой системе резервного сервера.
Это нагружает боевой сервер, но зато легально для создания standby базы на файловой системе другого сервера.

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

Alexander Ryndinmaverick2104... действия датагарда можно легко симулировать парами скриптов которые будут запускаться каждые ХХ минут через крон....Действия датанарда нельзя симулировать парой скриптов. При работе DG потери в случае failover стремятся к нулю или равны нулю (при настройке). Ручной накат логов это потеря нескольких минут

Если разместить копию redolog на переключаемом в случае аварии диске к резервному серверу, потери не будет ( сточностью до багов)

Alexander RyndinVadim Lejninпропущено...


Если разместить копию redolog на переключаемом в случае аварии диске к резервному серверу, потери не будет ( сточностью до багов)А зачем тогда весь этот цирк? :) Проще уж всю дисковую систему переключать... Получается классический failover кластер. Только это уже далеко не DR (если, конечно, не реплицировать диски в удаленный ЦОД)

Согласен, Все правильно, если есть disk system которую можно подключать к другому узлу
Единственно, failover cluster != standby и решает немного задачи отказоустойчивости чуток другим способом.


landyвместо rsync, с его проблемами, проще использовать штатные возможности RMAN
Имеется ввиду инкрементально-обновляемая копия?
Если БД сильно нагружена(много изменений) и SE - то это может занять достаточно много времени
Именно поэтому отказались от такого подхода - обновление занимало 6-8 часов
(БД как раз около 1Тб)
А потом, чтобы поднять БД в случае проблемы на эту копию нужно докатить архивлоги
"ручной" стендбай эффективнее

Если нагрузка на сервер большая, то придется лицензировать standby host, что не мешает выполнять накат копии базы на нем с помощью RMAN

landyнакат копии базы на нем с помощью RMAN

Подмонтировать, например, по NFS каталог с архивлогами и накатывать RMANом?

Как Вариант
Если есть storage которую можно монтировать с обеих узлов, то можно просто перемонтировать файловую систему в случае сбоя и запустить экземпляр на новом узле.

В этом случае, есть решение
failover cluster (как частный случай этого решения RAC one node) - монтируется набор dbfile master db (критическая точка отказа дисковая система)

В отличии от manual physical standby, где монтируется набор standby db datafiles

failover cluster не поможет, если наткнетесь например на bug, с разрушением данных,

Поэтому часто standby, делают с искусственной задержкой наката.

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

В любом случае, советую сначало поднять стенд, и вручную пройти различные сценарии восстановления, бо иначе:

Михаил Михайлович Жванецкий (С)Одно неловкое движение, и Вы отец...

maverick2104Vadim Lejninможно поднять урезанный по ресурсам экземпляр на боевой системе, и накатывать по cron с его помощью копию боевой базы, размещенной на дисковой системе резервного сервера.
Это нагружает боевой сервер, но зато легально для создания standby базы на файловой системе другого сервера.

Можно подробней насчет этого метода ?

На master сервере, поднимаешь еще одну базу, с таким же dbname, что и на мастере, но с разным SID и db_unique_name и обрезанными sga_target, для экономии памяти.
Файлы этой базы размещены на nfs ресурсе standby сервера, либо на дисковой системе, которая может быть смонтирована со standby сервера.

далее, запускаешь rman на standby экземляре
используя либо RMAN catalog, либо catalog start with <master archive log location>
синхронизируешь текущую о archivelog информацию с master
и выполняешь штатную rman recover.

oracle software rdbms на Standby сервер не запускается

maverick2104,
случайно отправил раньше времени
oracle software rdbms на Standby сервере в процессе наката не запускается, накат идет с master node

при аварии, поднимаешь standby сервере с уже накаченной версией базы
если остались кишки redo и не переданные archivelog, докатываешь и открываешь

p.s. С удивлением обнаружил что


на SE работает, хотя oracle на MOS утверждает что единственной альтернативой для SE является ручной standby

насколько это кошерно с точки зрения лицензии, и как обрабатывается redo транспорт не знаю