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 клиенте.

Для удаления базы данных, надо:

  1. Запустить базу данных в смонтированном эксклюзивном режиме:

    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 
    
  2. Использовать команду DROP для удаления базы:

    RMAN> drop database;
    database name is "ORCL" and DBID is 1290912723
    
  3. 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