Rman настройка резервного копирования на диск
Конфигурация БД для RMAN бэкапа – ч.1 – постоянные настройки, тип устройства и тип бэкапа (дискового) по умолчанию
Предполагается, что взятие бэкапа базы данных с помощью Менеджера Восстановления должно быть простым. Поэтому для большинства параметров, необходимых для бэкапа с RMAN, установлены разумные значения по умолчанию, которые позволят Вам делать простые бэкапы и восстановление без существенной настройки или конфигурирования.
Однако, при выполнении стратегии бэкапа, осуществляемой посредством RMAN, Вы можете использовать Менеджер Восстановления более эффективно при условии, что Вы понимаете наиболее распространенные опции, доступные для Вас. Большая часть из них может быть установлена в среде RMAN на постоянной основе, так что Вам не потребуется указывать одни и те же опции каждый раз при выполнении команды.
Далее рассмотрим, как можно изменить поведение RMAN по умолчанию для удовлетворения требованиям вашей стратегии бэкапа и восстановления, а также основные настройки, которые Вы можете изменить, и их наиболее распространенные возможные значения.
Статья охватывает следующие вопросы:
1-3. Копирование базы
Простое копирование базы данных.
Копирование всей базы
Выполнение копирования всей базы данных с помощью команды backup:
Просмотр информации об копии
Если в выводимой информации требуется отображать время, можно определить формат даты, используя переменную среды NLS_DATE_FORMAT:
4-2. Конфигурирование RMAN
Данную команду можно выполнить как из командной строки, тем самым изменив единственный параметр, так и объединив несколько команд конфигурации в блок RUN, что позволит изменить сразу несколько настроек:
При выполнении команды CONFIGURE установленные значения параметров будут применяться ко всем следующим сеансам RMAN, пока не будут очищены или изменены этой же командой.
1-2. Подключение к RMAN
Локальное подключение
Подключение подразумевает, что вы вошли в операционную систему, используя учётную запись oracle.
Локальное подключение с использованием имени и пароля
При подключении используется файл паролей.
Удалённое подключение
Подключение возможно только для пользователей с sysdba привилегией или пользователей использующих файл паролей.
1-5. Восстановление базы данных
Требуется восстановить базу данных после произошедшего сбоя. Учитываем, что имеется не повреждённая резервная копия, а так же имеются все контрольные файлы, архивные и оперативные журналы.
Восстановление всех файлов базы данных из копии
Для восстановления базы данных необходимо смонтировать экземпляр и запустить команду restore database:
Команда восстановила файлы данных из резервной копии.
Применение изменений к файлам базы данных
Следующим шагом осуществляется применение изменений в базе данных произошедших в интервал времени с момента создания резервной копии и до времени сбоя:
4-12. Пропуск ранее скопированных в файлов
Резервное копирование большой по объёму базы данных может занимать довольно значительное время. Если имеются ранее сделанные резервные копии файлов данных, то этот промежуток времени можно сильно сократить, осуществив пропуск этих файлов в процессе резервного копирования. Реализацию этого механизма в RMAN организует функция оптимизации резервного копирования (backup optimization). По умолчанию она выключена. Её включение осуществляется следующей командой:
Оптимизация применяется к трем типам файлов: файлам данных, архивным журналам и резервным наборам. Для того что бы оптимизация заработала, должны быть соблюдены следующие условия:
-
Должны выполняться команды BACKUP DATABASE и BACKUP ARCHIVELOG с опциями ALL или LIKE, BACKUP BACKUPSET с опцией ALL, BACKUP RECOVERY AREA, BACKUP RECOVERY FILES и BACKUP DATAFILECOPY.
Все каналы для команд резервного копирования должны иметь один и тот же тип.
Для примера, выполним резервное копирование архивных журнальных файлов:
Было скопировано три файла с sequence от 20 до 21. Переключим несколько раз текущий журнал и снова выполним ту же команду:
Как видно, RMAN пропустил сохранённые ранее в другом наборе архивные журналы с sequence от 20 до 22, и добавил новые с sequence от 23 до 25.
Если пропуск файлов осуществлять не нужно, а оптимизация включена, то на время определённого RMAN сеанса её можно выключить. Для этого в команде резервного копирования необходимо устанавить опцию force. Пропуск файлов при этом осуществляться не будет:
В данном примере RMAN осуществил полное резервное копирование всех журналов с sequence от 20 до 26, несмотря на то, что оптимизация включена в настройках RMAN.
RMAN использует определенные правила для каждого типа пропускаемого файла, чтобы определить, идентичен ли текущий файл ранее скопированной версии. Например, у файла данных должны быть тот же самый DBID и контрольная точка SCN. Точно так же у архивных журналов должны быть равны DBID, номер потока и порядковый номер. У резервного набора должны быть равны ID записи и штамп.
Однако, тот факт, что файлы идентичны, вовсе не означает, что они будут пропущены. Когда RMAN обнаруживает идентичный файл, то он становиться лишь кандидатом на оптимизацию. RMAN должен вначале рассмотреть политику сохранения и множественность резервных копий для того чтобы решить, достаточно ли резервных копий файла содержится на данном устройстве, прежде чем осуществить его пропуск. Этот алгоритм оптимизации может варьироваться в зависимости от типа резервируемого файла или факта копирования резервных комплектов. Ниже привидены общие правила режима оптимизации для разных типов файлов и резервного комплекта.
Файлы данных
Если используется политика сохранения на основе окна, то тип резервных носителей определяет, пропустит ли RMAN файл данных. Если резервное копирование осуществляется на ленту и последняя резервная копия является более старой чем сконфигурированное окно восстановления, RMAN сделает резервное копирование, даже не смотря на то, что файл будет идентичен. Таким образом, RMAN игнорирует настроенную политику оптимизации. Если резервное копирование будет осуществляться на диск, то если имеется идентичная резервная копия, файл будет пропущен, даже несмотря на то, что последняя копия будет старее окна восстановления. Поясним это на примере. Допустим, имеется копия табличного пространства только для чтения, сделанная две недели назад. По идее оно не должно меняться. Определено окно сохранения длительностью 7 дней. Если делается резервное копирование на ленту, то RMAN сделает копию, несмотря на то, что файлы не изменились. Если резервирование будет осуществляться на диск, то резервирование файлов будет пропущено, даже несмотря на то, что копия явно старее определённого окна сохранения.
Если будет использоваться политика сохранения, основанная на избыточности (например, избыточность равна r), то RMAN пропустит копирование файла, если n (определённое как r + 1) копий этого файла будут существовать на указанном устройстве.
Если политики сохранения нет, RMAN пропустит резервное копирование файла, если n число копий это файла существует на указанном устройстве. RMAN определяет значение n в порядке следующего приоритета:
- Число резервных копий при использовании команды BACKUP . COPIES n
- Число резервных копий при использовании команды SET BACKUP COPIES n
- Число резервных копий при использовании КОМАНДЫ CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE . TO n
- n=1
Архивные журналы
В случае архивных журналов RMAN определит значение n в порядке следующего приоритета:
- Число резервных копий при использовании команды BACKUP . COPIES n
- Число резервных копий при использовании команды SET BACKUP COPIES n
- Число резервных копий при использовании команды CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE . TO n
- n=1
Резервные наборы
Для резервных наборов значение n определяется в порядке следующего приоритета:
- Число резервных копий при использовании команды BACKUP . COPIES n
- Число резервных копий при использовании команды SET BACKUP COPIES n
- n=1
Чтобы два резервный комплекта в режиме оптимизации считались идентичным, у них должны соответствовать ID записи и штамп.
У медиа менеджеров могут быть свои собственные политики сохранения. Поэтому, RMAN может иногда пропускать файлы согласно своему алгоритму оптимизации, а медиа менеджер, согласно своему алгоритму. Чтобы избежать несоответствия, следует чаще выполнять команду crosscheck, чтобы синхронизировать репозитарий RMAN с метаданными медиа менеджера.
4-4. Включение и выключение автоматического резервирования контрольного файла
Изменения, помещаемые RMAN в контрольный файл и содержание инициализационного файла параметров, могут критично влиять на возможность восстановления базы данных. Для того чтобы не потерять эту важную информацию, в RMAN имеется возможность автоматического резервного сохранения этих двух файлов при операциях резервного копирования. Включить такой режим можно следующей командой:
или сбросить значение параметра в режим по умолчанию:
По умолчанию автоматическое резервное копирование контрольного файла отключено. Но даже тогда, когда эта опция отключена RMAN всегда сохранит контрольный файл и файл параметров в случаях резервного копирования, затрагивающих файл данных 1, принадлежащий целевой базе данных. Данный файл является частью системной области, которая содержит словарь базы данных.
Oracle рекомендует, чтобы режим автоматического сохранения контрольного файла был включен, если не используется каталог восстановления.
При включенном режиме RMAN поддержит автоматическое сохранение контрольного файла в следующих случаях:
- При успешном завершении команд BACKUP или COPY.
- После того как из командной строки RMAN выполнена команда CREATE CATALOG.
- При любых структурных изменениях базы данных модифицирующих содержимое контрольного файла.
Резервируемые файлы сохраняются в отдельный резервный набор.
Что касается последнего случая, то здесь необходимо уточнить, что любые изменения в физической структуре базы данных, даже если они делаются, к примеру, через SQL*Plus инициируют автоматическое сохранение контрольного файла. Эти изменения могут включать в себя, например добавление табличного пространства или файла данных, удаление файла данных, переключение табличного пространства в офлайн или онлайн, добавление оперативного журнала, переименование файла данных и т.д. После того как изменение произошло, серверный процессc Oracle (не процесс RMAN) автоматически создаст копию контрольного файла и двоичного файла инициализационных параметров (spfile).
Почему необходимо автоматически поддерживать контрольный файл после изменений структуры базы данных? Как только автоматическое резервирование контрольного файла будет включено, RMAN может восстановить базу данных, даже если текущий файл управления, каталог восстановления, и файл параметра сервера будут недоступны.
Следующие шаги демонстрируют этапы этого восстановления:
- Вначале RMAN восстановит серверный файл параметров из местоположения, где он был сохранён автоматически.
- Затем RMAN запустит экземпляр базы данных, используя этот файл параметров.
- Потом восстанавливается контрольный файл из того же местоположения, где и файл параметров.
- Как только контрольный файл смонтировался, RMAN будет соединяться с целевой базой данных в nocatalog режиме и использовать репозитарий RMAN из контрольного файла, чтобы восстановить файлы данных и базу данных.
- Здесь можно создать новый каталог восстановления и зарегистрировать в нём целевые базы данных.
- RMAN скопирует все записи репозитария RMAN из контрольных файлов целевых баз данных в новый каталог восстановления.
Эта последовательность восстановления показывает важность конфигурирования автоматического резервирования контрольного файла.
4-11. Конфигурация множественных резервных копий
В процессе резервного копирования, RMAN создаёт на одном устройстве части резервного набора в единственном экземпляре. Это режим по умолчанию. Однако в RMAN имеется возможность записи частей резервного набора сразу в несколько копий.
Следующая команда определяет, что при резервном копировании (архивные журналы, файлы данных, контрольные файлы) на диск должны быть сделаны две копии частей резервного набора: RMAN> configure datafile backup copies for device type disk to 2;
То же самое можно определить и для резервного копирования на ленту:
Если требуется, чтобы копии частей резервного набора писались не на одно физическое устройство, а на несколько (для большей надёжности), то можно сконфигурировать дисковый канал соответствующим образом, указав эти устройства в команде конфигурации. В результате копии резервных частей будут записаны через дисковый канал сразу в несколько мест (устройств). В следующем примере дисковый канал конфигурируется так, что при резервном копировании каждая копия части резервного набора помещается в отдельный каталог:
Выполним резервное копирование:
Как видно, при выполнении команды BACKUP вначале были получены две копии первого резервного набора. Одна копия была помещена в каталог /backup1, вторая в /backup2. Затем были получены две копии второй резервного набора, которые были помещены в те же каталоги.
Для ленточного канала, если поддерживается версия 2 SBT API, RMAN автоматически поместит каждую копию на отдельную ленту.
В качестве каталога назначения множественных резервных копий нельзя использовать флэш- область восстановления.
Множественные резервные копии можно получить только из резервных наборов. Нельзя получить множественные копии сразу для нескольких копий-отображения. Для начала надо создать одну копию-отображение, и только лишь потом из неё можно будет сделать сразу несколько копий.
Для проверки конфигурации RMAN на предмет установки множественных резервных копий, можно использовать следующие команды.
Для файлов данных:
Для архивных журнальных файлов:
4-3. Восстановление значений параметров по умолчанию
Если команда конфигурации не будет явно использоваться, чтобы определить значение каких- либо параметров RMAN, то RMAN будет использовать для этих параметров значения по умолчанию. При использовании команды configure . clear, можно возвратить изменённое значение отдельного параметра конфигурации в значение по умолчанию:
Данной командой невозможно очистить отдельные параметры, влияющие на определенный компонент RMAN. Например, если сконфигурирован канал с несколькими опциями, невозможно стереть отдельные опции командой configure . clear, таким образом, следующая команда не выполниться:
Вместо неё можно использовать следующую команду:
4-13. Определение имен файлов частей резервных копий
По умолчанию RMAN определяет названия файлов резервных частей в одном определённом формате. Если необходимо определить свои имена файлов получаемых копий, то для этого можно воспользоваться опцией format команды резервного копирования, как показано в следующем примере:
В данной опции, кроме указания непосредственного имени файла, можно указывать переменные замены, что позволяет сформировать более понятное имя. Если же опция format использоваться в команде не будет, RMAN автоматически сгенерирует уникальное имя для каждой резервной копии. При этом стоит учитывать, что некоторые из медиа менеджеров могут иметь свои ограничения на формат имени файла, например длину.
В дополнение к опции format, для генерации уникальных имён файлов копий-отображения, можно использовать параметр инициализации db_file_name_convert. Синтаксис значения этого параметра аналогичен синтаксису, задаваемому в опции format.
4-5. Определение каталога и имени файла при автоматическом резервировании контрольного файла
Если контрольный файл или файл параметров инициализации утеряны, RMAN может легко восстановить базу данных в случае включенного режима автосохранения этих файлов. По умолчанию, при включенной флэш-области восстановления, RMAN сохраняет резервные копии этих файлов в данную область. Когда область отключена, RMAN записывает копии в зависящее от операционной системы специфическое местоположение ($ORACLE_HOME/dbs для Unix и %ORACLE_HOME %\database для Windows). Местоположение можно переопределить, используя для этого команду конфигурирования:
Определяя имя файла, следует включать переменную %F в имя файла. Её использование позволяет получить уникальную комбинацию, состоящую из ID базы данных, дня, месяца, года и последовательности, что не позволит затереть более старые копии.
Для получения путей местоположения по умолчанию, достаточно очистить параметр следующей командой:
По умолчанию, все резервные копии RMAN делаются в несжатом формате. Однако можно сконфигурировать RMAN так, что при резервировании будут создаваться сжатые резервные наборы, причём не важно в каком месте, на диске или ленте. Следующая команда RMAN конфигурирует сжатое резервное копирование на диск:
Для того чтобы вернуться к несжатому резервному набору по умолчанию, достаточно в вышеприведённых командах опустить ключевое слово compressed:
RMAN использует бинарное сжатие для резервных сжатых наборов. Это позволяет уменьшить передаваемый трафик по сети в момент резервного копирования. К тому же, когда идёт восстановление из сжатого резервного набора, нет необходимости предварительно распаковывать его, всё происходит на «лету». Это сильно экономит время, в отличии от упаковщиков операционной системы.
Для версии Oracle 11G функция сжатия не ограничивается использованием только одного алгоритма. Можно запросить представление V$RMAN_COMPRESSION_ALGORITHM для просмотра доступных алгоритмов сжатия:
Как видно, алгоритм BZIP2 обеспечивает хорошее сжатие но меньшую скорость. В то же время алгоритм ZLIB обеспечиватет баланс между скоростью и сжатием.
Посмотреть используемый текущий алгоритм сжатия можно с помощью следующей команды:
В версии 11.2 это базовый алгоритм BASIC не требующий опции Advanced Compression.
Конфигурация Типа Бэкапа по Умолчанию для Дисковых Бэкапов
Вы можете сконфигурировать наборы бэкапов или копии образы по умолчанию, используя любую из следующих команд:
Настройка по умолчанию для бэкапов на диск, как и на ленту, – это набор бэкапов. Заметьте, что аналогичной опции для устройств медиа менеджеров не существует, поскольку RMAN может писать бэкапы на устройства медиа менеджеров только в виде наборов бэкапов.
Использование FRA и RMAN – ч.3 – настройка политики сохранения бэкапов на основе окна восстановления или избыточности
1-4. Симуляция отказа
Следующий пример демонстрирует симуляцию отказа базы данных, путём переименования одного из файлов базы данных, и последующее восстановление базы данных из резервной копии.
Просмотр расположения файлов базы данных
Для начала определим местоположение будущего переименованного файла (example01.dbf). Это можно сделать с помощью команды RMAN report schema:
Остановка базы данных
Остановим базу данных:
Переименование файла базы данных
Для симуляции отказа базы данных переименуем файл example01.dbf:
Запуск базы данных
Стартуем повреждённую базу данных:
База данных не сможет быть открыта пока файл данных example01.dbf не будет восстановлен.
Как Oracle Управляет Дисковым Пространством в Мгновенной Области Восстановления
Oracle не удаляет пригодные для удаления файлы из мгновенной области восстановления, пока пространство не понадобится для некоторой другой цели. В результате файлы, недавно перенесенные на ленту, часто бывают по прежнему доступны на диске для использования в восстановлении. Область восстановления таким образом может служить как своего рода кэш для ленты. Как только FRA становится полной, Oracle автоматически удаляет пригодные для удаления файлы, чтобы освободить пространство в мгновенной области восстановления, при необходимости.
Когда Файлы являются Пригодными для Удаления из Мгновенной Области Восстановления
Существуют относительно простые правила, управляющие тем, когда файлы становятся пригодными для удаления из мгновенной области восстановления:
- Постоянные файлы никогда не являются пригодными для удаления.
- Файлы, которые являются устаревшими согласно политике сохранения, пригодны для удаления.
- Временные файлы, которые были скопированы на ленту, доступны для удаления.
- В среде Data Guard политика удаления архивных журналов транзакций управляет тем, когда архивные redo журналы могут быть удалены из FRA.
Когда Пространство Мгновенной Области Восстановления Не Доступно
Если, к примеру, политика сохранения RMAN требует хранения набора бэкапов большего суммарного размера, чем дисковая квота мгновенной области восстановления, или политика сохранения установлена в NONE, то FRA может заполнится окончательно, не имея пространства, которое можно было бы освободить.
База данных генерирует предупреждение, когда пространство, пригодное для освобождения, меньше 15%, и критическое предупреждение, когда это пространство меньше 3%. Чтобы предупредить DBA об этом обстоятельстве, добавляется запись в журнал предупреждений, а также в таблицу DBA_OUTSTANDING_ALERTS (используемую Энтерпрайз Менеджером). Однако, база данных продолжает потреблять место в мгновенной области восстановления до тех пор, пока места, которое еще можно освободить, не останется совсем.
Когда область восстановления окончательно заполнится, Вы получите ошибку:
где nnnnn – это требуемое количество байтов, а mmmm – это дисковая квота для FRA.
База данных обрабатывает мгновенную область восстановления с недостаточным количеством места, пригодного для освобождения, в точности так же, как она обрабатывает обстоятельство заполненного диска. Часто, но не всегда, результатом будет зависание базы данных. Например, если FRA является одним из ваших обязательных местоназначений архивирования журналов транзакций, и база данных не может заархивировать новый журнал из-за того, что область восстановления заполнена, то архиватор может, в зависимости от вашей конфигурации, начать пытаться архивировать периодически, пока место области восстановления не освободится.
Для большинства задач резервного копирования, настроек по умолчанию, таких как тип резервного копирования (диск или лента), количество каналов и степень параллелизма, вполне достаточно. Но для более сложных задач, может понадобиться дополнительно, настроить окружение RMAN. Сделать это можно двумя способами:
- Установить параметры конфигурации постоянными для всех сеансов RMAN.
- Изменить параметры только для определённого задания резервного копирования или восстановления.
4-1. Просмотр параметров конфигурации RMAN
Для вывода текущих значений параметров конфигурации, в RMAN используется команда SHOW. Если требуется вывести значение только одного конкретного параметра, то для этого достаточно указать его имя сразу после ключевого слова этой команды:
Для вывода значений всех параметров RMAN, вместо имени параметра указывается ключевое слово ALL:
Ниже перечислены некоторые опции команды SHOW:
Опция | Описание |
---|---|
all | Показывает значения всех параметров |
archivelog deletion policy | Показывает политику удаления журнальных файлов. |
archivelog backup copies | Показывает число резервных копий журналов. |
auxname | Показывает имя вспомогательного экземпляра. |
backup optimization | Показывает использование оптимизации при резервном копировании. |
[auxiliary] channel | Показывает конфигурацию канала. |
channel for device type [disk | ] | Показывает характеристики канала. |
controlfile autobackup | Показывает, включено ли автоматическое копирование контрольного файла. |
controlfile autobackup format | Показывает формат автоматического копирования контрольного файла. |
datafile backup copies | Показывает число сохраняемых резервных копий файла данных. |
default device type | Показывает тип устройства по умолчанию. |
encryption algorithm | Показывает алгоритм шифрования, используемый в настоящее время. |
encryption for [database | tablespace] | Показывает шифрование для базы данных и каждого табличного пространства. |
exclude | Показывает табличные пространства, исключённые из резервного копирования. |
maxsetsize | Показывает максимальный размер для резервных наборов. Значение по умолчанию неограниченно. |
retention policy | Показывает политику удержания для резервных копий. |
snapshot controlfile name | Показывает снимок контрольного файла |
Для вывода значений параметров конфигурации RMAN команда SHOW запрашивает контрольный файл базы данных. Данные параметры всегда хранятся в этом файле независимо от того, используется ли каталог восстановления или нет. После того, как была произведена конфигурация окружения RMAN, настройки сохраняются в репозитарии контрольного файла, пока не будут изменены следующей командой конфигурации. Такое хранение требует, чтобы целевая база данных была смонтирована или открыта при выполнении команды SHOW.
Ниже перечислены самые важные из настроек отображаемые командой SHOW ALL:
- configure retention policy to redundancy 1 - RMAN сохраняет только один набор резервных копий.
- configure backup optimization off – оптимизация при резервном копировании выключена.
- configure default device type to disk - устройство по умолчанию для резервного копирования диск.
- configure controlfile autobackup off – автоматическое резервное копирование контрольного файла выключено.
- configure device type disk parallelism 1 backup type to backupset – по умолчанию для устройства резервного копирования диск включена степень параллелизма 1, и образующаяся резервная копия будет по умолчанию резервным набором.
- configure datafile backup copies for device type disk to 1 – по умолчанию RMAN делает одну копию файлов данных.
- configure maxsetsize to unlimited – по умолчанию максимальный размер резервного набора не определён.
- configure encryption for database off – по умолчанию режим шифрования базы данных при резервном копировании выключен.
Настройки не по умолчанию можно так же посмотреть в динамическом представлении V$RMAN_CONFIGURATION:
Постоянные Настройки Конфигурации: Управление Поведением RMAN
Для упрощения постоянного использования RMAN для бэкапа и восстановления, Менеджер Восстановления позволяет Вам настроить ряд постоянных настроек конфигурации для каждой целевой базы данных. Эти настройки контролируют многие аспекты поведения RMAN при работе с этими базами данных, такие как политика сохранения бэкапов, местоназначения по умолчанию для бэкапов на ленту или на диск, тип устройства бэкапа по умолчанию (лента или диск), и так далее.
Значения по умолчанию для этих конфигурационных настроек позволят Вам эффективно использовать RMAN без изменения какого-либо из этих значений. Однако, в том случае, если Вы разрабатываете более продвинутую стратегию бэкапа и восстановления, Вам потребуется изменить данные настройки, чтобы реализовать эту стратегию. Используйте команды RMAN SHOW и CONFIGURE для просмотра и изменения настроек конфигурации RMAN.
Отображение Текущих Настроек Конфигурации RMAN: SHOW
Команда SHOW используется для отображения текущего значения одной или всех настроек конфигурации RMAN, а также, установлены ли они в значение по умолчанию или нет.
После того, как Вы подключитесь к целевой БД и каталогу восстановления (если Вы его используете), запустите команлу SHOW с именем настройки, которую Вы хотели бы просмотреть. Например:
RMAN> SHOW RETENTION POLICY; RMAN> SHOW DEFAULT DEVICE TYPE; |
Команда SHOW ALL показывает текущие настройки всех параметров, которые Вы можете установить с помощью команды CONFIGURE . Вывод включает как параметры, которые Вы модифицировали, так и параметры, которые по прежнему установлены в свои значения по умолчанию.
Чтобы просмотреть все конфигурационные настройки, запустите команду RMAN SHOW ALL , как в этом примере:
Примерный вывод для SHOW ALL следующий:
Конфигурация отображается как ряд команд RMAN, необходимых для пересоздания конфигурации. Вы можете сохранить вывод SHOW ALL в текстовый файл и использовать этот командный файл для пересоздания конфигурации для той же самой или другой целевой базы данных.
Восстановление Настроек Конфигурации RMAN По Умолчанию: CONFIGURE… CLEAR
Вы можете вернуть любую настройку к ее значению по умолчанию, используя CONFIGURE… CLEAR , как в этих примерах:
Конфигурирование Сжатых Наборов Бэкапов для Ленты или Диска
Вы можете сконфигурировать RMAN для использования сжатых наборов бэкапов по умолчанию на конкретном типе устройства, применив команду CONFIGURE DEVICE TYPE с опцией BACKUP TYPE TO COMPRESSED BACKUPSET , как показано в следующих примерах.
Чтобы отключить сжатие, используйте команду CONFIGURE DEVICE TYPE с аргументами, указывающими желаемые вами другие настройки, но пропуская ключевое слово COMPRESSED , как в следующих примерах:
Конфигурирование Типа Устройства по Умолчанию для Бэкапов
По умолчанию, RMAN посылает все бэкапы в определенную директорию операционной системы на диске. Вы также можете сконфигурировать RMAN, чтобы делать бэкапы на такой носитель как лента.
После настройки устройства sbt (т.е. ленты или системы управления носителем) в соответствии с инструкциями в документации по управлению носителем от вашего производителя, Вы можете сделать медиа менеджер (менеджер по управлению носителем) устройством по умолчанию:
После конфигурации типа устройства по умолчанию, бэкапы производимые любой командой BACKUP, которые не указывают тип устройства назначения, направляются на сконфигурированный тип устройства по умолчанию. Например, следующие команды произвели бы несколько бэкапов на ленте:
Чтобы сконфигурировать диск в качестве устройства по умолчанию для бэкапов, Вы можете либо использовать CONFIGURE… CLEAR , чтобы вернуть настройку по умолчанию, либо явно сконфигурировать устройство по умолчанию, как показано далее:
4-14. Определение имен файлов для копий-отображения
Кроме задания имен файлов резервных частей, в RMAN можно так же изменять и имена файлов копий-отображения. Делается это всё с помощью той же опции format. Синтаксис опции аналогичен синтаксису, задаваемому для резервных частей, но есть небольшие различия, касающиеся переменных замены. Формат по умолчанию %U отображается по разному для копий- отображения файлов данных, архивных журналов и контрольных файлов. Следующая таблица демонстрирует это:
Тип файла | Значение %U |
---|---|
Файл данных | data-D-%d_id-%I_TS-%N_FNO-%f_%u |
Архивные файлы | arch-D_%d-id-%I_S-%e_T-%h_A-%a_%u |
Контрольные файлы | cf-D_%d-id-%I_%u |
В команде можно определить до четырех строк опции формата, но со второго по четвёртое значение они используются, если делаются множественные резервные копии. Таким образом, вторые, третьи, и четвертые значения опций формата используются, когда выполняются команды backup copies, set backup copies или configure . backup copies.
Как и в случае с частями резервных копий, для копий изображения можно использовать параметр db_file_name_convert, что бы сгенерировать собственные имена файлов. При использовании этой опции следует обеспечить пару префиксов имени файла, для того чтобы изменить названия выходных файлов. Первый префикс ссылается на имена файлов, которые копируются RMAN. Второй префикс ссылается на имена файлов для резервных копий. В следующем примере показано, как используя опцию db_file_name_convert можно определить новое имя файла копии отображения:
Как видно, при копировании табличного пространства users, из файла /u02/oradata/orcl/users01.dbf, на который ссылался первый префикс опции db_file_name_convert, была получена копия- отображение с именем указанным во втором префиксе.
Если опция db_file_name_convert будет использоваться в пределах команды резервного копирования, RMAN вначале использует пару имён из опции, что бы преобразовать имена файлов. Если это не удаётся сделать, будет осуществлена попытка назвать копию-отображения согласно опции формата. Если опция формата не используется, то RMAN будет использовать формат по умолчанию, то есть %U.
При попытке осуществить резервное копирование вашей базы данных с помощью RMAN у вас выдаётся ошибка:
Включение режима архивации базы данных
Проверка установки режима архивации
Для проверки установки режима архивации можно сделать следующий запрос к представлению V$DATABASE:
Команда archive log утилиты SQL*Plus так же показывает состояние режима архивирования. В дополнение она выводит информацию о режиме архивирования, состоянии флага автоматического архивирования, месте назначения архивных журнальных файлов и значениях последовательностей журналов.
Конфигурация Политики Хранения Бэкапов
Политика сохранения бэкапов указывает, какие бэкапы должны храниться для удовлетровения вашим требованиям восстановления данных. Эта политика может быть основана на окне восстановления (максимальное количество дней до момента в прошлом, вплоть до которого Вы можете восстановиться) или на избыточности (сколько копий каждого файла, взятого в бэкап, следует хранить).
Используйте команду CONFIGURE для установки политики сохранения.
Конфигурация Политики Хранения, Основанной на Окне Восстановления
Параметр RECOVERY WINDOW команды CONFIGURE указывает количество дней между настоящим моментом и ближайшей точкой восстанавливаемости. RMAN не считает какой-либо полный или инкрементальный бэкап уровня 0 устаревшим, если он попадает в пределы окна восстановления. В дополнение, RMAN хранит все архивные журналы и инкрементальные бэкапы уровня 1, которые необходимы для восстановления на произвольный момент времени внутри этого окна.
Запустите команду CONFIGURE RETENTION POLICY в командной строке RMAN. Этот пример гарантирует, что Вы сможете восстановить базу данных на любой момент в пределах последней недели:
RMAN не удаляет автоматически бэкапы, которые являются устаревшими для окна восстановления. Вместо этого Менеджер Восстановления показывает их как OBSOLETE (УСТАРЕВШИЕ) в выводе REPORT OBSOLETE и в столбце OBSOLETE представления V$BACKUP_FILES . RMAN удаляет устаревшие файлы, если Вы запускаете команду DELETE OBSOLETE .
Конфигурирование Политики Хранения, Основанной на Избыточности
Параметр REDUNDANCY команды CONFIGURE RETENTION POLICY указывает, сколько бэкапов каждого файла данных и контрольного файла следует хранить Менеджеру Восстановления. Другими словами, если количество бэкапов определенного файла данных или контрольного файла превышает настройку REDUNDANCY , RMAN рассматривает лишние бэкапы как устаревшие. Политика сохранения по умолчанию определяется как REDUNDANCY=1 .
По мере того, как Вы производите все больше бэкапов, RMAN продолжает следить, какие из них следует хранить, а какие являются устаревшими. RMAN хранит все архивные журналы транзакций и инкрементальные бэкапы, необходимые для восстановления неустаревших бэкапов.
Предположим, что Вы сделали бэкап файла данных 7 в Понедельник, Вторник, Среду и Четверг. Теперь у Вас есть четыре бэкапа файла данных. Если REDUNDANCY установлена в 2 , то бэкапы за Понедельник и за Вторник являются устаревшими. Если Вы сделаете другой бэкап в Пятницу, то бэкап за Среду становится устаревшим.
Запустите команду CONFIGURE RETENTION POLICY в сеансе RMAN, как в следующем примере:
Вывод Текущей Политики Хранения
Вы можете просмотреть текущую сконфигурированную политику сохранения с помощью команды SHOW RETENTION POLICY. Примерный вывод будет такой:
Отключение Политики Хранения
Когда Вы отключаете политику сохранения, RMAN перестает рассматривать любой бэкап как устаревший.
Чтобы отключить политику сохранения, запустите эту команду:
Установка политики сохранения в NONE не то же самое, что ее сброс. Ее сброс (или очистка) возвращает ее к настройке по умолчанию REDUNDANCY=1 , тогда как NONE отключает ее полностью.
Если Вы отключите политику сохранения и запустите REPORT OBSOLETE или DELETE OBSOLETE без указания в команде опции политики сохранения, RMAN сгенерирует ошибку, поскольку никакой политики сохранения не существует, чтобы можно было определить, какие бэкапы являются устаревшими.
Замечание: Если Вы используете мгновенную область восстановления, то Вам не следует запускать вашу базу данных с отключенной политикой сохранения. Если файлы никогда не становятся устаревшими, то файл может быть удален из FRA только в том случае, если он был взят в бэкап в каком-либо другом местоположении на диске или на третьеразрядном устройстве хранения, таком как лента. Вполне вероятно, что все пространство вашей области восстановления будет использовано. Это станет помехой нормальной работе вашей БД, как описано ниже (“Когда Пространство в Мгновенной Области Восстановления Не Доступно”). |
Читайте также: