mirall: (job)
    Data Guard broker без настроенного local listener работать не желает. А с настроенным local listener база не желает клонироваться. Так что сначала alter system set local_listener='' scope=both; А когда всё уже клонировано и приступаем к настройке broker, тогда alter system set local_listener='LISTENER_1522' scope=both;
mirall: (job)
    Что-то это всё мутно.
    Документация предлагает следующую процедуру.
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
RECOVER COPY OF DATABASE WITH TAG 'OSS';
BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE;
BACKUP DEVICE TYPE SBT ARCHIVELOG ALL;
BACKUP BACKUPSET ALL; DELETE ARCHIVELOG ALL;
    Если я что-нибудь в чём-нибудь понимаю, то это image copy backup. Он медленнее и занимает в разы больше места на диске, чем обычный. Кроме того, вызывает сомнения команда RECOVER COPY OF DATABASE WITH TAG 'OSS';. Судя по всему, сначала имеющийся бэкап куда-то восстанавливается. Вопрос, он восстанавливается прямо на standby или всё-таки куда-нибудь в recovery catalog. Если прямо на standby, то следующий закономерный вопрос: что будет, если во время снятия бэкапа навернётся primary database? Куда тогда переключаться и вообще, что делать? Далее, почему архивлоги бэкапятся прямо на ленту в то время как датафайлы — только на диск. Или в BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE; архивлоги включены по умолчанию? Обычно это опция.
    Также большие сомнения вызывают следующие пункты. Во-первых, как оценить время, за которое будет сниматься бэкап. Если это image copy, то долго — это не то слово. Во-вторых, как оценить необходимый объём дискового пространства? Опять же, image copy — это очень много. С учётом рекомендуемой политики хранения бэкапов (recovery window of n days), получается вообще запредельно. В разы больше, чем, собственно, объём датафайлов плюс архивлоги. А если база терабайтная? Это же в лучшем случае часы работы и нереальная куча места.
    И почему нельзя снимать обычный бэкап, желательно ещё и сжатый? Или можно, но такая опция просто не описана в официальной документации.
    Короче, вся эта бодяга требует кучу времени на исследования, включающие регулярное убийство то primary, то standby, их восстановления, проверки сценариев failover и сохранности данных.
mirall: (job)
Особенность в том, что он не долго и не муторно.

    primary> alter database commit to switchover to physical standby with session shutdown;
    Дальше )
mirall: (job)
    Вот почему-то клонирование базы с primary на standby прошло со свистом. А broker не хотел настраиваться никак. Хотя где там можно было запутаться в трёх с половиной командах, непонятно.

    Tip1. Listener. Таки у меня на одном сервере listener слушает порт 1521, а на втором — 1522. Решение баянистое, но пускай будет. Тем более, что есть одна маленькая хитрость.
    1) Добавить в tnsnames.ora псевдоним для listener: listener_1522 = (address=(protocol= tcp)(host= hostname)(port= 1522))
    2) SQL> alter system set local_listener='listener_1522' scope=both;
    Главное — не наоброт. Потому что определить local_listener, если нет соответствующей записи в tnsnames.ora, не выйдет — Oracle будет невнятно ругаться.
    В целом, порт 1522 ничем не хуже. Кроме того, что на нём по умолчанию не стартует сервис db_unique_name_XPT, без которого не стартует сервис db_unique_name_DGВ, без которого брокер, естественно, не работает.

    Tip2. Очевидный. Проверить записи в tnsnames.ora — базы должны друг друга видеть. После нескольких пересозданий standby, я забыла поправить tnsnames и долго ломала голову, чего же опять этому чёртову брокеру не хватает.

    Tip3. Убедиться, что параметры конфигурации баз в брокере соответствуют значениям из spfile. Иначе завалит предупреждениями и не уверена, что захочет нормально работать.

    И самое интересное, что я два дня билась над этим безобразием. Ужас. Позор на мои седины.
Page generated Sep. 25th, 2017 06:08 am
Powered by Dreamwidth Studios