Skip Headers

Oracle9i Real Application Clusters Administration
Release 2 (9.2)

Part Number A96596-01
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback

Go to previous page Go to next page

6
Using Recovery Manager in Real Application Clusters Environments

This chapter explains how to use Recovery Manager (RMAN) in Real Application Clusters environments. The topics in this chapter include:

Configuring RMAN in Real Application Clusters: Overview

Perform the procedures described in this chapter after installing the Oracle Enterprise Edition with Oracle Real Application Clusters and after reviewing the following documentation:

The configuration procedures described in this chapter explain how to:

  1. Configure the snapshot control file location.
  2. Configure the control file autobackup feature.
  3. Configure the archiving scheme.
  4. Change the archiving mode of the database (optional)
  5. Monitor the archiver processes.

Configuring the RMAN Snapshot Control File Location

In Real Application Clusters, identical copies of the snapshot control file must exist on every node that performs backups. Therefore, ensure that the same destination directory for a snapshot control file exists on all nodes used for backups.

RMAN creates a snapshot control file to obtain a consistent record of the contents of the target control file before making a backup. RMAN creates the snapshot control file on the node that performs backups. Run the following RMAN command to determine the default location of the snapshot control file:

SHOW SNAPSHOT CONTROLFILE NAME;

If needed, you can change the default location. For example, on UNIX 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 '?/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.

The CONFIGURE command creates persistent settings that are in effect across RMAN sessions. Therefore, you do not need to execute this command again unless you want to change the location of the snapshot control file.


Note:

You can also specify a cluster file system (CFS) file or a raw device destination for the location of your snapshot control file. This file is shared across all nodes in the cluster just like other datafiles in Real Application Clusters.


See Also:

Oracle9i Recovery Manager User's Guide for more information about configuring the snapshot control file

Configuring the RMAN Control File Autobackup Feature

The RMAN control file autobackup feature automatically creates backups of the control file after executing the BACKUP and COPY commands. This feature is important in disaster recovery because RMAN can restore the control file even without a recovery catalog.

If you set CONFIGURE CONTROLFILE AUTOBACKUP to ON, then RMAN automatically creates a control file and a server parameter file backup after you run the BACKUP or COPY commands. 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 on all nodes that perform 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.

See Also:

Oracle9i Recovery Manager User's Guide for more information about using the control file autobackup feature

Managing Archived Logs in Real Application Clusters Environments

After configuring the snapshot control file location and enabling the control file autobackup feature, decide how to configure your environment to manage the archived logs that each node generates.

When a cluster node generates an archived log, Oracle always records the filename of the log in the control file of the target database. If you are using a recovery catalog, then RMAN also records the archived log filenames in the recovery catalog when a resynchronization occurs.

The archived log naming scheme that you use is important because when a node writes to a log with a specific filename on its file system, the file must be readable by any node that needs to access this log. For example, if node 1 archives a log to /oracle/arc_dest/log_1_100.arc, then node 2 can only back up this log if it can read/oracle/arc_dest/log_1_100.arc on its own file system.

The backup and recovery strategy that you choose depends on how you configure the archiving destinations for each node. Whether only one node performs archived log backups or all nodes perform archived log backups, you need to ensure that all logs are backed up. Because only one instance can perform recovery, the node performing recovery must have read access to all logs in your cluster.

Archiving in a Real Application Cluster Environment

Your primary configuration task is to ensure that all archived redo logs can be read from every node during recovery, and if possible during backups. This scenario illustrates the archived log naming issues for configuring archiving in your cluster database.

In this scenario, assume that the following conditions are met:

Configure the initialization parameters file as:

sid1.log_archive_dest_1 = (location=/arc_dest)
sid2.log_archive_dest_1 = (location=/arc_dest)
sid3.log_archive_dest_1 = (location=/arc_dest)

Assume that the filenames of the archived logs are recorded in the control file as follows:

/arc_dest/log_1_62.arc 
/arc_dest/log_2_100.arc
/arc_dest/log_2_101.arc
/arc_dest/log_3_70.arc

/arc_dest/log_1_63.arc

Given this scenario, assume that your Real Application Clusters database performs recovery. If node 1 tries to read the logs for recovery, then it searches its local /arc_dest directory for the filenames as they are recorded in the control file. Using this data, node 1 only finds the logs that it archived locally, for example /arc_dest/log_1_62.arc and /arc_dest/log_1_63.arc. However, node 1 cannot apply the other logs because the filenames for these logs are not readable on its local file system. Thus, the recovery stalls. You can avoid this problem by configuring your cluster according to the schemes described in the following section.

RMAN Archiving Configuration Schemes

The two configuration schemes in this chapter describe a three-node UNIX system for a Real Application Clusters database. For both schemes, the LOG_ARCHIVE_FORMAT that you specify for the instance performing recovery must be the same as the format that you specified for the instances that archived the files.

In Real Application Clusters, set the same value for the LOG_ARCHIVE_FORMAT parameter on all instances. You can specify a different value of LOG_ARCHIVE_DEST_n during recovery if the archived redo log files are not at their original archiving destinations.

This section contains the following topics:

Cluster File System Archiving Scheme

The preferred configuration for Real Application Clusters is to use a cluster file system archiving scheme. As shown in Figure 6-1, each node writes to a single CFS archived log destination and can read the archived log files of the other nodes. Read access is achieved with a cluster file system. For example, if node 1 archives a log to /arc_dest/log_1_100.arc on the CFS, then any other node in the cluster can also read this file.


Note: :

In UNIX environments only, if you do not use a cluster file system, then the archived log files cannot be on the shared disk because UNIX shared disks are raw devices that you cannot easily partition for use with archived logs.


Figure 6-1 Cluster File System Archiving Scheme

Text description of racad006.gif follows
Text description of the illustration racad006.gif


Advantages and Disadvantages of the Cluster File System Archiving Scheme

The advantages of this scheme are:

Initialization Parameter Settings for the Cluster File System Archiving Scheme

In the CFS scheme, each node archives to a directory that is identified with the same name on all instances within the cluster database. To configure this, set values for the LOG_ARCH_DEST_n parameter for each instance using the sid designator as in the following example:

sid1.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest"
sid2.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest"
sid3.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest"

The following list shows archived log entry examples that would appear in the RMAN catalog or the in the control file based on the previous example. Note that any node can archive logs using any of the threads:

/arc_dest/arc_1_999.arc
/arc_dest/arc_1_1000.arc
/arc_dest/arc_1_1001.arc <- thread 1 archived in node 3
/arc_dest/arc_3_1563.arc <- thread 3 archived in node 2
/arc_dest/arc_2_753.arc <- thread 2 archived in node 1
/arc_dest/arc_2_754.arc
/arc_dest/arc_3_1564.arc

Location of Archived Logs for the Cluster File System Archiving Scheme

Because the file system is shared and because each node is writing its archived logs to directory /arc_dest in the cluster file system, each node can read the logs written by itself as well as any other node.

Non-CFS Local Archiving Scheme

In the non-CFS local archiving scheme, each node archives to a uniquely named local directory as shown in Figure 6-2. If recovery is required, then you can configure the recovery node so that it can access directories on the other nodes remotely. For example, use NFS on UNIX or shared drives on Windows platforms. Therefore, each node writes only to a local destination, but each node can also read archived log files in remote directories on the other nodes.

Figure 6-2 Non-CFS Local Archiving Scheme

Text description of rmanopsa.gif follows
Text description of the illustration rmanopsa.gif


To enable RMAN to back up and recover a Real Application Clusters database in one step, all archived logs must have uniquely identifiable names throughout the cluster. To do this, however, you cannot use the technique described in "Cluster File System Archiving Scheme" to have more than one node archive to a directory such as /arc_dest.


Note: :

In UNIX environments only, the archived log files cannot be on the shared disk because UNIX shared disks are raw devices that you cannot easily partition for use with archived logs.


Advantages and Disadvantages of the Non-CFS Local Archiving Scheme

The advantage of this scheme is:

The disadvantages of this scheme are:

Initialization Parameter Settings for the Non-CFS Local Archiving Scheme

You can set the archiving destination values as follows in the initialization parameter file:

sid1.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest_1"
sid2.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest_2"
sid3.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest_3"

The following list shows possible archived log entries in the database control file. Note that any node is able to archive logs from any of the threads:

/arc_dest_1/arc_1_1000.arc
/arc_dest_2/arc_1_1001.arc <- thread 1 archived in node 2
/arc_dest_2/arc_3_1563.arc <- thread 3 archived in node 2
/arc_dest_1/arc_2_753.arc <- thread 2 archived in node 1
/arc_dest_2/arc_2_754.arc
/arc_dest_3/arc_3_1564.arc

Location of Archived Logs in the Non-CFS Local Archiving Scheme

As illustrated in Table 6-1, each node has a directory containing the locally archived logs. Additionally, if you mount directories on the other nodes remotely through NFS or shared drives, then each node has two remote directories through which RMAN can read the archived log files that are archived by the remaining nodes in the cluster.

Table 6-1 Location of Logs in the Non-CFS Local Archiving Scheme
Node ... Can read the archived log files in the directory ... For logs archived by node ...

1

/arc_dest_1

1

1

/arc_dest_2

2 (through NFS)

1

/arc_dest_3

3 (through NFS)

2

/arc_dest_1

1 (through NFS)

2

/arc_dest_2

2

2

/arc_dest_3

3 (through NFS)

3

/arc_dest_1

1 (through NFS)

3

/arc_dest_2

2 (through NFS)

3

/arc_dest_3

3

File System Configuration for the Non-CFS Local Archiving Scheme

Because NFS is not required to perform backups, node 1 can back up its local logs to its tape drive, node 2 can back up its local logs to its tape drive, and so on. However, if you are performing recovery and a surviving instance must read all the logs that are on disk but not yet backed up, then you should configure NFS as shown in Table 6-2.

Table 6-2 NFS Configuration for Shared Read Local Archiving Scheme
Node Directory ... Is configured ... And mounted on ... On node ...

1

/arc_dest_1

Local read/write

n/a

n/a

1

/arc_dest_2

NFS read

/arc_dest_2

2

1

/arc_dest_3

NFS read

/arc_dest_3

3

2

/arc_dest_1

NFS read

/arc_dest_1

1

2

/arc_dest_2

Local read/write

n/a

n/a

2

/arc_dest_3

NFS read

/arc_dest_3

3

3

/arc_dest_1

NFS read

/arc_dest_1

1

3

/arc_dest_2

NFS read

/arc_dest_2

2

3

/arc_dest_3

Local read/write

n/a

n/a

Archived Log File Format and Destinations in Real Application Clusters

For any archived log configuration, uniquely identify the archived redo logs with the LOG_ARCHIVE_FORMAT parameter. The format of this parameter is operating system-specific and it can include text strings, one or more variables, and a filename extension. LOG_ARCHIVE_FORMAT can also have variables as shown in Table 6-3. Examples in Table 6-3 assume that LOG_ARCHIVE_FORMAT=log_%parameter and that the length limits for sequence values is ten characters and thread values is four characters.

Table 6-3 Archived Redo Log Filename Format Parameters
Parameter Description Example

%T

Thread number, left-zero-padded

log_0001

%t

Thread number, not padded

log_1

%S

Log sequence number, left-zero-padded

log_0000000251

%s

Log sequence number, not padded

log_251

The thread parameters %t or %T are mandatory for Real Application Clusters. For example, if the instance associated with redo thread number 1 sets LOG_ARCHIVE_FORMAT to log_%t_%s.arc, then its archived redo log files are named:

log_1_1000.arc
log_1_1001.arc
log_1_1002.arc
.
.
.
See Also:
  • Oracle9i Database Administrator's Guide for information about specifying the archived redo log filename format and destination
  • Oracle platform-specific documentation for information about the default log archiving format and destination

Changing the Archiving Mode in Real Application Clusters

After configuring your Real Application Clusters environment for RMAN, you can alter the archiving mode if needed. For example, if your Real Application Clusters database uses NOARCHIVELOG mode, then follow these steps to change the archiving mode to ARCHIVELOG mode:

  1. Shut down all instances.
  2. Reset the CLUSTER_DATABASE parameter to false on one instance. If you are using the server parameter file, then make a sid-specific entry for this.
  3. Add settings in the parameter file for the LOG_ARCHIVE_DEST_n, LOG_ARCHIVE_FORMAT, and LOG_ARCHIVE_START parameters. You can multiplex the destination to use up to ten locations. The LOG_ARCHIVE_FORMAT parameter should contain the %t parameter to include the thread number in the archived log file name. You must configure an archiving scheme before setting these parameter values.
  4. Start the instance on which you have set CLUSTER_DATABASE to false.
  5. Run the following statement in SQL*Plus:
    SQL>ALTER DATABASE ARCHIVELOG;
    
    
  6. Shut down the instance.
  7. Change the value of the CLUSTER_DATABASE parameter to true.
  8. Restart your instances.

You can also change the archiving mode from ARCHIVELOG to NOARCHIVELOG. To disable archiving, follow the preceding steps with the following changes:

  1. Delete the archiving settings that you created in step 3.
  2. Specify the NOARCHIVELOG keyword in step 5:
    ALTER DATABASE NOARCHIVELOG;
    

Querying the Archiver Processes

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

See Also:

Oracle9i Database Reference for more information about these views


Go to previous page Go to next page
Oracle
Copyright © 1998, 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback