| Oracle® Database 2 Day + Real Application Clusters Guide 11g Release 2 (11.2) Part Number E17264-12 |
|
|
PDF · Mobi · ePub |
| Oracle® Database 2 Day + Real Application Clusters Guide 11g Release 2 (11.2) Part Number E17264-12 |
|
|
PDF · Mobi · ePub |
To protect the database against data loss and reconstruct the database after data loss, you must devise, implement, and manage a backup and recovery strategy. This chapter describes how to back up and recover an Oracle Real Application Clusters (Oracle RAC) database.
This chapter contains the following sections:
Archiving the Oracle Real Application Clusters Database Redo Logs
Performing Backups of Your Oracle Real Application Clusters Database
About Preparing to Restore and Recover Your Oracle RAC Database
Displaying Backup Reports for Your Oracle Real Application Clusters Database
See Also:
Oracle Database Backup and Recovery User's Guide for more information about using the Recovery Manager utility
To protect your Oracle Real Application Clusters (Oracle RAC) database from hardware failures or disasters, you must have a physical copy of the database files. The files protected by the backup and recovery facilities built into Oracle Enterprise Manager include data files, 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 data file 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 data file 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 data files 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.
Note:
For the RMAN utility to work properly on Linux platforms, the
$ORACLE_HOME/bin directory must appear in the PATH variable before the /usr/X11R6/bin directory.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 data files with corrupt blocks
If the database files are damaged or need recovery, then Enterprise Manager can determine which parts of the database must be restored from a backup and recovered, including early detection of 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 fast 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 fast recovery area to simplify your backup management.
The larger the fast recovery area is, the more useful it becomes. Ideally, the fast recovery area should be large enough to contain all the following files:
A copy of all data files
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 fast recovery area for an Oracle RAC database must be placed on an Oracle ASM disk group, a cluster file system, or on a shared directory that is configured through a network file system file for each Oracle RAC instance. In other words, the fast recovery area must be shared among all of the instances of an Oracle RAC database. The preferred configuration for Oracle RAC is to use Oracle Automatic Storage Management (Oracle ASM) for storing the fast recovery area, using a different disk group for your recovery set than for your data files.
The location and disk quota must be the same on all instances. Oracle recommends that you place the fast recovery area on the shared Oracle 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 fast recovery feature, you must first configure the fast recovery area for each instance in your Oracle RAC database.
To make your data highly available, it is important to configure the database so you can recover your data after a system failure. Redo logs contain a record of changes that were made to datafiles. Redo logs are stored in redo log groups, and you must have at least two redo log groups for your database.
After the redo log files in a group have filled up, the log writer process (LGWR) switches the writing of redo records to a new redo log group. Oracle Database can automatically save the inactive group of redo log files to one or more offline destinations, known collectively as the archived redo log (also called the archive log). The process of turning redo log files into archived redo log files is called archiving.
When you archive your redo log, you write redo log files to another location before they are overwritten. This location is called the archived redo 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 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 four 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, because 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 must ensure that the archived redo logs for every instance are backed up.
To backup the archived redo logs from a single node, that node must 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 must 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.
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 perform 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 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.
See Also:
"Performing Backups of Your Oracle Real Application Clusters Database"
Oracle Database 2 Day DBA for more information about RMAN backups
Oracle Database 2 Day DBA for more information about configuring backup device settings
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:
On the Database Home page of Enterprise Manager Database Control, 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.
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 Oracle ASM, or to /u01/oradata/arch if you want local archiving on each node.
If you must configure a different archive log destination for any instance, then 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.
If you want to configure multiple archive log destinations for the database, then 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, then you are prompted to enter the login credentials.
See Also:
"About 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
Before taking backups of your Oracle Real Application Clusters (Oracle RAC) database using Enterprise Manager, you must configure access for the user performing the backups, or credentials. You can also configure the default values for certain backup settings, so they do not have to be specified every time a backup is taken.
See Also:
When using Enterprise Manager, you must have the proper credentials to perform 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.
Assuming you have a fast recovery area configured, you can configure several 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.
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 Oracle 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, then any operating system user who has execute permission for the RMAN command-line client can perform backups of an Oracle Real Application Clusters (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 or click Help on this page.
See Also:
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
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:
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.
Choose a backup type and click Schedule Customized Backup.
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.
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.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 early detection of 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.
This section discusses both instance recovery and media recovery. It contains the following topics:
See Also:
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 before recovering your database:
During recovery, because 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 must 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 is performing the recovery should be started in MOUNT mode. The other instances should be started in NOMOUNT mode.
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 1_001 is backed up to a device attached to the node racnode1, while the archived redo log file with sequence number 2_003 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 1_001, but not log sequence2_003. The channel connected to racnode2 can restore log sequence 2_003, but not log sequence 1_001.
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.
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 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, then 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.
See Also:
Oracle Database 2 Day DBA for more information about incremental backups of data files
Oracle Database 2 Day DBA for more information about configuring recovery settings
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.
The Perform Recovery page appears.
Follow the recovery procedures outlined in Chapter 9 ofOracle Database 2 Day DBA
See Also:
"About Preparing to Restore and Recover Your Oracle RAC Database"
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 MOUNT mode.
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.
When the database is not open, the Perform Recovery link takes you to the SPFILE restore page.
Specify the location of the fast 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
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.
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 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.
|
 Copyright © 2006, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|