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 Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.
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