7
Backing Up Real Application Clusters Databases

This chapter discusses creating backups in Real Application Clusters environments. The topics in this chapter are:

Backups in Real Application Clusters

To protect your data, you should archive the online redo log files and periodically back up the data files.

Choosing a Backup Method and Backup Type

You can use two methods for backups:

Using Recovery Manager
Using the operating system

Part of this chapter describes how to use Recovery Manager for backups in Real Application Clusters. For information about using operating system utilities, refer to the Oracle9i Recovery Manager User's Guide.

See Also:

Oracle Enterprise Manager Administrator's Guide for information about using the Oracle Enterprise Manager Backup Wizard

There are two types of backups:

This chapter uses the terms open and closed to indicate whether a database is available or unavailable during a backup. The term whole backup or database backup indicates that all data files and control files have been backed up. Full and incremental backups refer only to particular types of backups provided by Recovery Manager (RMAN).

Open Database Backups

An open backup includes copies of one or more data files and the current control file. Open backups allow you to back up all or part of the database while it is running. Users can update data in any part of the database during an open backup. Subsequent archived redo log files or incremental backups are also necessary to allow recovery up to the time of a media failure.

Depending on your configuration, you can perform backup operations from any node of a Real Application Clusters database. With Real Application Clusters, you can also make open backups of multiple tablespaces simultaneously from different nodes.

Closed Database Backups

When using operating system utilities for closed backups, the backups are done while the database is closed. When you use RMAN for closed backups, an instance must be started and mounted but not open.

Before performing a closed backup, shut down all instances of your Real Application Clusters database. Then start up mount one instance. While the database is closed, you can back up its files in parallel from different nodes (to back up from multiple nodes concurrently, an instance must be started, and mounted, on each node). A closed, whole database backup includes copies of all data files and the current control file.

In ARCHIVELOG mode, both open and closed backups are permitted. In addition, in the event of media failure, you can recover all transactions that were successfully committed to the database. In NOARCHIVELOG mode, however, only whole, closed backups are permitted. Also in NOARCHIVELOG mode, in the event of media failure you can only recover transactions that were committed to the database prior to the time that it was last shut down for backup.

Note:
Do not use operating system utilities to back up the control file in ARCHIVELOG mode. Instead, Oracle Corporation recommends that you use the ALTER DATABASE BACKUP CONTROLFILE command.

Never erase, reuse, or destroy archived redo log files until completing at least one or preferably multiple backups after the archivelogs were created. You can execute these backups in either open or closed mode.

See Also:

Online Backups and Real Application Clusters

Online backups in Real Application Clusters are efficient because they do not use the cache. Because backups primarily use I/O resources, you can use the less busy instances for other purposes. However, you should monitor disk usage to ensure that the I/O is not being saturated by the backup. If the I/O is saturated by the backup, it may adversely affect the online users.

Note:

Using the ALTER TABLESPACE ... BEGIN BACKUP statement generates extra redo logs.

Archiving Considerations for Real Application Clusters Environments

This section explains how to archive the redo log files for each instance:

Changing the Archiving Mode in Real Application Clusters

To enable archive logging in Real Application Clusters environments, the database must be mounted but not open. Then start Real Application Clusters in a disabled state. To do this:

Shut down all instances.
Reset the CLUSTER_DATABASE parameter to false on one instance. If you are using the server parameter file, make a sid-specific entry for this.
Add settings for the LOG_ARCHIVE_DEST_n, LOG_ARCHIVE_FORMAT, and LOG_ARCHIVE_START parameters to the parameter file. You can multiplex the destination to up to ten locations, and the LOG_ARCHIVE_FORMAT parameter should contain the %t parameter to include the thread number in the archived log file name.
Start up the instance on which you have set CLUSTER_DATABASE to false.
Enter the following statement:
```
ALTER DATABASE ARCHIVELOG
```
Shut down the instance.
Change the value of the CLUSTER_DATABASE parameter to true.
Restart your instances.

To disable archive logging, follow the same steps but use the NOARCHIVELOG clause of the ALTER DATABASE statement.

Monitoring the Archiving Process in Real Application Clusters

Use the GV$ARCHIVE_PROCESSES and V$ARCHIVE_PROCESSES views to find information about the state of the ARCH processes. These views display this information for all database instances, or just the instance you are connected to, respectively.

Archive File Format and Destinations in Real Application Clusters

Archived redo logs are uniquely named as specified by the LOG_ARCHIVE_FORMAT parameter. This operating system-specific format can include text strings, one or more variables, and a filename extension. LOG_ARCHIVE_FORMAT can have variables as shown in Table 7-1. Examples in Table 7-1 assume that LOG_ARCHIVE_FORMAT= arch%parameter, and the upper bound for all parameters is 10 characters.

Table 7-1 Archived Redo Log Filename Format Parameters

Parameter	Description	Example
`%T`	Thread number, left-zero-padded	`arch0000000001`
`%t`	Thread number, not padded	`arch1`
`%S`	Log sequence number, left-zero-padded	`arch0000000251`
`%s`	Log sequence number, not padded	`arch251`

The thread parameters %t or %T are mandatory for Real Application Clusters. For example, if the instance associated with redo thread number 7 sets LOG_ARCHIVE_FORMAT to LOG_%s_T%t.ARC, then its archived redo log files are named:

LOG_1_T7.ARC 
LOG_2_T7.ARC 
LOG_3_T7.ARC 
...

Backing Up the Archive Logs

Archive logs are generally accessible only by the node on which they were created. In Real Application Clusters you have three backup options:

Share the location of all archive log destinations with all nodes, for example, using a network file system (NFS)
Have each node back up its own archive log, for example, non-shared archived logging
Move the archive logs to one node and back them up, for example, using rcp

You can use RMAN to implement the first and second solutions as described in Chapter 6, "Configuring RMAN for Real Application Clusters".

Checkpoints and Log Switches

This section discusses the use of checkpoints and log switches in Real Application Clusters environments. The topics in this section are:

Forcing a Checkpoint

The SQL statement ALTER SYSTEM CHECKPOINT explicitly forces Oracle to perform a checkpoint for either the current instance or all instances. Forcing a checkpoint ensures that all changes to the database buffers are written to the data files on disk.

The GLOBAL clause of ALTER SYSTEM CHECKPOINT is the default. It forces all instances that have opened the database to perform a checkpoint. The LOCAL option forces a checkpoint on the current instance.

A global checkpoint is not finished until all instances complete the checkpoint. If any instance fails during the global checkpoint, however, the checkpoint might complete before that instance has been recovered.

To force a checkpoint on an instance running on a remote node, change the current instance with the CONNECT statement.

Note:
You need the ALTER SYSTEM privilege to force a checkpoint.

See Also:
"Setting and Connecting to Instances" for information on specifying a remote node

Forcing a Log Switch

A Real Application Clusters database can force a log switch for any instance that fails to archive its online redo log files for some period of time. This can be done either because the instance has not generated many redo entries or because the instance has shut down. This prevents an instance's redo log from remaining unarchived for an extended period of time. If media recovery is necessary, the redo entries used for recovery are always recent.

For example, after an instance has shut down, another instance can force a log switch for that instance so its current redo log file can be archived. The SQL statement ALTER SYSTEM SWITCH LOGFILE forces the current instance to begin writing to a new redo log file, regardless of whether the current redo log file is full.

When all instances perform forced log switches, it is known as a global log switch. To force all instances to perform a global log switch, use the SQL statement ALTER SYSTEM ARCHIVE LOG CURRENT omitting the THREAD keyword. After issuing this statement, Oracle waits until all online redo log files are archived before returning control to you. Specify the THREAD keyword to use this statement to force a single instance to perform a log switch and archive its online redo log files.

Use the INSTANCE FORCE LOG SWITCH clause for each instance. You may want to force a log switch to archive, drop, or rename the current redo log file.

Note:
You need the ALTER SYSTEM privilege to force a log switch.

Forcing a Log Switch on a Closed Thread

You can force a closed thread to complete a log switch while the database is open. This is useful if you want to drop the current log of the thread. This procedure does not work on an open thread, including the current thread, even if the instance that had the thread open is shut down. For example, if an instance aborted while the thread was open, you could not force the thread's log to switch.

To force a log switch on a closed thread, manually archive the thread using the SQL statement ALTER SYSTEM with the ARCHIVE LOG clause. For example:

   ALTER SYSTEM ARCHIVE LOG GROUP 2;

To archive a closed redo log group manually that will force it to log switch, you must connect with SYSOPER or SYSDBA privileges.

See Also:

The Oracle9i Database Administrator's Guide for information on connecting with SYSDBA or SYSOPER privileges

RMAN Backups in Real Application Clusters

This section describes the following RMAN backup issues:

Node Affinity Awareness

On some cluster platforms, certain nodes of the cluster have faster access to some data files than to other data files. RMAN automatically detects this affinity. When deciding which channel to use to back up a particular data file, RMAN gives preference to channels allocated at nodes with affinity to that data file. To use this feature, configure RMAN channels at the various nodes of the cluster that have affinity to the data files being backed up. For example:

CONFIGURE CHANNEL 1 DEVICE TYPE SBT CONNECT '@INST1'; 
CONFIGURE CHANNEL 2 DEVICE TYPE SBT CONNECT '@INST2';

Performing an Open Backup Using RMAN

If you are also backing up archive logs, then issue an ALTER SYSTEM ARCHIVE LOG CURRENT statement after the backup is complete. This ensures that you have all redo data to make the files in your backup consistent.

The following sample script distributes data file and archive log backups across two instances in a Real Application Clusters environment. It assumes:

There are more than 20 files in the database
4 tape drives available, two on each node
The archive log files produced by thread 2 are readable by node1

The BACKUP ... PLUS ARCHIVELOG command switches out of and archives the current online log and backs up archived logs that have not been backed up. Also, At the beginning of a backup of archived logs, RMAN automatically switches out of and archives the current online redo log if needed.

The sample script is as follows:

RUN 
{
  ALLOCATE CHANNEL NODE1_T1 TYPE SBT CONNECT 'SYS/KNL@NODE1';
  ALLOCATE CHANNEL NODE1_T2 TYPE SBT CONNECT 'SYS/KNL@NODE1';
  ALLOCATE CHANNEL NODE2_T3 TYPE SBT CONNECT 'SYS/KNL@NODE2';
  ALLOCATE CHANNEL NODE2_T4 TYPE SBT CONNECT 'SYS/KNL@NODE2';
  BACKUP
  FILESPERSET 6
  FORMAT 'DF_%T_%S_%P'
  DATABASE PLUS ARCHIVELOG;

See Also:

Oracle9i Recovery Manager User's Guide and Reference for complete information on open backups using RMAN

Backup Examples for Real Application Clusters Using Shared Directories

This section contains backup examples using shared directories, some of which use RMAN, for Real Application Clusters. The topics in this section are:

Using RMAN to Backup to Multiple Nodes with Several Channels

Although you can perform a concurrent backup of more than one node of a cluster using the CONNECT clause in the ALLOCATE CHANNEL command, you cannot recover from such a backup unless you have installed Oracle version 8.1.6 or greater.

RMAN stores the local path of the backup file in its recovery catalog. If you allocate multiple channels on recovery, RMAN expects to find the backup file in any of these channels. If RMAN cannot locate the required file in the channel, recovery fails.

Use the SET AUTOLOCATE ON command to make RMAN search all channels for each backup that is needed for a restore operation.

Avoiding the Thread Statement for Backing Up Archivelogs

Do not use the THREAD statement of the BACKUP ARCHIVED LOG clause when running RMAN first on one instance and then on the second one. The command syntax for this is:

  RMAN TARGET SYS/SYSPASS@DB1 CATALOG RMANUSER/RMANPASS@RMANCAT
  RUN 
  {
  ...
   BACKUP ARCHIVELOG THREAD 1;
  ...
  }
    RMAN TARGET  connect /as sys@db2 CATALOG RMANUSER/RMANPASS@RMANCAT
  {
  ...
    BACKUP ARCHIVELOG THREAD 2;
  ...
  }

This procedure might not work because it is possible that archivelogs for other threads are archived on different nodes. if node 1, for example, goes down for a longer period of time, the surviving node performs log switches for the inactive instance to maintain the system change number (SCN). The archiver of node 2 also archives the redo logs from DB1 into its log archive destination. This procedure is called a redo log switch.

Making Backups to Shared Archive Log Destinations

To create backups by sharing all archive logs with all nodes of a cluster, use NetBios, NFS or HA-NFS. Doing this enables you to execute the backups from any node because every node can read all the logs. In the following example, node 1 backs up all redo logs of all nodes. Make sure that the directories are configured for sharing as described in the previous sections.

The ALTER SYSTEM ARCHIVE LOG CURRENT statement forces all nodes to back up their current log files.

  RUN
  {
    ALLOCATE CHANNEL node_1 DEVICE TYPE sbt CONNECT 'sys/sys_pwd@node_1';
    ALLOCATE CHANNEL node_2 DEVICE TYPE sbt CONNECT 'sys/sys_pwd@node_2';
    BACKUP FILESPERSET 1
    (TABLESPACE SYSTEM, rbs, data1, data2
     CHANNEL node_1)
    (TABLESPACE temp, reccat, data3, data4
     CHANNEL node_2);
    BACKUP FILESPERSET 20 ARCHIVELOG ALL DELETE ALL INPUT;
  }

Backing Up Local Files from Each Node Using Non-Shared Archive Log Destinations

This section contains examples of making backups using non-shared archive log destinations. The topics in this chapter are:

If you do not share all archive logs, you can back up the logs locally on every node. For recovery, however, you need to have access from the node on which you begin recovery to all the archive logs created by the database. For this reason Oracle Corporation recommends using a media management system that supports archiving over the network or shared directory services to simplify restoring log files.

To do this, adapt the expression in the LIKE clause to your own configuration, for example, J:% if you use Windows NT and Windows 2000.

Backing Up All Files from One Node

You can back up all the archive logs from one node into one backup instead of archiving them from each node separately. This makes it easier to find all backups when you recover. If you do not use shared directories to back up and restore archive logs, copy or move them using operating system tools, while retaining their exact names. You can easily create scripts to do this before backing up or restoring the logs. If you are using Oracle Enterprise Manager, you can schedule the execution of this script before the backup.

To copy all archive logs to the local directories on node 1, use a script similar to the following:

#!/bin/sh
sqlplus system/manager@node1 @switchlog.sql 
rcp 'node2:/u01/app/oracle/product/901/admin/db/arch2/*' /u01/app/oracle/
product/901/admin/db/arch2

Ensure that you have adequate space on your destination device before executing this script.

Recovering Archive Logs from One Node

If you moved all archive logs to one node to back them up, recovery is as easy as recovery using shared directories. You do not need to use autolocate to restore archivelog backups if they were all backed up from one node, and if you are restoring from that same node.

Restoring and Recovering Archive Logs from All Local Nodes Using Oracle Release 1 (9.0.1)

If you backed the archive logs from each node using a media management system, you can use several channels for recovery. RMAN examines every channel for the required file if RMAN does not find it in the first one. This is the autolocate feature that recovers a database using the local tape drive on the remote nodes as shown in the following example:

RMAN TARGET sys/syspass CATALOG rmanuser/rmanpass@rmancat
RUN 
{
  ALLOCATE CHANNEL t1 DEVICE TYPE sbt PARMS 'ENV=(NSR_CLIENT=node1)';
  ALLOCATE CHANNEL t2 DEVICE TYPE sbt PARMS 'ENV=(NSR_CLIENT=node2)';
  SET AUTOLOCATE ON;
  RECOVER TABLESPACE users;
  SQL 'alter tablespace users online';
}

Restoring and Recovering Archive Logs from All Local Nodes Using Oracle 8.1.5 Or Earlier

If you backed up the logs from each node, restore all the log files from remote nodes before performing recovery. Perform recovery in three steps:

Restore the data files.
Restore the archive logs from remote nodes.
Recover the database.

Restore the files locally and move them to the recovering node. Because you have to restore the archive logs before RMAN can begin recovery, specify which log files to restore as in the following example:

RMAN TARGET sys/syspass@node1 catalog rmanuser/rmanpass@rmancat
RUN 
{
  ALLOCATE CHANNEL t1 TYPE 'sbt_tape';
  RESTORE TABLESPACE users;
  RELEASE CHANNEL t1;
}
RUN 
{
  ALLOCATE CHANNEL t1 TYPE 'sbt_tape' PARMS 'ENV=(NSR_CLIENT=node2)';
  # this next line is optional, they will be restored to the first log_archive 
dest at the restoring node
   SET ARCHIVELOG DESTINATION TO '/u01/app/oracle/product/901/admin/db/arch2';
   RESTORE ARCHIVELOG
   # this next line is optional, if you don't want to restore ALL archive logs:
from time "to_date('05.09.1999 00:00:00','DD.MM.YYYY HH24:Mi:SS')"
   # the like operand should be used as each archive dest may contain copies 
from each thread
  # (this is due to redo log switches)
  LIKE '%/2_%'; 
  RELEASE CHANNEL t1;
}
RUN 
{
  ALLOCATE CHANNEL d1 TYPE DISK;
  RECOVER TABLESPACE users;
SQL 'alter tablespace users online';
}

7 Backing Up Real Application Clusters Databases