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

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

Обзор возможостей

Требования к организации периодического резервного копирования (резервирование данных) не уникально для СУБД 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 последних бэкапов:

configure channel device type disk maxpiecesize 2G ;
configure controlfile autobackup on ;
configure controlfile autobackup format for device type disk to 'e:\oracle_backup\back1_ctl_%F' ;
configure retention policy to redundancy 2 ;
# или указать политику глубины хнанения в днях
# configure retention policy to recovery window of 15 days ;
backup check logical tag TDBFULL database format 'c:\oracle_backup\back1_db_%U' plus archivelog tag TARCH format 'c:\oracle_backup\back1_arc_%U' ;
# альтернативой следующей команде можно добавить delete all input skip inaccessible ;
# удалить архивные журналы, дважды забэкапленные перед этим
delete noprompt archivelog all backed up 2 times to device type DISK ;
# кроссчеки выполняются после бэкапов, что может привести к невозможности создания бэкапа
# например при потере части архивных журналов, но это же позволит увидеть проблему (при условии контроля прохождения бэкапов)
# проверить доступность бэкапов и удалить недоступные из метаданных
crosscheck backup ;
delete noprompt expired backup ;
# проверить доступность архивных журналов и бэкапсетов и удалить недоступные из метаданных
crosscheck archivelog all ;
delete noprompt expired archivelog all ;
# удалить не отвечающие политике глубины хранения бэкапы - примеры согласно политике по умолчанию
# или явно указанным критериям
delete noprompt obsolete ;
#delete noprompt obsolete redundancy 2 ;
#delete noprompt backup completed before 'trunc(sysdate)-16' tag = 'XXX' ;
list backup ;

В принципе это все. Любые ручные процедуры типа 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=... ; с корректными значениями вместо ...

восстановить control_file из backup_set, созданного RMAN, для чего:
стартовать RMAN и подключиться к базе: rman target /@
установить DBID (при создании backup_set это первая последовательность цифр в имени файла при использовании шаблона %F) командой: set dbid ;
сказать restore controlfile to '<полное_имя_файла, совпадающее с указанным в файле инициализации>' from '<полное_имя_архива>' ;

восстановить файлы БД, для чего:
смонтировать базу командой: alter database mount ;
при необходимости вывести данные о созданных бэкапах, сказать в RMAN команду list backup, при необходимости - сменить местоположение БД указать новое местоположение, восстановить файлы данных и изменить указатели на местоположение в контролфайле командным блоком RMAN, например:

# %b - имя файла без каталогов, %N - имя ьтабличного пространства, %f - тщмер файла, %I - DBID, %U - уникальная автогенерация
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' ;
-- или указать новый путь для всей БД
set newname for database 'e:\oradata\my_oracle_db\%b' ;
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 <наибольший_номер_журнала_из_предидущего_пункта + 1>

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

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

Белонин С.С. (С), май 2006 года