Oracle Faq

Configuring the RMAN Snapshot Control File Location

The snapshot control file is a temporary snapshot control file that RMAN creates to re-synchronize from a read-consistent version of the control file. RMAN only needs a snapshot control file when re-synchronizing with the recovery catalog or when making a backup of the current control file. In RAC, the snapshot control file is only needed on the nodes on which RMAN performs backups; the snapshot control file does not need to be globally available to all instances in a RAC environment. Run the following RMAN command to determine the configured location of the snapshot control file:

SHOW SNAPSHOT CONTROLFILE NAME;

You can change the configured location of the snapshot control file. For example, on UNIX-based systems you can specify the snapshot control file location as $ORACLE_HOME/dbs/scf/snap_prod.cf by entering the following at the RMAN prompt:

CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘$ORACLE_HOME/dbs/scf/snap_prod.cf’;

This command globally sets the configuration for the location of the snapshot control file throughout your cluster database. Therefore, ensure that the directory $ORACLE_HOME/dbs/scf exists on all nodes that perform backups.

Configuring the RMAN Control File and SPFILE Autobackup Feature

If you set CONFIGURE CONTROLFILE AUTOBACKUP to ON, then RMAN automatically creates a control file and an SPFILE backup after you run the BACKUP or COPY commands. RMAN can also automatically restore an SPFILE if this is required to start
an instance to perform recovery. This means that the default location for the SPFILE must be available to all nodes in your RAC database.

CONFIGURE CONTROLFILE AUTOBACKUP to ON

These features are important in disaster recovery because RMAN can restore the control file even without a recovery catalog. RMAN can restore an autobackup of the control file even after the loss of both the recovery catalog and the current control file. You can change the default name that RMAN gives to this file with the CONFIGURE CONTROLFILE AUTOBACKUP FORMAT command. Note that if you specify an absolute path name in this command, then this path must exist identically on all nodes that participate in backups.

RMAN performs the control file autobackup on the first allocated channel. Therefore, when you allocate multiple channels with different parameters, especially when you allocate a channel with the CONNECT command, determine which channel will
perform the control file autobackup. Always allocate the channel for this node first.

Configuring Channels for RMAN in Real Application Clusters

Configuring Channels to use Automatic Workload Balancing To configure channels to use automatic load balancing, use the following syntax:

CONFIGURE DEVICE TYPE [disk | sbt] PARALLELISM number of channels;

Where number of channels is the number of channels that you want to use for the operation. After you complete this one-time configuration, you can issue BACKUP or RESTORE commands.

Configuring Channels to Use a Specific Channel

To configure channels to use a specific channel, use the following syntax:

CONFIGURE CHANNEL DEVICE TYPE sbt CONNECT ‘SYS/change_on_install@node1′
CONFIGURE CHANNEL DEVICE TYPE sbt CONNECT ‘SYS/change_on_install@node2′

After this one-time configuration step, you can issue the BACKUP or RESTORE commands. In addition, you can use the PARMS command in this example to set vendor-specific parameters.

fter your RMAN configuration is operative in your RAC environment, use the GV$ARCHIVE_PROCESSES and V$ARCHIVE_PROCESSES views to determine the status of the archiver processes. Depending on whether you query the global or local views, these views display information for all database instances, or for only the instance to which you are connected.

Managing Backup and Recovery

Cluster File System Restore Scheme

The scheme that this section describes assumes that you are using the “Automatic Storage Management and Cluster File System Archiving Scheme” on page 7-5. In this scheme, assume that node 3 performed the backups to a CFS. If node 3 is available for the restore and recovery operation, and if all of the archived logs have been backed up or are on disk, then run the following commands to perform complete recovery:

RESTORE DATABASE;
RECOVER DATABASE;

If node 3 performed the backups but is unavailable, then configure a media management device for one of the remaining nodes and make the backup media from node 3 available to this node.

Channel Connections to Cluster Instances

Channel connections to the instances are determined using the connect string defined by channel configurations. For example, in the following configuration, three channels are allocated using user1/pwd1@service_name. If you configure the SQL Net service name with load balancing turned on, then he channels are allocated at a node as decided by the load balancing algorithm.

CONFIGURE DEVICE TYPE sbt PARALLELISM 3;
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
CONFIGURE CHANNEL DEVICE TYPE SBT CONNECT ‘user1/pwd1@‘

However, if the service name used in the connect string is not for load balancing, then you can control at which instance the channels are allocated using separate connect strings for each channel configuration as follows:

CONFIGURE DEVICE TYPE sbt PARALLELISM 3;
CONFIGURE CHANNEL 1.. CONNECT ‘user1/pwd1@node1′;
CONFIGURE CHANNEL 2.. CONNECT ‘user2/pwd2@node2′;
CONFIGURE CHANNEL 3.. CONNECT ‘user3/pwd3@node3′;

In the previous example, it is assumed that node1, node2 and node3 are SQL Net service names that connect to pre-defined nodes in your RAC environment. Alternatively, you can also use manually allocated channels to backup your database files. For example, the following command backs up the spfile, controlfile, datafiles and archived logs:

RUN
{
ALLOCATE CHANNEL CH1 CONNECT ‘user1/pwd1@node1′;
ALLOCATE CHANNEL CH2 CONNECT ‘user2/pwd2@node2′;
ALLOCATE CHANNEL CH3 CONNECT ‘user3/pwd3@node3′;
BACKUP DATABASE PLUS ARCHIVED LOG;
}

During a backup, the instances to which the channels connect must be either all mounted or all open. For example, if the node1 instance has the database mounted while the node2 and node3 instances have the database open, then the backup fails.

Deleting Archived Redo Logs after a Successful Backup

Assuming that you have configured the automatic channels as defined in section “Channel Connections to Cluster Instances” on page 8-4, you can use the following example to delete the archived logs that you backed up n times. The device type can
be DISK or SBT:

DELETE ARCHIVELOG ALL BACKED UP n TIMES TO DEVICE TYPE device_type;

During a delete operation, as long as at least one of the channels allocated has access to the archived log, RMAN will automatically schedule the deletion of the specific log on that channel. For a local archiving scheme, there must be at least one channel allocated that can delete an archived log. For a CFS archiving scheme, assuming that every node writes to the archived logs on the same CFS, the archived log can be deleted by any allocated channel.

If you have not configured automatic channels, then you can manually allocate the maintenance channels as follows and delete the archived logs.

ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT ‘SYS/oracle@node1′;
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT ‘SYS/oracle@node2′;
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT ‘SYS/oracle@node3′;
DELETE ARCHIVELOG ALL BACKED UP n TIMES TO DEVICE TYPE device_type;

Share This