Comments 8
А на MS SQL дюжина кликов в GUI)
Не увидел в вашем тексте - это реально Physical Standby (что можно увидеть выполнив select database_role from v$database) или всё же "якобы Standby", а на самом деле открытая копия 1й базы, куда мы накатывает архивлоги с другой базы и основная база ничего не знает про существования второй базы? Отсюда возникает проблема со стиранием архивлогов на первой базе - RMAN запросто может удалить архивлоги, которые еще не были накатаны на вторую базу. Да и удаляя архивлоги на второй базе, вы постоянно генерируете ошибку консистентности архивлогов на первой базе, когда RMAN на первой базе не может найти нужные ему архивлоги, которые зарегистрированы в бд (1й), но удалены кем-то еще (RMAN на 2й базе). Постоянно пользуетесь CROSSCHECK ARCHIEVELOG ALL ?
>> это реально Physical Standby (что можно увидеть выполнив select database_role from v$database) или всё же "якобы Standby"
Конкретно этот запрос на второй базе покажет Physical Standby (т. к. база смонтирована и запущена в режиме standby)
>> Отсюда возникает проблема со стиранием архивлогов на первой базе - RMAN запросто может удалить архивлоги, которые еще не были накатаны на вторую базу. Да и удаляя архивлоги на второй базе, вы постоянно генерируете ошибку консистентности архивлогов на первой базе, когда RMAN на первой базе не может найти нужные ему архивлоги, которые зарегистрированы в бд (1й), но удалены кем-то еще (RMAN на 2й базе). Постоянно пользуетесь CROSSCHECK ARCHIEVELOG ALL ?
Ну здесь уже тонкости в настройках резервного копирования, в моем случае архивлоги на primary пишутся в 2 папки, одна из которых шарится по NFS и вторая база может удалить архивлоги только из нее. На первой же базе архивлоги чистятся только те, что двухнедельной давности, при штатном работе скриптов обновления standby удаление архивлогов двухнедельной давности его не сломает. Если standby не обновляется по каким-либо причинам (отвалилась шара и т д), то на этот случай висит мониторинг изменения SCN базы - если после синхронизации он не поменялся, то тогда аларм админу. Любой сбой, как правило, замечают в течение 1-2х дней и архивлоги за этот период, как правило, еще не удалены и спокойно накатываются без необходимости создания standby заново.
Мне тут интереснее что будет, если `catalog start ...` каталогизирует архивлог, который еще не финализирован, т.е. еще не записан до конца? Будет ли стендбай пытаться его апплаить повторно, когда он финализируется?
В своем https://github.com/xtender/pySync я делаю по необходимости `alter system archive log current` и передаю на стендбай только финализированные архивлоги. Первоначально еще думал каждый финализированный архивлог отдельно применять, но потом отказался от этой идеи, оставив тоже rman catalog
Не упомянули про force logging режим работы субд.
Не упомянули про тонкости с лицензированием, например вот тут они, вполне доходчиво обсуждаются.
Прикручивать NFS-шару, для обмена арх-логами, ну, да, прикручивают, куда деватся. Но. Лучше использовать какой нибудь incrond+rsync, для пуляния в standby-сторону арх. логов, как только они появились, на стороне primary-бд. И на стороне standby-бд, тоже incrond-демон, реагирующий на появление файла архлога, запускающий шелл-скрипт, для наката его на standby-бд. А nfs-шару держать для складирования/расшаривания на/с неё бэкапов, в т.ч. бэкапов арх-логов.
Спасибо за комментарий!
Этот пост все-таки больше как пост-продолжение вот к этому. В том посте и в его комментариях как раз обсуждаются нюансы с лицензиями и про force logging сказано.
incrond+rsync — тоже интересный вариант, почему нет. Здесь, как говорится, уже прикручиваюют "любыми гвздями по вкусу" )
Создание и настройка Oracle standby без использования Oracle Data Guard