Managing Real Application Clusters Backup and Recovery

Redo Log Groups and Redo Threads in Real Application Cluster Databases

Redo logs contain a record of changes that have been made to datafiles. In a single-instance Oracle database environment, redo logs generated by database datafile changes are stored in two or more redo log file groups. Each of these groups contains a redo log file and possibly one or more mirrored copies of that file. In a RAC database, each instance requires its own set of redo log groups, which is known as its thread of redo. Mirrored copies of the redo log files provide your system with extra protection against data loss that is due to hardware failures or data corruption.

Each redo log thread must contain at least two redo log groups. Oracle recommends that each of your instances has a redo thread that contains the same number of redo log groups and, as with single-instance Oracle databases, each group should contain the same number of members. For example, in a RAC database with two instances, each instance could have a thread of redo that contains five redo log groups. This is a total of ten redo log groups for the database. Each of these groups could contain two members: a redo log and its mirrored copy. If you create your RAC database with the Database Configuration Assistant (DBCA), then your RAC database automatically implements a configuration that meets the Oracle recommendations.

In a RAC database, each instance writes and archives the redo log groups in its own thread in the same manner that single-instance Oracle databases do. This is described in Chapter 6, "Managing Database Storage Structures". However, in recovery mode, the instance performing the recovery is able to read and process all of the redo threads for the database, regardless of which instance generated the redo threads. This enables a running instance to recover the work completed by the failed instance. This also enables end users to continue working without waiting for the failed instance to be restarted. For example, assume that you have a RAC database with two instances, instance A and instance B. If instance A is down, then instance B can read the redo log files both for instance A and B to ensure a successful recovery.

In a RAC database that uses ASM, all of the redo log files reside on shared storage. In addition, each instance has transparent access to the redo log files of all of the other instances in the cluster.

To access the redo log file groups with Enterprise Manager:

1. Go to the Cluster Database Home Page, and click the Administration tab.

2. On the Cluster Database Administration page, under the Storage column, select Redo Log Groups.

On the Redo Log Groups page, you can create additional redo log groups and add members to the redo log group. The Thread column identifies the instance thread to which a redo log file belongs.

Backing Up Real Application Clusters Databases

When you use ASM to manage database files, Oracle recommends that you use RMAN for backup. You must have both database (SYSDBA) credentials and host operating system (OSDBA) credentials to perform backup and recovery.

In addition, if you log in to Enterprise Manager with SYSDBA privileges, any valid host operating system user who has execute permission for the RMAN command line client can perform backups. However, if you log in as a non-SYSDBA user, then you must provide an operating system user name that is a member of the OSDBA group.

To back up a RAC database:

1. Go to the Cluster Database Home Page, and click the Maintenance tab.

2. On the Cluster Database Maintenance page, under the Backup/Recovery column, select Schedule Backup.

3. Follow the backup procedures outlined in Chapter 9, "Performing Backup and Recovery".

Overview of Restore and Recovery Operations for a Real Application Clusters Database

This section discusses both instance recovery and media recovery. Instance recovery in RAC is automatic. Instance recovery can occur while a database is running. If a RAC instance fails, then a surviving database instance processes the online redo logs generated by the failed instance to ensure that the database contents are in a consistent state. The more nodes that are in a RAC environment, the shorter the duration of the automatic instance recovery. When recovery completes, the Oracle Clusterware attempts to restart the failed instance automatically.

Media recovery is a manual process that occurs while a database is closed, typically to recover and restore database files after catastrophic disk failures, block corruption, or user errors. Media recovery is always done by one instance in the cluster.

With RMAN, the process of recovering and restoring a RAC database is essentially the same as for a single-instance Oracle databases, except that you access RMAN from the Maintenance page at the cluster database level, instead of at the instance level.

To recover a RAC database:

1. Go to the Cluster Database Home Page and click the Maintenance tab.

2. On the Cluster Database Maintenance page, under the Backup/Recovery column, select Perform Recovery.

3. Follow the recovery procedures outlined in "Performing Restore and Recovery Operations" in Chapter 9, "Performing Backup and Recovery".

Using a Flash Recovery Area with a Real Application Clusters Database

To use a flash recovery area with a RAC database, the recovery area must be shared by all of the instances. To accomplish this, Oracle recommends that you place the flash recovery area on the shared ASM disks. In addition, you must set the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE parameters to the same values on all instances.

To use Flash Recovery, you must first configure the flash recovery area, as described in "Configuring the Flash Recovery Area" in Chapter 9, "Performing Backup and Recovery".