Release 8.0
A58396-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8 Backup and Recovery Guide Release 8.0 A58396-01 |
|
This chapter is a "quick start" to using Recovery Manager, and includes the following topics:
You will need to make the following decisions before you start using Recovery Manager:
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.
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
| 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.
|
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".
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:
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.
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
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. |
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.
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). |
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.
Recovery Manager does not back up init.ora and password files. You must plan how you will protect these files from media failure.
This section includes the following sample Recovery Manager connection options:
The following is the general form of the Recovery Manager connect string:
rman target internal/<pwd>@prd1 rcvcat rman/rman@rcat
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).
Set your ORACLE_SID to be the target database, and issue the following statement:
rman nocatalog RMAN> connect target
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
In this example, assume that:
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
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
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
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> }
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> }
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
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); }
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'
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".
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:
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. |
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
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).
