Как запустить rman oracle

Обновлено: 06.07.2024

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

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

Требования к организации периодического резервного копирования (резервирование данных) не уникально для СУБД Oracle. Однако внутри СУБД возможно несколько различных вариантов организации резервирования. Рассмотрим возможности:

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

Основной способ создания резервных копий для БД, находящихся в промышленной эксплуатации - "горячее" резервирование без простоя сервиса, которое может быть реализовано двумя штатными для СУБД Oracle методами. Первым методом является использованием специального режима резервирования, в который могут переводиться табличные пространства (команды ALTER TABLESPACE . BEGIN|END BACKUP) с копированием файлов данных средствами ОС, и созданием копии контрольного файла (например, командой ALTER DATABASE BACKUP CONTROLFILE TO TRACE). Этот метод описан в расширенном руководстве по резервированию БД от производителя для версии 9, но работает и в последующих версиях. И этот метод позволяет создавать простые и ясные решения по резервированию БД

Техническими особенностями "горячего" резерва являются необходимость активации режима сохранения архивных журналов и необходимость сохранения таких журналов вместе с созданными резервными копиями БД - как минимум за время, захватывающее период от начала до окончания резервирования

Для режима ". BEGIN|END BACKUP . " существует ещё одна особенность - движок пишет в оперативные, а значит и архивные, журналы расширенную информацию. Если в обычном режиме в оперативные журналы заносится только информация об изменениях в блоках данных, но не блок целиком, то при переводе в режим бэкапирования информация о каждом блоке с момента включения режима сохраняется несколько иначе. При первом журналировании модификаций блок записывается целиком, а далее пишутся только изменения. Такая особенность нужна для обеспечения защиты от изменения блока в процессе копирования файлов данных средствами операционной системы

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

Вторым методом является использование специально поставляемой в составе движка утилиты RMAN, призванной несколько упростить процесс создания резервных копий и восстановления БД. Этот метод является рекомендованным производителем и описываемом в штатной документации. Однако он имеет и плюсы, и минусы

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

Кроме того RMAN использует контрольный файл или специально созданную БД для учёта всех сделанных копий, и существенно упрощает процедуру восстановления БД, а также интеграцию с механизмом создания "тёплого" резерва сервиса с помошью штатного для редакции EE (enterprise edition) механизма Data Guard. Ещё одним плюсом является возможность интеграции в RMAN драйверов ленточных библиотек, что позволяет делать резерв данных непосредственно на ленту и восстановление с ленты

Однако RMAN является дополнительной надстройкой и по опыту коллег автора может преподнести сюрпризы в процессе восстановления, вплоть до невозможности восстановления. А при создании "тёплого" резерва сервиса (стэндбая) для редакции SE (standart edition) СУБД возможны взаимные накладки с механизмом скриптового стэндбая

Ещё одним способом создания резерва является использование утилит выгрузки и загрузки дампа данных Export/Import. Строго говоря бэкапом использование таких утилит считать нельзя. Связано это с тем, что в процессе создания даже полного дампа базы данные выгружаются не все - а именно не экспортируется схема SYS, содержащая словарь данных, и являющаяся уникальной для каждой БД. Поэтому объекты в схеме SYS не охватываются экспортом/импортом и говорить о полном бэкапе базы не приходится. Основное назначение этих утилит - перенос данных из базы в базу между разными платформами и версиями, когда нельзя подложить файлы данных напрямую. Однако автор видел вариант организации бэкапа с помощью экспортных утилит, восстановление в этом случае предполагало ручное накатывание информации в схему SYS с последующим восстановлением экспортного дампа. Это затратный и не рекомендованный способ, и им лучше не пользоваться

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

Бэкап базы Oracle с помощью RMAN

Необходимо обеспечить наличие (бэкап) следующей вспомогательной информации:

- начального init файла (в случае использования не spfile, а не pfile необязательно)
- trace копии контрольного файла (необязательно)
- журнала работы RMAN (необязательно, для определения sequence архивных журналов, можно вытащить и из контрольного файла или выделенного каталога)

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

В принципе это все. Любые ручные процедуры типа ALTER TABLESPACE BACKUP START/STOP при использовании RMAN не требуются. Еще - грамотно также обеспечить резервирование созданного в предидущем пункте резервного набора на внешний носитель

backup scripts for Oracle RDBMS - по этой ссылке можно скачать разработанную мной скриптовую обвязку для организации типового бэкапа БД через RMAN

Восстановление из бэкапа с помощью RMAN

Вариант восстановление базы «с нуля» на другой хост под Windows (UNIX):

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

- создать initSID.ora и orapwdSID файлы для загрузки экземпляра. Если init из внешнего backup и отредактировать его для соответствия желаемому имен описанных файлов и каталогов
- создать требуемые каталоги (bd, arc, logs как минимум, а также наличие информации об экземпляре в oratab - файле)
- с помощью oradim (для Windows) создать экземпляр командами:
oradim -NEW -SID ; oradim -EDIT -SID -STARTUPMODE a -PFILE имя_pfile -SHUTMODE i -SHUTTYPE inst
и стартовать сервис Windows

- сконфигурировать и запустить listener, с помощью tnsping и lsnrctl->status проверить работу listener

- запустить экземпляр в режиме nomount, для чего:
подключиться sqlplus и сказать startup nomount
ри необходимости вначале сказать . oraenv
или export ORACLE_SID=. ; export ORACLE_HOME=. ; export ORACLE_NLS_LANG=. ; с корректными значениями вместо .

восстановить файлы БД, для чего:
смонтировать базу командой: alter database mount ;
при необходимости вывести данные о созданных бэкапах, сказать в RMAN команду list backup, при необходимости - сменить местоположение БД указать новое местоположение, восстановить файлы данных и изменить указатели на местоположение в контролфайле командным блоком RMAN, например:
run <
set newname for datafile 'e:\oradata\my_oracle_db\system01.dbf' to 'c:\my_oracle_db\system01.dbf' ;
set newname for datafile 'e:\oradata\my_oracle_db\undotbs01.dbf' to 'c:\my_oracle_db\undotbs01.dbf' ;
set newname for datafile 'e:\oradata\my_oracle_db\users01.dbf' to 'c:\my_oracle_db\users01.dbf' ;
set newname for datafile 'e:\oradata\my_oracle_db\my_oracle_db.ora' to 'c:\my_oracle_db\my_oracle_db.ora' ;
restore database ;
switch datafile all ;
>

восстановить и накатить архивные журналы ДБ, для чего:
определить последний номер архивного журнала, сделанного сразу после создания backup_set (т.к. данные для команды list backup выводится не будут, необходимо воспользоваться текстовым журналом работы RMAN)
восстановить архивные журналы, при необходимости указав новое местоположение командным блоком RMAN, например:
run <
set archivelog destination to 'c:\my_oracle_db\archive' ;
restore archivelog sequence ;
>
сказать в RMAN: recover database until sequence

открыть БД, для чего:
изменить полный путь к оперативным журналам при необходимости (если меняется место расположения оперативных журналов) командой: alter database rename file 'прежнее имя файла' to 'новое имя файла'. Имена файлов оперативных журналов можно увидеть в v$logfiles, изменить на корректные для каждого файла
сказать: alter database open resetlogs ;
создать временные табличные пространства, например посмотрев параметры из ручного trace_бэкапа controlfile
создать копии контрольного файла (тушим базу, делаем физическую копию, корректируем файл инициализации)

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

Клонирование (2006) базы с помощью RMAN

Одной из дополнительных возможностей RMAN является возможность дублирования базы на целевой сервер, отличный от исходного, в то же местоположение и с тем же именем

Примем, что исходный сервер содержит базу, которую предстоит сдублировать (target db в терминологии RMAN), а на целевой сервер предстоит сдублировать базу (auxiliary db в терминологии RMAN)

Для подготовки к дублированию необходимо:

сконфигурировать SQLNet для исходного сервера и целевого серверов
обеспечить на целевом сервере всю структуру каталогов для создаваемой базы (db, arc, logs)
обеспечить на целевом сервере initDBNAME.ora и orapwdDBNAME файлы для создаваемой базы
обеспечить на целевом структуру каталогов для размещения бэкапа RMAN, аналогичную структуре бэкапа RMAN на исходном сервере
обеспечить наличие на целевом сервере (в правильной структуре каталогов) RMAN бэкапа текущей инкарнации дублируемой базы
обеспечить на целевом структуру каталогов для размещения архивных журналов, аналогичную структуре архивных журналов на исходном сервере
обеспечить наличие на целевом сервере (в правильной структуре каталогов) наличия архивных журналов, сделаных после бэкапа, используемого для клонирования

В общем случае дублирование производится подключением RMAN к target и auxiliary базам и инициализацией дублирования командой duplicate:

connect target target TRG_SYS_USER/TRG_SYS_PASS@TRG_SQLNET_ALIAS
connect auxiliary AUX_SYS_USER/AUX_SYS_PASS@AUX_SQLNET_ALIAS
duplicate target database to AUX_DB_NAME nofilenamecheck
как вариант, коннект можно проводить сразу в командной строке
rman target TRG_SYS_USER/TRG_SYS_PASS@TRG_SQLNET_ALIAS \
auxiliary AUX_SYS_USER/AUX_SYS_PASS@AUX_SQLNET_ALIAS

Клонирование (дуплицирование 2017) базы с помощью RMAN

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

Для подготовки к дублированию необходимо реализовать немного меньший набор требований, чем ранее:

Далее проводится сама процедура дупликации через командный файл, содержащий RMAN скрипт дупликации

Проследить объём дуплицированного для ASM можно следующим запросом

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

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

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

Замечание:
Хотя Ретроспективная База Данных Oracle и гарантированные точки реставрации и не являются в действительности настоящими бэкапами базы данных, они могут быть важной составляющей вашей стратегии защиты данных. Эти возможности могут потребовать некоторой начальной установки, в зависимости от того, каким образом Вы включаете их в вашу стратегию бэкапа. В ближайшее время я планирую подробно описать, как настроить вашу базу данных для использования этих возможностей (подписаться на обновления блога по RSS/Email).

Обзор Взаимодействия с Клиентом RMAN

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

Запуск RMAN и Выход из него

У Вас есть несколько основных способов запуска RMAN:

Запуск испольнительного файла RMAN из командной строки ОС без указания каких-либо опций соединения, как в этом примере:
% rman
Запуск испольнительного файла RMAN из командной строки ОС с подключением к целевой базы данных и, возможно, к каталогу восстановления, как в этих примерах:
% rman TARGET /
% rman TARGET SYS/oracle@trgt NOCATALOG
% rman TARGET / CATALOG rman/cat@catdb

Чтобы выйти из RMAN и завершить программу, напечатайте EXIT или QUIT в командной строке RMAN (приглашение или подсказка Менеджера Восстановления выглядит как RMAN>). Например:

Установка Переменных Среды Поддержки Глобализации для RMAN

Перед тем, как использовать (invoking) RMAN, может оказаться полезным установить переменные среды NLS_DATE_FORMAT и NLS_LANG . Эти переменные определяют формат, используемый для параметров времени в комадах RMAN, таких как RESTORE , RECOVER и REPORT .

Следующий пример показывает типичные настройки языка и даты:

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

База данных, которая не смонтирована, предполагает кодировку по умолчанию, т.е. US7ASCII . Если ваша кодировка будет отличаться от кодировки по умолчанию, то RMAN возвращает ошибки после того, как база данных будет смонтирована. Например, если кодировка равна WE8DEC , Вы можете установить параметр NLS_LANG следующим образом:

NLS_LANG=american_america.we8dec

NLS_LANG и NLS_DATE_FORMAT должны быть установлены для использования NLS_DATE_FORMAT .

Ввод Команд RMAN в Командной Строке

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

Можно вводить команды, которые должен выполнить RMAN. Например:

Большинство команд RMAN имеют ряд параметров и должны оканчиваться точкой с запятой. (С несколькими исключениями, такими как STARTUP, SHUTDOWN и CONNECT, которые могут использоваться с или без точки с запятой.)

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

RMAN> BACKUP DATABASE
2> INCLUDE CURRENT
3> CONTROLFILE
4> ;

Использование Командных Файлов с RMAN

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

BACKUP DATABASE INCLUDE CURRENT CONTROLFILE;

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

% rman TARGET / @cmdfile1

После выполнения команды, приложение RMAN завершается.

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

RMAN> @cmdfile1

RMAN> **end-of-file**

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

Синтаксическая Проверка Команд RMAN и Командных Файлов: CHECKSYNTAX

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

Проверка Синтаксиса RMAN в Командных Файлах: Пример

Чтобы протестировать команды в командном файле, запустите RMAN с параметром CHECKSYNTAX и используйте аргумент @ для указания имени командного файла, который требуется разобрать. Например, используйте текстовый редактор для создания командного файла /tmp/goodcmdfile со следующим содержанием:

Также создайте другой командный файл, /tmp/badcmdfile , с таким содержанием:

Когда Вы запускаете командные файлы через RMAN с CHECKSYNTAX , вывод будет:

Владимир Пржиялковский,
координатор Евро-Азиатской Группы Пользователей Oracle,
преподаватель УКЦ Interface Ltd.

Введение

Программа RMAN появилась в версии 8 СУБД Oracle как единое для всех платформ средство организации резервного копирования и восстановления данных на физическом уровне. По отношению к традиционным базовым возможностям резервирования и восстановления в Oracle, у программы RMAN есть некоторые преимущества, делающие ее в некоторых ситуациях (например, при больших объемах данных) практически незаменимой. К сожалению, наличие этих преимуществ не лишает RMAN и ряда существенных недостатков: собственной системы понятий, собственного командного языка и интерфейса общения с администратором. И то, и другое, и третье выполнено в плохих традициях разработчиков Oracle – не вполне логично, запутано и непоследовательно, – что затрудняет освоение этой программы. Назначение этой статьи – помочь перешагнуть через эти недостатки ради выгод, которые можно извлечь из RMAN.

Возможности RMAN

Возможности RMAN включают следующее:

-	выполнение полного резервирования и резервирования изменений
-	выполнение холодного/горячего резервирования, причем во втором случае табличные пространства не переводятся в режим backup, что позволяет избежать дополнительной нагрузки на журнал
-	обнаружение поврежденных блоков
-	параллельное выполнения операций ввода/вывода
-	автоматическое протоколирование операций копирования и восстановления

Уровни выполнения резервного копирования/восстановления с помощью RMAN:

база данных
табличные пространства
файлы табличных пространств
служебные файлы БД (контрольные, архивные)

В число основных понятий RMAN входят следующие:

-	Канал (channel). Серверный процесс, возникающий при установлении связи с устройством ввода/вывода (диск или магнитная лента) для записи или чтения файлов резервирования
-	Целевая БД (target database). БД, для которой снимается резервная копия, или которая восстанавливается по ранее снятой копии
-	Каталог (recovery catalog). Отдельная схема в БД (чаще в отдельной БД), которую можно заводить для хранения служебная информации о целевых базах, снятых копиях и процедурах восстановления. Альтернативой каталогу является индивидуальная работа с каждой целевой БД, когда служебная информация помещается в контрольный файл этой БД.
-	Копия (RMAN backup). Резервная копия какого-нибудь элемента БД, получаемая командой RMAN backup.
-	Резервный набор (backup set). Логически именует набор файлов, сформированных во время резервного копирования.
-	Резервный файл (backup piece). Двоичный файл с резервной информацией.

Синтаксис командного языка RMAN в версии 9 имеет определенные отличия от версии 8, но все основные конструкции сохранены. Кроме этого, в RMAN для версии 9 допускается целый ряд упрощений записи команд.

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

В тексте ниже для лаконичности предпочтение будет отдаваться синтаксису версии 9. Кроме этого для простоты рассматривается работа без каталога RMAN.

Пример копирования и восстановления базы данных

Простейший пример снятия резервной копии (холодное копирование – вся БД – работа без каталога) иллюстрируется следующей последовательностью команд (здесь команда CONNECT TARGET соединяет RMAN с СУБД версии 8):

RMAN NOCATALOG
RMAN> CONNECT TARGET internal/oracle
RMAN> SHUTDOWN IMMEDIATE
RMAN> STARTUP MOUNT
RMAN> RUN 2> ALLOCATE CHANNEL d1 TYPE DISK;
3> BACKUP FULL FORMAT 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus'
4> DATABASE;
4> >
RMAN>

В каталоге D:\ORACLE\ORADATA\TEACHER\RMAN-BACKUP появился файл RMAN_ TEACHER _02DGA6F0_1_1.BUS (реальное имя может варьироваться). Теперь можно удалить файлы с табличными пространствами и выполнить восстановление:

RMAN> RUN 2> ALLOCATE CHANNEL d1 TYPE DISK;
3> RESTORE DATABASE;
4> RECOVER DATABASE;
5> ALTER DATABASE OPEN;
6> >

База восстановлена и открыта.

Упрощения в версии 9

В версии RMAN для версии 9 описанное выше резервирование можно было бы выполнить так:

RMAN> BACKUP DATABASE FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus';

а восстановление так:

RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;

Здесь подразумевается использование неявного канала по умолчанию, так что объявлять его стало необязательно.

Кроме этого в версии 9 появилась команда CONFIGURE, с помощью которой (помимо прочего) можно связать с каналом направление и маску имени файлов для резервного набора:

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus';

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

RMAN> BACKUP DATABASE;

Резервирование файлов базы данных

Горячее полное резервирование БД

-	может выполняться в состоянии СУБД OPEN
-	может выполняться только при включенном режиме архивирования журналов

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

RMAN> BACKUP DATABASE FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus';

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

Пример в синтаксисе версии 9.0:

RMAN> BACKUP TABLESPACE system, users FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus';

Полное резервирование отдельных файлов табличного пространства

Пример в синтаксисе версии 9.0:

RMAN> BACKUP DATAFILE 1, 2;

RMAN> BACKUP FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus'
3> 'd:\oracle\oradata\teacher\system01.dbf’,
4> 'd:\oracle\oradata\teacher\users01.dbf’;

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

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

Резервирование контрольного файла

Обычное резервирование контрольного файла приходится выполнять отдельно. Пример явного резервирования в синтаксисе версии 9.0:

RMAN> BACKUP CURRENT CONTROLFILE;

В версии 9 можно, однако, перевести RMAN в режим, когда копии контрольного файла будут сниматься автоматически при всякой выдаче команд BACKUP или COPY:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

Резервирование оперативных файлов журнала

Оперативные (онлайновые) файлы журнала автоматически не резервируются. Для сохранения либо следует их

а) копировать отдельно, либо
б) перед полным резервированием БД отправлять в архив.

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

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

RMAN> BACKUP ARCHIVELOG ALL;

Пример того, как в версии 9.0 архивные файлы можно включить в состав резервного набора БД:

RMAN> BACKUP DATABASE FORMAT
2> 'd:\oracle\oradata\teacher\rman-backup\rman_%U.bus' PLUS ARCHIVELOG;

Резервирование изменений (неполное резервирование)

Для резервирования изменений в Oracle используется традиционная многоуровневая модель с конкретным числом уровней копии 5 (от 0 до 4). Точкой отсчета для копирования изменений обязана стать снятая ранее полная копия БД уровня 0.

Пример резервирования блоков, изменившихся со времени резервирования на уровнях 3, 2, 1 и 0 (разностное, «дифференциального» резервирование) в синтаксисе версии 9:

RMAN> BACKUP INCREMENTAL LEVEL 3 DATABASE;

Пример резервирования блоков, изменившихся со времени последнего резервирования на уровнях 2, 1 и 0 (разностно-накопительное, «кумулятивное» резервирование) с пропуском табличных пространств, закрытых для записи (синтаксис версии 9):

RMAN> BACKUP INCREMENTAL LEVEL 3 CUMULATIVE DATABASE
2> SKIP READONLY;

Разностно-накопительное (кумулятивное) резервирование уровня N отличается от разностного (дифференциального) тем, что резервирует изменения произошедшие после выполнения резервирования всех уровней < N, в то время как просто разностное – изменения, произошедшие после резервирования уровней <= N.

Выдача справочной информации

Выполняется специальными командами LIST и REPORT, а также разновидностью команды RESTORE. Примеры приводятся ниже.

Выдача подробного списка всех снятых копий:

RMAN> LIST BACKUP;

Выдача списка резервных наборов, содержащих табличное пространство SYSTEM:

RMAN> LIST BACKUP OF TABLESPACE system;

Вариант выдачи того же самого, но в обобщенном виде (версия 9):

RMAN> LIST BACKUP OF TABLESPACE system SUMMARY;

Выдача информации о копиях, снятых с архивов журналов:

RMAN> LIST BACKUP OF ARCHIVELOG ALL;

Выдача резервных копий, оказавшихся устаревшими:

RMAN> REPORT OBSOLETE;

Выдача файлов с данными БД, для восстановления которых потребуются архивы журналов 2-х дневной давности и более:

RMAN> REPORT NEED BACKUP DAYS 2 DATABASE;

Те же сведения, но только для пространства SYSTEM:

RMAN> REPORT NEED BACKUP DAYS 2 TABLESPACE system;

Выдача информации о том, годны ли файлы резервного набора для восстановления:

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

Выполняется командой DELETE. В простейшем варианте удаление устаревших копий может выглядеть так:

RMAN> DELETE OBSOLETE;

Обратите внимание, что RMAN удалил ненужные файлы резервных наборов. Вам не нужно автоматизировать удаление старых файлов, как раньше!

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

RMAN> CROSSCHECK BACKUP;
…
RMAN> DELETE EXPIRED BACKUP OF DATABASE;
…
RMAN> DELETE BACKUP OF DATABASE;

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

RMAN> DELETE OBSOLETE RECOVERY WINDOW OF 14 DAYS;

Восстановление данных

NOMOUNT: для восстановления контрольных файлов БД (фактически – СУБД)

MOUNT: для восстановления БД целиком или табличного пространства SYSTEM

OPEN: для восстановление табличных пространств, помимо SYSTEM (в этом случае перед процедурой восстановления само табличное пространство потребуется перевести в состояние OFFLINE).

Восстановление до момента сбоя («последнего момента»)

Некоторые примеры восстановления:

RMAN> RECOVER DATABASE;

RMAN> RECOVER TABLESPACE users;

RMAN> RECOVER DATAFILE 'd:\oracle\oradata\teacher\users01.dbf’;

RMAN> RESTORE CONTROLFILE;

RMAN> RUN 2> SET ARCHIVELOG DESTINATION TO ‘d:\oracle\oradata\archive’;
3> RESTORE ARCHIVELOG ALL; >

Восстановление пространств, закрытых на запись:

RMAN> SQL "ALTER TABLESPACE lookup_data OFFLINE";
RMAN> RECOVER TABLESPACE lookup_data;
RMAN> SQL "ALTER TABLESPACE lookup_data ONLINE";

Восстановление до указанного момента в прошлом

БД, работающую в режиме архивирования журнала, можно восстанавливать до определенного указанного момента с помощью фраз UNTIL . Пример:

Восстановление БД (вторая и третья строчки выше) можно выполнить и в SQL*Plus:

SQL > RECOVER DATABASE UNTIL CANCEL;
SQL> ALTER DATABASE OPEN RESETLOGS;

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

Автоматизация задач

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

Пусть в файле listbackup.rcm находятся строки:

CONNECT TARGET /
LIST BACKUP;
EXIT

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

RMAN CMDFILE=listback.rcm NOCATALOG

RMAN @listback.rcm NOCATALOG

При использовании каталога RMAN возможно к тому же использование хранимого сценария:

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

Используя средства операционной системы.
Используя утилиты самой базы данных.

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

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

Встроенные утилиты базы данных для создания резервных копий – это прежде всего exp и expdp, позволяющие создавать логическую резервную копию (то есть копию объекта базы данных). Такой способ создания резервной копии прост, а основной его недостаток это время восстановления из копии в случае необходимости переустановки экземпляра и возможность восстановить объект только на конкретный момент осуществления бэкапа.

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

Утилита RMAN появилась в версии 8g и совершенствовалась в последующих. Настроим эту утилиту для регулярного создания резервных копий нашей базы данных.

табличные пространства;
управляющие файлы;
журналы повторного выполнения;
файлы данных (init.ora, spfile, tnsnames.ora, listener.ora, orapwd);

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

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

После того как мы определились с тем что копировать и с какой периодичностью можем переходить к настройке экземпляра базы данных. В первую очередь следует убедиться, что база данных функционирует в режиме архивирования журналов повторного выполнения (archivelog) проверить это можно запросом:
от любого пользователя с правами sysdba. Если запрос вернул archivelog то всё в порядке переходим к следующему пункту, если noarchivelog то нужно перезапустить базу в режиме archivelog. Для этого нужно перезапустить базу в режиме mount командой:
и выполнить команду
она активирует режим archivelog, после этого остаётся только открыть базу данных командой:

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

После того как мы перевели базу данных в режим archivelog необходимо задать ей параметры области пакетного восстановления. Проверим не заданы ли они уже запросом:
если не заданы то задаём командами:
задаёт максимальный размер области пакетного восстановления и
задаёт расположение области пакетного восстановления в файловой системе. Создание области пакетного восстановления необходимо для того что бы rman мог самостоятельно удалять устаревшие копии, а так же отслеживать оставшееся свободное дисковое пространство и предупреждать если его остаётся мало.

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

первым делом конфигурируем параметры сохранности резервных копий это делается либо параметром CONFIGURE RETENTION POLICY либо устанавливается количество копий которые одновременно хранятся, либо указывается период в который копия считается актуальной. Установим параметр recovery window равный 7 дням командой:
включим автобэкап контрл файла при каждом создании резервной копии будет создаваться копия контрл файла:
активируем оптимизацию что бы rman не создавал копии файлов уже существуют резервные копии идентичные существующей:
и распараллелим на 2 канала процесс создания резервной копии:
Параметры устройства на которое сохраняется информация, шифрования, сжатия, формат автобэкапа контрл файла и максимальный размер файла копии мы менять не будем.

После этой настройки остаётся только создать в операционной системе файлы выполнения для rman и добавить их в планировщик задач.

Для остальных дней:

Для восстановления всей базы данных после полного их изчезновения применяется команда RESTORE DATABASE, после её выполнения необходимо синхронизировать данные с помощью архивных журналов командой RECOVER DATABASE, восстановление происходит в режиме mount.

Для восстановления конкретного табличного пространства необходимо сначало перевести его в режим OFFLINE командой:

После этого выполнить его восстановление и синхронизацию:
По завершении перевести его в режим online командой:

Так же можно откатить базу данных на определённым момент времени назад для этого выполняется команда:

Это восстановление нужно делать когда база данных находится в режиме mount, а при открытии указать опцию RESETLOGS, что бы не выполнялись изменения сохранённые в журналах повторного выполнения созданные после точки восстановления.

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

ПыСы. Спасибо тем, кто увидтт свои решения в данном документе, за предаставленную информацию.

Прошу коментариев спецов.

Итак сам документ.

В данном документе будет описан процесс резервного копирования и восстановления СУБД Oracle 10g работающей на базе операционной системы RHEL 4.3. В процессе мы разберёмся с работой скриптов и детально рассмотрим каждый шаг. Руководство может быть использована и на других современных UNIX подобных системах.

Необходимые условия – база данных работает в режиме archivelog.

Описание скриптов и их назначения процесса

В документе рассматриваются следующие скрипты:

envbackup.en Скрипт объявления переменных для работы скриптов резервного копирования и восстановления.
startdbbackup.sh Скрипт операционной системы, который вызывает начало полного резервного копирования.
backupall.rms Скрипт RMAN для резервного копирования базы данных и архивлогов. Вызывается для создания полной, горячей копии базы, архивлогов и контрол-файлов.
startarchlogbackup.sh Скрипт Операционной системы, который вызывает начало резервного копирования архивлогов.
startarchlogbackup.rms Скрипт RMAN для резервного копирования архивлогов.
startrestoredb.sh Скрипт Операционной системы, который вызывает начало восстановления базы данных.
restoreall.rms Скрипт RMAN, который восстанавливает базу данных.

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

Chmod -700 filename

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

set -x
. envbackup.env

rman target sys/nocatalog cmdfile backupall.rms

Ежедневный бэкап архивлогов

set -x
. envbackup.env

rman target sys/nocatalog cmdfile startarchlogbackup.rms

startarchlogbackup.rms

После успешной работы вышеперечисленных скриптов в каталоге /u01/oracle/backup / должны появиться файлы необходимые для восстановления после сбоя.

rman target sys/nocatalog cmdfile restoreall.rms

Удаление устаревших резервных копий и архивлогов

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

В нашем случае политикой резервного копирования устанавливается:

1) Хранение двух резервных копий.
2) Хранение архивлогов и бэкапа базы за 14 дней.
3) Восстановление на момент последнего, удачного архивлога.
4) Работа RMAN в режиме NOCATALOG.

Исходя из этого.

rman target sys/nocatalog

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

Если база находиться в режиме no archivelog

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

Проверить где хранятся параметры инициализации (в Oracle 10g по умолчанию SPFILE):

Если база работает в режиме NOARCHIVELOG

Перевод базы в SPFILE

1. sqlplus /nolog
2. conn /as sysdba
3. shutdown immediate
4. startup mount;
5. alter database archivelog;
6. alter database open;
7. alter system set log_archive_start=true scope=spfile;
8. alter system set log_archive_dest_1 = "location=/u01/oracle/backup/" SCOPE=spfile;
9. alter system set log_archive_format = "LOG%s_%t%r.ARC" scope=spfile;
10. shutdown immediate
11. startup

Да. И пробел лишний. И есть некие знаки, на которые РМАН будет ругаться. Дело в том, что доку писал в Ворде, а ворд Птица умная, и подставляет чтото своё.

Вопрос: Что это за команда?

В документации по 10gR1 и 10gR2 для RMAN - такой команды нет.

Вопрос: Что это за команда?

В документации по 10gR1 и 10gR2 для RMAN - такой команды нет.

The REPLICATE command is used to copy a control file to the locations specified in the CONTROL_FILES initialization parameter of the target database.
This operation is equivalent to executing multiple COPY CONTROLFILE statements.

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

Начиная с 9i достаточно сделать так:

и у вас будет полный бэкап файлов данных и всех необходимых архивных журналов.

И уже в 9i эта команда - depricated, она заменена на

delete expired - это удаление не устаревших копий, а копий которые физически не существуют. Они есть в списке бэкапов в контрольном файле(или в каталоге восстановления), но не существуют реально. Команды crosscheck backup и change archivelog all crosscheck определяют, что бэкапов нет и помечают их в каталоге как expired.

Вывод:
Автор не тестировал, того что предлагает, тупо списал скрипты из древнего топика и в вопросе разбирается слабо
Короче -- креатив гавно

PS. Я думаю, намного интересней новичкам было бы рассматривать WINDOWS, а также осветить режим NOARCHIVELOG

А я и не сопорю. Но просто иногда затаються вопросы, на которые спец говорит либо читай доку, либо используй поиск. Попытался причесать всё в один пост. И, о чудо, я получил КОНСТРУКТИВНУЮ критику о том, что я надёргал в этот пост.

"CIS" - это территория, что означает "Содружество независимых государств" - в 10g уже не существует. Теперь есть RUSSIA.

А скрипты срисованы с RMAN
Поэтому значек копирайта в теме выглядит как-то не очень

А я и не спорю. И то что это мне не пренадлежит, значОк копирайта и оглашает.

Recovery Manager: Release 10.2.0.1.0 - Production on Fri Apr 20 13:33:15 2007

connected to target database: DOC (DBID=3648683070)

allocated channel: c1
channel c1: sid=141 devtype=DISK

Starting backup at 20.04.07
channel c1: starting full datafile backupset
channel c1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u01/oracle/oradata/DOC/system01.dbf
input datafile fno=00003 name=/u01/oracle/oradata/DOC/sysaux01.dbf
input datafile fno=00004 name=/u01/oracle/oradata/DOC/users01.dbf
input datafile fno=00002 name=/u01/oracle/oradata/DOC/undotbs01.dbf
channel c1: starting piece 1 at 20.04.07
channel c1: finished piece 1 at 20.04.07
piece handle=/u01/oracle/backup/DOCDB-f-620400800-40-1 tag=TAG20070420T133320 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:56
channel c1: starting full datafile backupset
channel c1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel c1: starting piece 1 at 20.04.07
channel c1: finished piece 1 at 20.04.07
piece handle=/u01/oracle/backup/DOCDB-f-620400856-41-1 tag=TAG20070420T133320 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:03
Finished backup at 20.04.07

released channel: c1

sql statement: alter system archive log current

allocated channel: c1
channel c1: sid=141 devtype=DISK

Starting backup at 20.04.07
current log archived
channel c1: starting archive log backupset
channel c1: specifying archive log(s) in backup set
input archive log thread=1 sequence=17 recid=47 stamp=620340500
input archive log thread=1 sequence=18 recid=48 stamp=620340500
input archive log thread=1 sequence=19 recid=49 stamp=620340765
input archive log thread=1 sequence=20 recid=50 stamp=620340766
input archive log thread=1 sequence=21 recid=51 stamp=620400864
input archive log thread=1 sequence=22 recid=52 stamp=620400865
channel c1: starting piece 1 at 20.04.07
channel c1: finished piece 1 at 20.04.07
piece handle=/u01/oracle/backup/DOCDB-a-620400866-42-1 tag=TAG20070420T133425 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:04
Finished backup at 20.04.07

released channel: c1

allocated channel: c1
channel c1: sid=141 devtype=DISK

Starting backup at 20.04.07
channel c1: starting full datafile backupset
channel c1: specifying datafile(s) in backupset
including current control file in backupset
channel c1: starting piece 1 at 20.04.07
channel c1: finished piece 1 at 20.04.07
piece handle=/u01/oracle/backup/DOCDB-c-620400872-43-1 tag=TAG20070420T133431 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:01
Finished backup at 20.04.07

released channel: c1

host command complete

А скрипты срисованы с RMAN
Поэтому значек копирайта в теме выглядит как-то не очень

PS. Я думаю, намного интересней новичкам было бы рассматривать WINDOWS, а также осветить режим NOARCHIVELOG

Recovery Manager: Release 10.2.0.1.0 - Production on Fri Apr 20 14:18:47 2007

connected to target database: DOC (DBID=3648683070, not open)

RMAN> set snapshot controlfile name to '/u01/oracle/backup/snap_cf.f';

Recovery Manager: Release 10.2.0.1.0 - Production on Fri Apr 20 14:20:14 2007

connected to target database: DOC (DBID=3648683070, not open)
using target database control file instead of recovery catalog

Читайте также: