6 Administering Backup and Recovery

About Archived Redo Log Files for an Oracle RAC Database

When you use Oracle Database Configuration Assistant (DBCA) to create your Oracle Real Application Clusters (Oracle RAC) database, each instance is configured with at least two redo log files that are stored in the shared storage area. If you have a two-node Oracle RAC database, then at least 4 redo logs are created for the database, two for each instance.

If you use a cluster file system to store the archived redo log files for your Oracle RAC database, then the redo log files are shared file system files. If you use Oracle ASM to store the archived redo log files for your Oracle RAC database, then each instance automatically has access to all the archived redo log files generated by the database. If you use shared storage or raw devices to store the archived redo log files on each node, then you must configure the operating system to grant access to those directories for each instance of the cluster database that needs access to them.

The primary consideration when configuring archiving is to ensure that all archived redo logs can be read from every node during recovery, and if possible during backups. During recovery, as long as the archived log destinations are visible from the node that performs the recovery, Oracle RAC can successfully recover the archived redo log data. For creating backups of your Oracle RAC database, the strategy that you choose depends on how you configure the archiving destinations for each node. Whether only one node or all nodes perform archived redo log backups, you need to ensure that the archived redo logs for every instance are backed up.

To backup the archived redo logs from a single node, that node needs to have access to the archived log files of the other instances. The archived redo 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 archived redo log. For example, if node1 archives a log to /oracle/arc_dest/log_1_100_23452345.arc, then node2 can back up this archived redo log only if it can read/oracle/arc_dest/log_1_100_23452345.arc on its own file system.

About Parallelism and Backups Across Multiple RMAN Channels

Recovery Manager (RMAN) depends on server sessions, processes that run on the database server, to perform backup and recovery tasks. Each server session in turn corresponds to an RMAN channel, representing one stream of data to or from a backup device. RMAN supports parallelism, which is the use of multiple channels and server sessions to carry out the work of a single backup job or file restoration task.

Because the control file, SPFILE, and data files are accessible by any instance, the backup operation of these files is distributed across all the allocated channels. For backups of the archived redo log, the actions performed by RMAN depend on the type of archiving scheme used by your Oracle RAC database.

If you use a local archiving scheme, then each instance writes the archived redo log files to a local directory. When multiple channels are allocated that have access to the archived redo log, for each archived redo log file, RMAN determines which channels have access to that archived redo log file. Then, RMAN groups together the archived redo log files that can be accessed by a channel and schedules a backup job using that channel.

If each node in the cluster writes the archived redo log files to Oracle ASM, a clustered file system, or other type of shared storage, then each instance has access to all the archived redo log files. In this case, the backup of the archived redo log is distributed across all the allocated channels.

Configuring Archiving for Your Oracle RAC Database

For Oracle RAC, each instance has its own thread of redo. The preferred configuration for Oracle RAC is to configure the fast recovery area using an Oracle ASM disk group that is separate from the Oracle ASM disk group used for your data files. Alternatively, you can use a cluster file system archiving scheme.

To configure archiving for your Oracle RAC database:

1. On the Database Home page of Enterprise Manager Database Control, while logged in as a SYSDBA user, select Availability.

   The Availability subpage appears.

2. In the Backup/Recovery section, under the heading Setup, select Recovery Settings.

   The Recovery Settings page appears.

3. In the Media Recovery section, select the ARCHIVELOG mode option.

4. In the Log Archive Filename Format field, accept the default value, or enter the desired format.

   For clustered databases, the format for the archive log file name should contain the %t modifier, to indicate which redo log thread the archived redo log file belongs to. As a best practice, the format for the archive log file name should also include the %s (log sequence number) and %r (resetlogs identifier) modifiers.

5. If the archive log destination is the same for all instances, then in the Archive Log Destination field, change the value to the location of the archive log destination for the cluster database.

   For example, you might set it to +DATA if using Oracle ASM, or to /u01/oradata/arch if you want local archiving on each node.

   If you need to configure a different archive log destination for any instance, you must go to the Initialization Parameters page and modify the LOG_ARCHIVE_DEST_1 parameter that corresponds to the instance for which you want to configure the archive log destination. The Instance column should display the name of the instance, for example sales1. Change the Value field to contain the location of the archive log destination for that instance.

6. If you want to configure more than one archive log destination for the database, on the Recovery Settings page, click Add Another Row under the Archive Log Destination field.

7. After you have finished configuring archiving, click Apply.

   When prompted to restart the database, click Yes.

8. Enter the host and SYSDBA user credentials, then click Continue.

9. Wait a couple of minutes, then click Refresh.

   If the database has been restarted, you are prompted to enter the login credentials.

About Credentials for Performing Backup and Recovery

When using Enterprise Manager, you must have the proper credentials to perform some of the configuration tasks for backup and recovery, to schedule backup jobs, and to perform recovery. The following credentials may be required:

• The Oracle database administrator user you use when you log in to Enterprise Manager

• The host operating system user whose credentials you provide when performing backup and recovery tasks

To perform or schedule RMAN tasks, you must either log in to Enterprise Manager as a user with SYSDBA privileges, or provide host operating system credentials for a user who is a member of the dba group. The host operating system user must also have execute permission for the RMAN command-line client.

For tasks requiring host operating system credentials, a Host Credentials form appears at the bottom of the page used to perform the task. Enterprise Manager uses the credentials when it invokes RMAN to perform jobs you requested or scheduled.

The Host Credentials form always includes an option labeled Save as Preferred Credential. If you select this option before performing your action, then the provided credentials are stored persistently for the currently logged-in Oracle database user. The preferred credentials are reused by default whenever you log in as that user and perform operations requiring host credentials.

About Configuring Backup Settings

Assuming you have a fast recovery area configured, you can configure a number of settings and policies that determine how backups are stored, which data is backed up, and how long backups are retained before being purged from the fast recovery area. You can also configure settings to optimize backup performance for your environment.

Backing Up Archived Redo Log Files

Whether only one node or all nodes perform archive log backups, ensure that all archived redo log files for all nodes are backed up. If you use a local archiving scheme, then allocate multiple channels to provide RMAN access to all the archived redo log files.

You can configure RMAN to automatically delete the archived redo log files from disk after they have been safely backed up. This feature helps to reduce the disk space used by your Oracle RAC database, and prevent an unnecessary outage that might occur if you run out of available disk space.

To configure RMAN to automatically delete the archived redo log file files from disk after they have been safely backed up, when creating or scheduling your database backups:

1. On the Cluster Database Home page, select Availability.

   The Cluster Database Availability page appears.

2. In the Backup/Recovery section, under the heading Manage, select Schedule Backup.

3. Choose a backup type and click Schedule Customized Backup.

4. While specifying the options for your backup, select Also back up all archived logs on disk if you are performing an online backup. There is no need to back up archived redo log files when performing an offline backup because the database is in a consistent state at the time of backup and does not require media recovery if you restore.

5. Select Delete all archived logs from disk after they are successfully backed up if you are using shared storage for your archived redo log files.

   Note:

   Do not select Delete all archived logs from disk after they are successfully backed up if you are using a fast recovery area as your only archive log destination. In this case, archived redo log files that have been backed up are deleted automatically as space is needed for storage of other files.

About Preparing to Restore and Recover Your Oracle RAC Database

The node that performs the recovery of an Oracle Real Application Clusters (Oracle RAC) database must be able to restore all the required data files. That node must also be able to either read all the required archived redo log files on disk or be able to restore the archived redo log files from backup files.

This section discusses two tasks you must perform prior to recovering your database:

• About Configuring Access to the Archive Log

• About Putting the Oracle RAC Database Instances into the Correct State

About Restoring Archived Redo Log File Files

During a restore operation, RMAN automatically locates the most recent backups of the database that are available. A channel connected to a specific node attempts to restore files that were backed up only to that node. For example, assume that an archived redo log file with the sequence number 1001 is backed up to a device attached to the node racnode1, while the archived redo log file with sequence number 1002 is backed up to a device attached to the node racnode2. If you allocate channels that connect to nodes racnode1 and racnode2 for a restore operation, then the channel connected to racnode1 restores log sequence 1001, but not log sequence 1002. The channel connected to racnode2 can restore log sequence 1002, but not log sequence 1001.

If you use Oracle ASM or a clustered file system for storing the archived redo log files, then any instance can restore the archived redo log files.

About Performing Recovery Using Parallelism

Oracle RAC automatically selects the optimum degree of parallelism for instance failure and media recovery.

When using Enterprise Manager and RMAN to perform the recovery, Oracle RAC automatically makes parallel the following three stages of recovery:

• Restoring Data files—When restoring data files, the number of channels you allocate in the RMAN recovery script effectively sets the parallelism that RMAN uses. For example, if you allocate five channels, you can have up to five parallel streams restoring data files.

• Applying Incremental Backups—Similarly, when you are applying incremental backups, the number of channels you allocate determines the potential parallelism.

• Applying Archived Redo Log Files—Using RMAN, the application of archived redo log files is performed in parallel. Oracle RAC automatically selects the optimum degree of parallelism based on available CPU resources.

Recovering the Oracle RAC Database Using Enterprise Manager

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

To use Enterprise Manager and RMAN to restore and recover an Oracle RAC database:

1. On the Cluster Database Home Page, select Availability.

   The Cluster Database Availability page appears.

2. In the Backup/Recovery section, under the heading Manage, select Perform Recovery.

   The Perform Recovery page appears.

3. Follow the recovery procedures outlined in Chapter 9 of Oracle Database 2 Day DBA

Recovering the Parameter File from an Automatic File Backup

You can use Enterprise Manager to recover a lost or damaged server parameter file (SPFILE).

To recover an SPFILE for an Oracle RAC database:

1. Start the database in MOUNT mode.

2. On the Cluster Database Home page, select Availability.

   The Cluster Database Availability page appears.

3. In the Backup/Recovery section, under the heading Manage, select Perform Recovery.

   When the database is not open, the Perform Recovery link takes you to the SPFILE restore page.

4. Specify the location of the fast recovery area, if configured.

5. In the Backup Information section, select Use Other Backup Information and Use an Autobackup.

6. On the Perform Recovery: Restore SPFILE page, specify a different location for the SPFILE to be restored to.

7. When finished selecting your options, click Restore, then click Yes to confirm you want to restore the SPFILE.

8. After the SPFILE is restored, you are prompted to login to the database again.