You are on page 1of 21

RMAN NOTES AND MISCELLANY

ABSTRACT

RMAN is Oracle Corporations latest tool to perform backup and recovery on Oracle
databases. This paper covers notes that I made during my studies and tests of
RMAN.

WHAT IS RMAN?

Recovery Manager (RMAN) is an Oracle tool that lets the DBA perform backup and
recovery of Oracle databases. RMAN lets one perform full backups (with the
database up or down), incremental backups on the block level, and backups of
online redo logs and control files. The SYSDBA privilege is required to run RMAN on a
database. Among RMANs other benefits are:
o Keeps track of all backup and recovery operations performed against the
database.
o Manage centralized backup & recovery procedures for the enterprise.
o Identifies corrupt blocks.

Why use RMAN at EDC when other backup & recovery implementations have
proven so successful? The GASR database is slated to be in the terabyte range.
Such a large database would take a very long time to bring down for cold
backups. This leaves us with two options, either hot backups or RMAN.
Unfortunately, hot backups will backup the entire database files. RMAN can be
used to backup only those blocks that actually contain data. This can lead to big
savings in the backup space requirements. RMAN is being deployed on GASR to
perform incremental backups on the block level of this multi-terabyte database.

RECOVERY CATALOG

In order to use all of RMANs functionality, a Recovery Catalog is required. The


Recovery Catalog is essentially a repository for RMAN. Ideally, this should be in an
Oracle instance on a separate machine than the target database. Currently, I have
set up a Recovery Catalog in the SNU14 instance under the RMAN schema. You
start up RMAN, connect to the recovery catalog and then connect to the target
database as follows:

edcsns18% chsid gast


edcsns18% rman

Recovery Manager: Release 8.1.7.2.0 - Production


RMAN> connect catalog rman/password@snu14

RMAN-06008: connected to recovery catalog database

RMAN> connect target /

RMAN-06005: connected to target database: GAST (DBID=4222303827)

Notice that I had my environment set up for the GAST as my local database. This let
me connect to this target database with the connect target / command. If the
target database was remote, one could use the userid/password@connect_string
convention. This is exactly the tactic used to connect to the remote catalog
database.

If you need to create a Recovery Catalog, then you need to perform the following
steps:
1. Create a schema owner in the Recovery Catalog database.
2. Create a tablespace for that schema owner
3. Grant CONNECT, RESOURCE, and RECOVERY_CATALOG_OWNER roles to that schema
owner.
4. 8i: From RMAN, connect to the recovery catalog and issue the following
command: CREATE CATALOG TABLESPACE RMAN_TS;
5. Pre-8i: Run the $ORACLE_HOME/rdbms/admin/catrman.sql script.
As you can see, Oracle 8i supports the CREATE CATALOG statement. It also supports
the UPGRADE CATALOG and DROP CATALOG statements.

REGISTERING A DATABASE

Now that you have set up the Recovery Catalog, you need to register a database
with that recovery catalog in order to begin backup & recovery operations. This is
done with the REGISTER DATABASE command as can be seen below:

edcsns18% rman

Recovery Manager: Release 8.1.7.2.0 - Production

RMAN> connect catalog rman/password@snu14

RMAN-06008: connected to recovery catalog database

RMAN> connect target /

RMAN-06005: connected to target database: GASR (DBID=4162675397)

RMAN> register database;

RMAN-03022: compiling command: register


RMAN-03023: executing command: register
RMAN-08006: database registered in recovery catalog
RMAN-03023: executing command: full resync
RMAN-08002: starting full resync of recovery catalog
RMAN-08004: full resync complete

Here, we connected RMAN to the recovery catalog and the target database. The
target database was then registered with the recovery catalog. Notice that this
database was given a unique database identifier. A section that follows will cover
this in a little more detail.

To deregister a database from the Recovery Catalog, one needs to execute a


supplied PL/SQL package in the Recovery Catalog database as follows:

edcsns18% sqlplus rman@snu14

SQL*Plus: Release 8.1.7.0.0 - Production on Tue Nov 20 13:30:49 2001

(c) Copyright 2000 Oracle Corporation. All rights reserved.

Enter password:

Connected to:
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option
JServer Release 8.1.7.0.0 - Production

Today is: TUESDAY NOVEMBER 20TH,2001 13:31:56

SNU14 SQL> execute dbms_rcvcat.unregisterdatabase(248,4162675397);

PL/SQL procedure successfully completed.

Before you can deregister the database, you need to know the DB_KEY and DB_ID for
that database. For more information, refer to the section on Database Identifiers.

RE-SYNCING THE CATALOG

The Recovery Catalog is not immediately aware of changes made to the database.
For instance, you may add a tablespace to the database. The Recovery Catalog
needs to be aware of this for future backup and recovery operations. The BACKUP,
COPY, RESTORE, and SWITCH commands automatically update, or re-sync the Recovery
Catalog. If one wants to force the re-sync, it can be done as follows:

RMAN> resync catalog;

RMAN-03022: compiling command: resync


RMAN-03023: executing command: resync
RMAN-08002: starting full resync of recovery catalog
RMAN-08004: full resync complete

This should be done on a periodic basis so that RMAN is familiar with changes to
the online redo logs and the archive redo logs.
DATABASE IDENTIFIER

Notice that when I connected to the GAST database, it displayed a unique database
identifier, DBID=4222303827. Each database id is used to uniquely identify that
database to the Recovery Catalog. To see which databases currently exist in the
recovery catalog, issue the following:

RMAN> list incarnation of database;

RMAN-03022: compiling command: list

List of Database Incarnations


DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
248 249 GASR 4162675397 YES 1 20-SEP-01
107 108 GAST 4222303827 YES 1 05-NOV-01

Here, we can see that we have two databases currently registered with the
Recovery Catalog. And you can clearly see their individual DBID numbers.
BACKING UP A DATABASE

Its now time to backup the database. After all, thats what were here for! There
are multiple ways to perform a backup. What is not backed up? The following files
are not backed up by RMAN: INIT.ORA parameter files, password files, online redo
logs, transportable tablespaces not yet set to READ WRITE, and operating system
files. Youll have to employ some other method of backing those up. In our case,
Legato generally backs these files up without any of our intervention.

RMAN handles three different types of backups: backup sets, datafile copies (or
image copies), and operating system backups. Backup sets are created with the
BACKUP command. Backup sets can be a FULL backup of database blocks in use (not
to be confused with a full backup), and INCREMENTAL backups. Datafile copies are
done with the COPY command. OS backups can be done with OS commands
through RMAN.

The next few sub-sections will give you some details about RMANs backup
capabilities.

FULL (WHOLE DATABASE) BACKUP

An RMAN full backup is not like the cold backups of the past. Cold backups would
require that the database be down. A RMAN full backup can take place if the
database is up or down. All database blocks for the datafiles and control files will
be backed up regardless of whether those blocks are empty or not. If the full
backup needs to take place when the database is up and running, then that
database must be running in Archive Mode. A full backup is done similarly to the
following:

RMAN> run {
2> allocate channel disk1 type disk format
3> '/edcsns18/backup/oradata/gast/rman/%d_full_bkup_%t';
4> backup database;
5> sql 'ALTER SYSTEM ARCHIVE LOG CURRENT';
6> }

RMAN-03022: compiling command: allocate


RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: disk1
RMAN-08500: channel disk1: sid=11 devtype=DISK

RMAN-03022: compiling command: backup


RMAN-03023: executing command: backup
RMAN-08008: channel disk1: starting full datafile backupset
RMAN-08502: set_count=4 set_stamp=446312136 creation_time=20-NOV-01
RMAN-08010: channel disk1: specifying datafile(s) in backupset
RMAN-08522: input datafile fno=00003 name=/edcsns18/oradata7/gast/gast_data01.dbf
RMAN-08522: input datafile fno=00001 name=/edcsns18/oradata7/gast/system_gast.dbf
RMAN-08011: including current controlfile in backupset
RMAN-08522: input datafile fno=00002 name=/edcsns18/oradata7/gast/rbs_gast01.dbf
RMAN-08013: channel disk1: piece 1 created
RMAN-08503: piece
handle=/edcsns18/backup/oradata/gast/rman/GAST_full_bkup_446312136 comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:02:46
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete

RMAN-03022: compiling command: sql


RMAN-06162: sql statement: ALTER SYSTEM ARCHIVE LOG CURRENT
RMAN-03023: executing command: sql
RMAN-08031: released channel: disk1

There are some important points to note about this series of commands. They will
be explained here and not in further sections. First, the RUN command is used to
tell RMAN what series of commands to execute. Those commands can be found
between the open and closed braces.

CHANNELS
The first command in the example will open a channel. RMAN will only read or
write using a channel. In my case, Ive opened a channel to disk, but I could have
opened a channel to a tape device by specifying the sbt_tape type. Since this is a
disk channel, I had to tell it which directory to use and what the filename of the
backup set will be called. This is done with the FORMAT option. You can clearly see
that I placed the backup set in the /edcsns18/backup/oradata/gast/rman directory.
The rest of the FORMAT option declares the backup set filename in that directory,
%d_full_bkup_%t. Referring to the table below, one can see that %d is the database
name and %t is a timestamp.
Wildcard Meaning
---------- --------------------------------------
%d Database name (SID)
%t Timestamp
%u Unique name/number generated by Oracle
%c Copy number
%p Backup piece #
%s Backup set #

If you examine the RMAN messages, you will see:

RMAN-08502: set_count=4 set_stamp=446312136 creation_time=20-NOV-01

Here, you can see that the timestamp is 446312136. A further message shows:

RMAN-08503: piece handle=/edcsns18/backup/oradata/gast/rman/GAST_full_bkup_446312136

Here, you can see the backup set was placed in one piece in the appropriate
directory. The %d and %t wildcards have been replaced by the database SID and
timestamp respectively.

It is possible to allocate more than one channel to your backup. This is done to
improve performance. If I allocate three disk channels to three different physical
disk drives, then I can backup the database in one-third of the time it takes to
backup the database through one channel to one physical drive.

FULL BACKUP

The backup database command says to perform a full backup of the database. This
is all that is required.

SQL COMMANDS IN RMAN

The SQL directive passes a SQL command to the target database. In my example,
I issued the ALTER SYSTEM ARCHIVE LOG CURRENT command. Keep in mind that SQL
commands will not show any output other than the RMAN-03023: executing command:
sql message.

FINAL THOUGHTS

Notice that each of the datafiles of the database is included in the backup. This is
indicated by the RMAN messages:

RMAN-08522: input datafile fno=00003 name=/edcsns18/oradata7/gast/gast_data01.dbf

There is one of these for every file in the database. Notice that there is no TEMP
tablespace in this backup set. This is because the TEMP tablespace was created
with TEMPFILES instead of DATAFILES. As such, they do not require a backup. If
the TEMP tablespace needs to be restored, simply remove that tablespace from the
database and create a new one.

A copy of the control file was included in the backup set. This is confirmed in the
following message:

RMAN-08011: including current controlfile in backupset

The online redo logs were not included in the backup set. According to Oracle
Corp., a backup of online redo logs is not required, nor is it recommended. In fact,
restoring these datafiles can lead to a corrupt database.

When the backup is done, you will get a message indicating the elapsed time
along with a resync of the recovery catalog.

RMAN-08525: backup set complete, elapsed time: 00:02:46


RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete

TABLESPACE BACKUPS

Occasionally, one will want to backup just a tablespace (and its associated
datafiles). This can be done similarly to the following:

RMAN> run {
2> allocate channel disk1 type disk format
3> '/edcsns18/backup/oradata/gast/rman/%d_ts_bkup_%t';
4> backup tablespace "GAST_DATA"
5> filesperset 2;
6> }

RMAN-03022: compiling command: allocate


RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: disk1
RMAN-08500: channel disk1: sid=11 devtype=DISK

RMAN-03022: compiling command: backup


RMAN-03024: performing implicit full resync of recovery catalog
RMAN-03023: executing command: full resync
RMAN-08002: starting full resync of recovery catalog
RMAN-08004: full resync complete
RMAN-03023: executing command: backup
RMAN-08008: channel disk1: starting full datafile backupset
RMAN-08502: set_count=5 set_stamp=446313819 creation_time=20-NOV-01
RMAN-08010: channel disk1: specifying datafile(s) in backupset
RMAN-08522: input datafile fno=00003 name=/edcsns18/oradata7/gast/gast_data01.dbf
RMAN-08522: input datafile fno=00004 name=/edcsns18/oradata7/gast/gast_data02.dbf
RMAN-08013: channel disk1: piece 1 created
RMAN-08503: piece handle=/edcsns18/backup/oradata/gast/rman/GAST_ts_bkup_446313819
comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:02:05
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-08031: released channel: disk1

Here, we backed up just the GAST_DATA tablespace. We also used the optional
parameter to indicate that there could be at most 2 pieces, or files, for this backup
set.

DATAFILE BACKUPS

One can also backup a specific datafile if they choose.

RMAN> run {
2> allocate channel disk1 type disk format
3> '/edcsns18/backup/oradata/gast/rman/file_gast_data02_%t';
4> backup datafile '/edcsns18/oradata7/gast/gast_data02.dbf';
5> }

RMAN-03022: compiling command: allocate


RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: disk1
RMAN-08500: channel disk1: sid=11 devtype=DISK

RMAN-03022: compiling command: backup


RMAN-03023: executing command: backup
RMAN-08008: channel disk1: starting full datafile backupset
RMAN-08502: set_count=6 set_stamp=446314147 creation_time=20-NOV-01
RMAN-08010: channel disk1: specifying datafile(s) in backupset
RMAN-08522: input datafile fno=00004 name=/edcsns18/oradata7/gast/gast_data02.dbf
RMAN-08013: channel disk1: piece 1 created
RMAN-08503: piece
handle=/edcsns18/backup/oradata/gast/rman/file_gast_data02_446314147 comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:00:07
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-08031: released channel: disk1

CONTROL FILE BACKUPS

RMAN can also backup control files as well. A full backup will automatically backup
the control file, but it may be desirable to do this separately. For instance, you
may wish to backup a tablespace and include the control file in that backup.

RMAN> run {
2> allocate channel disk1 type disk format
3> '/edcsns18/backup/oradata/gast/rman/%d_ctl_file';
4> backup current controlfile;
5> }

RMAN-03022: compiling command: allocate


RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: disk1
RMAN-08500: channel disk1: sid=11 devtype=DISK

RMAN-03022: compiling command: backup


RMAN-03023: executing command: backup
RMAN-08008: channel disk1: starting full datafile backupset
RMAN-08502: set_count=7 set_stamp=446314336 creation_time=20-NOV-01
RMAN-08010: channel disk1: specifying datafile(s) in backupset
RMAN-08011: including current controlfile in backupset
RMAN-08013: channel disk1: piece 1 created
RMAN-08503: piece handle=/edcsns18/backup/oradata/gast/rman/GAST_ctl_file
comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:00:02
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-08031: released channel: disk1

The backup current controlfile command indicates that the control file should be
backed up.

ARCHIVE LOG BACKUPS

RMAN can now be used to backup the archived redo logs. Previously, DBAs had to
create custom scripts to accomplish this. Using RMAN is a great way to backup
those archived redo logs to tape without any other intervention.

In my database, I have 7 archived redo logs as shown by the following query:

GAST SQL> select recid,to_char(completion_time,'MM/DD/YY HH24:MI') as day


2 from v$archived_log;

RECID DAY
---------- --------------
1 11/06/01 12:47
2 11/06/01 14:04
3 11/06/01 14:39
4 11/07/01 14:06
5 11/08/01 11:48
6 11/08/01 11:48
7 11/20/01 15:38

7 rows selected.

It is easy to backup these archived redo logs as follows:

RMAN> run {
2> allocate channel disk1 type disk format
3> '/edcsns18/backup/oradata/gast/rman/%d_redologs';
4> backup archivelog all;
5> }

RMAN-03022: compiling command: allocate


RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: disk1
RMAN-08500: channel disk1: sid=11 devtype=DISK

RMAN-03022: compiling command: backup


RMAN-03023: executing command: backup
RMAN-08009: channel disk1: starting archivelog backupset
RMAN-08502: set_count=8 set_stamp=446314685 creation_time=20-NOV-01
RMAN-08014: channel disk1: specifying archivelog(s) in backup set
RMAN-08504: input archivelog thread=1 sequence=106 recid=1 stamp=445092441
RMAN-08504: input archivelog thread=1 sequence=107 recid=2 stamp=445097054
RMAN-08504: input archivelog thread=1 sequence=108 recid=3 stamp=445099161
RMAN-08504: input archivelog thread=1 sequence=109 recid=4 stamp=445183565
RMAN-08504: input archivelog thread=1 sequence=110 recid=5 stamp=445261712
RMAN-08504: input archivelog thread=1 sequence=111 recid=6 stamp=445261712
RMAN-08504: input archivelog thread=1 sequence=112 recid=7 stamp=446312303
RMAN-08013: channel disk1: piece 1 created
RMAN-08503: piece handle=/edcsns18/backup/oradata/gast/rman/GAST_redologs
comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:00:02
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-08031: released channel: disk1

You can clearly see that all 7 archived redo logs were archived with RMAN
messages similar to the following:

RMAN-08504: input archivelog thread=1 sequence=106 recid=1 stamp=445092441

One can also specify a range of archived redo logs instead with a command
similar to the following:

RMAN> run {
2> allocate channel disk1 type disk format
3> '/edcsns18/backup/oradata/gast/rman/%d_redologs_%t';
4> backup archivelog from time='07-NOV-01' until time='09-NOV-01';
5> }

RMAN-03022: compiling command: allocate


RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: disk1
RMAN-08500: channel disk1: sid=11 devtype=DISK

RMAN-03022: compiling command: backup


RMAN-03023: executing command: backup
RMAN-08009: channel disk1: starting archivelog backupset
RMAN-08502: set_count=9 set_stamp=446315058 creation_time=20-NOV-01
RMAN-08014: channel disk1: specifying archivelog(s) in backup set
RMAN-08504: input archivelog thread=1 sequence=109 recid=4 stamp=445183565
RMAN-08504: input archivelog thread=1 sequence=110 recid=5 stamp=445261712
RMAN-08504: input archivelog thread=1 sequence=111 recid=6 stamp=445261712
RMAN-08504: input archivelog thread=1 sequence=112 recid=7 stamp=446312303
RMAN-08013: channel disk1: piece 1 created
RMAN-08503: piece handle=/edcsns18/backup/oradata/gast/rman/GAST_redologs_446315058
comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:00:02
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-08031: released channel: disk1

This range specified those archived redo logs generated in a specific time frame.

INCREMENTAL BACKUPS

RMAN will let you perform incremental backups on a database. This lets you
backup only those database blocks that have changed since the last incremental
backup. Before RMAN, Oracles export utility was the only supported incremental
backup solution. But the import utility could not roll forward any changes since the
export was taken. RMAN lets you take incremental backups and roll forward any
changes since that backup.

All of the backups mentioned in the above sections will backup all database
blocks, even if they are completely empty. This is not one of the strengths of
RMAN. RMANs incremental backups will backup non-empty database blocks.

RMAN has multiple levels of incremental backups. The lowest level, level 0, is a
baseline incremental backup. Essentially, this is a full backup. A level 1
incremental backup will backup only those blocks that have changed since the
previous backup at level 1 or lower (level 0). RMAN also lets one perform a level 2
incremental backup.

Note: In order to perform incremental backups, the database must be running in


Archive Mode.

So lets look at an example of an incremental backup.

RMAN> run {
2> allocate channel disk1 type disk
3> format '/edcsns18/backup/oradata/gast/rman/%d_incremental0_%t.bkup';
4> backup incremental level 0 database;
5> }

RMAN-03022: compiling command: allocate


RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: disk1
RMAN-08500: channel disk1: sid=11 devtype=DISK
RMAN-03022: compiling command: backup
RMAN-03023: executing command: backup
RMAN-08008: channel disk1: starting incremental level 0 datafile backupset
RMAN-08502: set_count=10 set_stamp=446987592 creation_time=28-NOV-01
RMAN-08010: channel disk1: specifying datafile(s) in backupset
RMAN-08522: input datafile fno=00003 name=/edcsns18/oradata7/gast/gast_data01.dbf
RMAN-08522: input datafile fno=00001 name=/edcsns18/oradata7/gast/system_gast.dbf
RMAN-08011: including current controlfile in backupset
RMAN-08522: input datafile fno=00002 name=/edcsns18/oradata7/gast/rbs_gast01.dbf
RMAN-08522: input datafile fno=00004 name=/edcsns18/oradata7/gast/gast_data02.dbf
RMAN-08013: channel disk1: piece 1 created
RMAN-08503: piece
handle=/edcsns18/backup/oradata/gast/rman/GAST_incremental0_446987592.bkup
comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:02:06
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-08031: released channel: disk1

This completes the level 0 incremental backup. In my case above, the backup file
was 83 Mbytes in size. Some time later, a level 1 backup is performed. Changes
have been made to the database during this time.

RMAN> run {
2> allocate channel disk1 type disk
3> format '/edcsns18/backup/oradata/gast/rman/%d_incremental1_%t.bkup';
4> backup incremental level 1 database;
5> }

RMAN-03022: compiling command: allocate


RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: disk1
RMAN-08500: channel disk1: sid=11 devtype=DISK

RMAN-03022: compiling command: backup


RMAN-03023: executing command: backup
RMAN-08008: channel disk1: starting incremental level 1 datafile backupset
RMAN-08502: set_count=11 set_stamp=446987905 creation_time=28-NOV-01
RMAN-08010: channel disk1: specifying datafile(s) in backupset
RMAN-08522: input datafile fno=00003 name=/edcsns18/oradata7/gast/gast_data01.dbf
RMAN-08522: input datafile fno=00001 name=/edcsns18/oradata7/gast/system_gast.dbf
RMAN-08011: including current controlfile in backupset
RMAN-08522: input datafile fno=00002 name=/edcsns18/oradata7/gast/rbs_gast01.dbf
RMAN-08522: input datafile fno=00004 name=/edcsns18/oradata7/gast/gast_data02.dbf
RMAN-08013: channel disk1: piece 1 created
RMAN-08503: piece
handle=/edcsns18/backup/oradata/gast/rman/GAST_incremental1_446987905.bkup
comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:02:16
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-08031: released channel: disk1
The level 1 backup file is only 7 Mbytes in size. This is much smaller than the
original backup. Only those database blocks that changed since the level 0
incremental backup were involved in this backup.

THE NEXT STEP


In my examples, I used RMAN to backup directly to disk. This is the fastest
method. If you choose this method you need to take certain methods to protect
your backup. First, do not backup to a disk volume that contains database
datafiles. If you lose that volume, not only do you lose those database datafiles,
but you also lose the backup of those datafiles! Second, you strongly need to
consider moving your backup off the server entirely. If you lose the entire server,
youll lose the backup as well. So if youve backed up to disk, it is a good idea to
move those backups to tape or another server. Oracle does come with a module
for RMAN that will let it plug right into Legato (or other vendor backup packages).
This allows you backup directly to tape if you need to.

One other note, the recovery catalog should not reside in the same database as
you are backing up. It is a very good idea to house the recovery catalog in a
separate database in a different server. You can use any method to backup the
recovery catalog, including RMAN.

WHICH BACKUP FILES?


So youve now used RMAN to perform a variety of backups in the database. Lets
assume that youve copied those backup sets to tape somewhere to clear up your
disk unit for further backups. How do you know which files are in the backup sets
for recovery? How do you know which datafiles are in a particular backup set?
Luckily, RMAN keeps all of this information for you.

The simplest way to find out which backups have taken place through RMAN is to
use the list command. To find all backups of the target database issue the
following command:

RMAN> list backup of database;

RMAN-03022: compiling command: list

List of Backup Sets


Key Recid Stamp LV Set Stamp Set Count Completion Time
------- ---------- ---------- -- ---------- ---------- ----------------------
223 1 445183561 0 445183538 1 07-NOV-01

List of Backup Pieces


Key Pc# Cp# Status Completion Time Piece Name
------- --- --- ----------- ---------------------- ------------------------
224 1 1 AVAILABLE 07-NOV-01 /edcsns18/backup/oradata/
gast/rman/GAST_gast_01d8hthi_1_1

List of Datafiles Included


File Name LV Type Ckp SCN Ckp Time
---- ------------------------------------- -- ---- ---------- -------------
1 /edcsns18/oradata7/gast/system_gast.dbf 0 Full 142203 07-NOV-01
2 /edcsns18/oradata7/gast/rbs_gast01.dbf 0 Full 142203 07-NOV-01

Here, you can see that a backup set was created on 07-NOV-01. This backup set
consists of one backup piece,
/edcsns18/backup/oradata/gast/rman/GAST_gast_01d8hthi_1_1. This backup set only
comprises two database datafiles corresponding to the SYSTEM and RBS tablespaces.
If other backup sets were created for this target database, then the same
information presented above would follow for each backup set.

The above example shows how to list the backup sets for the database (of
database keywords). The same command can be used with other options such as
of tablespace ts_name or of controlfile or of archivelog all. For example:

RMAN> list backup of tablespace gast_data;

RMAN-03022: compiling command: list

List of Backup Sets


Key Recid Stamp LV Set Stamp Set Count Completion Time
------- ---------- ---------- -- ---------- ---------- ----------------------
234 2 445184986 0 445184944 2 07-NOV-01

List of Backup Pieces


Key Pc# Cp# Status Completion Time Piece Name
------- --- --- ----------- ---------------------- ------------------------
235 1 1 AVAILABLE 07-NOV-01
/edcsns18/backup/oradata/gast/rman/GAST_445184944.set2

This shows all the backup sets for the GAST_DATA tablespace. You may wish to
restrict the output of the list command to those backup sets generated in a
specific date range. This is done with the completed between option.

RMAN> list backup of tablespace gast_data


2> completed between '07-NOV-01' and '21-NOV-01';

RMAN-03022: compiling command: list

List of Backup Sets


Key Recid Stamp LV Set Stamp Set Count Completion Time
------- ---------- ---------- -- ---------- ---------- ----------------------
234 2 445184986 0 445184944 2 07-NOV-01

List of Backup Pieces


Key Pc# Cp# Status Completion Time Piece Name
------- --- --- ----------- ---------------------- ------------------------
235 1 1 AVAILABLE 07-NOV-01
/edcsns18/backup/oradata/gast/rman/GAST_445184944.set2

List of Datafiles Included


File Name LV Type Ckp SCN Ckp Time
---- ------------------------------------- -- ---- ---------- -------------
3 /edcsns18/oradata7/gast/gast_data01.dbf 0 Full 142242 07-NOV-01

List of Backup Sets


Key Recid Stamp LV Set Stamp Set Count Completion Time
------- ---------- ---------- -- ---------- ---------- ----------------------
9330 3 446311915 0 446311792 3 20-NOV-01

List of Backup Pieces


Key Pc# Cp# Status Completion Time Piece Name
------- --- --- ----------- ---------------------- ------------------------
9331 1 1 AVAILABLE 20-NOV-01
/edcsns18/backup/oradata/gast/rman/GAST_full_bkup_446311792

List of Datafiles Included


File Name LV Type Ckp SCN Ckp Time
---- ------------------------------------- -- ---- ---------- -------------
3 /edcsns18/oradata7/gast/gast_data01.dbf 0 Full 162347 20-NOV-01

The above output showed only those backup sets for the GAST_DATA tablespace
created between 11/07/01 and 11/21/01.

There is more information on the list command in the Oracle8i Recovery Manager
User's Guide and Reference manual. Use the list command to find out which
backup pieces are needed for recovery. If those backup pieces have been
archived to some other location, restore them before beginning recovery of the
database. This will make your life much simpler.

REPORTING

RMAN also comes with more advanced reporting functions. These reports can help
you make decisions. For example, to see which datafiles comprise the database,
issue the following:

RMAN> report schema;

RMAN-03022: compiling command: report


Report of database schema
File K-bytes Tablespace RB segs Name
---- ---------- -------------------- ------- -------------------
1 307200 SYSTEM YES /edcsns18/oradata7/gast/
system_gast.dbf
2 204800 RBS YES /edcsns18/oradata7/gast/
rbs_gast01.dbf
3 2048000 GAST_DATA NO /edcsns18/oradata7/gast/
gast_data01.dbf
4 102400 GAST_DATA NO /edcsns18/oradata7/gast/
gast_data02.dbf
5 102400 GAST_INDEX NO /edcsns18/oradata8/gast/
gast_index01.dbf

Here, you can see that this database is made of five datafiles. The REPORT SCHEMA
command lists the physical layout of your database according to RMAN. If you add
a datafile to the database, then RMAN needs to be notified of this change. This
can be done with the RESYNC CATALOG command.

The REPORT command can also let you know which datafiles need to be backed up.
For instance, to find out which datafiles have not been backed up in the last five
days, issue the following command:

RMAN> report need backup days=5;

RMAN-03022: compiling command: report


Report of files whose recovery needs more than 5 days of archived logs
File Days Name
---- ----- -----------------------------------------------------
1 8 /edcsns18/oradata7/gast/system_gast.dbf
2 8 /edcsns18/oradata7/gast/rbs_gast01.dbf
3 8 /edcsns18/oradata7/gast/gast_data01.dbf
4 8 /edcsns18/oradata7/gast/gast_data02.dbf
5 8 /edcsns18/oradata8/gast/gast_index01.dbf

This report shows that five datafiles need more than five days of archived logs to
recover. These files have not been backed up in the last five days.

The REPORT command can also let you know which backup sets are obsolete and
can be removed.

RMAN> report obsolete redundancy 3;

RMAN-03022: compiling command: report


Report of obsolete backups and copies
Type Key Completion Time Filename/Handle
-------------------- ------ ------------------ --------------------
Backup Set 223 07-NOV-01
Backup Piece 224 07-NOV-01
/edcsns18/backup/oradata/gast/rman/GAST_gast_01d8hthi_1_1
Backup Set 234 07-NOV-01
Backup Piece 235 07-NOV-01
/edcsns18/backup/oradata/gast/rman/GAST_445184944.set2
Backup Set 9330 20-NOV-01
Backup Piece 9331 20-NOV-01
/edcsns18/backup/oradata/gast/rman/GAST_full_bkup_446311792
Backup Set 9356 20-NOV-01
Backup Piece 9357 20-NOV-01
/edcsns18/backup/oradata/gast/rman/GAST_ctl_file
Datafile Copy 241 07-NOV-01
/edcsns18/backup/oradata/gast/rman/control.bkup

This command lists all backup sets that have at least 3 or more recent backups or
copies. If I only need three generations, then these backup sets can be removed.
The next section shows how to remove backup sets from RMAN.
REMOVING BACKUP SETS

It is unlikely that you have an unlimited supply of tapes or disk space to hold
every single backup ever made of your database. It is more likely that you have
allocated enough storage space to hold X generations of your backups (your
business rules determine X). For instance, you may desire to have the last three
good backups available. Over time, backup sets will become obsolete due to
storage considerations and those backup sets will be lost forever. RMAN needs to
be notified when those backup sets are no longer available for recovery.

In the previous section, I determined that five backup sets were obsolete. Lets
see how we can manually remove two.

RMAN> allocate channel for delete type disk;

RMAN-03022: compiling command: allocate


RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: delete
RMAN-08500: channel delete: sid=14 devtype=DISK

RMAN> change backuppiece


'/edcsns18/backup/oradata/gast/rman/GAST_gast_01d8hthi_1_1','/edcsns18/backup/orada
ta/gast/rman/GAST_445184944.set2' delete;

RMAN-03022: compiling command: change


RMAN-03023: executing command: DELETE
RMAN-08073: deleted backup piece
RMAN-08517: backup piece
handle=/edcsns18/backup/oradata/gast/rman/GAST_gast_01d8hthi_1_1 recid=1
stamp=445183539
RMAN-08073: deleted backup piece
RMAN-08517: backup piece
handle=/edcsns18/backup/oradata/gast/rman/GAST_445184944.set2 recid=2
stamp=445184945
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete

RMAN> release channel;

RMAN-03022: compiling command: release


RMAN-03023: executing command: release
RMAN-08031: released channel: delete

First, a channel needs to be allocated to delete backup sets. Then the CHANGE
BACKUPIECE is executed to delete each backup piece. Finally, the channel is
released. Notice now that the two backup pieces have been removed from RMAN.

RMAN> report obsolete redundancy 3;

RMAN-03022: compiling command: report


Report of obsolete backups and copies
Type Key Completion Time Filename/Handle
-------------------- ------ ------------------ --------------------
Backup Set 9330 20-NOV-01
Backup Piece 9331 20-NOV-01
/edcsns18/backup/oradata/gast/rman/GAST_full_bkup_446311792
Backup Set 9356 20-NOV-01
Backup Piece 9357 20-NOV-01
/edcsns18/backup/oradata/gast/rman/GAST_ctl_file
Datafile Copy 241 07-NOV-01
/edcsns18/backup/oradata/gast/rman/control.bkup

Only three backup pieces remain. This delete operation also removed the datafiles
from disk.

RMAN SCRIPTS

RMAN lets you store scripts in RMAN. This way, you can store regularly executed
tasks right in RMAN. Then you just run the stored script. To demonstrate this, well
store a FULL backup script in RMAN and then run the script.

RMAN> create script gast_full_backup {


2> allocate channel disk1 type disk format
3> '/edcsns18/backup/oradata/gast/rman/%d_full_bkup_%t';
4> backup database;
5> sql 'ALTER SYSTEM ARCHIVE LOG CURRENT';
6> }

RMAN-03022: compiling command: create script


RMAN-03023: executing command: create script
RMAN-08085: created script gast_full_backup

RMAN> run {execute script gast_full_backup;}

RMAN-03021: executing script: gast_full_backup

RMAN-03022: compiling command: allocate


RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: disk1
RMAN-08500: channel disk1: sid=18 devtype=DISK

RMAN-03022: compiling command: backup


RMAN-03023: executing command: backup
RMAN-08008: channel disk1: starting full datafile backupset
RMAN-08502: set_count=13 set_stamp=447763812 creation_time=06-DEC-01
RMAN-08010: channel disk1: specifying datafile(s) in backupset
RMAN-08522: input datafile fno=00003 name=/edcsns18/oradata7/gast/gast_data01.dbf
RMAN-08522: input datafile fno=00005 name=/edcsns18/oradata8/gast/gast_index01.dbf
RMAN-08522: input datafile fno=00001 name=/edcsns18/oradata7/gast/system_gast.dbf
RMAN-08011: including current controlfile in backupset
RMAN-08522: input datafile fno=00002 name=/edcsns18/oradata7/gast/rbs_gast01.dbf
RMAN-08522: input datafile fno=00004 name=/edcsns18/oradata7/gast/gast_data02.dbf
RMAN-08013: channel disk1: piece 1 created
RMAN-08503: piece
handle=/edcsns18/backup/oradata/gast/rman/GAST_full_bkup_447763812 comment=NONE
RMAN-08525: backup set complete, elapsed time: 00:02:06
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete

RMAN-03022: compiling command: sql


RMAN-06162: sql statement: ALTER SYSTEM ARCHIVE LOG CURRENT
RMAN-03023: executing command: sql
RMAN-08031: released channel: disk1

The first command creates the script. The second command runs that script.

RECOVERY

What good would a backup be if you werent able to recover the database? RMAN
lets one easily recover databases as well. In this example, Ill show how to recover
the entire database, but recovery can be done on the tablespace or datafile level
as well.

SVRMGR> startup
ORACLE instance started.
Total System Global Area 13197472 bytes
Fixed Size 73888 bytes
Variable Size 4841472 bytes
Database Buffers 8192000 bytes
Redo Buffers 90112 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: '/edcsns18/oradata7/gast/gast_data02.dbf'

Here we can see that the GAST_DATA02.DBF is missing when we tried to startup the
database. We need to recover this datafile from the backup. First, well start the
database in MOUNT mode.

SVRMGR> shutdown abort


ORACLE instance shut down.
SVRMGR> startup mount
ORACLE instance started.
Total System Global Area 13197472 bytes
Fixed Size 73888 bytes
Variable Size 4841472 bytes
Database Buffers 8192000 bytes
Redo Buffers 90112 bytes
Database mounted.

Now that the database has been mounted, lets use RMAN to perform recovery.

RMAN> connect catalog rman/password@snu14

RMAN-06008: connected to recovery catalog database

RMAN> connect target /


RMAN-06005: connected to target database: GAST (DBID=4222303827)

RMAN> run {
2> allocate channel ch1 type disk;
3> restore database;
4> recover database;
5> }

RMAN-03022: compiling command: allocate


RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: ch1
RMAN-08500: channel ch1: sid=11 devtype=DISK

RMAN-03022: compiling command: restore

RMAN-03022: compiling command: IRESTORE


RMAN-03023: executing command: IRESTORE
RMAN-08016: channel ch1: starting datafile backupset restore
RMAN-08502: set_count=13 set_stamp=447763812 creation_time=06-DEC-01
RMAN-08089: channel ch1: specifying datafile(s) to restore from backup set
RMAN-08523: restoring datafile 00001 to /edcsns18/oradata7/gast/system_gast.dbf
RMAN-08523: restoring datafile 00002 to /edcsns18/oradata7/gast/rbs_gast01.dbf
RMAN-08523: restoring datafile 00003 to /edcsns18/oradata7/gast/gast_data01.dbf
RMAN-08523: restoring datafile 00004 to /edcsns18/oradata7/gast/gast_data02.dbf
RMAN-08523: restoring datafile 00005 to /edcsns18/oradata8/gast/gast_index01.dbf
RMAN-08023: channel ch1: restored backup piece 1
RMAN-08511: piece
handle=/edcsns18/backup/oradata/gast/rman/GAST_full_bkup_447763812 tag=null
params=NULL
RMAN-08024: channel ch1: restore complete
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete

RMAN-03022: compiling command: recover

RMAN-03022: compiling command: recover(1)

RMAN-03022: compiling command: recover(2)

RMAN-03022: compiling command: recover(3)


RMAN-03023: executing command: recover(3)
RMAN-08054: starting media recovery
RMAN-08055: media recovery complete

RMAN-03022: compiling command: recover(4)


RMAN-08031: released channel: ch1

In order to recover the database, we first need to allocate a channel to our backup
set. We then restore the datafiles and then perform recovery. Finally, we release
the channel. At this point, the database has been fully recovered. But the
database is not yet open.

RMAN> run { sql 'alter database open'; }


RMAN-03022: compiling command: sql
RMAN-06162: sql statement: alter database open
RMAN-03023: executing command: sql

The database is now open for processing. This command could have also been
included in the restore operation.

You might also like