Using RMAN Effectively In A Dataguard Environment. (文档 ID 848716.1)

In this Document

Purpose

Scope

Details

Creating a standby database using RMAN.

Automatic maintenance of the archivelogs on the standby database using RMAN.

Rolling forward a Standby database using rman incremental backups.

Using Rman backups to backup standby database

Reinstating a Physical Standby Using Backups Instead of Flashback.

Known issues

References

---

Applies to:

Oracle Database - Enterprise Edition - Version 8.1.7.0 to 11.2.0.3 [Release 8.1.7 to 11.2]
Information in this document applies to any platform.

Purpose

This article basically talks about how RMAN can be used in a dataguard environment effectively.

Scope

Data Guard enables and automates the management of a disaster recovery solution for Oracle databases located on the same campus or across the continent. Data Guard consists of a production database (also known as the primary database) and one or more standby database(s), which are transactionally consistent copies of the production database.

RMAN is a tool integrated with the Oracle Database that satisfies the demands of high performance, manageable backup and recovery. RMAN is designed to work intimately with the server, providing block-level corruption detection during backup and restore. RMAN optimizes performance and space consumption during backup with file multiplexing and compression, and operates with leading backup software systems via the supplied Media Management Library (MML) API.

RMAN brings rich functionality such as online backups, incremental backups, block media recovery, automation of backup management tasks, and integration with 3rd party media management systems into the Data Guard configuration. Since RMAN and Data Guard are part of the integrated Oracle High Availability technology stack, RMAN backups can be seamlessly offloaded to a physical standby database, allowing customers to gain more value out of their disaster recovery investment. Backups do not impact normal Data Guard operation they can be taken while the standby database is in recovery or read-only mode. Backups can be used to recover either primary or standby database servers.

Data Guard and RMAN were both designed with the Oracle database architecture in mind. Together, they offer the most reliable and tightly integrated solution to achieve superior levels of Oracle database availability supporting your mission critical applications. Data Guard and RMAN are both fully supported features of the Oracle Database Enterprise Edition (RMAN is also provided with Oracle Database Standard Edition).

This article basically talks about how RMAN can be used in a dataguard environment effectively. The following topics will be discussed here.

++ Creating a standby database using RMAN.
++ Automatic maintenance of the archivelogs on the standby database using RMAN.
++ Rolling forward a Standby database using RMAN incremental backups.
++ Using RMAN to backup the Standby databases.
++ Reinstating a Physical Standby Using RMAN Backups Instead of Flashback.

Details

Creating a standby database using RMAN.

Apart from manually creating the standby database, RMAN can also be used to create the standby database. There are several advantages to using RMAN to create a standby database:

* RMAN creates standby databases using backups of the primary database, restoring datafiles to  the standby site from backups. Thus, the primary database is not affected during the creation of standby databases.
* RMAN automates renaming of files including Oracle Managed Files (OMF), and directory structures.
* RMAN restores archived redo log files from backups and performs recovery to catch up the standby database to the primary database.

The procedure for preparing a standby database with RMAN is basically the same as for preparing a duplicate database.Nevertheless, you need to amend the duplication procedures described in the following articles to account for the issues specific to a standby database. 

Note 374069.1 Creating a Standby Database on a new host

There are a few other documents related to creation of a standby, but are describing a specific situation

ASM related :
  Note 838828.1 Step-By-Step Guide To Create Physical Standby On Normal File System For ASM Primary using RMAN
  Note 837102.1 Step By Step Guide On Creating Physical Standby Using RMAN Duplicate In ASM Filesystem For ASM Primary

Miscellaneous :
   Note 469493.1 Step By Step Guide To Create Physical Standby Database Using RMAN Backup and Restore
   Note 1075908.1 Step by Step Guide on Creating Physical Standby Using RMAN DUPLICATE...FROM ACTIVE DATABASE

 

Automatic maintenance of the archivelogs on the standby database using RMAN.

By default, archived redo log files in a flash recovery area that were backed up to a tertiary device or made obsolete (as defined by the RMAN retention policy) are eligible for deletion. The archived redo log files that are backed up or obsolete can eventually be deleted automatically to make space if the disk space in the flash recovery area becomes full. However, you can change this default deletion policy using the following RMAN command:

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO [CLEAR | NONE | APPLIED ON STANDBY];

The necessary steps to implement the above feature is clearly provided in the following article.

Note 728053.1 Configure RMAN to purge archivelogs after applied on standby
Note 394261.1 How to Ensure that RMAN Does NOT Delete Archived Logs That Have Not Yet Shipped to Standby

 

Rolling forward a Standby database using rman incremental backups.

In some situations, RMAN incremental backups can be used to synchronize a physical standby database with the primary database. Using the RMAN BACKUP INCREMENTAL FROM SCN command, you can create a backup on the primary database that starts at the standby database's current SCN, which can then be used to roll the standby database forward in time.

RMAN incremental backups will be useful in the following situations

* Physical Standby Database Lags Far Behind the Primary Database
* Physical Standby Database Has Nologging Changes On a Subset of Datafiles
* Physical Standby Database Has Widespread Nologging Changes

The steps that have to be implemented in the above situations are clearly described in the following articles.

Note.290814.1 Rolling a Standby Forward using an RMAN Incremental Backup in 10g
Note.290817.1 Rolling a Standby Forward using an RMAN Incremental Backup in 9i
Note 958181.1 Rolling a Standby Forward using an RMAN Incremental Backup To Fix The Nologging Changes
Note 836986.1 Steps to perform for Rolling forward a standby database using RMAN incremental backup when primary and standby are in ASM filesystem

Miscellaneous :
Note 605234.1   How to Copy ASM datafile From Primary Database to Standby Database on ASM using RMAN
Note 1531031.1 Steps to perform for Rolling forward a standby database using RMAN incremental backup when datafile is added to primary

 

Using Rman backups to backup standby database

RMAN can back up the standby database and its associated archived redo logs. Standby backups of datafiles and archived redo logs are fully interchangeable with primary database backups. In other words, you can run the RESTORE command
to restore a backup of a standby datafile to the primary database, and you can restore a backup of a primary datafile to the standby database. The standby control file and primary control file, however, are not interchangeable.

The following articles provide extensive information about rman backups in the standby environemnt.

Note 602299.1 Benefits and Usage of RMAN with Standby Databases
Note 203980.1 How To Use RMAN For Backup And Restore In A Standby Database Environment
Note 1419923.1 Howto make a consistent RMAN backup in an Standby database in Active DataGuard mode

 

Reinstating a Physical Standby Using Backups Instead of Flashback.

After a Data Guard failover to a physical standby database, using flashback database is still the MAA recommendation to reinstate the original primary database since it is the simplest and fastest approach. However, if for some reason the flashback data is not available or flashback database was not enabled before the failure, you can use the steps provided in this document to reinstate the original primary database using existing backups instead of flashback database.

The steps are clearly depicted in the following article. 

Note 416310.1 Reinstating a Physical Standby Using Backups Instead of Flashback

 

Known issues

Note 357759.1 Known RMAN - Dataguard Problems

Note 1385911.1 RMAN-06131 error occurred during rman backup on standby database in dataguard environment
Note 344529.1 Rman Backup on Dataguard Site Fails Rman-06059 Attempting to Backup a Log Previously Backed Up and Deleted

 

---

References

NOTE:290814.1 - Rolling a Standby Forward using an RMAN Incremental Backup in 10g
NOTE:203980.1 - How To Use RMAN For Backup And Restore In A Standby Database Environment
NOTE:728053.1 - Configure RMAN to purge archivelogs after applied on standby
NOTE:290817.1 - Rolling a Standby Forward using an RMAN Incremental Backup in 9i
NOTE:374069.1 - Creating a Standby Database on a new host
NOTE:416310.1 - Reinstating a Physical Standby Using Backups Instead of Flashback
NOTE:602299.1 - Benefits and Usage of RMAN with Standby Databases
NOTE:836986.1 - Steps to perform for Rolling forward a standby database using RMAN Incremental Backup.
NOTE:958181.1 - Rolling a Standby Forward using an RMAN Incremental Backup To Fix The Nologging Changes
NOTE:1531031.1 - Steps to perform for Rolling forward a standby database using RMAN incremental backup when datafile is added to primary