Источник: статья представляет собой краткое изложение одноименной презентации автора, доложенной на семинаре Oracle Db Community Day, 29 августа 2013 Г.
В этой небольшой заметке я не буду пытаться выразить все свои эмоции, удивления и недоумения, А также желание поделиться с товарищами по профессии теми догадками, долгими путями осмысления происходящего, что характерно для выступления на семинаре перед колллегами, но вряд ли уместно прозвучит в журнальной статье.
Главный смысл проделанной работы — найти правльное решение и посоветовать всем друзьям и коллегам очень внимательно читать документацию, даже набранную самым мелким шрифтом, чтобы потом не обвинять ни себя, ни вендора в ошибках и недоговоренностях, не пытаться решать все-таки иногда неразрешимые задачи.
Rman Commands Use The Recovery Catalog Metadata To Behave Transparently Across Different Physical Databases In The Data Guard Environment. For Example, You Can Back Up A Tablespace On A Physical Standby Database And Restore And Recover It On The Primary Database. Similarly, You Can Back Up A Tablespace On A Primary Database And Restore And Recover It On A Physical Standby Database.
[Перевод: Команды Rman используют метаданные из каталога восстановления, чтобы прозрачно работать с различными физическии базами данных в среде Data Guard. Например, можно продублировать табличное пространство на физической резервной базе данных, возвратить и восстановить его на основной базе данных. Точно так же можно продублировать табличное пространство основной базы данных и восстановить и возвратить его на физическую резервную базу данных.]
Сначала всё было хорошо…
Выдержка Из Документации: Oracle® Database Backup and Recovery Reference 11g Release 2 (11.2):
To make a consistent backup, the standby database must shutdown cleanly and be mounted, but not placed in recovery mode. Any other status results in an inconsistent backup and must be restored using media recovery.
[Перевод: Чтобы сделать согласующуюся резервную копию, резервная база данных должна аккуратно закрыта, смонтированна, но процесс восстановления (recovery mode) не должен быть начат. Любые другие состояния приводят к несогласованной резервной копии и должны быть восстановлены через восстановление среды.]
Пишем скрипт для бэкапа:
Backup database plus archivelog: Run an ALTER SYSTEM ARCHIVE LOG CURRENT statement. Run the BACKUP ARCHIVELOG ALL command. Back up the files specified in the BACKUP command. Run an ALTER SYSTEM ARCHIVE LOG CURRENT statement. Back up any remaining archived redo log files.
Starting backup at 25-JUL-13
[Перевод выделенного фрагмента:
спецификация не соответствует любому заархивированному log-фойлу в репозитории.
Процедура восстановления (backup) завершается аварийно, поскольку более нет backup-файлов.]
Finished backup at 25-JUL-13
rman target / catalog rman/***@***:1521/rmanrep crosscheck backup; restore controlfile from tag '...'; sql "alter database mount"; restore database; sql "alter database flashback off"; list backup of archivelog all; --позволяет посмотреть какой sequence уже отсутствует так как восст всегда неполное recover database until sequence ...; -- восстанавливаем до отсутствующего sequence sql "alter database open resetlogs"; unregister db_unique_name testbrstb; exit;
То есть, подтверждается уже ранее сказанное:
To make a consistent backup, the standby database must shutdown cleanly and be mounted, but not placed in recovery mode. Any other status results in an inconsistent backup and must be restored using media recovery.
[Перевод: Чтобы сделать согласующуюся резервную копию, резервная база данных должна аккуратно закрыта, смонтированна, но процесс восстановления (recovery mode) не должен быть начат. Любые другие состояния приводят к несогласованной резервной копии и должны быть восстановлены через восстановление среды.]
