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: RMAN-03023: RMAN-08006: RMAN-03023: compiling command: register executing command: register database registered in recovery catalog 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. 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. All rights reserved.

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: RMAN-03023: RMAN-08002: RMAN-08004: compiling command: resync executing command: resync starting full resync of recovery catalog 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 DB Key ------248 107 Database Incarnations Inc Key DB Name DB ID ------- -------- ---------------249 GASR 4162675397 108 GAST 4222303827 CUR --YES YES Reset SCN ---------1 1 Reset Time ---------20-SEP-01 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: RMAN-03023: RMAN-08030: RMAN-08500: compiling command: allocate executing command: allocate allocated channel: disk1 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: RMAN-06162: RMAN-03023: RMAN-08031: compiling command: sql sql statement: ALTER SYSTEM ARCHIVE LOG CURRENT executing command: sql 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 ---------%d %t %u %c %p %s

Meaning -------------------------------------Database name (SID) Timestamp Unique name/number generated by Oracle Copy number Backup piece # 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: RMAN-03023: RMAN-08003: RMAN-08005: backup set complete, elapsed time: 00:02:46 executing command: partial resync starting partial resync of recovery catalog 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: RMAN-03023: RMAN-08030: RMAN-08500: RMAN-03022: RMAN-03024: RMAN-03023: RMAN-08002: RMAN-08004: RMAN-03023: RMAN-08008: RMAN-08502: RMAN-08010: RMAN-08522: RMAN-08522: RMAN-08013: compiling command: allocate executing command: allocate allocated channel: disk1 channel disk1: sid=11 devtype=DISK compiling command: backup performing implicit full resync of recovery catalog executing command: full resync starting full resync of recovery catalog full resync complete executing command: backup channel disk1: starting full datafile backupset set_count=5 set_stamp=446313819 creation_time=20-NOV-01 channel disk1: specifying datafile(s) in backupset input datafile fno=00003 name=/edcsns18/oradata7/gast/gast_data01.dbf input datafile fno=00004 name=/edcsns18/oradata7/gast/gast_data02.dbf 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: RMAN-03023: RMAN-08030: RMAN-08500: compiling command: allocate executing command: allocate allocated channel: disk1 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>

} compiling command: allocate executing command: allocate allocated channel: disk1 channel disk1: sid=11 devtype=DISK

RMAN-03022: RMAN-03023: RMAN-08030: RMAN-08500:

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 ---------1 2 3 4 5 6 7 DAY -------------11/06/01 12:47 11/06/01 14:04 11/06/01 14:39 11/07/01 14:06 11/08/01 11:48 11/08/01 11:48 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> 4> 5>

'/edcsns18/backup/oradata/gast/rman/%d_redologs'; backup archivelog all; } compiling command: allocate executing command: allocate allocated channel: disk1 channel disk1: sid=11 devtype=DISK

RMAN-03022: RMAN-03023: RMAN-08030: RMAN-08500:

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: RMAN-03023: RMAN-08030: RMAN-08500: RMAN-03022: RMAN-03023: RMAN-08009: RMAN-08502: RMAN-08014: compiling command: allocate executing command: allocate allocated channel: disk1 channel disk1: sid=11 devtype=DISK compiling command: backup executing command: backup channel disk1: starting archivelog backupset set_count=9 set_stamp=446315058 creation_time=20-NOV-01 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: RMAN-03023: RMAN-08030: RMAN-08500: compiling command: allocate executing command: allocate allocated channel: disk1 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: RMAN-03023: RMAN-08030: RMAN-08500: compiling command: allocate executing command: allocate allocated channel: disk1 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 Key ------223 Backup Sets Recid Stamp LV Set Stamp Set Count Completion Time ---------- ---------- -- ---------- ---------- ---------------------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 Key ------234 Backup Sets Recid Stamp LV Set Stamp Set Count Completion Time ---------- ---------- -- ---------- ---------- ---------------------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 Key ------234 Backup Sets Recid Stamp LV Set Stamp Set Count Completion Time ---------- ---------- -- ---------- ---------- ---------------------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 Key ------9330 Backup Sets Recid Stamp LV Set Stamp Set Count Completion Time ---------- ---------- -- ---------- ---------- ---------------------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 File ---3 of Datafiles Included Name LV Type Ckp SCN Ckp Time ------------------------------------- -- ---- ---------- ------------/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: RMAN-03023: RMAN-08030: RMAN-08500: compiling command: allocate executing command: allocate allocated channel: delete 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: RMAN-03023: RMAN-08030: RMAN-08500: compiling command: allocate executing command: allocate allocated channel: disk1 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: RMAN-03023: RMAN-08003: RMAN-08005: RMAN-03022: RMAN-06162: RMAN-03023: RMAN-08031:

backup set complete, elapsed time: 00:02:06 executing command: partial resync starting partial resync of recovery catalog partial resync complete compiling command: sql sql statement: ALTER SYSTEM ARCHIVE LOG CURRENT executing command: sql 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 Fixed Size Variable Size Database Buffers Redo Buffers Database mounted.

13197472 73888 4841472 8192000 90112

bytes bytes bytes bytes bytes

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: RMAN-03023: RMAN-08030: RMAN-08500: compiling command: allocate executing command: allocate allocated channel: ch1 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: RMAN-03023: RMAN-08054: RMAN-08055: compiling command: recover(3) executing command: recover(3) starting media recovery 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.