Зачем нам делать резервные копии архивных журналов Oracle вместе с файлами данных

Основы резервного копирования и восстановления базы данных Oracle® 10g Release 2 (10.2) говорят, что

Архивные журналы повторов являются ключом к успешному восстановлению носителя. Поддерживайте их регулярно.

Но мне интересно, почему резервное копирование архивных журналов так важно. Можно ли выполнить восстановление на определенный момент времени, просто используя обычные полные и инкрементные резервные копии файлов данных RMAN.

Нет, вам все еще нужны архивированные журналы повторов. Резервная копия RMAN отличается от холодной резервной копии; когда вы восстанавливаете его, вам необходимо применить все повторные действия, созданные с момента запуска резервного копирования и до момента завершения резервного копирования, чтобы обеспечить согласованность SCN во всех файлах данных и контрольном файле.

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

В резервном копировании RMAN проблема сломанных блоков устраняется, потому что блоки считываются Oracle через SGA, а не с помощью инструмента Unix cp. Однако DBF изменяется между временем считывания первого блока и последним блоком, так что это та же проблема, только в большем масштабе. То есть SCN изменяется между первым и последним блоками в резервной копии. Архивные журналы повторов также охватывают это.

RMAN предоставляет вам управляемость каталога и средство для создания «горячих» резервных копий без необходимости создавать повторные операции с гораздо более высокой скоростью (что создает нагрузку на диски, систему резервного копирования и т. Д.). Однако BACKUP DATABASEбудет не дать вам последовательную базу данных и само по себе; только способ сделать это в Oracle является холодным резервным копированием.

Резервное копирование архивных журналов необходимо только при работе в режиме архивного журнала, поэтому возникает вопрос, должна ли база данных делать это или нет. Это описано в том же документе, на который вы ссылаетесь под заголовком Выбор между ARCHIVELOG и NOARCHIVELOG . Вот выдержка:

Выбор между режимами ARCHIVELOG и NOARCHIVELOG

Журналы повторов вашей базы данных предоставляют полную запись изменений в файлах данных вашей базы данных (за некоторыми исключениями, такими как прямые пути загрузки).

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

2.3.3.1 Последствия работы в режиме NOARCHIVELOG

Запуск вашей базы данных в режиме NOARCHIVELOG накладывает серьезные ограничения на вашу стратегию резервного копирования и восстановления.

• Вы не можете выполнять онлайн резервное копирование своей базы данных. Вы должны аккуратно закрыть свою базу данных, прежде чем сможете сделать резервную копию в режиме NOARCHIVELOG.

• Вы не можете использовать любые методы восстановления данных, которые требуют архивированных журналов повторов. К ним относятся полное восстановление носителя на определенный момент времени, как описано в разделе «Формы восстановления данных», и более продвинутые методы восстановления, такие как восстановление отдельных табличных пространств на определенный момент времени и базы данных Flashback (описанные в Oracle Database Backup and Recovery Advanced). Руководство пользователя.).

Если вы работаете в режиме NOARCHIVELOG и вам необходимо восстановиться после повреждения файлов данных из-за сбоя диска, у вас есть два основных варианта восстановления:

• Удалите все объекты с экстентами, находящимися в затронутых файлах, а затем удалите файлы. Остальная часть базы данных не повреждена, но все данные в затронутых файлах потеряны.

• Восстановите всю базу данных из самой последней резервной копии и потеряйте все изменения в базе данных с момента резервного копирования. (Восстановление изменений, поскольку резервное копирование потребовало бы восстановления носителя с использованием заархивированных журналов повторов.)

...

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

Вы почти всегда захотите работать в режиме ARCHIVELOG, поэтому вы почти всегда хотите делать резервные копии ваших архивных журналов.