| Oracle® Database 2 Day + Real Application Clusters Guide 10g Release 2 (10.2) Part Number B28759-01 |
|
|
View PDF |
| Oracle® Database 2 Day + Real Application Clusters Guide 10g Release 2 (10.2) Part Number B28759-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:
Deploying a Flash Recovery Area in Oracle Real Application Clusters
Credentials for Performing Enterprise Manager Backup and Recovery
Performing Backups and Recovering Your Database: Oracle By Example Series
See Also:
Oracle Database Backup and Recovery Basics for more information about using the Recovery Manager utilityTo 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. With 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. The process of restoring damaged files for your database is called database recovery.
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 oepations. 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 restore and recovery scenarios, including the following:
Complete restore and recovery of the database
Point-in-time recovery of the database or selected tablespaces
Flashback Database
Other flashback features of Oracle for logical-level repair of unwanted changes to database objects
Media recovery at the block level for datafiles with corrupt blocks
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 walks you through the recovery process, prompting for needed information and performing required recovery actions.
See Also:
Oracle Database 2 Day DBA for more information about database backup, database recovery, and Oracle Flashback conceptsUsing 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 logs 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 with 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, as described in Oracle Database 2 Day DBA, 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 the Database Configuration Assistant 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.
If you use a cluster file system, you must specify LOG_ARCHIVE_DEST_1 and LOG_ARCHIVE_FORMAT for each node in the database parameter initialization file.
See Also:
Oracle Database 2 Day DBA for details on how to configure archiving using ASM
Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide for more information about configuring and managing archived redo logs for an Oracle RAC database
An instance does not need access to the archived logs from a different instance except when performing backup or recovery operations. When performing backup operations across instances, the archived redo 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.
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 logs for your Oracle RAC database, then each instance automatically has access to all the archived log files generated by the database. If you use shared storage or raw devices to store the archived log files on each node, then you must configure the operating system to grant access to those directories for each instance in 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 a check box labeled Save as Preferred Credential. If you check this box 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.
Assuming you have a flash recovery area configured and are running in ARCHIVELOG mode, 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 using Enterprise Manager to configure backup settings for your databaseWhen 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:
Go to the Cluster Database Home Page, and click the Maintenance tab.
On the Cluster Database Maintenance page, under the Backup/Recovery column, select Schedule Backup.
Follow the backup procedures outlined in Chapter 9, "Performing Backup and Recovery" of Oracle Database 2 Day DBA.
RMAN depends on server sessions, processes that run on the database server, to perform backup and restore 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 one backup or recovery 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 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 log files to a local directory. When multiple channels are allocated that have access to the archived logs, for each archived log file, RMAN determines which channels have access to that archived log. Then, RMAN groups together the archived logs that can be accessed by a channel and schedules a backup job using that channel.
If each node in the cluster writes the archived log files to ASM, a clustered file system, or other type of shared storage, then each instance has access to all the archived log files. In this case, the backup of the archived log files is distributed across all the allocated channels.
Whether only one node or all nodes perform archived log backups, ensure that all archived logs 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 logs.
You can configure RMAN to automatically delete the 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 redo log 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 logs 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 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, 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 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 log files on disk or be able to restore the archived log files from backup files.
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 log files.
If you do not use shared storage or a clustered file system to store the archived log files for your cluster database, then you need to make the archived 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 crash. Any database file can be vulnerable to a media failure. If a media failure occurs, then you must use 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.
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 Maintenance 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:
Go to the Cluster Database Home Page and click the Maintenance tab.
On the Cluster Database Maintenance page, under the Backup/Recovery column, select Perform Recovery.
Follow the recovery procedures outlined in Chapter 9 of Oracle Database 2 Day DBA
You can use Enterprise Manager to restore a lost or damaged server parameter file (SPFILE).
To restore an SPFILE for an Oracle RAC database:
With the database in the MOUNT state, go to the Backup/Recovery section on the Maintenance tab.
Click Perform Recovery.
When the database is not open, the Perform Recovery link takes you to the SPFILE restore page.
Restore the SPFILE to either its default location or to a new location that you specify.
See Also:
Oracle Database Backup and Recovery Basics for more information about restoring a server parameter fileDuring 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 log file with the sequence number 1001 is backed up to the drive attached to the node docrac1, while the archived log file with sequence number 1002 is backed up to the drive 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 logs, then any instance can restore the archived redo logs.
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 Logs—With RMAN, the application of archived redo logs is performed in parallel. Oracle RAC automatically selects the optimum degree of parallelism based on available CPU resources.
Managing RMAN backups, with or without Enterprise Manager, consists of two tasks: managing the backups of your database that are stored on disk or tape, and managing the record of those backups in the RMAN repository. Enterprise Manager simplifies both backup management tasks.
Some of the tasks involved in managing backups include the following:
Searching for backups
Validating the contents of backup sets or image copies
Cross-checking a backup
Deleting expired or obsolete backups
Marking backups as available or unavailable
See Also:
Oracle Database 2 Day DBA. for more information about these topics and details on how to perform these tasksBackup reports contain summary and detailed information about past backup jobs run by RMAN, including both backups run through Enterprise Manager and the RMAN command-line client.
To view backup reports:
From the Cluster Database Home page, click the Maintenance tab.
On the Maintenance property page, under the Backup/Recovery column, select Backup Reports.
The Backup Reports page contains a list of recent backup jobs.
Specify any filter conditions and click Go to restrict the list to backups of interest.
You can use the Filter By 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 to be listed (whether it succeeded or failed, and whether warnings were generated during the job).
To view detailed information about any backup, click the value in the Backup Name column.
The View Backup Report page is displayed for the selected backup. This page contains summary information about this backup, such as how many files of each type were backed up, how much data total, and the number, and the size and type of backup files created.
The View Backup Report page also contains a Filter By section that you can use to quickly run a search for another backup or backups from a specific date range. The resulting report contains aggregate information for backups matching the search criteria.
See Also:
Oracle Database 2 Day DBA for more information about displaying backup reports using Enterprise ManagerOracle By Example (OBE) has a series of tutorials for Oracle RAC databases. This OBE steps you through the basic administrative tasks described in this chapter and includes annotated screen shots.
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
