| Oracle® Database 2 Day + Real Application Clusters Guide 11g Release 1 (11.1) Part Number B28252-01 |
|
|
View PDF |
| Oracle® Database 2 Day + Real Application Clusters Guide 11g Release 1 (11.1) Part Number B28252-01 |
|
|
View PDF |
This chapter describes how to back up and recover an Oracle Real Application Clusters (Oracle RAC) database.
This chapter contains the following sections:
Credentials for Performing Enterprise Manager Backup and Recovery
About Preparing to Restore and Recover Your Oracle RAC Database
Performing Backups and Recovering Your Database: Oracle By Example Series
See Also:
Oracle Database Backup and Recovery User's Guide for more information about using the Recovery Manager utility
To protect your Oracle RAC database from hardware failures or disasters, you need to have a physical copy of the database files. The files protected by the backup and recovery facilities built into Oracle Enterprise Manager include datafiles, control files, server parameter files (SPFILEs), and archived redo log files. Using these files, your database can be reconstructed. The backup mechanisms that work at the physical level protect against damage at the file level, such as the accidental deletion of a datafile or the failure of a disk drive. Database recovery involves restoring, or copying, the damaged files from backup and performing media recovery on the restored files. Media recovery is the application of redo logs or incremental backups to a restored datafile in order to update it to the current time or some other specified time.
The Oracle Database flashback features, such as Oracle Flashback Drop and Oracle Flashback Table, provide a range of physical and logical data recovery tools as efficient, easy-to-use alternatives to physical and logical backup operations. The flashback features enable you to reverse the effects of unwanted database changes without restoring datafiles from backup or performing media recovery.
The Enterprise Manager physical backup and recovery features are built on the Recovery Manager (RMAN) command-line client. Enterprise Manager makes available many of the RMAN features, and provides wizards and automatic strategies to simplify and further automate RMAN-based backup and recovery.
The Enterprise Manager Guided Recovery capability provides a Recovery Wizard that encapsulates the logic required for a wide range of file restoration and recovery scenarios, including the following:
Complete restoration and recovery of the database
Point-in-time recovery of the database or selected tablespaces
Flashback Database
Other flashback features of Oracle Database for logical-level repair of unwanted changes to database objects
Media recovery at the block level for datafiles with corrupt blocks
If the database files are damaged or need recovery, Enterprise Manager can determine which parts of the database must be restored from a backup and recovered, including proactively detecting situations such as corrupted database files. Enterprise Manager guides you through the recovery process, prompting for needed information and performing the required recovery actions.
Using a flash recovery area minimizes the need to manually manage disk space for your backup-related files and balance the use of space among the different types of files. Oracle recommends that you enable a flash recovery area to simplify your backup management.
The larger the flash recovery area is, the more useful it becomes. Ideally, the flash recovery area should be large enough to contain all the following files:
A copy of all datafiles
Incremental backups
Online redo logs
Archived redo log files that have not yet been backed up
Control files and control file copies
Autobackups of the control file and database initialization parameter file
The preferred configuration for Oracle RAC is to use Automatic Storage Management (ASM) for a recovery area using a different disk group for your recovery set than for your datafiles. Alternatively, you can use a cluster file system archiving scheme.
The location and disk quota must be the same on all 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 the Flash Recovery feature, you must first configure the flash recovery area for each instance in your Oracle RAC cluster.
When you archive your redo log, you write redo log files to another location prior to their being overwritten. This location is called the archive log. These copies of redo log files extend the amount of redo data that can be saved and used for recovery. Archiving can be either enabled or disabled for the database, but Oracle recommends that you enable archiving.
When you use Oracle Database Configuration Assistant (DBCA) to create your Oracle RAC database, each instance is configured with at least two redo log files that are stored in the shared storage. If you use a cluster file system, then these files are shared file system files. If you do not have a cluster file system, then these files are raw devices. If you use ASM, then these files are stored on the ASM disk group.
For Oracle Real Application Clusters, each instance has its own thread of redo. The preferred configuration for Oracle RAC is to configure the flash recovery area using an ASM disk group that is separate from the ASM disk group used for your datafiles. Alternatively, you can use a cluster file system archiving scheme.
To configure archiving for your Oracle RAC database:
On the Enterprise Manager Database Control Home page, while logged in as a SYSDBA user, select Availability.
The Availability subpage appears.
In the Backup/Recovery section, under the heading Setup, select Recovery Settings.
The Recovery Settings page appears.
In the Media Recovery section, select the ARCHIVELOG mode option.
In the Log Archive Filename Format field, accept the default value, or enter the desired format, then click Apply.
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.
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 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 docrac1. Change the Value field to contain the location of the archive log destination for that instance.
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.
After you have finished configuring archiving, click Apply.
When prompted to restart the database, click Yes.
Enter the host and SYSDBA user credentials, then click Continue.
Wait a couple of minutes, then click Refresh.
If the database has been restarted, you are prompted to enter the login credentials.
See Also:
"Configuring Initialization Parameters for an Oracle RAC Database"
"Editing Initialization Parameter Settings for an Oracle RAC Database"
Oracle Real Application Clusters Administration and Deployment Guide for more information about configuring and managing archived redo log files for an Oracle RAC database
An instance does not need access to the archived redo log files from a different instance except when performing backup or recovery operations. When performing backup operations across instances, the archive log naming scheme that you use is important because when an instance writes to a log with a specific file name on its file system, that file must be readable by any instance that needs to access this archived redo log file.
Also, the backup and recovery strategy that you implement for your Oracle RAC database depends on how you configure the archiving destinations for each instance.
If you use 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.
You must have the proper credentials to perform some of the configuration tasks for backup and recovery, and to schedule backup jobs and 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.
See Also:
Assuming you have a flash 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 flash recovery area. You can also configure settings to optimize backup performance for your environment.
See Also:
Oracle Database 2 Day DBA for more information about configuring backup policy settings
Oracle Database 2 Day DBA for more information about configuring backup settings
When you use ASM to manage database files, Oracle recommends that you use RMAN for creating backups. You must have both database (SYSDBA) privileges and host operating system (OSDBA) credentials to perform backup and recovery operations.
If you log in to Enterprise Manager with SYSDBA privileges, any operating system user who has execute permission for the RMAN command-line client can perform backups of an Oracle RAC database. However, if you log in as a database user without SYSDBA privileges, then you must provide the name and password of an operating system user that is a member of the OSDBA group before you can perform the backup operation.
To back up an Oracle RAC database:
On the Cluster Database Home page, select Availability.
The Cluster Database Availability page appears.
In the Backup/Recovery section, under the heading Manage, select Schedule Backup.
Follow the backup procedures outlined in Chapter 9, "Performing Backup and Recovery" of Oracle Database 2 Day DBA.
See Also:
"Credentials for Performing Enterprise Manager Backup and Recovery"
Oracle Database 2 Day DBA for more information about configuring your database for backup and recovery
Oracle Database 2 Day DBA for more information about performing and scheduling backups using Enterprise Manager Database Control
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 datafiles are accessible by any instance, the backup operation of these files is distributed across all the allocated channels. For backups of archived redo log files, 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 logs, 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 file files to ASM, a clustered file system, or other type of shared storage, then each instance has access to all the archived redo log file files. In this case, the backup of the archived redo log file files is distributed across all the allocated channels.
See Also:
Oracle Database 2 Day DBA for more information about RMAN backups
Oracle Database 2 Day DBA for more information about configuring backup device settings
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:
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.
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 flash 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.The Enterprise Manager Guided Recovery capability provides a Recovery Wizard that encapsulates the logic required for a wide range of restore and recovery scenarios. Enterprise Manager can determine which parts of the database must be restored and recovered, including proactively detecting situations such as corrupted database files. Enterprise Managers takes you through the recovery process, prompting for information and performing required file restoration and recovery actions.
The node that performs the recovery of an Oracle RAC database must be able to restore all the required datafiles. 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 contains the following topics:
During recovery, as long as the archive log file destinations are visible from the node that performs the recovery, Oracle RAC can successfully access the archived redo log files during recovery.
If you do not use shared storage or a clustered file system to store the archived redo log files for your cluster database, then you need to make the archived redo log files available to the node performing the recovery.
Recovery of a failed instance in Oracle RAC is automatic. If an Oracle RAC database 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. When recovery completes, Oracle Clusterware attempts to restart the failed instance automatically.
Media recovery is a manual process that occurs while a database is closed. A media failure is the failure of a read or write operation of a disk file required to run the database, due to a physical problem with the disk such as a head malfunction. Any database file can be vulnerable to a media failure. If a media failure occurs, then you must perform media recovery to restore and recover the damaged database files. Media recovery is always done by one instance in the cluster.
Before starting media recovery, the instance that will be performing the recovery should be started in MOUNT mode. The other instances should be started in NOMOUNT mode.
This section discusses both instance recovery and media recovery. It contains the following topics:
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:
On the Cluster Database Home Page, select Availability.
The Cluster Database Availability page appears.
In the Backup/Recovery section, under the heading Manage, select Perform Recovery.
Follow the recovery procedures outlined in Chapter 9 of Oracle Database 2 Day DBA
See Also:
"About Preparing to Restore and Recover Your Oracle RAC Database"
"Credentials for Performing Enterprise Manager Backup and Recovery"
Oracle Database 2 Day DBA for more information about performing user-directed recovery
You can use Enterprise Manager to recover a lost or damaged server parameter file (SPFILE).
To recover an SPFILE for an Oracle RAC database:
Start the database in the MOUNT.
On the Cluster Database Home page, select Availability.
The Cluster Database Availability page appears.
In the Backup/Recovery section, under the heading Manager, select Perform Recovery.
When the database is not open, the Perform Recovery link takes you to the SPFILE restore page.
Specify the location of the flash recovery area, if configured.
In the Backup Information section, select Use Other Backup Information and Use an Autobackup.
On the Perform Recovery: Restore SPFILE page, specify a different location for the SPFILE to be restored to.
When finished selecting your options, click Restore, then click Yes to confirm you want to restore the SPFILE.
After the SPFILE is restored, you are prompted to login to the database again.
See Also:
"Starting and Stopping Oracle RAC Databases and Database Instances"
"About the Server Parameter File for Oracle Real Application Clusters"
Oracle Database Backup and Recovery User's Guide for more information about recovering a server parameter file
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 docrac1, while the archived redo log file with sequence number 1002 is backed up to a device attached to the node docrac2. If you allocate channels that connect to nodes docrac1 and docrac2 for a restore operation, then the channel connected to docrac1 restores log sequence 1001, but not log sequence 1002. The channel connected to docrac2 can restore log sequence 1002, but not log sequence 1001.
If you use ASM or a clustered file system for storing the archived redo log files, then any instance can restore the archived redo log files.
See Also:
Oracle Database Backup and Recovery User's Guide for more information about restoring archived redo log file files
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 Datafiles—When restoring datafiles, 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 datafiles.
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.
See Also:
Oracle Database 2 Day DBA for more information about incremental backups of datafiles
Oracle Database 2 Day DBA for more information about configuring recovery settings
Managing RMAN backup files, with or without Enterprise Manager, consists of two tasks:
Managing the backup files for your database that are stored on disk or tape
Managing the record of those backup files in the RMAN repository
Enterprise Manager simplifies both backup file management tasks. Some of the other tasks involved in managing backup files include the following:
Searching for backup files
Validating the contents of backup sets or image copies
Cross-checking a backup
Deleting expired or obsolete backup files
Marking backup files as available or unavailable
See Also:
Oracle Database 2 Day DBA for more information about these topics and details on how to perform these tasks
Backup reports contain summary and detailed information about past backup jobs run by RMAN, including backup jobs run through Enterprise Manager and the RMAN command-line client.
To view backup reports:
On the Cluster Database Home page, select Availability.
The Availability page appears.
In the Backup/Recovery section, under the heading Manage, select Backup Reports.
The View Backup Report page appears, with a list of recent backup jobs.
In the Search section, specify any filter conditions and click Go to restrict the list to backups of interest.
You can use the Search section of the page to restrict the backups listed by the time of the backup, the type of data backed up, and the status of the jobs (whether it succeeded or failed, and whether or not warnings were generated during the job).
To view detailed information about any backup, click the backup job name in the Backup Name column.
The Backup Report page is displayed for the selected backup job. This page contains summary information about this backup job, such as how many files of each type were backed up, the total size of the data backed up, and the number, size, and type of backup files created.
The Backup Report page also contains a Search section that you can use to quickly run a search for another backup job or backup jobs from a specific date range. The resulting report contains aggregate information for backup jobs matching the search criteria.
Oracle By Example (OBE) has a series of tutorials for Oracle RAC databases. This OBE takes you through the basic administrative tasks described in this chapter and includes annotated screenshots.
To view the Performing Backups and Recovering Your Database OBE, go to the following URL
http://www.oracle.com/technology/obe/10gr2_db_vmware/ha/rman/rman.htm
