Configuring Rman Recovery Catalog

RMAN can be used either with or without a recovery catalog. A recovery catalog is a schema stored in a database that tracks backups and stores scripts for use in RMAN backup and recovery situations. Generally, an experienced DBA would suggest that the Enterprise Manager instance schema and RMAN catalog schema be placed in the same utility database on a server separate from the main servers. The RMAN schema generally only requires 15 megabyte per year per database backed up.

The RMAN schema owner is created in the RMAN database using the following steps:

1. Start SQL*Plus and connect as a user with administrator privileges to the database containing the recovery catalog. For example, enter:

CONNECT SYS/oracle@catdb AS SYSDBA

2. Create a user and schema for the recovery catalog. For example, enter:

CREATE USER rman IDENTIFIED BY cat
TEMPORARY TABLESPACE temp
DEFAULT TABLESPACE tools
QUOTA UNLIMITED ON tools;

3. Grant the recovery_catalog_owner role to the user. This role provides all of the privileges required to maintain and query the recovery catalog:

SQL> GRANT RECOVERY_CATALOG_OWNER TO rman;

Once the owner user is created, the RMAN recovery catalog schema can be added:

1. Connect to the database that contains the catalog owner. For example, using the RMAN user from the above example, enter the following from the operating system command line. The use of the CATALOG keyword tells Oracle this database contains the repository:

% rman CATALOG rman/cat@catdb

2. It is also possible to connect from the RMAN utility prompt:

% rman

RMAN> CONNECT CATALOG rman/cat@catdb

3. Now, the CREATE CATALOG command can be run to create the catalog. The creation of the catalog may take several minutes. If the catalog tablespace is this user's default tablespace, the command would look like the following:

CREATE CATALOG;

While the RMAN catalog can be created and used from either a 9i or 10g database, the Enterprise Manager Grid Control database must be a 9i database. This is true at least for release 1, although this may change with future releases.

Each database that the catalog will track must be registered.

Registering a Database with RMAN

The following process can be used to register a database with RMAN:

1. Make sure the recovery catalog database is open.

2. Connect RMAN to both the target database and recovery catalog database. For example, with a catalog database of RMANDB and user RMAN, owner of the catalog schema, and the target database, AULT1, which is the database to be backed up, database user SYS would issue:

% rman TARGET sys/oracle@ault1 CATALOG rman/cat@rmandb

3. Once connected, if the target database is not mounted, it should be opened or mounted:

RMAN> STARTUP;

--or--

RMAN> STARTUP MOUNT;

4. If this target database has not been registered, it should be registered it in the connected recovery catalog:

RMAN> REGISTER DATABASE;

The database can now be operated on using the RMAN utility.

Example RMAN Operations

The following is an example of the command line connection to a RAC environment, assuming the RAC instances are AULT1 and AULT2:

$ rman TARGET SYS/kr87m@ault2 CATALOG rman/cat@rmandb

The connection string, in this case AULT2, can only apply to a single instance, so the entry in the tnsnames.ora for the AULT2 connection would be:

ault2 =
(DESCRIPTION =
(ADDRESS_LIST =
(LOAD_BALANCE = OFF)
(FAILOVER = ON)
(ADDRESS = (PROTOCOL = TCP)(HOST = aultlinux2)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = ault)
(INSTANCE_NAME = ault2)
)

If the instances use archive logs, RAC requires that a channel connection be specified for each instance that will resolve to only one instance. For example, using the AULT1 and AULT2 instances from the previous example:

CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE DEVICE TYPE TO sbt PARALLELISM 2;
CONFIGURE CHANNEL 1 DEVICE TYPE sbt CONNECT = 'SYS/kr87m@ault1';
CONFIGURE CHANNEL 2 DEVICE TYPE sbt CONNECT = 'SYS/kr87m@ault2';

This configuration only has to be specified once for a RAC environment. It should be changed only if nodes are added or removed from the RAC configuration. For this reason, it is known as a persistent configuration, and it need never be changed for the life of the RAC system. This configuration requires that each of the specified nodes be open, the database is operational, or closed, the database shutdown. If one specified instance is not in the same state as the others, the backup will fail.

RMAN is also aware of the node affinity of the various database files. The node with the greatest access will be used to backup those datafiles that the instance has greatest affinity for. Node affinity can, however, be overridden with manual commands, as follows:

BACKUP
#Channel 1 gets datafiles 1,2,3
(DATAFILE 1,2,3 CHANNEL ORA_SBT_TAPE_1)
#Channel 2 gets datafiles 4,5,6,7
(DATAFILE 4,5,6,7 CHANNEL ORA_SBT_TAPE2)

The nodes chosen to backup an Oracle RAC cluster must have the ability to see all of the files that require backup. For example:

BACKUP DATABASE PLUS ARCHIVELOG;

The specified nodes must have access to all archive logs generated by all instances. This could entail some special considerations when configuring the Oracle RAC environment.

The essential steps for using RMAN in Oracle RAC are:

* Configure the snapshot control file location.

* Configure the control file autobackup feature.

* Configure the archiving scheme.

* Change the archivemode of the database, although this is optional.

* Monitor the archiver process.

The following section will show how the snapshot control file location is configured.

clone Oracle database using rman

Clone an Oracle database using RMAN duplicate (same server)
tnsManager - Distribute tnsnames the easy way and for free!

This procedure will clone a database onto the same server using RMAN duplicate.

* 1. Backup the source database.
To use RMAN duplicate an RMAN backup of the source database is required. If there is already one available, skip to step 2. If not, here is a quick example of how to produce an RMAN backup. This example assumes that there is no recovery catalog available:

rman target sys@ nocatalog

backup database plus archivelog format '/u01/ora_backup/rman/%d_%u_%s';

This will backup the database and archive logs. The format string defines the location of the backup files. Alter it to a suitable location.

* 2. Produce a pfile for the new database
This step assumes that the source database is using a spfile. If that is not the case, simply make a copy the existing pfile.

Connect to the source database as sysdba and run the following:

create pfile='init.ora' from spfile;

This will create a new pfile in the $ORACLE_HOME/dbs directory.

The new pfile will need to be edited immediately. If the cloned database is to have a different name to the source, this will need to be changed, as will any paths. Review the contents of the file and make alterations as necessary.

Because in this example the cloned database will reside on the same machine as the source, Oracle must be told how convert the filenames during the RMAN duplicate operation. This is achieved by adding the following lines to the newly created pfile:

db_file_name_convert=(,)
log_file_name_convert=(,)

Here is an example where the source database scr9 is being cloned to dg9a. Note the trailing slashes and lack of quotes:

db_file_name_convert=(/u01/oradata/scr9/,/u03/oradata/dg9a/)
log_file_name_convert=(/u01/oradata/scr9/,/u03/oradata/dg9a/)


* 3. Create bdump, udump & cdump directories
Create bdump, udump & cdump directories as specified in the pfile from the previous step.

* 4. Add a new entry to oratab, and source the environment
Edit the /etc/oratab (or /opt/oracle/oratab) and add an entry for the new database.

Source the new environment with '. oraenv' and verify that it has worked by issuing the following command:

echo $ORACLE_SID

If this doesn't output the new database sid go back and investigate why not.

* 5. Create a password file
Use the following command to create a password file (add an appropriate password to the end of it):

orapwd file=${ORACLE_HOME}/dbs/orapw${ORACLE_SID} password=

* 6. Duplicate the database
From sqlplus, start the instance up in nomount mode:

startup nomount

Exit sqlplus, start RMAN and duplicate the database. As in step 1, it is assumed that no recovery catalog is available. If one is available, simply amend the RMAN command to include it.

rman target sys@ nocatalog auxiliary /

duplicate target database to ;

This will restore the database and apply some archive logs. It can appear to hang at the end sometimes. Just give it time - I think it is because RMAN does a 'shutdown normal'.

If you see the following error, it is probably due to the file_name_convert settings being wrong. Return to step 2 and double check the settings.

RMAN-05001: auxiliary filename '%s' conflicts with a file used by the target database

Once the duplicate has finished RMAN will display a message similar to this:

database opened
Finished Duplicate Db at 26-FEB-05

RMAN>

Exit RMAN.

* 7. Create an spfile
From sqlplus:

create spfile from pfile;

shutdown immediate
startup

Now that the clone is built, we no longer need the file_name_convert settings:

alter system reset db_file_name_convert scope=spfile sid='*'
/

alter system reset log_file_name_convert scope=spfile sid='*'
/

* 8. Optionally take the clone database out of archive log mode
RMAN will leave the cloned database in archive log mode. If archive log mode isn't required, run the following commands from sqlplus:

shutdown immediate
startup mount
alter database noarchivelog;
alter database open;

* 9. Configure TNS
Add entries for new database in the listener.ora and tnsnames.ora as necessary.