NetVault Plug-in for Oracle 11.3 - User Guide

Oracle® Data Guard: an overview

Oracle’s Oracle Data Guard “ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions. Data Guard maintains these standby databases as copies of the production database. If the production database becomes unavailable because of an outage, Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage. Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability.”

With Data Guard, administrators can optionally improve production database performance by offloading resource-intensive backup and reporting operations to Standby Database Servers. In addition, backups can be used to recover either the Primary or Standby Database Server, regardless of whether the backups were taken from the Primary or the Standby Database Server.

Plug‑in for Oracle provides support for a limited number of Oracle versions in a Data Guard environment. The installation, configuration, backup, and restore procedures differ slightly in a Data Guard environment. This topic offers specifics on how the plug-in operates in a Data Guard environment.

For a complete list of supported Oracle versions and platforms in a Data Guard environment, see the Quest NetVault Backup Compatibility Guide.

NOTE: The plug-in’s RMAN backup method is the only method supported in Data Guard environments. Unless outlined in the following topics, backups and restores performed with the plug-in for Data Guard physical or standby databases are the same as backups and restores performed with non-Data Guard databases.

Defining a deployment strategy

Determining a strategy for protecting and recovering a Data Guard environment is essential to deploying and using the plug-in in the Data Guard environment. All strategies are valid for any of the supported deployments as detailed in Deployment.

Back up from Primary only

The simplest strategy is to perform all the backups from the Primary Database Server. You can use these backups to recover the Primary or one of the Standby Database Servers. While this strategy is valid, resource-intensive backup operations affect database performance on the Primary Database Server. With this strategy, the plug-in is installed on the Primary Database Server. Plug‑in for Oracle is only required to be installed on the Standby Database Server when it is targeted for a restore.

Back up from both Primary and Standby

Offloading resource-intensive backup operations to the Standby Database Server is often one of the drivers for deploying Data Guard. The Oracle® version dictates how much of the backup operations can be offloaded to the Standby Database Server:

While Oracle 11.x does not require all backups to be performed on the Standby Database Server, a valid strategy for an Oracle 11.x environment is to mimic the requirements of a 10.2.x environment. In a 10.2.x environment, only datafiles and archived redo log files are offloaded to the Standby Database Server while the Control Files and SPFILE backups are performed from the Primary Database Server.

Another valid strategy for Oracle 10.2.x and 11.x is to perform Control File and SPFILE backups from the Primary Database Server while alternating the backups of the datafiles and archived redo log files between the Primary Database Server and the Standby Database Server. For example, Incremental Level 0 Backups are performed weekly on the Standby Database Server and the Incremental Level 1 backups are performed daily from the Primary Database Server. In addition, daily backups of the Control File and SPFILE are performed from the Primary Database Server.

Oracle’s Maximum Availability Architecture (MAA) best practices recommend that backups be taken at both the primary and the standby databases to reduce MTTR, in case of double outages and to avoid introducing new site practices on switchover and failover.

With this strategy, Plug‑in for Oracle is installed on both the Primary and at least one of the Standby Database Servers that performs backups.

NOTE: For Oracle versions before Oracle 11.x, backups of SPFILE were assumed to be usable at any other standby database. However, in practice, all standby databases cannot use the same SPFILE. Therefore, RMAN does not allow an SPFILE backup taken at one database site to be used at a different database site. This restriction is in place only when the COMPATIBLE initialization parameter is set to 11.0.0. The standby database lets you offload all backup operations to one specific standby database, except the backups of SPFILE. However, if the COMPATIBLE initialization parameter is set to 11.0.0, the SPFILE can be backed up to disk and cataloged manually at standby sites where backups are written to tape or NetVault Backup media. The additional metadata stored in SPFILE backup sets enables RMAN to identify which database SPFILE is contained in which backup set. Thus, the appropriate SPFILE backup is chosen during restore from tape or NetVault Backup media.

When implementing a strategy that backs up from both Primary and Standby Servers for an Oracle® 10.2.x Data Guard environment, consider the accompanying backup-destination strategy, which is detailed in Defining a Backup Destination strategy.

Because RMAN stores backup metadata in the Recovery Catalog, a backup performed from the Primary Database Server to the FRA results in the RMAN backup pieces created during backup being registered in the Recovery Catalog. On the following day, if a backup performed from the Standby Database Server is also performed to the FRA, the RMAN backup pieces created during backup are also registered in the Recovery Catalog.

Later in the week, if a backup of the FRA is performed to NetVault Backup Media Manager from the Standby Database Server, the FRA-to-NetVault Backup Media Manager backup attempts to access backup sets that were created by the Primary Database Server’s backups to the FRA. Because the primary and standby databases do not share the FRA, the FRA-to-NetVault Backup Media Manager backup fails. RMAN attempts to access backup sets on the Primary Database Server that are not accessible from the Standby Database Server that is performing the FRA-to-NetVault Backup Media Manager backup.

Therefore, for Oracle 10.2.x Data Guard environments, Quest recommends that backups to FRA only be performed from either the Primary Database Server or the Standby Database Server, but not both.

In Oracle 11.x Data Guard environments, the Oracle parameter db_unique_name allows the Recovery Catalog to distinguish the origin of backups to the FRA. When selecting FRA-to-NetVault Backup Media Manager backups, RMAN backs up the backup sets in the FRA of the Database Server performing the FRA-to-NetVault Backup Media Manager backup.

For more information on performing backups to NetVault Backup Media Manager, see Setting backup options. For more information on FRA backups, see Flash Recovery Area (FRA) backups.