Oracle - это просто  
  Резервное копирование баз данных Oracle  


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


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

Требования к организации периодического резервного копирования (резервирование данных) не уникально для СУБД 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, например:
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 <наибольший_номер_журнала_из_предидущего_пункта + 1>

открыть БД, для чего:
изменить полный путь к оперативным журналам при необходимости (если меняется место расположения оперативных журналов) командой: 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 лет несколько прибавилось опыта, и технологии выросли. Появился термин "дуплицирование", появилась возможность клонировать БД непосредственно с продуктовой БД, в том числе с последующим подкатом журналов. Далее тезисно опишу процедуру дуплицирования:

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

  • развернуть софт СУБД на сервере - приёмнике, например через описанную в официальном руководстве по установке процедуру клонирования домашнего каталога
  • сконфигурировать SQLNet для сервера - источника и сервера - приёмника, причём на последнем нам нужна статическая регистрация
  • обеспечить на целевом сервере всю структуру каталогов для создаваемой базы (db, arc, logs)
  • обеспечить на целевом сервере spfile и orapwdDBNAME файлы для создаваемой базы, при необходимости выправить параметры log_file_name_convert и db_file_name_convert

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

rman debug on trace=путь_к_трэйсу log=путь_к_log << EOF
connect target sys/password@src_TNS_alias
#connect target "sys/password@src_TNS_alias as sysdba"
connect auxiliary sys/password@dst_TNS_alias
#connect auxiliary "sys/password@dst_TNS_alias as sysdba"
run {
allocate channel src01 type disk;
...
allocate channel srcNN type disk;
allocate auxiliary channel dst01 type disk;
...
allocate auxiliary channel dstNN type disk;
# опционально заменить имя файлов, из опыта нужно указать
# именно номера, а не сторые имена. Switch автоматом в конце
set newname for datafile 1 to 'новое_полное_имя' ;
...
set newname for datafile NNto 'новое_полное_имя' ;
# стэндбай дупликация
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE SECTION SIZE 64G DORECOVER ;
# не стэндбай дупликация
DUPLICATE TARGET DATABASE FROM ACTIVE DATABASE SECTION SIZE 64G DORECOVER NOFILENAMECHECK ;
release channel src01;
...  например 10 каналов  ...
release channel dst01;
...  например 10 каналов  ...
}
EOF

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

set linesize 400 pagesize 400
select INSTNAME,DBNAME,round(sum(BYTES_READ)/power(2,30)/2,1) gb_read,
       round(sum(BYTES_WRITTEN)/power(2,30)/2,1) gb_wrtn
       from gv$asm_disk_iostat group by INSTNAME,DBNAME order by 1,2;

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

SET LINES 200
COL name FORM a80
COL status FORM A8
COL file# FORM 9999
COL control_file_SCN FORM 999999999999999
COL datafile_SCN FORM 999999999999999

SELECT a.name,a.status,a.file#,a.checkpoint_change# control_file_SCN,b.checkpoint_change# datafile_SCN,
       CASE
       WHEN ((a.checkpoint_change# - b.checkpoint_change#) = 0) THEN 'Startup Normal'
       WHEN ((b.checkpoint_change#) = 0) THEN 'File Missing?'
       WHEN ((a.checkpoint_change# - b.checkpoint_change#) > 0) THEN 'Media Rec. Req.'
       WHEN ((a.checkpoint_change# - b.checkpoint_change#) < 0) THEN 'Old Control File'
       ELSE 'what the ?' END datafile_status
       FROM v$datafile a -- control file SCN for datafile
            ,v$datafile_header b -- datafile header SCN
       WHERE a.file# = b.file# ORDER BY a.file# ;

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

. oraenv [testdb9]
nohup rmancmdfile=rman_part_file_9.cmd log=part_file_copy_9.log1 &
-- файл rman_part_file_9.cmd содержит:
connect target sys/pwd@alias_SRC
connect auxiliary sys/pwd@alias_DST
RUN {
ALLOCATE CHANNEL src01 TYPE DISK;
ALLOCATE AUXILIARY CHANNEL dst01 TYPE DISK;
backup as copy datafile 9 auxiliary format '+DATA/dbname/datafile/file9.dbf';
backup as copy datafile 10 auxiliary format '+DATA/dbname/datafile/file10.dbf';
}

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

(даты последующих модификаций не фиксируются)


 
     
   
   
    Нравится      

(C) Белонин С.С., 2000-2018. Дата последней модификации страницы:2018-01-09 13:25:29