6
Getting Started with Recovery Manager

This chapter is a "quick start" to using Recovery Manager, and includes the following topics:

Decisions to Make Before Using Recovery Manager

You will need to make the following decisions before you start using Recovery Manager:

Will You Use a Recovery Catalog?

There are costs and benefits associated with using and not using a Recovery Catalog. Following is a brief overview of some of these costs and benefits.

Costs and Benefits When Using a Recovery Catalog

When you use a recovery catalog, Recovery Manager can perform a wider variety of automated backup and recovery functions; however, Recovery Manager requires that you maintain a recovery catalog schema, and any associated space used by that schema.

If you use a recovery catalog, you must decide which database you will use to install the recovery catalog schema, and also how you will back this database up.

The size of the recovery catalog schema:

is dependent on the number of databases monitored by the catalog
is dependent on the number and size of Recovery Manager scripts stored in the catalog
will grow as the numbers of archived logs and backups for each database grow

If you use Recovery Manager to back up many databases, you may wish to create a separate recovery catalog database, and create the Recovery Manager user in that database. You should also decide whether or not to operate this database in ARCHIVELOG mode.

If you store the recovery catalog in a separate database, you will require a small amount of disk space for the following:

system
temp
rollback segment tablespaces
online redo log

An additional benefit of maintaining a separate recovery catalog is that it is only unavailable at the DBA's discretion. Most of the space used in this database is devoted to supporting tablespaces (for example, system, temp, and rollback).

Table 6-1 lists typical space requirements for 1 year

Table 6-1: Typical Space Requirements for 1 Year

Type of Space	Space Requirement
system	50 megabytes
temp	5 megabytes
rollback	5 megabytes
recovery catalogt	10 megabytes
online logs	1 megabyte each (3 groups, each with 2 members)

If you have more than one database to back up, you can create more than one recovery catalog and have each database serve as the other's recovery catalog. For example, assume there are two production databases, one called "prd1," and a second called "prd2." You can install the recovery catalog for "prd1" in the "prd2" database, and the recovery catalog for the "prd2" database in "prd1." This enables you to avoid the extra space requirements and memory overhead of maintaining a separate recovery catalog database. However, this solution is not practical if the recovery catalog databases for both reside in tablespaces residing on the same physical disk.

Note: You must install the recovery catalog schema in a different database from the target database you will be backing up. If you don't, the benefits of using a recovery catalog are lost if you lose the database and need to restore.

Warning: Ensure that the recovery catalog and target databases do not reside on the same disks. If they are on the same disks and you lose one, you will most likely lose the other.

See Also: For more information, see "The Recovery Catalog" on page 7-5.

Costs and Benefits When not Using a Recovery Catalog

The following recovery features are not available when you do not use a recovery catalog:

point-in-time recovery
stored scripts
recovery when the control file is lost or damaged

In order to restore and recover your database without using a recovery catalog, Oracle recommends that you:

Use multiplexed control files (minimum of two), and have each control file on separate disks to protect against media failure.
Keep excellent record of what files were backed up, the date they were backed up, and also the names of the backup pieces each file was written to. Keep all Recovery Manager backup logs.

Warning: It is difficult to restore and recover if you lose your control files and do not use a recovery catalog. The only way to restore and recover when you have lost all control files and need to restore and recover datafiles, is to call Oracle WorldWide Customer Support (WWCS). WWCS will need to know the following:

current schema of the database
which files were backed up
what time the files were backed up
names of the backup pieces containing the files

Oracle recommends using Recovery Manager with a recovery catalog.

Setting Up the Recovery Catalog Schema

When you use a recovery catalog, you need to set up the schema. Oracle suggests you put the recovery catalog schema in its own tablespace; however, it could be put in the system tablespace, if necessary.

To Set Up the Recovery Catalog Schema

Using Server Manager (LineMode) connect internal (or as SYSDBA) to the database containing the recovery catalog.

Issue the following commands:

       spool create_rman.log
       connect internal
       create user rman identified by rman
       temporary tablespace temp 
       default tablespace rcvcat quota unlimited on rcvcat;
       grant recovery_catalog_owner to rman;
       connect rman/rman
       @?/rdbms/admin/catrman

Check the create_rman.log file for any errors before continuing.

Assume the following for the recovery catalog schema created here:

there is a tablespace called "rcvcat" that stores the recovery catalog
there is a tablespace called "temp"
the database is configured in the same way as all "normal" databases (for example, catalog.sql and catproc.sql have successfully run)

Note: You must not run catrman.sql script in the SYS schema. Run the catrman.sql script in the recovery catalog schema.

Also, you must install the recovery catalog schema in a different database from the target database you will be backing up. If you don't, the benefits of using a recovery catalog are lost if you lose the database and need to restore.

Warning: Ensure that the recovery catalog and target databases do not reside on the same disks; if they do and you lose one, you will most likely lose the other.

Decide When and How to Back Up the Recovery Catalog

It is important that you maintain regular backups of your recovery catalog--Oracle recommends a daily backup.

You should also use 2 different methods to back up your Recovery Catalog. For example, you could use Recovery Manager and the Export utility, or Recovery Manager and an operating system utility.

If you use Recovery Manager to back up the recovery catalog database, create a second recovery catalog in a separate database (such as the production database you are backing up). If you use the recovery catalog to back itself up, and lose this database due to media failure, you won't easily be able to restore it.

Decide How to Resynchronize the Recovery Catalog

You should automate recovery catalog resynchronizations so that a resychronization is performed at least once a day. If your site generates many archived logs each day, then you should resynchronize the catalog once an hour.

It typically takes a short amount of time to resynchronize the catalog, and the shorter the time lapse between resynchronizations, the faster the resynchronization process will be.

At least once a week verify that the automatic catalog resynchronization process you set up, works.

Note: You should manually resynchronize the catalog whenever you make any structural changes to the database (such as adding a file, or dropping a tablespace).

Decide Whether or Not to Use Password Files

Generally, you need to use a password file when connecting to the target database over a non-secure Net8 connection, especially when you do the following:

You run Recovery Manager remotely (from a different machine than the database you wish to back up). For example, if you choose to use Oracle Enterprise Manager - Backup Manager GUI
You wish to use Recovery Manager, and use a TNS alias in the connect string for the target database.
You have a Parallel Server database, and wish to backup this database from more than one node in the cluster concurrently, while using only one Recovery Manager session.

See Also: The Oracle8 Parallel Server Guide, Backup and Recovery chapter for an example backup distributed over two nodes in an OPS cluster.

Decide How to Back Up init.ora Files and Password Files

Recovery Manager does not back up init.ora and password files. You must plan how you will protect these files from media failure.

Recovery Manager Connection Options

This section includes the following sample Recovery Manager connection options:

Note: The examples in this section are not used with Oracle Enterprise Manager Backup Manager GUI. Also, there are many more Recovery Manager connection options than shown in the examples here.

To Perform a General Connect to Recovery Manager

The following is the general form of the Recovery Manager connect string:

rman target internal/<pwd>@prd1 rcvcat rman/rman@rcat

Connecting to Recovery Manager Without a Recovery Catalog

In this example, assume that:

the target database is called "prod1" (and has the same TNS alias)
"scott" has been granted SYSDBA privileges (password is "tiger")

If the target database does not have a password file, the user you are logged in as must be validated using O/S authentication (similar to svrmgrl, and connect internal).

To Connect to Recovery Manager Without Password Files

Set your ORACLE_SID to be the target database, and issue the following statement:

rman nocatalog 
RMAN> connect target

To Connect to Recovery Manager With Password Files

If the target database uses password files, you can connect using:

rman target internal/kernel@prod1 nocatalog

rman nocatalog
RMAN> connect target internal/kernel@prod1

Recovery Manager automatically requests a connection to the target database as SYSDBA.

If you wish to connect as a DBA user who has SYSDBA privileges, issue the following statement:

rman target scott/tiger@prod1 nocatalog

Connecting to Recovery Manager With a Recovery Catalog

In this example, assume that:

the recovery catalog database is called "rcat" (and has the same TNS alias)
the schema containing the recovery catalog is "rman" (password is "rman")
the target database is called "prod1" (and has the same TNS alias)
"scott" has been granted SYSDBA privileges (password is "tiger")

To Perform a Connect Using Password Files

In the following statement the administrator is connecting using password files for the target database, and the password to connect internal is `kernel'.

rman target internal/kernel@prod1 rcvcat rman/rman@rcat

To Perform a Connect Without Using Password Files

In this statement Recovery Manager is running on the same machine as the target database. The administrator starts Recovery Manager by setting the ORACLE_SID to the target instance, then issuing the following statement:

rman rcvcat rman/rman@rcat
RMAN> connect target

To Connect as a Specific User with SYSDBA

Here, Recovery Manager automatically requests a connection to the target database as SYSDBA using O/S authentication, not a password file:

rman target scott/tiger@prod1 rcvcat rman/rman@rcat

Running Recovery Manager Commands

This section includes the following topics:

Catalog maintenance commands are executed outside of a run command as follows:

rman target internal/kernel@prod1 rcvcat rman/rman@rcat
RMAN> resync catalog;

Commands such as backup, restore, and allocate must be executed within a run command as follows:

rman target internal/kernel@prod1 rcvcat rman/rman@rcat
RMAN> run {
2> allocate channel c1 type disk;
3> copy datafile 5 to `/dev/backup/prod1/prod1_tab7.dbf';
4> }

Running Recovery Manager Commands Interactively: Example 1

To run Recovery Manager commands interactively, you need to start Recovery Manager, then type the commands into the command line interface, as follows:

     rman target internal/kernel@prod1 rcvcat rman/rman@rcat
     RMAN> register database;
     RMAN> run {
     2>   allocate channel d1 type disk;
     3>   allocate channel d2 type disk;
     4>   allocate channel d3 type disk;
     5>   backup
     6>     incremental level 0
     7>     tag db_level_0
     8>     filesperset 6
     9>     format `/dev/backup/prod1/df/df_t%t_s%s_p%p'
     10>     (database);
     11>    sql `alter system archive log current';
     12>    backup
     13>     filesperset 20
     14>     format `/dev/backup/prod1/al/al_t%t_s%s_p%p'
     15>     (archivelog all
     16>      delete input);
     17> }

Using Command Files: Example 2

You can type Recovery Manager commands into a file, and then run the command file by specifying its name on the command line.

The contents of the command file should be identical to commands entered at the command line.

Here, the Recovery Manager script from Example 1 has been placed into a file (called" b_whole_l0.rcv"). This file is run from the command line as follows.

rman target internal/kernel@prod1 rcvcat rman/rman@rcat cmdfile 
b_whole_l0.rcv

Using Stored Scripts: Example 3

A stored script is a set of Recovery Manager commands (enclosed in braces) that are stored in the recovery catalog. A stored script only relates to one database. You cannot use stored scripts if you do not use a recovery catalog.

To create a stored script, you can either enter your script interactively into the Recovery Manager command line interface (as in Example 1), or type your Recovery Manager commands into a command file, and run the command file (as in Example 2).

Following is a stored script:

     replace script b_whole_l0 {
     # Backup Whole database, and archived logs
       allocate channel d1 type disk;
       allocate channel d2 type disk;
       allocate channel d3 type disk;
       backup
         incremental level 0
         tag b_whole_l0
         filesperset 6
         format `/dev/backup/prod1/df/df_t%t_s%s_p%p'
          (database);
         sql `alter system archive log current';
         backup
          filesperset 20
          format `/dev/backup/prod1/al/al_t%t_s%s_p%p'
          (archivelog all
           delete input);
     }

Specifying Time Parameters in Recovery Manager

Before invoking Recovery Manager, set the NLS_DATE_FORMAT and NLS_LANG environment variables. These variables specify the format used for the time parameters in Recovery Manager commands, such as:

restore and recover
report

The following example shows typical environment variables:

NLS_LANG=american
NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS'

Note: Both NLS_LANG and NLS_DATE_FORMAT must be set for NLS_DATE_FORMAT to be used.

Recovery Manager Sample Scripts and Scenarios

There are a number of sample scripts in the RDBMS demo directory. These files are executable Recovery Manager command files and are fully commented to explain the features used. You can edit them to customize them for your site.

The file case1.rcv creates a number of stored scripts that back up, restore and recover a database. These scripts are typical of how some DBAs back up their databases, and you can use them as a starting point for developing backup, restore and recovery scripts.

The following files contain either a backup or recovery scenario. These scripts show more of the Recovery Manager syntax flexibility and power than appears in the sample scripts:

case2.rcv - incomplete recovery
case3.rcv - disaster recovery
case4.rcv - consistent backup

See Also: Additional backup and recovery scenarios are in Chapter 9, "Recovery Manager Scenarios" .

Prerequisites for Performing Backups to Tape

To back up to and restore from sequential media, such as tape, you must have a Media Manager integrated with Oracle.

This section includes the following topics:

Linking with a Media Manager

To integrate Oracle with a Media Manager, you must:

have Media Manager software and hardware installed and configured
obtain that Media Management Vendor's library interface software (Media Managment Library) from that Vendor

The Media Management Library (MML) is then linked with the Oracle kernel software. This enables Oracle server processes to call the Media Manager.

Note: For instructions on how to achieve this on your platform, see your operating system-specific Oracle documentation and the documentation supplied by your Media Manager.

Generating Unique File Names

You should use the substitution variables provided by Recovery Manager to generate unique backup piece names when writing backups to a Media Manager. A backup piece name is determined by the format string specified either in the backup command, or in the allocate channel command.

The Media Manager considers the backup piece name as the `file name backed up', so this name must be unique in the Media Manager catalog.

Warning: When a backup generates a file whose name already exists in the Media Manager's catalog, the original file having that name is deleted.

You can use the following substitution variables to make unique format strings:

%d - database name (uppercase)

%t - backup set stamp

%s - backup set number

%p - piece number in the set

%u - an 8 character id composed of compressed representations of the backup set number and the time the backup set was created

Note: Some Media Managers only support a 14-character backup piece name. See your Media Management documentation to determine the limit for your Media Manager.

Know Your Media Manager's Maximum File Size Limit

Some Media Managers have limits on the maximum size of files they can back up or restore.

As Recovery Manager multiplexes multiple datafiles into one output file (one backup piece), it is possible that the piece size is in excess of the size that many Media Managers or file systems are able to store.

To avoid problems,find out what operational limits on file sizes exist, and ensure the files written out by Recovery Manager do not exceed these limits.To limit backup piece file sizes, use the keyword kbytes in a setlimit channel command (see scenario case1.rcv in the demo directory for an example).

6 Getting Started with Recovery Manager