Для того чтобы начать применение RMAN в процедурах резервного копирования и восстановления базы данных требуется совсем немного времени. При инсталляции программного обеспечения Oracle, RMAN уже устанавливается автоматически, и необходимы только две вещи для начала его использования, это наличие резервируемой базы данных (целевая база данных или target database) и клиента RMAN, который осуществляет интерфейс между пользователем и процессами сервера RMAN.
Когда вы используете RMAN, вы взаимодействуете с клиентом, который интерпретирует вводимые команды, и запускает необходимые серверные процессы, исполняющие эти команды. В дополнение, кроме клиента и целевой базы данных, в RMAN есть такое понятие как репозитарий, который представляет собой записи метаданных RMAN обо всех резервных копиях и действиях по резервному копированию и восстановлению. Эту информацию RMAN использует, когда выполняет операции резервного копирования или восстановления.
По умолчанию, RMAN всегда хранит копию репозитария в контрольном файле целевой базы данных, но опционально он может использовать для этих целей и каталог восстановления (recovery catalog), который представляет собой отдельную схему в базе данных. Всякий раз, когда происходят изменения в структуре базы данных, заархивированных журнальных файлах или резервных копиях, RMAN обновляет каталог восстановления новой порцией информации из контрольного файла целевой базы данных. В отличие от контрольного файла, где старая информация может быть заменена более новой по истечении периода времени, хранение в каталоге позволяет хранить более длительную историю репозитария. К тому же, в случае утери контрольного файла, информация не о резервных копиях не пропадёт вместе с ним. В идеале, схема каталога восстановления должна находиться в базе данных, отличной от целевой базы, это позволит повысить защищённость каталога в случае сбоя. Для этой же цели, можно так же использовать всего лишь один каталог восстановления для всех имеющихся баз данных. В этом случае лучше конечно развернуть для этого отдельный экземпляр.
3-1. Запуск клиента RMAN
Клиент RMAN представляет собой исполняемый файл rman, всегда находящийся в каталоге $ORACLE_HOME/bin. Если была правильно установлена переменная $ORACLE_HOME, запустить RMAN можно из любого места, просто введя rman в командной строке:
[oracle@alfa ~]$ rman Recovery Manager: Release 10.2.0.3.0 - Production on Thu Apr 21 13:22:05 2011 Copyright (c) 1982, 2005, Oracle. All rights reserved.
Учитывайте, что появление подсказки RMAN вовсе не означает, что произошло подключение клиента к целевой, вспомогательной базе данных или к каталогу восстановления. Если попытаться на данном этапе выполнить какую либо команду, то RMAN будет использовать репозитарий в nocatalog режиме. Дальнейшее подключение к каталогу восстановления в этом случае будет невозможно и придётся перезапускать клиент RMAN, чтобы в дальнейшем можно было без проблем подсоединиться к каталогу.
[oracle@alfa ~]$ rman
Recovery Manager: Release 10.2.0.3.0 - Production on Thu Apr 21 13:31:09 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> show all;
using target database control file instead of recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of show command at 04/21/2011 13:31:15
RMAN-06171: not connected to target database
RMAN> connect catalog system/test@alfa.alldba.ru;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06445: cannot connect to recovery catalog after NOCATALOG has been used
Когда работа с RMAN закончена, достаточно просто ввести команду exit для закрытия клиента RMAN:
RMAN> exit Recovery Manager complete.
Кроме этого, можно использовать команду quit для прерывания RMAN сессии.
RMAN> quit; Recovery Manager complete.
3-2. Ввод команд RMAN
RMAN использует в свободной форме язык команд. Каждый оператор команды RMAN начинается с зарезервированного слова, сопровождается определенными аргументами, и заканчивается точкой с запятой. Команда может располагаться как на одной строке, так и на нескольких. Например, следующая команда, расположенная в одной строке, производит резервную копию целевой базы данных:
RMAN> backup database;
Если вводится неполная команда и нажимается ENTER, RMAN всегда запросит, нужно ли продолжать ввод команды. При этом будет произведён переход на новую строку с отображением её номера. К примеру, следующая команда резервирует базу данных вместе с ее контрольным файлом:
RMAN> backup database 2> include current 3> controlfile 4> ;
Когда осуществляется ввод команды в таком виде, RMAN буферизует каждую строку, которая заканчивается ENTER, до тех пор, пока не встретится строка заканчивающаяся точкой с запятой. После этого RMAN выполняет введённую команду.
В RMAN имеется возможность добавлять комментарии к своим командам. Это облегчает их логический разбор в командных файлах. Началу комментария в этом случае всегда должен предшествовать знак #. Любой текст, расположенный в строке после символа #, считается комментарием и будет проигнорирован при выполнении. Например, следующий командный файл RMAN, который выполняет инкрементальную резервную копию базы данных, использует комментарии:
# this command will be run daily backup incremental level 1 for recover of copy # uses incrementally updated backups database;
Хотя предполагается, что резервные слова не будут использованы в качестве части аргументов команд, всё же такая возможность в RMAN есть. Для этого, достаточно в процессе ввода команды заключить подобные слова в одинарные или двойные кавычки:
RMAN> run{
2> allocate channel 'backup' device type disk;
3> }
В дальнейшем, конечно лучше отказаться от всякого использования зарезервированных слов, особенно в качестве имен каналов.
3-3. Запись вывода RMAN в текстовый файл
Служебную информацию, которую выводит RMAN на экран можно записывать в текстовый файл. Для этого достаточно выполнить команду spool с указанием имени файла журнала:
RMAN> spool log to 'backup.log'; RMAN> backup datafile 1; RMAN> spool log off; Spooling for log turned off Recovery Manager10.2.0.3.0
Заботиться о предварительном наличии файла журнала не стоит. Клиент RMAN сам создаст файл, если он не существует. Если же файл с таким именем уже присутствует в каталоге, то содержимое его будет полностью заменено. Чтобы этого не случилось, можно использовать следующий синтаксис команды spool:
RMAN> spool log to 'backup.log' append;
В данном примере информация будет добавляться в конец файла журнала backup.log. Если необходимо, что бы журнализация RMAN начиналась непосредственно с начала запуска клиента RMAN, в аргумент команды запуска можно добавить ключ «log» с указанием имени файла журнала. Правда надо учитывать, что RMAN в этом случае будет интерактивным. В следующем примере RMAN выполняет командный файл commandfile1.rcv с записью вывода результатов в файл журнала backup.log:
[oracle@alfa ~]$ rman target / cmdfile commandfile1.rcv log backup.log
Файл журнала в данном примере будет перезаписываться при каждом запуске RMAN. Если в дальнейшем потребуется сохранять выходную информацию RMAN в один и тот же журнальный файл, то в командную строку запуска клиента надо добавить аргумент append:
[oracle@alfa ~]$ rman target / cmdfile commandfile2.rcv log backup.log append
Журнализация RMAN, начиная с командной строки, хотя и позволяет сохранять информацию в файл, но она не отображает эту информацию на экране. Если такое отображение всё же требуется, то для таких случаев можно использовать команду «tee» (Unix/Linux), перенаправляя на неё поток стандартного вывода RMAN:
[oracle@alfa ~]$ rman | tee backup.log
Даже если файл журнала не был заранее задан, это вовсе не означает, что нельзя увидеть сообщения производимые RMAN. Существует динамическое представление v$rman_output, в котором эти сообщения дублируются:
SQL> SELECT recid, output FROM v$rman_output RECID OUTPUT ----- ----------------------------------------------------------------------- connected to target database: ORCL (DBID=1265664822) 2 3 backup datafile 1; 4 5 6 Starting backup at 26-APR-11 7 using target database control file instead of recovery catalog 8 allocated channel: ORA_DISK_1 9 channel ORA_DISK_1: sid=140 devtype=DISK 10 channel ORA_DISK_1: starting full datafile backupset 11 channel ORA_DISK_1: specifying datafile(s) in backupset 12 input datafile fno=00001 name=/u02/oradata/orcl/system01.dbf 13 channel ORA_DISK_1: starting piece 1 at 26-APR-11 14 channel ORA_DISK_1: finished piece 1 at 26-APR-11 15 piece handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2011_04_26/o1_mf_nnndf_TAG20110 426T121322_6vdzo2nr_.bkp tag=TAG2 16 channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25 17 channel ORA_DISK_1: starting full datafile backupset 18 channel ORA_DISK_1: specifying datafile(s) in backupset 19 including current control file in backupset 20 including current SPFILE in backupset 21 channel ORA_DISK_1: starting piece 1 at 26-APR-11 22 channel ORA_DISK_1: finished piece 1 at 26-APR-11 23 piece handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2011_04_26/o1_mf_ncsnf_TAG20110 426T121322_6vdzoxjl_.bkp tag=TAG2 24 channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03 25 Finished backup at 26-APR-11 26 27
Представление содержит всю выходную информацию производимую заданиями RMAN, начиная с начала запуска экземпляра, и может содержать в себе до 32768 строк.
3-4. Подключение к целевой базе данных
После того как клиент RMAN запущен для осуществления действий резервного копирования и восстановления необходимо подключиться к целевой базе данных. Сделать это можно с помощью команды connect одним из двух способов, и всего лишь один раз. Первый способ заключается в подключении к базе данных с проверкой подлинности операционной системой:
RMAN> connect target /; connected to target database: ORCL (DBID=1265664822)
Второй способ использует файл паролей:
RMAN> connect target sys/test@alfa.alldba.ru;
connected to target database: ORCL (DBID=1265664822)
Учитывайте, что во втором случае пользователь должен иметь sysdba привилегию и быть зарегистрированным в файле паролей. При этом в команде подключения не надо указывать служебное слово as sysdba, так как rman уже подразумевает, что данная привилегия у вас есть.
Вышеперечисленные способы подключения можно совместить с процессом запуска клиента rman, указав в качестве его командных параметров параметры подсоединения. Вот как это будет выглядеть в нашем случае:
[oracle@alfa ~]$ rman target /; Recovery Manager: Release 10.2.0.3.0 - Production on Tue May 10 11:28:41 2011 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database: ORCL (DBID=1265664822)
или
[oracle@alfa ~]$ rman target sys/test@alfa.alldba.ru;
3-5. Выполнение команд операционной системы в пределах RMAN
Иногда, после запуска клиента rman, требуется выполнить какие либо команды операционной системы, не выходя при этом из оболочки самого клиента. Для решения этой проблемы, в rman имеется команда host, которая вызывает подоболочку операционной системы. Выполнить с помощью неё команды операционной системы можно двумя способами. Первый способ заключается в передаче команде host в качестве аргумента единственной команды операционной системы. Так, в следующем примере, после копирования файла users01.dbf в каталог /tmp выполняется команда ls, для просмотра факта наличия скопированного файла в операционной системе:
RMAN> backup datafile '/u02/oradata/orcl/users01.dbf' format '/tmp/users01.dbf'; Starting backup at 10-MAY-11 using channel ORA_DISK_1 channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset input datafile fno=00004 name=/u02/oradata/orcl/users01.dbf channel ORA_DISK_1: starting piece 1 at 10-MAY-11 channel ORA_DISK_1: finished piece 1 at 10-MAY-11 piece handle=/tmp/users01.dbf tag=TAG20110510T122817 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 10-MAY-11 RMAN> host 'ls –l /tmp/*.dbf'; -rw-r----- 1 oracle oinstall 8241152 Май 10 12:28 /tmp/users01.dbf host command complete
При данном способе, после выполнения команды операционной системы, происходит возвращение управления оболочке клиента RMAN.
Во втором способе выполнения команд подоболочка операционной системы запускается в диалоговом режиме. После выполнения каждой команды операционной системы, возвращение управления клиенту RMAN не происходит, и подоболочка будет ожидать от пользователя ввода новой команды. Завершение работы с подоболочкой и переход к приглашению RMAN, в этом случае, будет осуществляться по специальной команде exit:
RMAN> backup datafile 5 format '/tmp/example01.cpy'; Starting backup at 10-MAY-11 using channel ORA_DISK_1 channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset input datafile fno=00005 name=/u02/oradata/orcl/example01.dbf channel ORA_DISK_1: starting piece 1 at 10-MAY-11 channel ORA_DISK_1: finished piece 1 at 10-MAY-11 piece handle=/tmp/example01.cpy tag=TAG20110510T123117 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03 Finished backup at 10-MAY-11 RMAN> host; [oracle@alfa ~]$ ls -l /tmp/*.cpy -rw-r----- 1 oracle oinstall 59105280 Май 10 12:31 /tmp/example01.cpy [oracle@alfa ~]$ exit; exit host command complete
3-6. Скрипты RMAN
Выполнение некоторых команд RMAN может занимать довольно длительное время, и чтобы хоть как-то автоматизировать этот процесс, у RMAN имеется возможность объединять команды в скрипты. Это позволяет не дожидаться результатов окончания каждой команды, и открывает возможность выполнения команд в любое время с использованием планировщика.
Скрипты можно образовывать двумя способами. Первый способ – это создание файла скрипта командной оболочки, в котором будут исполняться команды RMAN. Преимуществом данного метода является то, что в одном скрипте можно указать как команды RMAN, так и команды командного интерпретатора, что придаёт ему большую гибкость. Ниже приведён пример такого скрипта full_backup, осуществляющего полное резервное копирование базы:
export ORACLE_SID=$1
rman target / <<- EOF
sql 'alter system archive log current';
run {
allocate channel d1 type disk;
backup full database format '/u01/app/oracle/admin/orcl/backup/backup_%n_%T_%s_%p.bkp';
}
EOF
Стоит отметить, что сочетание <<- EOF в скрипте означает, что командный интерпретатор должен читать текст файла сценария до тех пор, пока не встретиться символ EOF. Символ не обязательно должен быть таким, его вполне можно заменить и другим сочетанием.
Альтернативный способ образования скрипта заключается в создании текстового файла, в котором перечисляются команды RMAN. Например, файл скрипта созданного выше, выглядел бы в этом случае так:
sql 'alter system archive log current';
run {
allocate channel d1 type disk;
backup full database format '/u01/app/oracle/admin/orcl/backup/backup_%n_%T_%s_%p.bkp';
}
Запустить такой скрипт можно с помощью клиента RMAN:
[oracle@alfa ~]$ rman target / @full_backup.rman;
Символ @ с указанием имени файла скрипта означает, что RMAN должен прочитать файл до конца, и последовательно выполнить все команды указанные в нём. Это символ, кстати, можно использовать и внутри командной строки клиента RMAN, что позволяет сделать скрипт нагляднее и гибче.
3-7. Выполнение командных файлов RMAN
Как было сказано выше, для автоматизации процессов резервного копирования и восстановления, можно использовать скрипты RMAN. Запускаются такие командные скрипты с помощью клиента RMAN с указанием ключевого слова cmdfile.
[oracle@alfa ~]$ rman target / cmdfile full_backup.rman
Скрипт можно выполнить и без указания ключевого слова cmdfile, просто поместив символ @ перед именем файла:
[oracle@alfa ~]$ rman target / @full_backup.rman
При выполнении такого скрипта, происходит предварительный разбор всех команд указанных в нём. Если при этом, в синтаксисе какой-то команды, найдена ошибка, то выполнение скрипта немедленно прерывается.
Для выполнения скрипта можно использовать и оболочку RMAN. В этом случае надо указать, как и в последнем примере, символ @ перед именем файла:
RMAN> @full_backup.rman
Процесс выполнения такого файла будет отличаться от его запуска из командной строки. Каждая команда скрипта разбирается здесь непосредственно перед исполнением и возникающие ошибки не приводят к прерыванию всего командного файла.
3-8. Подключение к вспомогательной базе данных
Для осуществления дублирования базы данных или восстановления табличного пространства по времени потребуется подключение к вспомогательной базе данных. Осуществить такое подключение из клиента RMAN можно с помощью той же команды connect с указанием ключевого слова auxiliary:
RMAN> connect auxiliary sys/****@aux
Нельзя задавать подключение к основной и вспомогательной базе в одной строке. Должны быть выполнены две команды подключения.
3-9. Выполнение нескольких команд RMAN как единого блока
После того как среда RMAN настроена, и были определены команды резервного копирования, может возникнуть ситуация, когда эти команды нужно выполнить в клиенте RMAN строго последовательно. При этом, ошибка возникающая при исполнении любой команды этого последовательного набора, должна предотвратить выполнение следующих операций. То есть команды должны выступать в виде единого атомарного блока. Для оформления такого блока в RMAN есть специальный синтаксис. Начинается такой блок с ключевого слова run, далее за ним следуют фигурные скобки, внутрь которых помещаются команды:
RMAN> run {
2> allocate channel dev1 device type sbt;
3> set backup copies = 2;
4> backup datafile 4;
5> backup archivelog all;
6> }
При обнаружении закрывающей скобки блока, RMAN группирует команды блока в один или блоее шагов и начинает их выполнять немедленно.
Очень часто блок используется для того чтобы изменить какие либо параметры по умолчанию, так как при закрытии блока все параметры изменённые внутри него восстанавливаются к своим первоначальным значениям. Для этих изменений существуют специальные команды (например allocate channel или set newname for datafile), которые могут выполнятся только в пределах блока. В противоположность этому существуют команды, применение которых внутри блока запрещено, например:
connect, configure create catalog, drop catalog, upgrade catalog create script, delete script, replace script list report
3-10. Выполнение SQL команд в RMAN клиенте
При выполнении операций резервного копирования и восстановления может понадобиться исполнить некоторые SQL команды, не выходя при этом из среды RMAN. Для осуществления этих действий в RMAN существует зарезервированное слово sql, после которого в одинарных или двойных кавычках указывается текст sql команды:
RMAN> sql 'alter system archive log current'; sql statement: alter system archive log current
Не все sql команды можно полноценно выполнить таким образом. Например, команда select хотя и будет выполнена, но данные в этом случае выбраны не будут.
RMAN> sql 'select sysdate from dual'; sql statement: select sysdate from dual
Если в тексте выполняемой sql команды, требуется указать какой либо текст или, например имена файлов в одинарных кавычках, то такая команда заключается в двойные апострофы, а сам текст обрамляется удвоенными кавычками.
RMAN> sql "begin dbms_application_info.set_action(''Full backup''); end;";
sql statement: begin dbms_application_info.set_action(''Full backup''); end;
Последний пример кстати демонстрирует, что вместо sql команд в RMAN можно выполнять и PL/SQL блоки.
3-11. Старт и остановка базы данных в RMAN
Во время выполнения задач резервного копирования и восстановления можно загружать и выгружать базу данных Oracle не выходя из клиента RMAN. Для выполнения этих действий используются аналоги команд SQL*Plus STARTUP и SHUTDOWN.
Старт базы данных
Для старта базы данных используется команда RMAN startup. Так же как и её аналог из SQL*Plus она может использоваться с различными опциями. Если опции не указываются, то команда осуществляет автоматическое монтирование и открытие базы данных:
RMAN> startup; connected to target database (not started) Oracle instance started database mounted database opened Total System Global Area 285212672 bytes Fixed Size 1261372 bytes Variable Size 268435652 bytes Database Buffers 12582912 bytes Redo Buffers 2932736 bytes
Использование опций в команде STARTUP из RMAN клиента позволяет сделать процесс восстановления базы данных гибче. В следующем примере можно наблюдать, как происходит восстановление в RMAN по шагам, начиная от старта базы данных в NOMOUNT режиме и заканчивая открытием базы данных с опцией RESETLOGS:
[oracle@alfa ~]$ rman target / Recovery Manager: Release 10.2.0.3.0 - Production on Tue Nov 8 14:59:16 2011 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database (not started) RMAN> startup nomount; Oracle instance started Total System Global Area 285212672 bytes Fixed Size 1261372 bytes Variable Size 268435652 bytes Database Buffers 12582912 bytes Redo Buffers 2932736 bytes RMAN> restore controlfile from autobackup; Starting restore at 08-NOV-11 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=156 devtype=DISK allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: sid=155 devtype=SBT_TAPE channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111108 channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111107 channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111106 channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111105 channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111104 channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111103 channel ORA_SBT_TAPE_1: looking for autobackup on day: 20111102 channel ORA_SBT_TAPE_1: no autobackup in 7 days found recovery area destination: /u01/app/oracle/flash_recovery_area/ database name (or database unique name) used for search: ORCL channel ORA_DISK_1: autobackup found in the recovery area channel ORA_DISK_1: autobackup found: /u01/app/oracle/flash_recovery_area/ORCL/autobackup/2011_11_08/o1_mf_s_766683874_7cl91lo5 _.bkp channel ORA_DISK_1: control file restore from autobackup complete output filename=/u02/oradata/orcl/control01.ctl output filename=/u02/oradata/orcl/control02.ctl output filename=/u02/oradata/orcl/control03.ctl Finished restore at 08-NOV-11 RMAN> alter database mount; database mounted released channel: ORA_DISK_1 released channel: ORA_SBT_TAPE_1 RMAN> recover database; Starting recover at 08-NOV-11 Starting implicit crosscheck backup at 08-NOV-11 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=155 devtype=DISK Crosschecked 3 objects Finished implicit crosscheck backup at 08-NOV-11 Starting implicit crosscheck copy at 08-NOV-11 using channel ORA_DISK_1 Finished implicit crosscheck copy at 08-NOV-11 searching for all files in the recovery area cataloging files... cataloging done List of Cataloged Files ======================= File Name: /u01/app/oracle/flash_recovery_area/ORCL/autobackup/2011_11_08/o1_mf_s_766683874_7cl91lo5 _.bkp using channel ORA_DISK_1 allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: sid=156 devtype=SBT_TAPE channel ORA_SBT_TAPE_1: WARNING: Oracle Test Disk API starting media recovery archive log thread 1 sequence 45 is already on disk as file /u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_45_759tw74z_.arc archive log thread 1 sequence 46 is already on disk as file /u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_46_759tw8sj_.arc archive log thread 1 sequence 47 is already on disk as file /u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_47_759twjfk_.arc archive log thread 1 sequence 48 is already on disk as file /u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_48_759twkrz_.arc archive log thread 1 sequence 49 is already on disk as file /u02/oradata/orcl/redo03.log archive log filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_45_759tw7 4z_.arc thread=1 sequence=45 archive log filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_46_759tw8 sj_.arc thread=1 sequence=46 archive log filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_47_759twj fk_.arc thread=1 sequence=47 archive log filename=/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2011_08_24/o1_mf_1_48_759twk rz_.arc thread=1 sequence=48 archive log filename=/u02/oradata/orcl/redo03.log thread=1 sequence=49 media recovery complete, elapsed time: 00:00:02 Finished recover at 08-NOV-11 RMAN> alter database open resetlogs; database opened
Для того чтобы вышеуказанный пример получился, резервная копия, с которой происходит восстановление контрольного файла, должна быть создана с предварительно включенным параметром CONTROLFILE AUTOBACKUP:
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON; old RMAN configuration parameters: CONFIGURE CONTROLFILE AUTOBACKUP OFF; new RMAN configuration parameters: CONFIGURE CONTROLFILE AUTOBACKUP ON; new RMAN configuration parameters are successfully stored
Опцию NOMOUNT команды STARTUP можно так же использовать, если серверный (или инициализационный) файл параметров потерян и требуется его восстановление из резервной копии. Следующий пример демонстрирует этот процесс по шагам.
Для начала, переименуем файл параметров, имитируя его потерю:
[oracle@alfa /]$ cd $ORACLE_HOME/dbs [oracle@alfa dbs]$ ls spfileorcl.ora spfileorcl.ora [oracle@alfa dbs]$ mv spfileorcl.ora spfileorcl.old
Если сейчас попробовать стартовать экземпляр, то он запросит файл параметров:
SQL> startup; ORA-01078: failure in processing system parameters LRM-00109: could not open parameter file '/u01/app/oracle/product/10.2.0/db_1/dbs/initorcl.ora'
Утерянный файл параметров имеется в резервной копии RMAN, но для того чтобы восстановить его, надо запустить базу данных в NOMOUNT режиме. Поэтому, используем для старта базы данных фиктивный файл параметров.
Перед стартом обязательно устанавливаем идентификатор базы данных, так как мы не подключаемся к каталогу восстановления:
RMAN> set DBID 1265664822; executing command: SET DBID
Стартуем экземпляр с фиктивным файлом параметров:
RMAN> startup force nomount; startup failed: ORA-01078: failure in processing system parameters LRM-00109: could not open parameter file '/u01/app/oracle/product/10.2.0/db_1/dbs/initorcl.ora' starting Oracle instance without parameter file for retrival of spfile Oracle instance started Total System Global Area 159383552 bytes Fixed Size 1260648 bytes Variable Size 58721176 bytes Database Buffers 96468992 bytes Redo Buffers 2932736 bytes
Попробуем восстановить файл параметров из резервной копии:
RMAN> restore spfile from autobackup; Starting restore at 11-JAN-12 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=36 devtype=DISK channel ORA_DISK_1: looking for autobackup on day: 20120111 channel ORA_DISK_1: looking for autobackup on day: 20120110 channel ORA_DISK_1: looking for autobackup on day: 20120109 channel ORA_DISK_1: looking for autobackup on day: 20120108 channel ORA_DISK_1: looking for autobackup on day: 20120107 channel ORA_DISK_1: looking for autobackup on day: 20120106 channel ORA_DISK_1: looking for autobackup on day: 20120105 channel ORA_DISK_1: no autobackup in 7 days found RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 01/11/2012 13:39:14 RMAN-06172: no autobackup found or specified handle is not a valid copy or piece
Восстановление закончилось неудачей. Почему? Чтобы ответить на этот вопрос, вспомним, что экземпляр базы данных запускался с фиктивным файлом параметров. В нём нет указаний на путь к директории флэш-области восстановления, которая содержит резервные копии. RMAN просто не может их найти. Значит, придётся задавать расположение флэш-области вручную. В нашем случае путь к директории флэш-области складывается из значений двух параметров db_recovery_file_dest и db_name, которые можно определить прямо в команде восстановления файла параметров:
RMAN> restore spfile from autobackup db_recovery_file_dest='/u01/app/oracle/flash_recovery_area' db_name='orcl'; Starting restore at 11-JAN-12 using channel ORA_DISK_1 recovery area destination: /u01/app/oracle/flash_recovery_area database name (or database unique name) used for search: ORCL channel ORA_DISK_1: autobackup found in the recovery area channel ORA_DISK_1: autobackup found: /u01/app/oracle/flash_recovery_area/ORCL/autobackup/2012_01_10/o1_mf_s_772211704_7jrby9p9 _.bkp channel ORA_DISK_1: SPFILE restore from autobackup complete Finished restore at 11-JAN-12
Как видно RMAN нашел резервную копию и восстановил из неё файл параметров. Проверим наличие файла в операционной системе:
[oracle@alfa dbs]$ ls spfileorcl.ora spfileorcl.ora
Файл параметров действительно присутствует. Теперь можно стартовать базу данных:
RMAN> startup force; Oracle instance started database mounted database opened Total System Global Area 285212672 bytes Fixed Size 1261372 bytes Variable Size 268435652 bytes Database Buffers 12582912 bytes Redo Buffers 2932736 bytes
Файл параметров восстановлен, и база данных открыта. Причём сделано это всё было только в клиенте RMAN.
Остановка базы данных
Для закрытия базы данных и остановки экземпляра, в клиенте RMAN можно использовать команду SHUTDOWN. Команда поддерживает в синтаксисе те же самые опции, что и её аналог в SQL*Plus. В следующем примере показано, как используя только RMAN клиент, можно остановить базу данных, стартовать её в смонтированном режиме, сделать резервную копию и открыть базу данных для использования:
RMAN> shutdown immediate; database closed database dismounted Oracle instance shut down RMAN> startup mount; connected to target database (not started) Oracle instance started database mounted Total System Global Area 285212672 bytes Fixed Size 1261372 bytes Variable Size 264241348 bytes Database Buffers 16777216 bytes Redo Buffers 2932736 bytes RMAN> backup database; Starting backup at 11-JAN-12 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=157 devtype=DISK channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset input datafile fno=00001 name=/u02/oradata/orcl/system01.dbf input datafile fno=00003 name=/u02/oradata/orcl/sysaux01.dbf input datafile fno=00002 name=/u02/oradata/orcl/undotbs01.dbf input datafile fno=00005 name=/u02/oradata/orcl/example01.dbf input datafile fno=00004 name=/u02/oradata/orcl/users01.dbf channel ORA_DISK_1: starting piece 1 at 11-JAN-12 channel ORA_DISK_1: finished piece 1 at 11-JAN-12 piece handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_01_11/o1_mf_nnndf_TAG20120 111T142105_7jtw51on_.bkp tag=TAG20120111T142105 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:02:14 Finished backup at 11-JAN-12 Starting Control File and SPFILE Autobackup at 11-JAN-12 piece handle=/u01/app/oracle/flash_recovery_area/ORCL/autobackup/2012_01_11/o1_mf_s_772294711_7 jtw98ss_.bkp comment=NONE Finished Control File and SPFILE Autobackup at 11-JAN-12 RMAN> alter database open; database opened
Стоит отметить, что команды STARTUP и SHUTDOWN в клиенте RMAN имеют ограничения. Так, с их помощью нельзя закрыть и стартовать экземпляр каталога восстановления. Данные команды относятся только к целевой базе данных. Поэтому, если всё же потребуется остановить или стартовать экземпляр каталога из клиента RMAN, необходимо подключиться к нему как к целевой базе данных, и только затем использовать команды STARTUP и SHUTDOWN.
3-12. Проверка синтаксиса RMAN команд
В RMAN имеется возможность проверки синтаксиса вводимых команд. Для входа в этот режим необходимо запустить клиента RMAN с аргументом командной строки checksyntax. После этого, можно проверять синтаксис команд, вводя и запуская их в оболочке клиента или подгружая файл скрипта с содержащимися в нём командами. Сами команды исполняться при этом не будут.
Следующий пример демонстрирует проверку синтаксиса единственной команды:
[oracle@alfa ~]$ rman checksyntax
Recovery Manager: Release 10.2.0.3.0 - Production on Tue Jan 24 18:33:39 2012
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> run {backup database;}
The command has no syntax errors
Как видно из примера, ошибок в синтаксисе этой команды не обнаружено.
Кроме проверки синтаксиса отдельных команд, в RMAN можно проверить синтаксис команд целого скрипта. Для этого надо указать файл скрипта в качестве аргумента командной строки при запуске клиента:
[oracle@alfa ~]$ rman checksyntax @backup1.rman
Recovery Manager: Release 10.2.0.3.0 - Production on Tue Jan 24 18:43:42 2012
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> run
2> {
3> allocate channel dev1 device type sbt;
4> set backup copies = 2;
5> backup datafiles
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "identifier": expecting one of: "archivelog, as, backup,
backupset, blocks, channel, check, copy, copies, controlfilecopy, cumulative, current,
database, datafile, datafilecopy, device, diskratio, db_recovery_file_dest,
db_file_name_convert, duration, filesperset, for, format, full, force, incremental, keep,
(, maxsetsize, nochecksum, noexclude, nokeep, not, proxy, pool, reuse, recovery, skip,
spfile, setsize, tablespace, tag, to, validate"
RMAN-01008: the bad identifier was: datafiles
RMAN-01007: at line 5 column 8 file: backup1.rman
В примере мы видим, что в синтаксисе третьей команды скрипта имеется ошибка.
Использование аргумента checksyntax позволяет предотвратить появление грубых ошибок во время выполнения командного скрипта RMAN. Рекомендуется всегда использовать данную проверку, когда скрипт модифицируется.
3-13. Сокрытие паролей при подключении к RMAN
Запуск клиента RMAN часто сопровождается указанием в аргументах командной строки параметров подключения, таких как база данных, имя и пароль пользователя. В результате, в различные логи операционной системы могут попадать данные, которые содержат командную строку запуска RMAN с паролём пользователя в открытом виде. Существует два способа избежать этого. Первый – это указывать в командной строке только имя пользователя. Клиент RMAN сам запросит пароль. Вводимые символы при этом отображаться не будут:
[oracle@alfa ~]$ rman target sys@alfa.alldba.ru
Recovery Manager: Release 10.2.0.3.0 - Production on Tue Jan 24 18:50:07 2012
Copyright (c) 1982, 2005, Oracle. All rights reserved.
target database Password:
connected to target database: ORCL (DBID=1265664822)
Если же требуется выполнить командный скрипт RMAN и при этом необходимо избежать указывания пароля в командной строке, то можно поместить команду подключения CONNECT с именем и паролём пользователя в самое начало файла скрипта. При выполнении такого скрипта RMAN клиент сделает подключение, заменив в выводе имя пользователя и пароль звёздочками:
[oracle@alfa ~]$ rman @backup.rman; Recovery Manager: Release 10.2.0.3.0 - Production on Tue Jan 24 14:04:56 2012 Copyright (c) 1982, 2005, Oracle. All rights reserved. RMAN> connect target * 2> backup database; connected to target database: ORCL (DBID=1265664822) Starting backup at 24-JAN-12 …
В последнем случае стоит ограничить доступ другим пользователям к файлу сценария на уровне операционной системы, так как в нём будет указаны параметры подключения в открытом виде.
3-14. Идентификация серверных сеансов RMAN
Для выполнения задач резервного копирования и восстановления, RMAN образует с целевой базой данных или каталогом восстановления сеансы. Иногда возникают случаи, когда необходимо прервать работу одного из таких сеансов. Ниже на примерах будет показано, как можно идентифицировать такие сеансы в системе, для того чтобы их в дальнейшем можно было уничтожить.
Определение колличества сеансов
Узнать количество сеансов RMAN можно с помощью следующей формулы:
Количество сеансов = C+N+2
где:
- C – количество выделенных каналов;
- N – число опций CONNECT, используемых в командах выделения каналов (если не определено, то равно 1);
Если используется каталог восстановления, всегда имеется, по крайней мере, два сеанса, один к каталогу восстановления, другой по умолчанию к целевой базе данных. Сеанс по умолчанию необходим для того, чтобы выполнить такие задачи, как применение архивных журналов во время процесса восстановления.
Идентификация сеансов
Если RMAN клиент запускается на сервере базы данных (unix), то для того чтобы отобразить список серверных процессов относящихся к сеансам RMAN достаточно выполнить следующую команду:
[oracle@alfa ~]$ ps -ef | grep rman oracle 3743 2887 4 10:20 pts/1 00:00:00 rman target /
Из примера видно, что был запущен клиент RMAN c идентификатором процесса PID равным 3743. Ищем процессы имеющие идентификаторы родительского процесса PPID равным этому значению:
[oracle@alfa ~]$ ps -ef | grep 3743 oracle 3748 3743 0 10:20 ? 00:00:00 oracleorcl (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) oracle 3749 3743 0 10:20 ? 00:00:00 oracleorcl (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
Найденные процессы и будут принадлежать сеансам запущенного клиента RMAN. По их PID можно легко найти идентификаторы (SID, SERIAL#) сеансов и уничтожить их с помощью команды ALTER SYSTEM … KILL SESSION.
Идентификатор сеанса SID так же можно встретить и в выходной информации RMAN:
RMAN> backup database; Starting backup at 25-JAN-12 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=145 devtype=DISK
В этом примере мы видим, что для резервного копирования базы данных был применён канал ORA_DISK_1, который использует сеанс с идентификатором SID = 145.
Если клиент RMAN подключается к базе данных удалённо, то определить такие сеансы через команды операционной системы будет затруднительно. В этом случае придётся обращаться к системному представлению V$SESSION и идентифицировать сеансы либо по названию программы клиента, либо по терминалу. В остальном сеансы RMAN не несут никаких отличительных признаков по сравнению с другими сеансами:
SQL> SELECT sid, serial#, username, terminal FROM v$session WHERE program = 'rman.exe' SID SERIAL# USERNAME TERMINAL --- ------- -------- -------- 146 31 SYS 0500-ASU 158 57 SYS 0500-ASU Выбрано: 2 строки
3-15. Удаление базы данных из клиента RMAN
Если требуется удалить базу данных, то сделать это можно с помощью утилиты SQL*Plus. Но если нет возможности в её использовании, то удаление можно провести и в RMAN клиенте.
Для удаления базы данных, надо:
- Запустить базу данных в смонтированном эксклюзивном режиме:
SQL> startup restrict mount exclusive; ORACLE instance started. Total System Global Area 285212672 bytes Fixed Size 1261372 bytes Variable Size 268435652 bytes Database Buffers 12582912 bytes Redo Buffers 2932736 bytes Database mounted. SQL> exit
- Использовать команду DROP для удаления базы:
RMAN> drop database; database name is "ORCL" and DBID is 1290912723
- RMAN потребует подтверждение на удаление. Необходимо ввести YES:
Do you really want to drop the database (enter YES or NO)? YES database dropped
Можно использовать ключевое слово noprompt в команде DROP для предотвращения диалога запроса на удаление. Это может пригодиться в случае составления командного скрипта RMAN.
Стандартная команда DROP DATABASE удаляет только файлы данных, файлы онлайн журналов, и контрольные файлы. Но в RMAN эта команда имеет расширенный синтаксис. Используя дополнительные ключевые слова, можно с помощью этой команды дополнительно избавиться и от всех резервных копий сделанных ранее RMAN:
RMAN> drop database including backups; database name is "ORCL" and DBID is 1301354837 Do you really want to drop all backups and the database (enter YES or NO)? YES using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=156 devtype=DISK List of Backup Pieces BP Key BS Key Pc# Cp# Status Device Type Piece Name ------- ------- --- --- ----------- ----------- ---------- 1 1 1 1 AVAILABLE DISK /u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_01_26/o1_mf_nnndf_TAG20120126T094 438_7l1xlq7k_.bkp 2 2 1 1 AVAILABLE DISK /u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_01_26/o1_mf_ncnnf_TAG20120126T094 438_7l1xnkg7_.bkp deleted backup piece backup piece handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_01_26/o1_mf_nnndf_TAG20120 126T094438_7l1xlq7k_.bkp recid=1 stamp=773574279 deleted backup piece backup piece handle=/u01/app/oracle/flash_recovery_area/ORCL/backupset/2012_01_26/o1_mf_ncnnf_TAG20120 126T094438_7l1xnkg7_.bkp recid=2 stamp=773574337 Deleted 2 objects released channel: ORA_DISK_1 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=156 devtype=DISK specification does not match any archive log in the recovery catalog database name is "ORCL" and DBID is 1301354837 database dropped
Комментариев нет:
Отправить комментарий