Oracle Rman: резервное копирование backup и восстановление базы Oracle

Источник: Oracle Rman: резервное копирование backup и восстановление базы Oracle

 

Традиционный пользовательский метод резервного копирования состоит в применении команд операционной системы для копирования необходимых файлов в другое место и/или на ленточное устройство. В случае применения утилиты RMAN резервное копирование файлов базы данных Oracle выполняться внутри базы данных посредством самого сервера баз данных. RMAN умеет делать резервные копии и копии образов файлов данных, управляющих файлов, архивных журналов повторного выполнения, файлов SPFILE и фрагментов резервных копий RMAN. Поэтому компания Oracle рекомендует применять для резервного копирования баз данных именно интерфейс RMAN.


 

Oracle RMAN. Оглавление

На заметку! Администраторам “старой школы” может быть удобнее использовать команды операционной системы, потому что они им уже хорошо знакомы, однако администраторам нового поколения может быть лучше применять утилиту RMAN, поскольку она проста и безопасна и обладает такими функциональными возможностями, которых у традиционных методов нет. Всеми доступными в RMAN функциями для резервного копирования и восстановления можно пользоваться через интерфейс OEM (как Database Control, так и Grid Control), что избавляет от необходимости запоминать сложные команды.


Утилита RMAN упрощает процедуры резервного копирования, позволяя использовать мощные и в то же время легкие в написании сценарии резервного копирования и восстановления. Вдобавок RMAN обладает функциям наподобие обнаружения повреждений внутри блоков данных и способностью выполнять резервное копирование только изменившихся блоков в базе данных. Сценарии RMAN можно сохранять в базе данных и использовать прямо оттуда, что избавляет от необходимости писать сценарии уровня операционной системы. RMAN автоматически обеспечивает создание резервных копий всех файлов базы данных, что исключает вероятность допущения человеческой ошибки, которая присутствует в методах резервного копирования, основанных на применении команд операционной системы.

Несмотря на всю свою изощренность, утилита RMAN все же обладает некоторыми ограничениями. Например, напрямую считывать данные с ленточного устройства или записывать их на него с помощью RMAN нельзя: для создания резервных копий на ленте необходимо применять дополнительное специальное ПО уровня управления носителями (Management Media Layer — MML).


На заметку! Утилита RMAN может создавать и управлять резервными копиями на дисках и ленточных устройствах, также еще называемых устройствами SBT (system backup to tape devices — ленточные устройства хранения системных резервных копий), перемещать резервные копии с диска на ленту и восстанавливать резервные копии с ленты. Однако для взаимодействия с устройствами SBT ей требуется дополнительное ПО уровня управления носителями или диспетчер носителей. Компания Oracle поставляет собственное ПО уровня управления носителями в форме продукта Oracle Secure Backup.


Преимущества RMAN

Утилита RMAN обладает массой преимуществ по сравнению с пользовательскими методами резервного копирования.

  • С помощью RMAN можно выполнять инкрементное резервное копирование. Размер резервных копий в таком случае зависит не от размера базы данных, а скорее от уровня активности внутри нее, поскольку во время инкрементного резервного копирования не измененные блоки пропускаются. Выполнять инкрементное резервное копирование другим способом не возможно. Можно выполнять инкрементный экспорт, но это не считается настоящим резервным копированием ни для каких баз данных.
  • RMAN позволяет восстанавливать файл данных с несколькими поврежденными блоками данных в оперативном режиме, не прибегая к восстановлению из резервной копии. Такой прием называется восстановлением носителя на уровне блоков (block media recovery).

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


  • Вероятность возникновения проблем из-за человеческой ошибки сводится к минимуму, потому что за именами и размещением всех файлов следит не отдельный администратор баз данных, а сама утилита RMAN. Умея пользоваться RMAN, один администратор баз данных может легко принимать обязанности по выполнению резервного копирования и восстановления баз данных от другого.
  • Простая команда RMAN вроде BACKUP DATABASE позволяет выполнять резервное копирование всей базы данных без создания сложных сценариев.
  • Поддерживаемая RMAN функция сжатия неиспользуемых блоков предоставляет возможность пропускать копирование никогда не использовавшихся блоков данных в файле данных во время создания его резервной копии и тем самым экономить место и время, затрачиваемые на его резервное копирование и сохранение.
  • С помощью RMAN очень легко автоматизировать процесс резервного копирования и восстановления. Кроме того, RMAN может автоматически обеспечивать параллельное выполнение сеансов резервного копирования и восстановления.
  • RMAN умеет выполнять проверку на ошибки во время резервного копирования и восстановления и тем самым гарантировать, что подвергаемые резервному копированию файлы не повреждены. У RMAN есть возможность восстанавливать любые поврежденные блоки данных без перевода файла данных в автономный режим.
  • При выполнении резервного копирования в оперативном режиме с использованием утилиты RMAN никакие данные повторного выполнения не генерируются в отличие от того, когда резервное копирование выполняется в оперативном режиме утилитами операционной системы. Связанные с этим накладные расходы, следовательно, получаются гораздо меньшими.
  • Поддерживаемая RMAN функция двоичного сжатия позволяет сокращать размер резервных копий, сохраняемых на диске.
  • В случае использования каталога восстановления сценарии резервного копирования и восстановления можно сохранять прямо в нем.
  • RMAN умеет эмулировать процедуры резервного копирования и восстановления.
  • RMAN позволяет делать копии образов (image copies), которые похожи на создаваемые операционной системой резервные копии файлов.
  • RMAN может легко интегрироваться с мощными сторонними продуктами по управлению носителями для облегчения процесса создания и сохранения резервных копий на ленте.
  • RMAN хорошо интегрируется с предлагаемыми в OEM функциональными средствами для резервного копирования, что позволяет легко планировать выполнение операций резервного копирования для большого количества баз данных через общий каркас управления.
  • С помощью функциональных возможностей RMAN можно легко клонировать базы данных и поддерживать резервные (standby) базы данных.

Как явно показывает приведенный выше перечень, нет никаких сомнений, что лучше пользоваться утилитой RMAN, чем предусмотренными в операционной системе методами для резервного копирования и восстановления (также называемые пользовательскими методами резервного копирования и восстановления). Поэтому утилите RMAN будет уделяться довольно много внимания в этой статье. Oracle поддерживает применение как RMAN, так и пользовательских методов для резервного копирования и восстановления, но рекомендует использовать все-таки RMAN.

 

Архитектура RMAN

Утилита RMAN работает посредством серверных сеансов, подключающихся к целевым базам данных, под которыми подразумеваются базы данных Oracle, которые требуется подвергнуть резервному копированию или восстановлению. Коллекция информации о целевой базе данных, вроде информации о ее схеме, резервной копии, параметрах конфигурации и сценариях для ее резервного копирования и восстановления, называется репозиторием RMAN. Утилита RMAN использует такие метаданные о целевых базах данных Oracle для выполнения всех своих операций по резервному копированию и восстановлению. Время от времени она извлекает их из управляющего файла целевой базы данных и сохраняет в каталоге восстановления.

Ниже приведен полный перечень сущностей, которые позволяют утилите RMAN выполнять ее функции в области резервного копирования и восстановления.

  • Целевая база данных (target database). Так называется база данных, в отношении которой RMAN выполняет резервное копирование. Все операции по резервному копированию и восстановлению осуществляются при помощи запускаемых в целевой базе данных серверных сеансов RMAN.
  • Репозиторий RMAN (RMAN repository). Так называются используемые утилитой RMAN метаданные о резервных копиях, архивных журналах повторного выполнения и ее собственных действиях. Главным источником для репозитория RMAN служит управляющий файл каждой базы данных.
  • Схема каталога восстановления (recovery catalog schema). Так называется схема в базе данных каталога восстановления, которой принадлежат необходимые RMAN для выполнения резервного копирования и восстановления метаданные (репозиторий RMAN).
  • Клиент RMAN (RMAN client). Управление операциями RMAN осуществляется посредством клиентских сеансов RMAN. Клиентом RMAN называется интерфейс командной строки, через который выдаются команды на выполнение операций резервного копирования и восстановления за счет взаимодействия с серверным процессом RMAN. Это могут быть как специальные команды RMAN, так и обычные SQL-операторы. Клиент запускает серверные сеансы RMAN в отношении целевой базы данных и указывает им выполнять операции резервного копирования и восстановления. Для подключения к целевой базе данных клиент RMAN использует Oracle Net, и потому он может находиться на любом хосте, который подключен к целевому хосту через Oracle Net.
  • Исполняемый модуль RMAN (RMAN executable). Так называется фактическая программа, которая управляет всеми операциями резервного копирования и восстановления. Находится исполняемый модуль RMAN (иногда также называемый просто rman) в каталоге $ORACLE_HOME/bin. Администратор баз данных указывает, какую операцию резервного копирования или восстановления требуется выполнить, а исполняемый модуль RMAN непосредственно выполняет ее, взаимодействуя с целевой базой данных, после чего записывает результаты в управляющий файл и (если требуется) в каталог восстановления.
  • Серверные процессы (server processes). Так называются фоновые процессы, которые упрощают взаимодействие между исполняемым модулем RMAN и целевой базой данных. Именно они на самом деле и производят чтение и запись данных на дисковые и ленточные устройства во время резервного копирования и восстановления.

На заметку! Еще есть три сущности, наличие которых необязательно при использовании RMAN: область пакетного восстановления, база данных каталога восстановления (и схема каталога восстановления) и программное обеспечение для управления носителями.


 

Репозиторий RMAN и каталог восстановления

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

  • наборы резервных копий и другие копии файлов данных;
  • копии и наборы резервных копий архивных журналов повторного выполнения;
  • табличные пространства и файлы данных;
  • хранимые сценарии и параметры конфигурации RMAN.

По умолчанию RMAN хранит все метаданные в управляющем файле. Вся собираемая RMAN информация сначала записывается в управляющий файл, а затем в каталог восстановления, если таковой существует. Например, при создании RMAN нового набора резервных копий информация об этом становится доступной для просмотра в представлении V$BACKUP_SET. Но помимо этого она также становится доступной для просмотра и в представлении каталога восстановления — RC_BACKUP_SET. То есть получается, что при каждом изменении в репозитории RMAN информация об этом фиксируется в двух местах: в управляющем файле и необязательном каталоге восстановления. Записываемые в каталог восстановления версии репозитория RMAN сохраняются в виде таблиц в базе данных, а записываемые в управляющий файл версии — в виде записей внутри управляющего файла.

При желании управлять RMAN можно с помощью одной лишь хранимой в управляющем файле информации. Противники применения каталога восстановления заявляют, что его слишком трудно поддерживать и для его управления требуется создавать еще одну базу данных. Однако есть несколько команд RMAN, которыми можно пользоваться только в случае использования каталога восстановления. Кроме того, применять хранимые RMAN сценарии тоже можно только при наличии каталога восстановления. В случае использования управляющего файла не исключена вероятность перезаписывания накопленных данных, а в случае применения каталога восстановления все такие данные будут сохранены. Объясняется это тем, что управляющий файл предусматривает выделение конечного пространства для связанных с резервным копированием операций, в то время как каталог восстановления обеспечивает гораздо больше места для хранения касающихся резервного копирования данных. Один каталог восстановления в системе позволяет выполнять операции резервного копирования и восстановления для десятков баз данных. Следовательно, за счет применения каталога восстановления можно централизовать и автоматизировать процедуры резервного копирования и восстановления. Oracle рекомендует использовать для обслуживания каталога восстановления отдельную базу данных, но это совершенно не обязательно.


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


 

Уровень управления носителями

При применении утилиты RMAN резервные копии можно сохранять прямо на дисках операционной системы. При желании сохранять их на ленте потребуется дополнительное программное обеспечение, называемое программным обеспечением уровня управления носителями ( Media Management Layer — MML) или диспетчером носителей (Media Manager). RMAN позволяет перемещать резервные копии с диска на ленту и выполнять восстановление из резервных копий на ленте, если необходимо. В состав Oracle Database 11g входит патентованный продукт для управления носителями под названием Oracle Secure Backup (Безопасное резервное копирование Oracle), о котором более подробно будет рассказываться позже в следующих заметках моего блога здесь.

 

Подключение к RMAN

Подключаться к RMAN можно путем ввода в приглашении операционной системы команды rman. (Обязательно проверяйте корректность настройки переменных пути, потому что в некоторых операционных системах, например, в SUSE Linux, вместо поддерживаемой Oracle утилиты RMAN может предлагаться поддерживаемая операционной системой утилита под названием rman.) После этого будет появляться приглашение RMAN>, позволяющее вводить различные команды RMAN. Команды RMAN также можно использовать в пакетном режиме и передавать по конвейеру за счет применения поставляемого вместе с Oracle пакета DBMS_PIPE.

Иметь привилегии SYSDBA для того, чтобы просто подключаться к каталогу RMAN, не обязательно; для этого вполне достаточно специальной учетной записи rman и пароля. Как будет показано позже, в разделе “Создание каталога восстановления”, пользователь rman является владельцем этого каталога. К RMAN можно подключаться как посредством механизма аутентификации паролей базы данных, так и с помощью механизма аутентификации операционной системы. В следующих подразделах каждый из этих методов описывается более подробно.

 

Подключение к RMAN с помощью механизма аутентификации базы данных

К утилите RMAN можно подключаться с использованием учетных данных целевой базы данных. После установки соединения с целевой базой данных можно начинать вводить желаемые команды резервного копирования или восстановления. Для завершения сеанса работы с RMAN служит команда exit. Ниже приведен пример подключения к целевой базе данных по имени orcl:

$ rman
Recovery Manager: Release 11.1.0.6.0 - Production on Thu Mar 27 11:09:16 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
RMAN> CONNECT TARGET /
connected to target database: ORCL (DBID=1080111806)
RMAN> exit
Recovery Manager complete.
$

Использование ПО уровня управления носителями с утилитой RMAN


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

Отслеживание файлов резервных копий и операций резервного копирования вручную тоже со временем начинает негативно сказываться на продуктивности. Даже в случае применения утилиты RMAN большое количество баз данных требует обязательного использования дополнительно еще какие-нибудь сторонних средств для управления графиками выполнения резервного копирования и автоматизации сохранения резервных копий на носителях. Oracle ведет программу BSP (Oracle Backup Solutions Program — программа по созданию связанных с резервным копированием решений для Oracle), участниками которой являются производители, занимающиеся разработкой продуктов по управлению носителей, способных работать с утилитой RMAN. К числу некоторых наиболее важных игроков в этой сфере относятся компании Legato Systems (с продуктом NetWorker) и VERITAS (с продуктом NetBackup). Полный перечень производителей, занимающихся разработкой программного обеспечения для управления носителями в рамках программы BSP, можно найти по следующему адресу:

http://otn.oracle.com/deploy/availability/htdocs/bsp.htm#MMV

Продукт NetWorker, например, представляет собой автоматизированное средство для выполнения операций резервного копирования, осуществления за ними мониторинга и планирования графика их проведения в том числе. NetWorker позволяет выполнять процедуры резервного копирования параллельно с сохранением резервных копий одновременно на нескольких ленточных носителях и тем самым сокращать время, требуемое на осуществление резервного копирования чрезвычайно больших баз данных. Legato и другие производители подобных частных продуктов предусматривают использование выделенных серверов хранения и ленточных устройств с возможностью автоматической смены носителя. В частности, NetWorker предусматривает получение данных через RMAN, сохранение их на ленте и предоставление для лент служб архивации и индексации. Продукты вроде NetWorker обеспечивают гораздо более высокую производительность средств ввода-вывода по сравнению с традиционными утилитами, которые предлагаются в составе операционной системы.

Еще одним интересным сторонним продуктом является программное обеспечение Business Copy XP, предлагаемое компанией Hewlett Packard в рамках ее линейки продуктов для машин UNIX. Это программное обеспечение, по сути, представляет собой стратегию зеркального отображения на основе массивов, которая позволяет делать копии в оперативном режиме лишь за часть того времени, которое обычно на это уходит. Оно даже позволяет выполнять в отношении копируемых данных фоновые процессы без оказания негативного влияния на производительность. Подобное сокращение требуемого на выполнение резервного копирования времени дает возможность проводить операции по резервному копированию гораздо чаще.

Раньше для получения доступа к последовательным устройствам хранения наподобие ленточных библиотек в Oracle можно было использовать только сторонние продукты по управлению носителями RMAN. На самом деле компания Oracle даже предлагала в связке с базой данных рассчитанную на одного пользователя версию Legato NetWorker, которая называлась Legato Single Server Version (LSSV). Однако во втором выпуске Oracle Database 10g появилось решение для управления носителями ее собственного производства под названием Oracle Secure Backup.


Ниже показан эквивалентный предыдущим командам способ указания учетных данных на уровне операционной системы:

$ rman target system/system__passwd
Recovery Manager: Release 11.1.0.6.0 - Production on Thu Mar 27 11:38:16 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.connected to
target database: ORCL (DBID=1080111806)
RMAN>

 

Подключение к RMAN с помощью механизма аутентификации операционной системы

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

$ rman target /
Recovery Manager: Release 11.1.0.6.0 - Production on Thu Mar 27 11:09:16 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: ORCL (DBID=1080111806)
RMAN>

 

Подключение к каталогу восстановления

В предыдущих примерах подключение осуществлялось прямо к целевой базе данных без подключения к каталогу восстановления. В случае настройки необязательного каталога восстановления появляется возможность подключаться сначала к каталогу восстановления и выполнять все связанные с резервным копированием или восстановлением действия через него. В Oracle настоятельно рекомендуют применять такой подход из-за многочисленных преимуществ. Ниже показан пример подключения к каталогу восстановления, который находится в базе данных nick, хотя целевой является база данных orcl:

$ rman target orcl catalog rman/rman@nick
Recovery Manager: Release 11.1.0.6.0 - Production on Thu Mar 27 11:09:16 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.target database Password:
connected to target database: ORCL (DBID=1065483535)
connected to recovery catalog database
RMAN>

 

Перенаправление вывода в файл журнала

По умолчанию утилита RMAN отображает весь вывод на экране, но при желании его можно перенаправить в файл журнала, указав при запуске RMAN параметр LOG. Например:

$ rman LOG /u01/app/oracle/rman.log

Когда задается параметр LOG, утилита RMAN перестает отображать на экране какой-либо вывод. Чтобы заставить RMAN сохранять вывод в файле журнала и при этом также отправлять его еще и на стандартное устройство вывода, можно воспользоваться поддерживаемой в Linux и UNIX командой tee:

$ rman | tee /u01/app/oracle/rman.log

Команда tee делает вывод RMAN видимым на экране, одновременно отправляя его в файл журнала.

 

Написание сценариев для RMAN

Как будет показано в последующих разделах, вполне можно пользоваться простыми вводимыми вручную командами RMAN, вроде BACKUP DATABASE и LIST OBSOLETE. Однако вводимые вручную команды являются далеко не единственным или не наилучшим способом для передачи указаний утилите RMAN. Утилита RMAN поставляется с мощным языком сценариев, который позволяет легко инкапсулировать наиболее типичные процедуры резервного копирования. Сценарии RMAN можно хранить как в каталоге восстановления, так и виде простых текстовых файлов, и делать как специфическими, рассчитанными только на конкретную базу данных, так и глобальными, пригодными для использования в нескольких базах данных.

В общем RMAN поддерживает сценарии двух видов: хранимые сценарии (которые хранятся в каталоге восстановления RMAN) и текстовые сценарии (которые хранятся в обычных текстовых файлах). Преимущество хранимых сценариев состоит в том, что любой подключающийся к RMAN пользователь может легко получать к ним доступ. Хранимые сценарии могут служить альтернативой командным файлам для любого ряда выполняемых регулярно команд RMAN. В отличие от командных файлов, которые хранятся в файловой системе, хранимые сценарии располагаются в каталоге восстановления.

При необходимости использовать большое количество конфигурационных параметров для определенной процедуры резервного копирования, гораздо легче использовать сценарий. Из этого следует, что сценарии в RMAN, по сути, выполняют ту же самую функцию, что и обычные сценарии в UNIX или SQL, а именно — помогают хранить и выполнять повторно длинные наборы команд.

 

Применение командных файлов

Хранимые в операционной системе файлы команд удобно создавать для регулярно выполняемых с помощью RMAN процедур резервного копирования. Для указания RMAN, какой командный файл ей нужно выполнить, служит следующий синтаксис: @имя_файла. Например, можно создать командный файл по имени testfile1, содержащий следующую команду RMAN:

BACKUP DATABASE PLUS ARCHIVELOG;

Тогда запустить этот командный файл testfile1 из командной строки операционной системы можно будет так:

$ rman target / @testfile1

Обратите внимание, что синтаксис @имя_файла можно также применять для запуска командного файла и в приглашении RMAN, как показано ниже:

RMAN> @testfile1

В приглашении командной строки можно также задавать конструкцию USING для указания значений, которые должны использоваться для содержащихся в командном файле переменных подстановки и тем самым делать командный файл динамическим. Ниже перечислены шаги, показывающие, как создать и выполнить простой динамический сценарий оболочки, предусматривающий вызов командного файла с переменными подстановки.

1. Создайте командный файл (monthly_backup.cmd) с переменными подстановки:

#monthly_backup.cmd
CONNECT TARGET /
RUN
{
ALLOCATE CHANNEL c1
DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=&1)';
BACKUP DATABASE
TAG &2
FORMAT '/u02/app/oracle/bck/&1%U.bck'
RESTORE POINT &3;
}
EXIT;

В командном файле monthly_backup.cmd используются три переменных подстановки: одна для названия набора лент, одна для задания строки FORMAT и одна для имени точки восстановления.

2. Создайте сценарий оболочки, который будет использоваться для запуска файла monthly_backup.cmd. Этот сценарий оболочки называется mybackup.sh и содержит три переменных оболочки, для которых потребуется передавать значения в командной строке при вызове сценария:

#!/bin/tcsh
# name: mybackup.sh
# usage: use the tag name and number of copies as arguments
set media_family = $argv[1]
set format = $argv[2]set restore_point = $argv[3]
rman @'/u01/app/oracle/scripts/monthly_backup.cmd' USING $media_family $format
$restore_point

Теперь имеется сценарий оболочки (mybackup.sh), который можно выполнять за счет передачи в командной строке соответствующих аргументов и тем самым указания значений для содержащихся в командном файле monthly_backup.cmd переменных подстановки.

3. Выполните сценарий оболочки mybackup.sh:

% mybackup.sh archival_backup bck0906 FY06Q3

При каждом запуске сценария mybackup.sh можно будет указывать разные значения для переменных подстановки прямо в командной строке.

 

Создание и выполнение хранимых сценариев

Все хранимые сценарии в RMAN создаются командой CREATE SCRIPT, следом за которой внутри фигурных скобок ({}) указывается содержимое сценария. Внутри скобок команды CREATE SCRIPT можно использовать те же команды, что и внутри блока RUN. Сценарии RMAN действительно выглядят немного непонятно на первый взгляд, но являются очень эффективными и на самом деле довольно легкими в написании.

Ниже приведен упрощенный пример сценария еженощного резервного копирования, предусматривающий выполнение полного резервного копирования базы данных. Обратите внимание на то, что за счет использования ключевого слова SQL в сценарий RMAN могут вставляться обычные SQL-команды:

RMAN> CREATE SCRIPT nightly_backup {
2> ALLOCATE CHANNEL c1 TYPE DISK;
3> BACKUP DATABASE FORMAT '/u01/app/oracle/%u';
4> SQL 'ALTER DATABASE BACKUP CONTROLFILE TO TRACE';
5> }
created script nightly_backup
RMAN>

Для выполнения сценария применяются команды RUN и EXECUTE SCRIPT. Таким образом, после создания сценария nightly_backup все, что потребуется сделать, чтобы запустить процесс полного резервного копирования — выполнить этот сценарий следующим образом:

RMAN> RUN {EXECUTE SCRIPT nightly_backup;}
executing script: nightly_backup
allocated channel: c1
channel c1: sid=19 devtype=DISK
. . .
RMAN>

Сценарии RMAN позволяют выполнять сложные задания с помощью лишь нескольких коротких строк. Например, приведенный ниже сценарий предусматривает использование двух ленточных устройств для выполнения полного резервного копирования базы данных. Он сначала выделяет два канала (два соединения с сервером), затем выполняет резервное копирование в указанном формате, после чего освобождает каналы.

RMAN>  RUN {
2>     ALLOCATE CHANNEL c1 TYPE 'sbt_tape';
3>     ALLOCATE CHANNEL c2 TYPE 'sbt_tape';
4>     BACKUP
5>     FORMAT 'full d%d_u%u'
6>     FILESPERSET 10
7>     DATABASE;
8>     RELEASE CHANNEL c1;
9>     RELEASE CHANNEL c2;
10>    }

При желании команды RMAN можно размещать в файле операционной системы, называемом командным файлом. Ниже приведен пример, показывающий, как использовать файл операционной системы для выполнения команд RMAN и сохранения результатов в журнальном файле (output.txt):

$ rman TARGET/CATALOG rman/cat@catdb CMDFILE commandfile.rcv LOG outfile.txt

 

Проверка синтаксиса в сценариях RMAN

Для проверки синтаксиса в сценарии (или любой команды RMAN), который планируется использовать с RMAN, можно применять параметр CHECKSYNTAX. Ниже приведен пример выполнения проверки синтаксиса в содержащемся в файле testfile сценарии, показывающий, что синтаксис в этом сценарии является правильным:

$ rman CHECKSYNTAX @/tmp/testfile
Recovery Manager: Release 11.1.0.6.0 - Production on Thu Mar 27 11:09:16 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
RMAN> # command file with correct syntax
Командный файл с правильным синтаксисом
2> restore database;
3> recover database;
4>
The cmdfile has no syntax errors
Recovery Manager complete.
$

 

Создание глобальных сценариев RMAN

Все продемонстрированные до сих пор сценарии представляли собой локальные сценарии, которые могут использоваться только в той базе данных, в которой они создаются. Однако помимо локальных можно создавать и выполнять глобальные сценарии RMAN. Такие сценарии выполняются в отношении базы данных, зарегистрированной в каталоге восстановления, при условии подключения клиента RMAN одновременно и к каталогу восстановления, и к целевой базе данных. Заставлять базы данных совместно использовать сценарии RMAN можно, только если они предусматривают подключение к базе данных с каталогом RMAN. Приведенный ниже оператор показывает, как выглядит синтаксис, который должен применяться для создания глобального сценария:

RMAN> CREATE GLOBAL SCRIPT global_full_backup
{
BACKUP DATABASE PLUS ARCHIVELOG;
DELETE OBSOLETE;
}
created global script global_full_backup
RMAN>

Выполняется глобальный сценарий тем же способом, что и локальный:

RMAN> RUN {EXECUTE GLOBAL SCRIPT global_full_backup};} 

 

Распечатка сценария

Приведенная ниже команда PRINT SCRIPT показывает, как распечатывать содержимое глобального сценария на экране:

RMAN> PRINT GLOBAL SCRIPT global_full_backup;
printing stored global script: global_full_backup
{backup database plus archivelog ;
delete obsolete;
}
RMAN> 

 

Отображение перечня имен сценариев

Команда LIST…SCRIPT NAMES позволяет просматривать имена всех сценариев, которые хранятся в каталоге восстановления. Ниже приведен пример ее использования: RMAN> LIST SCRIPT NAMES;

Команда LIST…SCRIPT NAMES приводит к отображению списка всех локальных и глобальных сценариев, которые можно выполнять для базы данных, с которой в текущий момент установлено соединение. Для просмотра имен сценариев, которые можно выполнять для всех зарегистрированных в каталоге восстановления баз данных, служит команда LIST ALL SCRIPT NAMES.

 

Удаление хранимых сценариев

Для удаления хранимого сценария из каталога восстановления применяется команда DELETE SCRIPT, как показано ниже:

RMAN> DELETE SCRIPT 'my-script';

Если сценарий является глобальным, тогда нужно использовать команду DELETE GLOBAL SCRIPT.

 

Создание динамических хранимых сценариев

Создавать динамический хранимый сценарий можно путем указания переменных подстановки во время создания сценария командой CREATE SCRIPT. Конструкция USING позволяет задавать значения для переменных подстановки в командном файле. Ниже перечислены необходимые для создания и использования динамического хранимого сценария шаги.

1. Создайте командный файл, который можно использовать для создания хранимого сценария. В предлагаемом здесь примере этот командный файл называется myscript.rman и содержит команду CREATE SCRIPT для создания нового хранимого сценария. Для значений, которые должны назначаться динамически, применяются переменные подстановки.

RMAN> CREATE SCRIPT quarterly {
ALLOCATE CHANNEL c1
DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=&1)';
BACKUP
TAG &2
FORMAT '/disk2/bck/&1%U.bck'
KEEP FOREVER
RESTORE POINT &3
DATABASE;
}

В сценарии QUARTERLY (создаваемом командным файлом myscript.rman) используются три переменных подстановки: OB_MEDIA_FAMILY, которая служит для указания имени набора лент; FORMAT, применяемая для указания форматирующей строки; RESTORE_POINT, которая используется для указания имени точки восстановления.

2. Подключитесь к целевой базе данных и каталогу восстановления, указав первоначальные значения для трех переменных подстановки в сценарии QUARTERLY. Укажите эти значения после ключевого слова USING:

$ rman target / catalog rman@catdb USING arc_backup bck0908 FY08Q3

Обратите внимание, что на этом этапе осуществляется просто вход в RMAN: указание конструкции USING во время входа в RMAN позволяет всего лишь передать для трех переменных подстановки в сценарии необходимые значения. Сам сценарий будет создаваться на следующем шаге.

3. После входа в RMAN выполните командный файл myscript.rman, чтобы создать сценарий QUARTERLY:

RMAN> @catscript.rman

После этого у RMAN появится новый хранимый сценарий по имени QUARTERLY, способный принимать различные значения для своих трех переменных подстановки. Теперь, когда динамический хранимый сценарий создан, его можно легко выполнять каждый квартал, просто передавая соответствующие значения трем содержащимся в нем переменным подстановки. Например, предположим, что необходимые значения выглядят так: название семейства носителей — arch_bkp, форматирующая строка — bkp1208, имя точки восстановления — FY0804. Тогда получается, что вызвать хранимый сценарий QUARTERLY с такими значениями параметров можно следующим образом:

RUN
{
EXECUTE SCRIPT quarterly
USING arch_bkp
bkp1208
FY08Q4;
}

Как показывает пример, передавать переменным внутри динамического хранимого сценария различные значения во время выполнения очень легко.

 

Преобразование сценариев RMAN

Сценарии можно преобразовывать из текстовых в хранимые и наоборот. Ниже показана команда RMAN, с помощью которой можно отправлять содержимое хранимого сценария в текстовый файл:

RMAN> PRINT script nightly_backup to file 'test.txt';
script nightly_backup written to file test.txt
RMAN>

 

Замена хранимого сценария

Команда REPLACE SCRIPT позволяет обновлять (заменять) хранимый сценарий.

Ниже приведен пример:

RMAN> REPLACE SCRIPT full_backup
{
BACKUP DATABASE;
}

Если сценария full_backup не существует, утилита RMAN создаст его. Для замены глобального сценария необходимо использовать команду REPLACE GLOBAL SCRIPT.

 

Важные термины RMAN

В RMAN применяются некоторые специальные термины. Для эффективного использования RMAN необходимо хорошо разбираться во всех терминах, которые описываются в следующих подразделах.

Фрагмент резервной копии

Фрагментом резервной копии (backup piece) называется файл операционной системы, содержащий резервную копию файла данных, управляющего файла или файлов архивных журналов повторного выполнения. Вся информация в этом файле хранится в понятном только для RMAN формате.

 

Набор резервных копий

Набором резервных копий (backup set) называется логическая структура, состоящая из одного или более фрагментов резервных копий RMAN (по умолчанию на каждый набор приходится по одному фрагменту). Набор резервных копий может создаваться как на диске, так и на ленте. При выполнении резервного копирования базы данных, файла данных, табличного пространства или архивного журнала RMAN группирует весь ряд связанных фрагментов резервных копий в один набор резервных копий. При поступлении команды на выполнение резервного копирования RMAN автоматически создает набор резервных копий для размещения вывода. Не следует забывать о том, что набор резервных файлов представляет собой файл или набор файлов в специальном формате, который способна понимать только утилита RMAN. Поэтому использовать наборы резервных копий для восстановления базы данных может лишь RMAN.

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

 

Копии образов

Копии образов (image copies) похожи на те, которые можно делать для файлов операционной системы командой cp в UNIX или copy в DOS. Их можно создавать для файлов данных, управляющих файлов и файлов архивных журналов повторного выполнения. Сохранять копии образов, создаваемые с помощью RMAN, однако, можно только на диске; сохранять их на ленте нельзя.

RMAN может использовать и копии, которые создавались не в RMAN, а при помощи утилит операционной системы. Копии такого типа называются либо пользовательскими копиями, либо копиями операционной системы. На самом деле копии образов, создаваемые RMAN, отличаются от обычных копий, создаваемых командой cp, лишь тем, что информация о них заносится в управляющий файл или каталог восстановления. В случае применения для получения копий образов команды операционной системы, такой как dd, можно применить RMAN-команду CATALOG и записывать эти копии в каталог RMAN. То есть скопированный вручную файл данных можно использовать во время восстановления, если сначала зарегистрировать его в RMAN командой CATALOG. После этого все подобные пользовательские копии файлов данных станет можно применять в операциях RMAN через команды RESTORE и SWITCH.

Для создания копий образов в RMAN применяется команда BACKUP AS COPY. Утилиту RMAN можно заставить всегда создавать копии образов, а не наборы резервных копий (которые она создает по умолчанию), внеся следующее изменение в конфигурацию:

RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY PARALLELISM 1;
new RMAN configuration parameters are successfully stored
released channel: ORA_DISK_1
starting full resync of recovery catalog
full resync complete
RMAN>

Использовать копии образов, генерируемые при помощи RMAN-команды BACKUP AS COPY, можно точно так же, как и любые другие копии файлов, создаваемые утилитами операционной системы.

 

Прокси-копии

Утилита RMAN может выполнять резервное копирование особого вида, называемое прокси-копированием (proxy copy), при котором управление процессом копирования передается диспетчеру носителей. Прокси-копии не могут использоваться с дисками. Ниже приведен пример создания прокси-копии:

RMAN> BACKUP DEVICE TYPE sbt PROXY DATAFILE 2; 

 

Канал

Сеансам RMAN для выполнения связанных с резервным копированием и восстановлением задач требуется использовать некие соединения с сервером. Такие соединения называются в RMAN каналами (channels). Каналы определяют, какое именно устройство, диск или лента будет применяться для резервного копирования или восстановления. Допустимо как применять предварительно сконфигурированные каналы (нечто вроде каналов по умолчанию), так и задавать каналы вручную.

Конфигурировать постоянные каналы для сеансов RMAN можно посредством механизма автоматического выделения каналов (automatic channel allocation). Ниже показано, как сделать устройством по умолчанию ленту и диск:

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt; /* ленточное устройство */
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO disk; /* файловая система ОС */

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

Вручную задавать тип канала можно с помощью команды ALLOCATE CHANNEL. В приведенном ниже примере в этой команде указано, что должно использоваться устройство sbt, под которым подразумевается последовательное ленточное устройство. Обратите внимание, что в этом примере для выделения канала указан блок RUN. Блок RUN применяется в RMAN тогда, когда операторы внутри блока нуждаются в специальной настройке среды:

RMAN> RUN
{ALLOCATE CHANNEL a1 DEVICE TYPE sbt;
backup database;
}
RMAN>

Указание дескрипторов и форматов для резервных копий

Утилита RMAN позволяет использовать для каждой резервной копии специальный дескриптор (tag), который позволяет ее легко распознавать. Это дает возможность указывать, какие именно резервные копии должны применяться во время операции восстановления, добавляя соответствующий дескриптор. Дескрипторы являются очень удобным способом обозначения различных резервных копий, особенно тех, которые создаются посредством стратегий инкрементного резервного копирования. Ниже приведен простой пример, показывающий, как присваивать дескриптор полной резервной копии базы данных:

RMAN> BACKUP TAG 'weekly_full_db_bkup' DATABASE; 

Вместе с командами на выполнение резервного копирования можно указывать параметр FORMAT и с его помощью задавать желаемое место размещения и имя для копий и фрагментов резервных копий. Для генерации уникальных имен файлов нужно применять переменные подстановки. Ниже приведен пример определения формата и места размещения файла с помощью параметра FORMAT:

RMAN> BACKUP FORMAT='AL_%d/%t/%s/%p' ARCHIVELOG LIKE '%arc_dest%';

 

Копирование резервных копий RMAN

Создавать несколько экземпляров копий образов RMAN во время выполнения самого резервного копирования нельзя. Однако допускается делать несколько экземпляров наборов резервных копий в рамках команды BACKUP. Каждый из этих экземпляров можно отправлять на другой диск или ленту. Всего в рамках одной команды BACKUP допускается создавать до четырех экземпляров каждого из фрагментов в наборе резервных копий. Указывать, что требуется создать несколько экземпляров, можно следующим образом.

  • С использованием команды CONFIGURE…BACKUP COPIES.
  • С использованием конструкции SET BACKUP COPIES в блоке RUN.
  • С использованием конструкции COPIES в команде BACKUP.

Ниже приведен пример создания нескольких экземпляров резервной копии на нескольких различных дисках:

RMAN> BACKUP DEVICE TYPE DISK
COPIES 2 DATAFILE 1
FORMAT '/disk1/df1_%U', '/disk2/df1_%U';

Если на диске уже существует ранее подготовленная резервная копия, создать ее копию на другом диске можно с помощью такой команды BACKUP AS BACKUPSET:

RMAN> BACKUP DEVICE TYPE DISK AS BACKUPSET DATABASE PLUS ARCHIVELOG;

При желании создать экземпляр сделанной ранее резервной копии на ленте нужно воспользоваться следующей командой BACKUP BACKUPSET:

RMAN> BACKUP DEVICE TYPE sbt BACKUPSET ALL

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

  • Создание копии образа базы данных:
      RMAN> BACKUP AS COPY DATABASE;
  • Копирование предыдущей копии образа базы данных:
      RMAN> BACKUP AS COPY COPY OF DATABASE; 
  • Создание копии образа одного табличного пространства:
      RMAN> BACKUP AS COPY TABLESPACE SYSAUX; 
  • Создание набора резервных копий из копии образа табличного пространства:
      RMAN> BACKUP AS BACKUPSET COPY OF TABLESPACE SYSAUX; 
  • Копирование файла данных:
      RMAN> BACKUP AS COPY DATAFILE 2; 
  • Копирование копии файла данных:
      RMAN> BACKUP AS COPY COPY OF DATAFILE 2; 

 

Размещение резервных копий RMAN

Предположим, что в качестве устройства по умолчанию командой CONFIGURE DEFAULT DEVICE TYPE был сконфигурирован диск (DISK). То, в каком именно месте на этом диске RMAN будет создавать файлы резервных копий, зависит от следующих факторов.

  • Если в команде на выполнение резервного копирования для файла резервной копии указано место размещения и имя в параметре FORMAT (как описывалось ранее в статье), это место будет переопределять любое место, заданное для области пакетного восстановления. Например:
      RMAN> BACKUP DATABASE FORMAT '/tmp/%U'; /* %U генерирует уникальное имя файла */
  • Если в команде на выполнение резервного копирования не задан параметр FORMAT, утилита RMAN будет по умолчанию использовать для сохранения резервных копий область пакетного восстановления, как, например, в следующем случае:
      RMAN> BACKUP DATABASE; 
  • Если же область пакетного восстановления не была сконфигурирована, и в команде на выполнение резервного копирования не указан параметр FORMAT, утилита RMAN будет сохранять резервные копии в каталоге операционной системы на диске.

 

Команды RMAN

Чтобы использовать утилиту RMAN для выполнения процедур резервного копирования, необходимо разбираться лишь в ограниченном наборе команд. В следующих подразделах описываются лишь те команды RMAN, которые имеют отношение к процедурам резервного копирования и которые для удобства были поделены на следующие категории:

  • команды, касающиеся резервного копирования;
  • команды, касающиеся заданий;
  • команды, касающиеся копирования;
  • команды, касающиеся генерации отчетов;
  • команды, касающиеся отображения перечней различных элементов;
  • команды, касающиеся проверки резервных копий.

 

Команды, касающиеся резервного копирования (backup)

Очевидно, что самой важной в этой категории является команда BACKUP. Как уже отмечалось ранее, используемый канал может как указываться вручную непосредственно во время резервного копирования, так и выделяться автоматически самой утилитой RMAN.

Команда BACKUP позволяет выполнять резервное копирование всей базы данных, табличного пространства, одного файла данных (текущего или копии), управляющего файла (текущего или копии), файла SPFILE, архивного журнала повторного выполнения и других наборов резервных копий. Ниже приведены некоторые примеры использования команды BACKUP:

RMAN> BACKUP DATABASE;
RMAN> BACKUP TABLESPACE users;
RMAN> BACKUP DATAFILE '/u01/app/oracle/oradata/finance/users01.dbf';

Выдача просто команды BACKUP DATABASE равнозначна применению команды BACKUP AS BACKUPSET. Все предыдущие команды RMAN генерируют один или более наборов резервных копий, которые представляют собой понятные только RMAN логические единицы резервного копирования.

 

Создание копий образов при резервном копировании

В случае использования такой версии команды BACKUP, как BACKUP AS COPY, утилита RMAN генерирует для файлов, подлежащих резервному копированию, копии образов. Чтобы создать соответствующие копии образов для приведенных выше примеров, нужно использовать такие команды:

RMAN> BACKUP AS COPY DATABASE;
RMAN> BACKUP AS COPY TABLESPACE USERS;
RMAN> BACKUP AS COPY DATAFILE '/u01/app/oracle/oradata/finance/users01.dbf';

На заметку! По умолчанию RMAN создает все резервные копии на ленте или диске в виде наборов резервных копий.


Ни в одном из предыдущих примеров имена для создаваемых RMAN резервных копий не указывались. Во всех таких случаях RMAN присваивает создаваемым резервным копиям принятый по умолчанию дескриптор. Как уже объяснялось выше, при желании присвоить резервной копии специфический дескриптор, можно использовать параметр TAG. Ниже приведен пример присоединения к резервной копии RMAN дескриптора weekly_backup:

RMAN> BACKUP DATABASE TAG = 'weekly_backup';

 

Логическая проверка резервных копий RMAN

Во время резервного копирования можно использовать ключевое слово LOGICAL и тем самым позволить RMAN выполнять логическую проверку файлов резервных копий. Ниже приведен пример выполнения проверки на предмет логического повреждения в экземпляре копии базы данных (duptest), который делается из копии базы данных (test):

RMAN> BACKUP AS COPY COPY OF DATABASE FROM TAG 'TEST' CHECK LOGICAL TAG 'DUPTEST';

 

Инкрементное резервное копирование

Все приведенные в предыдущих разделах команды BACKUP предусматривали выполнение полного резервного копирования. Однако с помощью утилиты RMAN также можно выполнять и инкрементное резервное копирование, и на самом деле это является одним из ее главных преимуществ.

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

Процедуры инкрементного резервного копирования могут проводиться на уровнях 0 и 1. Процедура инкрементного резервного копирования на уровне 0 подразумевает копирование всех блоков данных, точно так же как и полное резервное копирование, и служит основой для последующих процедур инкрементного резервного копирования. Для выполнения процедуры инкрементного копирования на уровне 1 обязательно нужна исходная инкрементная резервная копия уровня 0.

Утилита RMAN позволяет выполнять инкрементное резервное копирование двух следующих видов.

  • Дифференциальное резервное копирование (differential backup). Подразумевает выполнение резервного копирования всех блоков, которые изменились с момента проведения последнего инкрементного резервного копирования на уровне либо 1, либо 0.
  • Кумулятивное резервное копирование (cumulative backup). Подразумевает выполнение резервного копирования всех блоков, которые изменились с момента проведения последнего инкрементного резервного копирования на уровне 0.

Следующая команда позволяет провести необходимое начальное инкрементное резервное копирование на уровне 0:

RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;

После исходного резервного копирования на уровне 0 можно приступать к инкрементному дифференциальному резервному копированию на уровне 1:

RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;

Кумулятивное инкрементное резервное копирование на уровне n будет приводить к выполнению резервного копирования всех блоков, которые изменились с момента проведения последнего резервного копирования на уровне n – 1 или ниже. То есть в случае выполнения кумулятивного инкрементного резервного копирования на уровне 2, оно будет приводить к резервному копированию всех блоков данных, которые изменились с момента проведения резервного копирования на уровне 0 или на уровне 1. Хотя выполнять инкрементное резервное копирования на уровне 2 и можно, согласно Oracle допустимыми считаются только уровни 0 и 1.

Размер файла инкрементной резервной копии будет зависеть от количества изменившихся блоков и инкрементного уровня. Кумулятивные резервные копии, как правило, будут занимать больше места, поскольку предусматривают дублирование данных, копировавшихся при проведении процедур резервного копирования на том же уровне. Однако у них есть одно важное преимущество: они сокращают время восстановления, поскольку позволяют применять только одну резервную копию. Поэтому в Oracle рекомендуют использовать все-таки кумулятивные резервные копии, если на сервере хватает места.

Ниже приведен пример, показывающий, как инкрементные процедуры могут использоваться в общей стратегии резервного копирования.

  • В воскресенье — выполнение инкрементного резервного копирования на уровне 0.
  • С понедельника по субботу — выполнение процедур дифференциального инкрементного резервного копирования на уровне 1.
  • Повторение цикла на следующей неделе.

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

Рассмотрим теперь альтернативную стратегию, предусматривающую использование кумулятивных резервных копий.

  • В воскресенье — выполнение инкрементного резервного копирования на уровне 0.
  • С понедельника по субботу — выполнение процедур кумулятивного инкрементного резервного копирования на уровне 1.
  • Повторение цикла на следующей неделе.

Обратите внимание, что в данном случае ежедневные процедуры кумулятивного резервного копирования на уровне 1 подразумевают архивирование всех блоков, которые изменились с момента воскресного резервного копирования. Следовательно, если вдруг в четверг возникнет необходимость восстановить базу данных, достаточно будет применить лишь одну кумулятивную резервную копию, а именно — ту, что была создана в ночь перед проведением воскресной процедуры инкрементного резервного копирования на уровне 0.

 

Команды, касающиеся заданий

Команды ALLOCATE CHANNEL и SWITCH нельзя использовать по отдельности. Их обязательно нужно применять только вместе с командой RUN, как показано ниже:

RMAN> RUN
{ALLOCATE CHANNEL c1 DEVICE TYPE sbt
PARMS='ENV=(NSR_GROUP=default)';
BACKUP DATAFILE 1;
}
allocated channel: c1
channel c1: sid=11 devtype=SBT_TAPE
channel c1: MMS Version 2.2.0.1

Команда SWITCH похожа на команду ALTER DATABASE RENAME DATAFILE. Она позволяет заменять файл данных той копией этого файла, которая была сделана утилитой RMAN.

Копии файлов данных

Команда BACKUP AS COPY в RMAN позволяет создавать простую копию файла данных (для этого можно использовать и старую команду COPY, но, начиная с Oracle Database 10g, в Oracle больше не рекомендуют ее применять).

Создаваемые по команде BACKUP AS COPY копии образов идентичны копиям, которые создаются утилитами операционной системы. Ниже приведен пример использования команды BACKUP AS COPY:

RMAN> BACKUP AS COPY DATAFILE 1;
Starting backup at 05-JUN-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile fno=00001 name=C:\ORALE\PRODUCT\11.1.0\ORADATA\NEWS\SYSTEM01.DBF
output filename=C:\ORALE\PRODUCT\11.1.0\FLASH_RECOVERY_AREA\NEWS\DATAFILE\O1_MF_
SYSTEM_0Q2XPZ1Y_.DBF tag=TAG20041016T143037 recid=2 stamp=539706790
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:02:35
channel ORA_DISK_1: starting datafile copy
copying current controlfile
output filename=C:\ORALE\PRODUCT\11.1.0\FLASH_RECOVERY_AREA\NEWS\CONTROLFILE\O1_
MF_TAG20041016T143037_0Q2XVT4T_.CTL tag=TAG20041016T143037 recid=3 stamp=539706796
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07
Finished backup at 05-JUN-08
RMAN>

Следующий пример иллюстрирует применение более старой команды COPY:

RMAN> COPY DATAFILE 1 TO 'c:\download\test.copy';
Starting backup at 05-JUN-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile fno=00001 name=C:\ORALE\PRODUCT\11.1.0\ORADATA\ORCL\SYSTEM01.DBF
output filename=C:\DOWNLOAD\TEST.COPY tag=TAG20041009T124719 recid=2 stamp=53909
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:35
Finished backup at 05-JUN-08
RMAN> 

 

Удаление резервных копий

Для удаления физических резервных копий, которые были созданы в RMAN, служит команда DELETE. Эта команда приводит к удалению физических резервных копий, обновлению записей в управляющем файле с указанием на то, что резервные копии были удалены, и стиранию представлявших их записей в каталоге восстановления (если таковой используется). С ее помощью можно удалять наборы резервных копий, архивные журналы повторного выполнения и копии файлов данных.


Внимание! Для удаления резервных копий RMAN лучше всегда применять команду DELETE из RMAN, а не команду удаления, поддерживаемую операционной системой. Иначе в репозитории RMAN будут содержаться записи о резервных копиях, которые больше не доступны.


Ниже приведен пример удаления всех архивных журналов повторного выполнения, для которых с помощью RMAN как минимум дважды создавались резервные копии на ленте:

RMAN> DELETE ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;

Команда DELETE OBSOLETE будет приводить к удалению всех резервных копий, которые больше не нужны. Эту команду удобно выполнять периодически для удаления всех устаревших резервных копий. Резервная копия считается устаревшей, если она уже больше не требуется для восстановления базы данных согласно используемой политике сохранности (retention policy). Команда DELETE EXPIRED будет приводить к удалению из каталога восстановления всех записей, которые представляют недействительные резервные копии, и снабжению их пометкой DELETED. Ее удобно использовать, если есть подозрение, что резервные копии или архивные журналы RMAN были удалены с диска утилитой операционной системы (а не RMAN). Сначала можно выполнить команду CROSSCHECK, чтобы RMAN могла пометить резервные копии, которые не удается найти, как недействительные (expired). Недействительными считаются все резервные копии, файлы которых утилите RMAN не удается обнаружить. Затем можно воспользоваться командой DELETE EXPIRED для удаления представляющих эти файлы записей из управляющего файла и каталога восстановления.

 

Команды, касающиеся генерации отчетов

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

Команды REPORT SCHEMA, RERPORT OBSOLETE, REPORT NEED BACKUP и REPORT UNRECOVERABLE

Команда REPORT SCHEMA отображает список всех файлов данных, которые являются частью целевой базы данных.

Команда REPORT OBSOLETE отображает список всех резервных копий, которые оказываются устаревшими согласно выбранной политике сохранности резервных копий:

RMAN> REPORT OBSOLETE;
RMAN retention policy will be applied to the command
RMAN retention policy is set to recovery window of 14 days
no obsolete backups found
RMAN>

Если в репозитории обнаружены устаревшие резервные копии, их можно удалить командой DELETE OBSOLETE.

В случае использования для хранения резервных копий области пакетного восстановления, RMAN будет автоматически удалять устаревшие резервные копии при возникновении необходимости в освобождении места для более новых резервных копий. До тех пор устаревшие резервные копии будут оставаться в области пакетного восстановления. Если область пакетного восстановления не применяется, время от времени понадобится вручную выполнять команду DELETE OBSOLETE для удаления устаревших файлов резервных копий.

Команда REPORT NEED BACKUP отображает список любых файлов данных, которые нуждаются в резервном копировании согласно требованиям политики сохранности, которая была изначально выбрана для резервных копий. В приведенном ниже примере она показывает, что нуждающихся в резервном копировании файлов нет:

RMAN> REPORT NEED BACKUP;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
Report of files with less than 1 redundant backups
File #bkps                           Name
---- ----- ---------------------------------------------------------
1      0   /u01/app/oracle/product/11.1.0/oradata/nicko/system01.dbf
2      0   /u01/app/oracle/product/11.1.0/oradata/nicko/undotbs01.dbf
3      0   /u01/app/oracle/product/11.1.0/oradata/nicko/sysaux01.dbf
4      0   /u01/app/oracle/product/11.1.0/oradata/nicko/users01.dbf
RMAN>

Команда REPORT UNRECOVERABLE отображает список всех недоступных для восстановления файлов данных. Недоступным для восстановления считается файл данных с сегментом, который подвергся операции, не предусматривающей запись в журнале, и потому нуждается в немедленном резервном копировании.

 

Команда CATALOG

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

  • восстановление резервной копии управляющего файла;
  • восстановление резервного (standby) управляющего файла;
  • воссоздание управляющего файла;
  • включение параметра DB_RECOVERY_FILE_DEST и последующее его отключение.

Резервное копирование файлов данных и архивных журналов повторного выполнения тоже может приводить к созданию файлов, о которых RMAN не будет известно. Например, команду CATALOG можно применять для занесения в каталог копий файлов базы данных, которые были сделаны в результате выполнения резервного копирования на уровне 0. Это позволит далее проводить инкрементное резервное копирование с использованием уже этих копий файлов данных в качестве основы.

С помощью команды CATALOG заносить в каталог можно все хранящиеся на диске копии файлов данных, фрагменты резервных копий и архивные журналы. Ниже приведено несколько примеров:

RMAN> CATALOG DATAFILECOPY '/u01/app/oracle/backup/users01.dbf';
RMAN> CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp';

За счет применения команды CATALOG START WITH утилиту RMAN можно заставить начать поиск всех не зафиксированных в каталоге файлов в указанном месте. Эту команду особенно удобно применять, когда имена файлов имеют непонятный вид, как, например, при использовании файловой системы OMF или ASM. Ниже приведен пример выдачи команды CATALOG START WITH для занесения в репозиторий RMAN одновременно множества файлов:

RMAN> CATALOG START WITH '/disk1/backups/';

В случае выполнения этой команды RMAN сначала отобразит перечень всех имеющихся в каталоге /disk1/backups файлов, а затем добавит их в свой репозиторий после получения соответствующего подтверждения на выполнение данной операции.

В случае обнаружении несоответствий между записями в каталоге восстановления и фактическими резервными копиями на диске, RMAN при попытке выполнить резервное копирование или восстановление будет выдавать ошибку. Избавляться от недействительных записей в каталоге восстановления можно применением команды DELETE с параметром FORCE, как показано ниже:

RMAN> DELETE FORCE NOPROMPT ARCHIVELOG SEQUENCE 40;

 

Команды, касающиеся отображения перечней различных элементов

Несколько команд в RMAN позволяют отображать списки различных элементов, вроде резервных копий и хранимых сценариев в каталоге восстановления.

В частности, команда LIST BACKUP позволяет просматривать информацию обо всех выполненных процедурах резервного копирования, которые зарегистрировала утилита RMAN. Она отображает перечень всех наборов резервных копий и копий образов, а также отдельных файлов данных, управляющих файлов, файлов архивных журналов повторного выполнения и файлов SPFILE, которые имеются среди файлов резервных копий. Список всех резервных копий можно также получать путем выполнения запроса к представлению V$BACKUP_FILES и к представлению каталога восстановления RC_BACKUP_FILES. В листинге 1 показан пример вывода команды LIST BACKUP.


RMAN> LIST BACKUP;
List of Backup Sets
===================
BS Key Type LV Size       Device Type Elapsed Time Completion Time
------ ---- -- ---------- ----------- ------------ ---------------
892    Full    169M       DISK            00:01:19       06-JUN-08
List of Datafiles in backup set 892
File LV Type Ckp SCN     Ckp Time    Name
---- -- ---- ----------  ---------   ----
1       Full 81814        06-JUN-08  C:\ORALE\PRODUCT\11.1.0\
ORADATA\NEWS\SYSTEM01.DBF
. . .
List of Archived Logs in backup set 917
BS Key   Type  LV  Size        Device Type  Elapsed Time  Completion Time
-------  ----  --  ----------  -----------  ------------  ---------------
928      Full      3M          DISK             00:00:06        06-JUN-08
BP Key: 930 Status: AVAILABLE Compressed: NO Tag: TAG20041016T132630
Controlfile Included: Ckp SCN: 81959 Ckp time: 06-JUN-08
RMAN>

Команда LIST COPY похожа на команду LIST BACKUP и отображает полный перечень всех копий, которые были сделаны при помощи RMAN.

RMAN> LIST COPY;

Команда LIST ARCHIVELOG ALL выводит список всех доступных копий архивных журналов.

И, наконец, команда LIST SCRIPT NAMES позволяет просматривать список имен всех хранимых сценариев в каталоге восстановления, а команда LIST GLOBAL SCRIPT NAMES — соответственно, перечень имен всех глобальных сценариев.

Команды, касающиеся проверки резервных копий

С помощью команды VALIDATE BACKUPSET можно проверять наборы резервных копий на предмет действительности, прежде чем использовать их в процедуре восстановления. В следующем примере вывод этой команды показывает, что RMAN не удалось найти набор резервных копий BACKUPSET 1:

RMAN> VALIDATE BACKUPSET 1;
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ================
=============== ЗДЕСЬ ИДЕТ СТЕК СООБЩЕНИЙ ОБ ОШИБКАХ =======
RMAN-00571: ===========================================================
RMAN-03002: failure of validate command at 06/05/2008 13:14:04
Неудачное выполнение команды проверки действительности 06/05/2008 13:14:04
RMAN-06004: ORACLE error from recovery catalog database: RMAN-20215:
backup set not found
Ошибка ORACLE из базы данных каталога восстановления: RMAN-20215:
Не удалось обнаружить набор резервных копий
RMAN-06159: error while looking up backup set
Ошибка при поиске набора резервных копий
RMAN>

Команду CROSSCHECK можно также применять для проверки того, что резервная копия действительно существует и является пригодной для использования. Пример использования этой команды будет приведен позже в этой статье, в разделе “Наблюдение за заданиями RMAN и проверка состояния резервных копий”.

 

Параметры конфигурации RMAN

У RMAN имеется несколько параметров конфигурации, для которых при первом использовании RMAN устанавливаются значения по умолчанию. Для начала работы с утилитой RMAN или изучения способов применения ее команд вообще ничего конфигурировать не требуется. Однако по мере приобретения опыта будет обязательно возникать желание сконфигурировать какие-нибудь параметры этой утилиты так, чтобы они больше отвечали существующим потребностям. Для просмотра значений, принятых по умолчанию, служит команда SHOW ALL, вывод которой показан в листинге 2:


RMAN> SHOW ALL;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name ORCL are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BZIP2'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'C:\ORCL\APP\ORACLE\PRODUCT\11.1.0\DB_1\
DATABASE\SNCFORCL.ORA'; # default

Просматривать текущие значения всех конфигурационных параметров RMAN, для которых были изменены принятые по умолчанию значения, можно через представление V$RMAN_CONFIGURATION:

 

SQL> SELECT * FROM v$rman_configuration;
CONF#  NAME                          VALUE
-----  ----------------------------  -----------------
1      DEFAULT DEVICE TYPE TO        'SBT_TAPE'
2      CONTROLFILE AUTOBACKUP        ON
3      BACKUP OPTIMIZATION           ON
4      RETENTION POLICY              TO REDUNDANCY 2
SQL>

Если параметров, для которых были изменены принятые по умолчанию значения, нет, приведенный выше запрос не будет возвращать никаких строк. Изменять значения всех конфигурационных параметров RMAN можно командой CONFIGURE. Давайте теперь более подробно остановимся на наиболее важных конфигурационных параметрах и том, как их можно изменять.

 

Политика сохранности резервных копий

Политика сохранности резервных копий (backup retention policy) указывает RMAN, когда следует считать резервные копии файлов данных и файлов журналов устаревшими. Обратите внимание на то, что при указании RMAN считать файл резервной копии устаревшим по истечении определенного периода времени, RMAN лишь помечает файл как устаревший, но не удаляет его; это требует самостоятельного удаления устаревших файлы.

Конфигурировать политику сохранности резервных копий можно двумя способами: с помощью принятого по умолчанию параметра REDUNDANCY или посредством параметра RETENTION WINDOW. В том и другом случаях для установки политики сохранности, которая должна использоваться по умолчанию для всех файлов базы данных, нужно использовать команду CONFIGURE RETENTION POLICY.

 

Параметр REDUNDANCY

Параметр REDUNDANCY позволяет указывать, сколько экземпляров резервных копий требуется сохранять. По умолчанию для него устанавливается значение 1. Изменять это значение можно следующим образом:

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
RMAN>

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

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

Параметр RECOVERY WINDOW

Использование при настройке политики сохранности резервных копий параметра RECOVER WINDOW позволяет указывать, насколько далеко назад по времени должно выполняться восстановление в случае возникновения в базе данных неполадки с носителем. RMAN будет сохранять все резервные копии файлов данных и файлов журналов на один день раньше указанного в RECOVERY WINDOW периода. Например, в случае указания в RECOVERY WINDOW семи дней, RMAN будет сохранять все резервные копии, начиная с тех, что были сделаны непосредственно перед началом данного семидневного периода. Устанавливать значение для RECOVERY WINDOW можно следующим образом:

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
old RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
RMAN>

Как видно в этом примере, устанавливать значение допускается только либо для параметра REDANDANCY, либо для параметра RECOVERY WINDOW, но не для обоих одновременно. Изменение значения одного или другого будет приводить к замещению предыдущих настроек.

 

Параметр DEFAULT DEVICE TYPE

По умолчанию устройством, применяемым для размещения резервных копий, является диск, т.е. RMAN будет автоматически сохранять все резервные копии в файловой системе сервера. Если необходимо, чтобы резервные копии сохранялись на ленте, для параметра DEFAULT DEVICE TYPE должно быть установлено значение sbt (которым обозначаются все ленточные носители). Ниже приведен пример:

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;
old RMAN configuration parameters:
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
new RMAN configuration parameters:
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
RMAN>

Переключаться обратно на использование диска можно с помощью такой команды:

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK;
old RMAN configuration parameters:
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
new RMAN configuration parameters:
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
RMAN> 

 

Параметры шифрования и сжатия

Для того чтобы создавать шифрованные резервные копии RMAN на диске, требуется иметь доступ к компоненту Oracle Advanced Security (Дополнительные функции защиты Oracle), а для того чтобы создавать шифрованные резервные копии на ленте — к интерфейсу Oracle Secure Backup SBT (Безопасное резервное копирование Oracle с использованием устройства SBT).

Для просмотра различных алгоритмов шифрования, которые поддерживает RMAN, можно использовать представление V$RMAN_ENCRYPTION_ALGORITHM. В общем случае в RMAN предлагается три следующих режима шифрования.

  • Прозрачное шифрование (transparent encryption). Требует применения инфраструктуры открытых ключей Oracle (Oracle Public Key Infrastructure — PKI).
  • Шифрование на основании пароля (password-based encryption). Требует указания пароля при выполнении резервного копирования и восстановления из резервных копий.
  • Двухрежимное шифрование (dual-mode encryption). Позволяет выполнять шифрование посредством любого из двух предыдущих режимов. Расшифровка может выполняться либо путем предоставления пароля, либо за счет использования Oracle Wallet.

Команды, которые можно применять для шифрования резервных копий выглядят так: CONFIGURATION ENCRYPTION и SET ENCRYPTION.

Помимо шифрования резервные копии RMAN также можно и сжимать. Для указания утилите RMAN, что она должна сжать создаваемую резервную копию, служит команда CONFIGURE COMPRESSION. Команда CONFIGURE COMPRESSION ALGORITHM позволяет выбрать один из двух доступных алгоритмов сжатия: BZIP2 или ZLIB. По умолчанию используется алгоритм ZLIB, который по заявлениям Oracle работает значительно быстрее (приблизительно на 40%), чем альтернативный алгоритм BZIP2. Изучить предлагаемое Oracle описание отличий между этими двумя алгоритмами можно, выполнив запрос к представлению V$RMAN_COMPRESSION_ALGORITHM. Например:

SQL> select algorithm_name,algorithm_description, is_default
2 from v$rman_compression_algorithm;
ALGORITHM   ALGORITHM DESCRIPTION                    IS_DEFAULT
---------  ----------------------------------------  ----------
ZLIB       fast but little worse compression ratio   YES
           быстрый, но с несколько худшим сжатием    ДА
BZIP2      good compression ratio but little slower  NO
           хорошее сжатие, но несколько медленный    НЕТ
SQL> 

Как здесь видно, алгоритм ZLIB работает быстрее, но зато алгоритм BZIP2 обеспечивает более высокую степень сжатия.

 

Конфигурация каналов

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

Ниже приведен пример настройки двух каналов, первый из которых предусматривает создание резервных копий в соответствующем каталоге внутри /test01, а второй — в соответствующем каталоге внутри /test02:

RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT
'/test01/app/oracle/oradata/backup/%U';
new RMAN configuration parameters:
CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT'/test01/app/oracle/oradata/backup/%U';
new RMAN configuration parameters are successfully stored
RMAN> CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT
'/test02/app/oracle/oradata/backup/%U';
new RMAN configuration parameters:
CONFIGURE CHANNEL 2 DEVICE TYPE DISK
FORMAT'/test02/app/oracle/oradata/backup/%U';
new RMAN configuration parameters are successfully stored

На заметку! Параметры DISK PARALLELISM и CHANNEL связаны между собой. Например, в случае указания для степени параллелизма (DISK PARALLELISM) значения 4 и настройки лишь двух или даже вообще ни одного канала, RMAN будет открывать четыре универсальных канала. В случае же выполнения вручную настройки, например, шести каналов, но указания для степени параллелизма значения 1, RMAN будет использовать только первый канал и игнорировать остальные пять.


В случае запуска сеанса резервного копирования с несколькими каналами выход из строя одного из них, например, из-за неполадки с ленточным устройством, не будет приводить к прекращению процесса резервного копирования. Вместо этого RMAN будет завершать процесс резервного копирования с оставшимися каналами и сообщать о возникшей проблеме в представлении V$RMAN_OUTPUT. Эта способность RMAN также называется функцией автоматического переключения каналов (Automatic Channel Failover).

 

Степень параллелизма

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

RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 4;
old RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY PARALLELISM 1;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COPY;
new RMAN configuration parameters are successfully stored
released channel: ORA_DISK_1
starting full resync of recovery catalog
full resync complete
RMAN>

 

Оптимизация процесса резервного копирования

Параметр BACKUP OPTIMIZATION гарантирует, что утилита RMAN не будет выполнять резервное копирование файла, если уже подготовлены резервные копии идентичных версий этого файла. Включается этот параметр так:

RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
new RMAN configuration parameters:
CONFIGURE BACKUP OPTIMIZATION ON;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
RMAN>

 

Параметры, касающиеся управляющих файлов

У RMAN есть несколько конфигурационных параметров, которые касаются резервного копирования управляющих файлов. В следующих подразделах описываются наиболее важные из них.

 

Параметр CONTROLFILE AUTOBACKUP

В случае установки для параметра CONTROLFILE AUTOBACKUP значения ON, утилита RMAN начинает при каждом создании резервной копии файлов данных автоматически выполнять резервное копирование управляющего файла и файла SPFILE. Конфигурируется подобное поведение следующим образом:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
RMAN>

Теперь при использовании команды BACKUP утилита RMAN будет также автоматически выполнять резервное копирование управляющего файла и файла SPFILE (если таковой имеется):

RMAN> BACKUP TABLESPACE sysaux;
Starting backup at 06-JUN-08
. . .
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:16
Finished backup at 06-JUN-05
Starting Control File Autobackup at 06-JUN-05
Finished Control File Autobackup at 06-JUN-05
RMAN>

 

Параметр AUTOBACKUP FORMAT

С помощью параметра AUTOBACKUP FORMAT можно задавать для резервных копий управляющих файлов желаемое место размещения и формат. Например:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'/test01/app/oracle/oradta/backup/cf_%F';
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR
DEVICE TYPE DISK TO '/test01/app/oracle/oradata
/backup/cf_%F'; new RMAN configuration parameters
are successfully stored
RMAN>

Параметр ARCHIVELOG DELETION POLICY

Параметр ARCHIVELOG DELETION POLICY позволяет настраивать политику постоянства, которая должна применяться для определения того, когда архивные журналы повторного выполнения становятся пригодными для удаления с диска. Действие этой политики распространяется на все места хранения архивных журналов, в том числе, на область пакетного восстановления.

Из области пакетного восстановления все годные журналы удаляются автоматически. Однако их также можно удалять и вручную, в том числе и из области пакетного восстановления, выполнив либо команду DELETE ARCHIVELOG, либо команду BACKUP…DELETE INPUT.

По умолчанию для параметра ARCHIVELOG DELETION POLICY используется значение NONE. При таком значении возможность удаления архивных журналов повторного выполнения будет рассматриваться только в том случае, если они были перемещены в место, на которое указывает параметр LOG_ARCHIVE_DEST_n, а затем также хотя бы один раз сохранены в виде резервных копий на диске или ленте.

Вместо NONE для параметра ARCHIVELOG DELETION POLICY с помощью команды CONFIGURE ARCHIVELOG DELETION POLICY BACKED можно также сконфигурировать и явное значение, как показано в следующем примере:

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY
TO BACKED UP 2 TIMES TO SBT;

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

 

Работа с каталогом восстановления

Применение каталога восстановления совершенно не обязательно, поскольку Oracle вполне может использовать для хранения данных репозитория RMAN (метаданных) управляющий файл. Однако, как уже объяснялось ранее в этой статье, лучше все-таки потратить немного времени на создание этого каталога и пользоваться им. Во всех приведенных в этой статье описаниях предполагается, что такой каталог существует.


Совет. Нужно обязательно удостовериться в том, что база данных, в которой создается каталог восстановления, функционирует в режиме архивации журналов (ARCHIVELOG). Это гарантирует наличие в будущем возможности выполнения процедуры PITR (восстановления данных до состояния, в котором они находились на определенный момент времени в прошлом).


Для создания каталога восстановления сначала необходимо подключиться к базе данных, в которой планируется создать этот каталог, затем создать новую схему владельца каталога восстановления (которой обычно присваивается имя rman) и предоставить необходимые привилегии для доступа к ней, и только потом, наконец, создать сам каталог восстановления. После создания каталога можно приступить к регистрации в нем баз данных.

 

Создание схемы каталога восстановления

Чтобы использовать каталог восстановления, сначала потребуется создать соответствующую схему. Создать эту схему или пользователя можно как в существующем, так и в новом табличном пространстве, предусмотренном специально для этой цели. Сам каталог восстановления будет храниться в принятом по умолчанию табличном пространстве этой схемы. Ниже приведен пример создания схемы по имени rman:

SQL> CREATE USER RMAN IDENTIFIED BY rman
TEMPORARY TABLESPACE temp
DEFAULT TABLESPACE rman_tbsp
QUOTA UNLIMITED ON rman_tbsp
User created.
SQL>

Сначала нужно обязательно создать для пользователя rman табличное пространство rman_tbsp.

 

Выдача необходимых привилегий

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

SQL> GRANT RECOVERY_CATALOG_OWNER TO rman;
Grant succeeded.
SQL>

 

Подключение к утилите RMAN

Подключаться к утилите RMAN можно двумя способами. Во-первых, это можно делать, сначала вызвав RMAN, а затем воспользовавшись командой CONNECT CATALOG для установки подключения, как показано в следующем примере (где предполагается, что каталог восстановления содержится в базе данных nicko):

$ rman
Recovery Manager: Release 11.1.0.6.0 - Production on Thu Mar 27 11:36:34 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
RMAN> CONNECT CATALOG rman/rman@nicko
connected to recovery catalog database
RMAN>

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

$ rman CATALOG rman/rman@nicko
connected to recovery catalog database
RMAN> 

В случае подключения к базе данных каталога напрямую соединение с целевой базой данных сразу же не устанавливается (если только целевая база данных не совпадает с базой данных каталога). Для подключения к целевой базе данных потребуется выдать из интерфейса RMAN следующую команду (где nina — это имя целевой базы данных):

RMAN> connect target nina
Connected to target database: NINA (DBID=1974138212)
RMAN>

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

$ rman catalog rman/rman@nicko target nina
Recovery Manager: Release 11.1.0.6.0 - Production on Thu Mar 27 11:36:34 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.target database password:
connected to target database: NINA (DBID=1974138212)
connected to recovery catalog database
RMAN>

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


 

Создание каталога восстановления

При желании использовать для хранения метаданных RMAN каталог восстановления (а не управляющий файл, как предлагается по умолчанию), прежде всего, нужно создать такой каталог в схеме владельца каталога восстановления (rman).

Делается это сначала подключением к базе данных одним из рассмотренных в предыдущем разделе способов, а затем выдачей команды CREATE CATALOG, как показано ниже:

RMAN> CREATE CATALOG;
recovery catalog created
RMAN>

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

Для удаления каталога восстановления можно использовать команду DROP CATALOG:

RMAN> DROP CATALOG;
Recovery catalog owner is RMAN
Enter DROP CATALOG command again to confirm catalog removal
RMAN> DROP CATALOG;
Recovery catalog dropped
RMAN>.

 

Регистрация базы данных

Чтобы утилита RMAN могла выполнять свою работу, необходимо, чтобы целевая база данных, которая подвергается резервному копированию или восстановлению, была зарегистрирована. Под регистрацией базы данных подразумевается занесение этой базы данных в каталог восстановления. После регистрации базы данных RMAN автоматически извлекает все связанные с ней метаданные и сохраняет их в своей собственной схеме.

Создавать отдельный каталог восстановления для каждой из существующих баз данных Oracle не нужно; все базы данных вполне можно регистрировать в одном каталоге восстановления. Для регистрации новой базы данных в каталоге восстановления сначала нужно подключиться к целевой базе данных:

$ rman catalog rman/rman@nicko target nina
Recovery Manager: Release 11.1.0.6.0 - Production on Thu Mar 27 11:36:34 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
target database Password:
connected to target database: NINA (DBID=1974138212)
connected to recovery catalog database
RMAN>

Внимание! Перед регистрацией базы данных в каталоге восстановления не забудьте установить ORACLE_SID в значение системного идентификатора (SID) целевой базы данных, иначе соединение будет устанавливаться не с целевой базой данных, а с той, имя экземпляра которой совпадает с указанным в ORACLE_SID для сеанса UNIX.


Далее можно перейти непосредственно к регистрации базы данных:

RMAN> REGISTER DATABASE;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN> 

Эта команда успешно зарегистрирует целевую базу данных в каталоге восстановления. После этого с помощью команды REPORT SCHEMA можно проверить, действительно ли все файлы данных целевой базы данных присутствуют в списке.

С использованием следующей команды проверяется инкарнация (отдельная версия) базы данных:

RMAN> LIST INCARNATION;
List of Database Incarnations
DB Key   Inc Key  DB Name   DB ID        STATUS      Reset SCN  Reset Time
-------  -------  --------  -----------  ----------  ---------  -----------
1        8        NINA      1974138212   PARENT              1  11-JAN-08
1        2        NINA      1974138212   CURRENT        318842  05-JUN-08
RMAN>

 

Обслуживание каталога восстановления

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

 

Ресинхронизация каталога восстановления

Изменения, вносимые в структуру целевой базы данных, в каталог восстановления автоматически не передаются. Команды BACKUP и COPY автоматически приводят к ресинхронизации каталога восстановления при каждом выполнении операции по созданию резервной копии или копии образа. Но в двух случаях — при прохождении целевой базой данных ряда физических изменений и при выполнении в целевой базе данных слишком большого количества переключений между журналами в ходе операций резервного копирования — ресинхронизацию каталога бывает необходимо выполнять вручную.

Во время операции ресинхронизации RMAN считывает содержимое управляющего файла целевой базы данных и соответствующим образом обновляет хранящуюся в нем информацию о файлах данных, переключениях журналов, физической схеме и т.д. В Oracle рекомендуют выполнять ресинхронизацию каталога восстановления после внесения любых изменений в физическую структуру целевой базы данных. Ресинхронизация осуществляется просто подключением к целевой базе данных и выдачей команды RESYNC CATALOG:

RMAN> RESYNC CATALOG;
starting full resync of recovery catalog
full resync complete
RMAN>

Резервное копирование каталога восстановления

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

  • Проводить резервное копирование каталога восстановления как можно чаще.
  • Никогда не хранить каталог восстановления в целевой базе данных, потому что в случае возникновения неполадки с носителем это может закончиться одновременной потерей и целевой базы данных и каталога восстановления.
  • Всегда запускать базу данных, в которой содержится каталог восстановления, в режиме архивирования журналов (ARCHIVELOG).
  • Предусматривать несколько экземпляров резервных копий базы данных каталога восстановления и желательно сохранять их не только на диске, но и на ленте.
  • Устанавливать для политики сохранности резервных копий (RETENTION POLICY) значение больше 1.
  • Устанавливать для параметра CONTROLFILE AUTOBACKUP значение ON и тем самым обеспечивать наличие автоматической резервной копии управляющего файла и, следовательно, возможность выполнения восстановления базы данных каталога в любое время.
  • Устанавливать очень высокое значение для параметра CONTROL_FILE_RECORD_KEEP_TIME, чтобы перезапись управляющего файла не происходила очень быстро и тем самым не приводила к скоропостижному стиранию данных репозитория RMAN.

Обратите внимание, что помимо создания обычных резервных копий базы данных каталога восстановления с помощью утилиты RMAN, можно также создавать и логические резервные копии этого каталога утилитой Data Pump Export.

 

Восстановление каталога восстановления

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

Если резервные копии каталога восстановления не были подготовлены или были сделаны, но использовать их невозможно (например, из-за того, что какие-то их части утрачены), каталог восстановления потребуется воссоздавать заново.

Воссоздавать каталог восстановления можно одним из следующих способов.

  • Выполнив команду RESYNC CATALOG для обновления каталога восстановления с использованием информации репозитория, содержащейся в управляющем файле целевой базы данных. Конечно, любые устаревшие метаданные будут утеряны навсегда.
  • Выполнив команду CATALOG START WITH… для повторного занесения в каталог восстановления любых доступных резервных копий.

 

Занесение резервных копий в каталог восстановления

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

RMAN> CATALOG DATAFILECOPY '/u01/old_backups/users01.dbf';

Для занесения в каталог восстановления сразу ряда файлов из определенного каталога в файловой системе служит команда CATALOG START WITH:

RMAN> CATALOG START WITH '/u01/old_backups/';

После отображения каждого файла RMAN будет ожидать подтверждения, прежде чем добавить его в каталог восстановления.

Обновление каталога восстановления до новой версии

В случае использования клиента RMAN из выпуска Oracle 11.1, а схемы каталога восстановления — из более старой версии, нужно обязательно выполнять процедуру обновления каталога восстановления до новой версии. Узнать номер версии схемы каталога восстановления можно с помощью следующего запроса:

SQL> SELECT * FROM rcver;
VERSION
---------
10.02.00

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

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

1. Если владелец каталога восстановления создавался в версии более ранней, чем 10.1, выполните следующую команду GRANT (где rman — имя владельца каталога):

SQL> GRANT CREATE TYPE TO rman;

2. Запустите RMAN и подключитесь к базе данных каталога восстановления:

RMAN> connect catalog rman/rman; 

3. Выполните команду UPGRADE CATALOG:

RMAN> UPGRADE CATALOG; 

4. Подтвердите команду, введя ее снова:

RMAN> UPGRADE CATALOG; 

После этого каталог восстановления вместе с клиентом RMAN можно будет использовать в Oracle Database 11g и 12с.

 

Импорт каталогов восстановления

Каталогов восстановления может быть несколько, и каждый из них может отвечать за базы данных, относящиеся к разным версиям Oracle. Если это так, тогда эти каталоги восстановления командой IMPORT CATALOG можно консолидировать в один каталог. По умолчанию эта команда импортирует метаданные всех баз данных, которые зарегистрированы в исходном каталоге восстановления, в целевой каталог восстановления. При желании ей можно явно указать, какие конкретно базы данных требуется импортировать в целевой каталог. По умолчанию RMAN отменяет регистрацию импортируемой базы данных в исходном каталоге восстановлении, но при желании можно делать так, чтобы импортируемые базы данных оставались в исходном каталоге, добавив к команде IMPORT CATALOG конструкцию NO UNREGISTER.

Целевые базы данных, базы данных каталогов восстановления и схемы каталогов восстановления могут происходить из разных версий Oracle. Компания Oracle, однако, рекомендует консолидировать все каталоги восстановления в один каталог со схемой самой последней версии. Команда IMPORT CATALOG помогает и в этом.

В следующем примере предполагается, что команду IMPORT CATALOG необходимо применить для объединения двух каталогов восстановления, один из которых происходит из версии 10.2, а второй — из версии 11g, в один общий каталог со схемой версии 11g. Необходимые шаги описаны ниже.

1. Подключитесь к целевому каталогу восстановления:

$ rman
RMAN> connect catalog rman/rman@rman11

2. Введите команду IMPORT CATALOG вместе с информацией о подключении к исходному каталогу восстановления (rman10), которая вводилась в первом шаге:

RMAN> import catalog rman1/rman1@rman10;
Starting import catalog at 30-MAR-08
connected to source recovery catalog database
import validation complete
database unregistered from the source recovery catalog
Finished import catalog at 30-MAR-08
RMAN>

По умолчанию команда IMPORT CATALOG импортирует все зарегистрированные базы данных из исходного каталога в целевой, но при желании можно также указать конкретную базу или базы данных:

RMAN> import catalog rman10/rman10@tenner
dbid = 123456, 1234557;
RMAN> import catalog rman10/rman10@tenner
db_name = testdb, mydb;

Здесь первый пример демонстрирует, как указывать один или более идентификаторов подлежащих импорту баз данных (Database ID — DBID), а второй — как передавать имена баз данных, которые нужно импортировать. Оба способа позволяют ограничивать операцию импорта конкретными базами данных.

 

Перемещение каталога восстановления

Перемещать каталог восстановления в другую базу данных можно с помощью команды IMPORT CATALOG. Перед выполнением команды IMPORT CATALOG потребуется создать пустой каталог в целевой базе данных.

Ниже показан пример применения команды IMPORT CATALOG для перемещения каталога восстановления:

$ rman
RMAN> connect catalog rman/rman@target_db
RMAN> import catalog rman10/rman10@source_db;

Выполнение этой команды приведет к перемещению содержимого каталога восстановления в целевую базу данных, а точнее — к импорту содержимого каталога восстановления из базы данных source_db в каталог, находящийся в базе данных target_db.

 

Удаление каталога восстановления

Для удаления каталога восстановления служит команда DROP CATALOG:

RMAN> DROP CATALOG;

В случае удаления каталога восстановления командой DROP CATALOG сами созданные RMAN резервные копии будут оставаться нетронутыми. В управляющих файлах целевой базы данных будут содержаться записи обо всех последних сделанных RMAN резервных копиях. Воссоздав каталог восстановления и зарегистрировав целевую базу данных, существующие резервные копии можно будет снова делать пригодными для использования в операциях RMAN.

 

Виртуальные частные каталоги (VIRTUAL CATALOG)

После регистрации различных баз данных в каталоге восстановления от имени владельца этого каталога обязательно приходится предоставлять разрешения на получение к нему доступа каким-то пользователям. Даже если пользователю требуется доступ только к одной или двум базам данных, не остается ничего иного, кроме как разрешать ему доступ ко всем базам данных, которые были зарегистрированы в каталоге. Для улучшения безопасности в Oracle рекомендуют создавать один центральный каталог, называемый базовым каталогом восстановления, и регистрировать в нем все базы данных, которыми нужно управлять, а затем создавать каталоги поменьше, называемые виртуальными частными каталогами, и позволять через них получать доступ лишь к определенным наборам баз данных. По сути, под виртуальным частным каталогом подразумевается просто набор синонимов и представлений, основанных на данных базового каталога восстановления, но хранящихся в схеме владельца виртуального частного каталога. Это позволяет обслуживать единственный каталог восстановления, как и раньше, но при этом также обладать возможностью предоставлять пользователям доступ лишь к его отдельным подмножествам через виртуальные частные каталоги.

Прежде чем создавать виртуальный каталог, сначала потребуется создать владельца этого каталога. Затем можно приступить непосредственно к созданию самого виртуального частного каталога. Следующие подразделы посвящены созданию владельца и собственно виртуального частного каталога.

Создание владельца виртуального частного каталога

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

1. Запустите SQL*Plus и подключитесь к базе данных каталога восстановления от имени пользователя, обладающего привилегиями администратора (SYS).

Например:

SQL> connect sys/sammyy1 as sysdba

2. Выполните следующий оператор для создания владельца виртуального частного каталога:

SQL> CREATE USER virtual1 IDENTIFIED BY virtual1
DEFAULT TABLESPACE virtual_tbsp1

3. Назначьте новому владельцу роль RECOVERY_CATALOG_OWNER:

SQL> GRANT recovery_catalog_owner TO virtual1;
Start RMAN and connect as the base recovery catalog owner:
RMAN> CONNECT CATALOG rman/rman@catdb 

4. Чтобы новый владелец виртуального каталога восстановления мог работать с базами данных, предоставьте ему необходимые привилегии:

RMAN> GRANT CATALOG FOR DATABASE prod1 to virtual1;

Показанная выше команда подразумевает выдачу владельцу виртуального частного каталога virtual1 прав на управление базой данных prod1. Команда GRANT CATALOG предусматривает разрешение пользователю virtual1 только получать доступ к базе данных prod1. При желании разрешить новому пользователю еще и регистрировать новые базы данных в виртуальном каталоге, которым он владеет, нужно использовать команду REGISTER DATABASE:

RMAN> GRANT REGISTER DATABASE TO virtual1;

Теперь, когда новый владелец виртуального частного каталога создан, можно переходить к созданию непосредственно самого виртуального частного каталога.

 

Создание виртуального частного каталога

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

1. Подключитесь к базе данных базового каталога восстановления от имени нового владельца виртуального каталога. Например:

RMAN> CONNECT CATALOG virtual1/virtual1@catdb;

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

RMAN> CREATE VIRTUAL CATALOG; 

Теперь пользователь virtual1 может начинать работать с виртуальным частным каталогом и получать доступ только к одной базе данных prod1.

 

Удаление виртуального частного каталога

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

RMAN> DROP CATALOG; 

Лишение доступа, предоставленного через виртуальный частный каталог

Команда REVOKE CATALOG позволяет лишать владельца виртуального частного каталога доступа к той или иной базе данных:

RMAN> REVOKE CATALOG FOR DATABASE prod1 FROM virtual1;

В этой команде можно указывать как имя базы, доступа к которой требуется лишить (как показано здесь), так и ее идентификатор.

Лишать владельца виртуального частного каталога права регистрировать новые базы данных в виртуальном частном каталоге (и, следовательно, в базовом каталоге восстановления тоже) можно с помощью следующей команды:

RMAN> REVOKE REGISTER DATABASE FROM virtual1;

Примеры сценариев выполнения резервного копирования при помощи RMAN

В следующих подразделах данной статьи моего блога приводится несколько примеров типичных сценариев выполнения резервного копирования посредством RMAN.

Резервное копирование всей базы данных с помощью RMAN

Для выполнения резервного копирования всей базы данных служит команда BACKUP DATABASE. При выдаче этой команды RMAN автоматически создает резервную копию всех файлов данных, которые являются частью базы данных, как показано в листинге 3:


RMAN> BACKUP DATABASE;
Starting backup at 06-JUN-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=C:\ORALE\PRODUCT\10.1.0\ORADATA\ORCL\SYSTEM01.DBF
input datafile fno=00003 name=C:\ORALE\PRODUCT\10.1.0\ORADATA\ORCL\SYSAUX01.DBF
input datafile fno=00005 name=C:\ORALE\PRODUCT\10.1.0\ORADATA\ORCL\EXAMPLE01.DBF
input datafile fno=00002 name=C:\ORALE\PRODUCT\10.1.0\ORADATA\ORCL\UNDOTBS01.DBF
input datafile fno=00004 name=C:\ORALE\PRODUCT\10.1.0\ORADATA\ORCL\USERS01.DBF
. . .
Starting Control File Autobackup at 06-JUN-08
piece handle=C:\ORACLE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\ORCL\AUTOBACKUP\2005_06
_06\O1_MF_N_539094997_0PJ8FDBF_.BKP comment=NONE
Finished Control File Autobackup at 06-JUN-08
RMAN>

 

Резервное копирование архивных журналов

Для выполнения резервного копирования всех архивных журналов, для которых еще раньше никогда не создавалась резервная копия, применяется команда BACKUP ARCHIVELOG ALL. Команда BACKUP DATABASE PLUS ARCHIVELOG служит для резервного копирования всех файлов данных плюс любых существующих файлов архивных журналов повторного выполнения, как показано в листинге 4 ниже:


RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
Starting backup at 06-JUN-08
current log archived
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=38 devtype=DISK
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=4 recid=1 stamp=539702327
. . .
16\O1_MF_ANNNN_TAG20041016T132206_0Q2SPK4S_.BKP comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:05
Finished backup at 06-JUN-08
RMAN>


На заметку! Если база данных функционирует в режиме ARCHIVELOG, файлы журналов повторного выполнения постоянно архивируются, что, следовательно, избавляет от необходимости выполнять резервное копирование файлов оперативных журналов повторного выполнения. На самом деле утилита RMAN даже не позволяет выполнять резервное копирование оперативных журналов повторного выполнения. Наилучшим способом защиты оперативных журналов от отказа носителя является их мультиплексирование с созданием дубликатов на разных дисках, которые подключены к разным дисковым контроллерам. Без копии потеря оперативного журнала чревата потерей данных.


 

Выполнение резервного копирования в оперативном режиме с использованием сценария RMAN

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


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


В листинге кода 6 ниже приведен типичный сценарий, предусматривающий выполнение посредством RMAN нескольких операций резервного копирования в оперативном режиме с сохранением резервных копий на диске.


RMAN> RUN {
# резервное копирование базы данных с сохранением резервной копии на диске
ALLOCATE CHANNEL d1 TYPE DISK;
ALLOCATE CHANNEL t2 TYPE DISK;
ALLOCATE CHANNEL t3 TYPE DISK;
# резервное копирование всей базы данных
BACKUP
TAG whole_database_open
FORMAT '/u01/oradata/backups/db_%t_%s_p%p'
DATABASE;
# переключение текущего файла журнала
SQL 'alter system archive log current';
# резервное копирование архивных журналов
BACKUP
ARCHIVELOG ALL
FORMAT '/u11/oradata/backups/al_%t_%s_p%p';
# резервное копирование экземпляра управляющего файла
BACKUP
CURRENT CONTROLFILE
TAG = cf1
FORMAT '/u12/oradata/backups/cf_%t_%s_p%p';
RELEASE channel d1;
RELEASE channel d2;
RELEASE channel d3;
}
RMAN>

 

Резервное копирование управляющего файла

Для выполнения резервного копирования управляющего файла применяется команда BACKUP CURRENT CONTROLFILE, как показано в листинге кода 7 ниже:


RMAN> BACKUP CURRENT CONTROLFILE;
Starting backup at 06-JUN-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current controlfile in backupset
channel ORA_DISK_1: starting piece 1 at 06-JUN-08
channel ORA_DISK_1: finished piece 1 at 06-JUN-08
piece handle=C:\ORALE\PRODUCT\10.1.0\FLASH_RECOVERY_AREA\NEWS\BACKUPSET\2005_06_
06\O1_MF_NCNNF_TAG20041016T132630_0Q2SYTM3_.BKP comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
Finished backup at 06-JUN-08
RMAN>

Если было настроено автоматическое создание резервных копий управляющего файла командой CONTROLFILE AUTOBACKUP ON, может выполняться процедура резервного копирования всей базы данных, предусматривающая копирование всех файлов данных, файлов журналов и управляющего файла в том числе, с помощью RMAN-команды BACKUP DATABASE PLUS ARCHIVELOG, как показывалось ранее в листинге выше.

 

Резервное копирование табличного пространства

Для резервного копирования отдельных табличных пространств, которое может выполняться только в случае, если база данных функционирует в режиме архивирования журналов (ARCHIVELOG), применяется команда BACKUP TABLESPACE:

RMAN> BACKUP TABLESPACE USERS;

 

Резервное копирование файла данных с помощью RMAN

Для резервного копирования одного файла данных служит команда BACKUP DATAFILE имя_файла, в которой при желании можно указать конкретное целевое место для размещения резервной копии файла. Если конкретное место не указано, RMAN будет сохранять файлы резервных копий в области пакетного восстановления. Ниже приведен пример использования этой команды:

RMAN> BACKUP DATAFILE '/u01/orcl/oradata/system01.dbf';

 

Перезапуск процедуры резервного копирования в RMAN

В случае прерывания процедуры резервного копирования в RMAN, ее выполнение можно возобновить с того же места, где она была прервана, а не начинать выполнять заново. Предположим, что каждый день выполняется какая-то операция резервного копирования, и последний раз выполнение этой операций прервалось на середине. Показанная ниже команда позволит легко возобновить ее с места прерывания:

RMAN> BACKUP DATABASE NOT BACKED UP SINCE TIME 'SYSDATE-1';

Обратите внимание, что команда BACKUP DATABASE NOT BACKED UP SINCE TIME будет приводить к выполнению резервного копирования только тех файлов, которые не успели пройти процедуру резервного копирования до этого.

 

Указание лимитов по длительности выполнения резервного копирования

Иногда еженощное резервное копирование сказывается на производительности какого-то критически важного задания базы данных. Для облегчения подобной ситуации можно заставить базу данных тратить больше времени на выполнение резервного копирования за счет использования в RMAN-команде BACKUP параметра DURATION. В случае использования параметра DURATION утилита RMAN будет вычислять наиболее подходящую для задания скорость выполнения резервного копирования. Кроме того, можно добавлять свои собственные директивы и тем самым указывать базе данных либо сводить к минимуму время выполнения резервного копирования (MINIMIZE TIME), либо сводить к минимуму загрузку системы (MINIMIZE LOAD).

В частности, за счет применения конструкции DURATION в связанных с резервным копированием командах вроде BACKUP AS COPY можно указывать, сколько конкретно времени (в часах и минутах) Oracle следует тратить на выполнение резервного копирования:

DURATION <часов>:<минут> [PARTIAL] [MINIMIZE {TIME|LOAD}]

Доступные параметры описаны ниже.

  • PARTIAL. Позволяет перекрывать принятое по умолчанию поведение RMAN в случае выхода процедуры резервного копирования за рамки указанного временного интервала. Эта конструкция предотвращает генерацию утилитой RMAN сообщений об ошибках.
  • MINIMIZE TIME. Указывает утилите RMAN завершать резервное копирование как можно быстрее.
  • MINIMIZE LOAD. Указывает утилите RMAN замедляться, если она укладывается в рамки выделенного для резервного копирования времени.

На заметку! При желании использовать параметр MINIMIZE LOAD лучше сохранять резервные копии на диске, потому что в случае сохранения резервных копий на ленте наверняка потребуется, чтобы процедура резервного копирования завершалась как можно быстрее.


В общем, главное запомнить, что параметр PARTIAL в конструкции DURATION позволяет предотвращать появление ошибок в случае превышения указанного лимита времени, параметр MINIMIZE TIME — делать так, чтобы задание выполнялось максимально быстро, а параметр MINIMIZE LOAD — сводить к минимуму потребление ресурсов системы.

Ниже приведен пример применения конструкции DURATION:

RMAN> BACKUP AS COPY
2> DURATION 04:00
3> MINIMIZE TIME DATABASE;

В этом примере конструкция DURATION указывает следующее.

  • Ограничить время выполнения резервного копирования четырьмя часами (DURATION 04:00).
  • Выполнить резервное копирование на полной скорости, чтобы оно завершалось до истечения выделенного четырехчасового лимита (MINIMIZE TIME), если возможно.
  • Провести резервное копирование всей базы данных (DATABASE).

 

Резервное копирование с инкрементным обновлением

Функция резервного копирования с инкрементным обновлением позволяет создавать копии образов файлов и применять к ним процедуры инкрементного резервного копирования, тем самым продвигая или накатывая исходные копии образов вперед до момента, когда была сделана инкрементная резервная копия уровня 1. При выполнении восстановления обновленная инкрементным образом копия образа может использоваться так, будто бы она является самой настоящей копией образа, сделанной во время инкрементного резервного копирования. Применение процедур резервного копирования с инкрементным обновлением представляет собой революционный прорыв в стратегиях резервного копирования, поскольку позволяет всегда иметь в распоряжении доступную обновленную копию образа независимо от того, когда была сделана первая полная резервная копия уровня 0. Команда, которую необходимо использовать для выполнения резервного копирования с инкрементным обновлением, выглядит так:

RMAN> BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY
WITH TAG 'incr-update' LEVEL 0 DATABASE;

Эта команда будет приводить к созданию инкрементной резервной копии уровня 1 и обновлению уже существующей полной резервной копии уровня 0, т.е., по сути, к обновлению предыдущей резервной копии уровня 0 до состояния, в котором она должна пребывать на текущий день.

В листинге 7 показан сценарий, который можно использовать для настройки выполнения резервного копирования с инкрементным обновлением.


RMAN> RUN {
RECOVER COPY OF DATABASE WITH TAG 'incr_update';
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE;
}

В этом сценарии команда RECOVER COPY заставит RMAN применять любые инкрементные резервные копии уровня 1 к набору копий файлов данных с таким же дескриптором. Команда BACKUP будет приводить к созданию инкрементной резервной копии уровня 1. При первом запуске сценария, однако, в случае отсутствия существующей резервной копии уровня 0, эта команда будет приводить к созданию резервной копии уровня 0 для выполнения роли начальной точки в стратегии инкрементного резервного копирования.

В частности, при выполнении данного сценария происходит следующее.

  • В первый день команда BACKUP будет приводить к созданию резервной копии уровня 0, поскольку таковой еще не существует.
  • Во второй день команда BACKUP будет приводить к созданию инкрементной резервной копии уровня 1.
  • В третий и каждый последующий день команда RECOVER COPY будет приводить к применению к резервной копии уровня 0 резервных копий уровня 1 и тем самым постоянно обновлять ее.

Использование сценария, приведенного в листинге 7, избавит от необходимости вручную применять к исходной резервной копии уровня 0 многочисленные инкрементные резервные копии. Каждый день из-за применения к исходной резервной копии уровня 0 сделанной за этот день инкрементной резервной копии (уровня 1) она будет становиться полной резервной копией уровня 0 за этот день. Проводить еще одну процедуру полного резервного копирования базы данных не потребуется. При необходимости в выполнении восстановления достаточно будет воспользоваться самой последней резервной копией уровня 0, которая будет представлять собой версию, обновленную в соответствии со всеми инкрементными резервными копиями уровня 1, произведенными с момента создания первой резервной копии уровня 0, и затем применить к ней архивные журналы.

 

Быстрое инкрементное резервное копирование

Во время процедур инкрементного резервного копирования Oracle потребуется сканировать всю базу данных. Это делает процедуры инкрементного резервного копирования излишне долгими.

Для отслеживания физического местонахождения всех изменений в блоках базы данных применяется файл отслеживания изменений, который впервые появился в версии Oracle Database 10g. Утилита RMAN считывает этот файл для выяснения того, какие именно блоки данных ей надлежит прочитать и скопировать, и тем самым избегает необходимости считывать все файлы данных, что позволяет значительно сократить время, затрачиваемое на выполнение резервного копирования.

Записью информации об изменениях в блоках в файл отслеживания изменений занимается фоновый процесс записи отслеживаемых изменений (Change Tracking Writer — CTWR), представляющий собой еще один механизм, который впервые появился в Oracle Database 10g.

 

Включение функции отслеживания изменений в блоках

При желании отслеживать изменения в блоках, нужно явно включить соответствующую функцию, как показано ниже:

SQL> ALTER DATABASE
2 ENABLE BLOCK CHANGE TRACKING
3 USING FILE '/u01/oradata/finance/changetrack.log';
Database altered.
SQL> 

Изменением имени или места размещения файла отслеживания изменений осуществляется оператором ALTER DATABASE RENAME FILE (перед переименованием этого файла необходимо удостовериться в том, что база данных находится в режиме монтирования):

SQL> ALTER DATABASE RENAME FILE
'/u01/app/oracle/finance/changetrack.log'
TO
'/u02/app/oracle/finance/changetrack.log';
Database altered.
SQL>

Для отключения функции отслеживания изменений в блоках служит такой оператор:

SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
Database altered.
SQL> 

 

Наблюдение за работой функции отслеживания изменений в блоках

Мониторинг функции отслеживания изменений в блоках осуществляется через представления V$BLOCK_CHANGE_TRACKING и V$BACKUP_DATAFILE.

В представлении V$BLOCK_CHANGE_TRACKING можно просматривать информацию об имени, размере и состоянии файла отслеживания изменений, как показано в следующем примере:

SQL> SELECT filename,status,bytes
2 FROM v$block_change_tracking;
FILENAME                                         STATUS  BYTES
------------------------------------------------ ------- ---------
/U01/APP/ORACLE/ORADATA/FINANCE/CHANGETRACK.LOG  ENABLED 11599872
SQL>

В представлении V$BACKUP_DATAFILE по соотношению значений в столбцах BLOCKS_READ и DATAFILE_BLOCKS можно определить, сколько блоков (в процентах) приходится считывать Oracle. Если разница между значениями в этих столбцах является слишком большой, возможно, требуется проводить резервное копирование чаще.

 

Сжатие резервных копий в RMAN

При необходимости экономить пространство создаваемые RMAN резервные копии можно сжимать. Степень сжатия зависит от того, данные какого рода содержатся в файлах данных. В Oracle рекомендуют пользоваться встроенной в RMAN функцией сжатия, а не внешней утилитой сжатия. Применять обе вместе ни в коем случае нельзя.


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


Команда, которую в RMAN можно использовать для сжатия набора резервных копий, выглядит так:

RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;

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

SQL> SELECT fname, compressed, backup_type
FROM v$backup_files;

По заявлениям Oracle встроенная в RMAN технология двоичного сжатия способна позволять сокращать объем занимаемого файлом резервной копии пространства приблизительно на 50–75%.

 

Создание архивных резервных копий RMAN

Иногда бывает необходимо подготовить резервную копию для долгосрочного хранения. Преследуемой при этом целью является не обеспечение возможности однажды использовать эту резервную копию для восстановления базы данных, а обеспечение возможности применить эту резервную копию для восстановления того вида, в котором данные находились на момент ее создания. Кроме того, создание подобной резервной копии может требоваться исключительно для соблюдения установленных регуляторных норм. Резервные копии подобного рода называются архивными резервными копиями (archival backup) или долгосрочными резервными копиями (long-term backup) и, как правило, сохраняются на устройствах типа магнитных лент за пределами сайта.

Для создания долгосрочных резервных копий достаточно указать в команде BACKUP конструкцию KEEP. Эта конструкция делает так, чтобы на резервную копию не распространялось действие сконфигурированной в текущий момент политики сохранности резервных копий (RETENTION POLICY). Она указывает утилите RMAN делать резервную копию всех файлов данных, управляющего файла и файла SPFILE. Помимо этого, RMAN также автоматически генерирует и резервную копию архивных журналов повторного выполнения для обеспечения возможности восстановления базы данных до согласованного состояния. Преобразовать существующую резервную копию в архивную можно за счет применения команды CHANGE, а также указать, что резервная копия должна храниться бесконечно, применив в команде BACKUP или CHANGE конструкцию KEEP FOREVER, или, наоборот, ограничить время ее хранения конструкцией KEEP UNTIL TIME.

Ниже приведен пример создания долгосрочной архивной резервной копии. В этом примере дополнительно используется конструкция RESTORE POINT для указания SCN-номера, до которого должно осуществляться восстановление базы данных для того, чтобы она считалась согласованной. Этого SCN-номер захватывается непосредственно после создания резервных копий файлов данных. Утилита RMAN будет сохранять данную точку восстановления столько же времени, сколько и саму архивную резервную копию.

Перед созданием архивной резервной копии устанавливается соединение с целевой базой данных и каталогом восстановления. Устанавливать соединение с каталогом восстановления требуется только в случае, если планируется использование конструкции KEEP FOREVER; если планируется применять просто конструкцию KEEP, устанавливать соединение с каталогом восстановления не нужно.

RUN
{
ALLOCATE CHANNEL ch1
DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=archival_backup)';
BACKUP DATABASE
TAG quarterly
KEEP FOREVER
RESTORE POINT FY08Q2;
}

Этот код предполагает генерацию резервной копии всех файлов данных и архивных журналов, а также создание точки восстановления, до которой должно проводиться восстановление базы данных. Конструкция KEEP FOREVER указывает, что эта резервная копия должна храниться бесконечно. При желании ограничить срок сбережения резервной копии, достаточно указать вместо конструкции KEEP FOREVER конструкцию KEEP UNITL TIME:

RUN
{
ALLOCATE CHANNEL ch1
DEVICE TYPE sbt
PARMS 'ENV=(OB_MEDIA_FAMILY=archival_backup)';
BACKUP DATABASE
TAG quarterly
KEEP UNTIL TIME 'SYSDATE+365'
RESTORE POINT FY08Q2;
}

Теперь этот код указывает, что резервная копия должна храниться на протяжении 365 дней, после чего становится устаревшей и, следовательно, пригодной для удаления.

 

Ограничение размера резервных копий, создаваемых с помощью RMAN

С помощью параметра MAXSETSIZE можно ограничивать максимальный размер создаваемого RMAN набора резервных копий. Ограничивать набор резервных копий до определенного размера удобно потому, что это позволяет в случае прерывания выполняемой RMAN операции резервного копирования воспользоваться поддерживаемой RMAN возможностью перезапуска процесса резервного копирования и подвергнуть резервному копированию только те файлы, которые не успели его пройти до прерывания. Ниже приведен пример, показывающий, как ограничить размер набора резервных копий:

RMAN> BACKUP DEVICE TYPE sbt
MAXSETSIZE 250M
ARCHIVELOG ALL;

Вдобавок можно использовать параметр SECTION SIZE для создания многосекционной резервной копии, под которой подразумевается такой набор резервных копий, в котором каждый фрагмент резервной копии содержит блоки из одной секции подвергаемого резервному копированию файла. Этот параметр удобно использовать для выполнения параллельного резервного копирования очень большого файла данных. Ниже приведен пример применения параметра SECTION SIZE:

RMAN> BACKUP
SECTION SIZE 250M
TABLESPACE TEST;

Предположим, что размер табличного пространства TEST составляет 1 Гбайт. Тогда настройка четырех каналов sbt (установка для отвечающего за параллельное выполнение параметра устройства SBT значения 4) позволит разбить процесс на четыре параллельных потока и тем самым значительно улучшить показатели производительности.

 

Шифрование резервных копий, создаваемых с помощью RMAN

Для резервных копий RMAN можно конфигурировать два вида шифрования: прозрачное шифрование, настраиваемое командой CONFIGURE ENCRYTPION, и двухрежимное шифрование или шифрование на основе пароля, конфигурируемое по команде SET ENCRYPTION на уровне сеанса RMAN. В этом разделе приводятся шаги, которые служат для настройки этих двух видов шифрования.

Для настройки шифрования резервных копий в прозрачном режиме достаточно выдать команду CONFIGURE, как показывалось ранее в этой статье. После настройки соответствующего постоянного параметра конфигурации все последующие резервные копии будут делаться в шифрованном виде.

Что касается шифрования на основе пароля, то шаги, требуемые для его настройки, выглядят следующим образом.

1. Подключитесь к целевой базе данных через RMAN.

RMAN> connect target /
connected to target database: ORCL (DBID=1170903133)
using target database control file instead of recovery catalog
RMAN>

2. Выполните команду SET ENCRYPTION ON IDENTIFIED BY PASSWORD ONLY, как показано ниже:

RMAN> set encryption on identified by sammyy1 only;
executing command: SET encryption
RMAN>

Ключевое слово ONLY указывает RMAN применять шифрование на основе пароля даже в случае, если ранее с помощью команды CONFIGURE ENCRYPTION было сконфигурировано прозрачное шифрование. Любые создаваемые далее резервные копии будут обязательно шифроваться.


Совет. Поскольку шифрование с применением бумажника Oracle Wallet не подразумевает использования никаких паролей, оно является безопаснее шифрования на основе пароля. Вдобавок оно упрощает перенос табличных пространств.


Под двухрежимным шифрованием подразумевается защита данных одновременно как прозрачным шифрованием, так и шифрованием на основе пароля. Для настройки такого шифрования применяются те же шаги, что и для настройки шифрования на основе пароля, но только без ключевого слова ONLY.

Следует иметь в виду, что шифрование резервных копий RMAN сопровождается дополнительным потреблением ресурсов ЦП. Для смягчения этой проблемы можно выполнять операции резервного копирования, предусматривающие шифрование резервных копий, с использованием нескольких каналов RMAN.

 

Наблюдение за заданиями RMAN и проверка состояния резервных копий

Следить за выполняемыми RMAN операциями резервного копирования можно посредством нескольких важных представлений словаря данных. Представления V$BACKUP_CORRUPTION и V$COPY_CORRUPTION, например, предоставляют важную информацию о поврежденных блоках. (О повреждении блоков данных более подробно будет рассказываться позже в этой статье, в разделе “Обнаружение повреждений в базе данных”.) Представление V$RMAN_OUTPUT позволяет наблюдать за выполнением заданий RMAN.

Представление V$RMAN_STATUS отображает сведения о состоянии всех выполненных заданий и команд, как показано ниже:

SQL> SELECT operation, status, start_time, end_time
FROM v$rman_status;
OPERATION      STATUS   START_TIME   END_TIME
---------   ---------   ----------   ---------
LIST        COMPLETED    28-APR-08   28-APR-08
VALIDATE    COMPLETED    28-APR-08   28-APR-08
BACKUP         FAILED    28-APR-08   28-APR-08
BACKUP      COMPLETED    29-APR-08   29-APR-08
. . .
SQL>

Выдав запрос к представлению V$SESSION_LONGOPS, можно получить информацию о ходе выполнения операций резервного копирования:

SQL> SELECT TO_CHAR(start_time,'DD-MON-YY HH24:MI') "Start of backup",Sofar,
totalwork, elapsed_seconds/60 "ELAPSED TIME IN MINUTES",
ROUND(sofar/totalwork*100,2) "Percentage Completed so far"
FROM v$session_longops
WHERE opname='prod1_dbbackup';

Для проверки того, что подготовленные RMAN резервные копии пригодны для использования во время восстановления, служат команды CROSSCHECK и VALIDATE, о чем более подробно рассказывается в следующих подразделах.

 

Применение команды CROSSCHECK

Утилита RMAN поддерживает полезную команду CROSSCHECK, которая позволяет проверять, действительно ли наборы резервных копий и копии образов, перечисленные в каталоге восстановления, существуют в указанных местах, и не были ли они случайно удалены или перезаписаны. Вдобавок она также позволяет проверить правильность заголовков и удостовериться в том, что RMAN действительно может читать файлы. Таким образом, команда CROSSCHECK позволяет тестировать как наличие резервных копий, так и их читабельность. Ниже приведен пример применения команды CROSSCHECK в RMAN:

RMAN> CROSSCHECK BACKUPSET 326;
allocated channel: ORA_DISK_1
. . .
channel ORA_DISK_4: sid=21 devtype=DISK
crosschecked backup piece: found to be 'AVAILABLE'
Crosschecked 1 objects
RMAN>

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

 

Применение команды VALIDATE

Утилита RMAN помогает обнаруживать как физические, так и логические повреждения. Когда она сталкивается с повреждениями блоков того или иного рода, она заносит информацию об этом в управляющий файл и каталог восстановления. Команда VALIDATE позволяет удостоверяться в том, что подвергаемые резервному копированию файлы действительно существуют в надлежащих местах и что они являются читабельными и не содержат никаких логических и физических повреждений. Для тестирования одного конкретного набора резервных копий достаточно использовать эту команду следующим образом:

RMAN> VALIDATE BACKUPSET 9;

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

RMAN> BACKUP VALIDATE DATABASE ARCHIVELOG ALL; 

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

Например, выполнение следующей команды не приведет к восстановлению никаких файлов данных; вместо этого будет проведена проверка содержимого наборов резервных копий на предмет восстанавливаемости:

RMAN> RUN {
ALLOCATE CHANNEL d1 TYPE DISK;
RESTORE DATABASE VALIDATE;
{

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

Команду BACKUP_VALIDATE можно применять только на уровне наборов данных, в то время как команду VALIDATE — на уровне и наборов резервных копий, и табличных пространств, и файлов данных, и даже блоков данных. Последнюю команду можно применять для проверки целостности области пакетного восстановления. Ее удобно выполнять периодически в профилактических целях для своевременного выявления любых недостающих файлов данных или поврежденных блоков данных. RMAN заносит информацию о любых неполадках, которые обнаруживает во время выполнения команды VALIDATE, в ADR (Automatic Diagnostic Repository — репозиторий автоматической диагностики), после чего их можно легко просматривать и устранять через интерфейс Data Recovery Advisor (Помощник по восстановлению данных). Хотя по умолчанию команда VALIDATE предусматривает выполнение проверки только на предмет наличия физических повреждений в блоках данных (также по-другому называемых повреждениями между блоками — interblock), при желании в ней можно указать конструкцию CHECK LOGICAL и тем самым обеспечить проведение проверки на предмет наличия логических повреждений (по-другому называемых повреждениями внутри блоков — intrablock).

Ниже приведен пример применения команды VALIDATE DATABASE для выполнения проверки на предмет повреждений в блоках данных на уровне базы данных:

RMAN> VALIDATE DATABASE;
Starting validate at 01-APR-08
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=155 device type=DISK
. . .
channel ORA_DISK_1: validation complete, elapsed time: 00:17:07
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
1    OK     0              12542        72960           4351550
File Name: C:\ORCL11\APP\ORACLE\ORADATA\ORCL11\SYSTEM01.DBF
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data       0              48959
Index      0              9143
Other      0              2316
. . .
including current control file for validation
including current SPFILE in backup set
channel ORA_DISK_1: validation complete, elapsed time: 00:00:02
List of Control File and SPFILE
===============================
File Type    Status Blocks Failing Blocks Examined
------------ ------ -------------- ---------------
SPFILE       OK     0              2
Control File OK     0              594
Finished validate at 01-APR-08
RMAN>

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *