Oracle8 Backup and Recovery Guide
Release 8.0

A58396-01

Library

Product

Contents

Index

Prev Next

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:

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:

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 Recovery Catalog Space Requirements for 1 Year
Type of Space   Space Requirement  

system

 

50 megabytes

 

temp

 

5 megabytes

 

rollback

 

5 megabytes

 

recovery catalog

 

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 Chapter 7, "Recovery Manager Concepts".

Costs and Benefits When not Using a Recovery Catalog

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

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

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

  1. Using Server Manager (LineMode) connect internal (or as SYSDBA) to the database containing the recovery catalog.
  2. 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:

    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:

    See Also: Oracle8 Parallel Server Concepts and Administration, for an example of a 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:

    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:

    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
    

    or

    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:

    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:

    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:

    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).




    Prev

    Next
    Oracle
    Copyright © 1997 Oracle Corporation.

    All Rights Reserved.

    Library

    Product

    Contents

    Index