NetVault Plug-in for Oracle 7.1

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

•

Back up from both Primary and Standby

•

Back up from Standby only

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 is a valid strategy, resource-intensive backup operations will impact 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:

•

Oracle 10.2.x – Backing up the datafiles and the archived redo log files can be offloaded to the Standby Database Server while the backups of the Control Files and the SPFILE must be performed on the Primary Database Server. In addition, backups of the datafiles and archived redo log files can be used to recover either the Primary or Standby Database Server, regardless of whether the backups were taken from the Primary or Standby Database Server. For more information, refer to RMAN to Back Up and Restore Files in Oracle 10.2.x Data Guard Concepts and Administration.

•

Oracle 11.x – Backups of the datafiles, archived redo log files, Control Files, and SPFILE are interchangeable between the Primary and Standby Database Server, which means that all backups can be performed from one of the 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. For more information, refer to Using RMAN to Back Up and Restore Files in Oracle 11.x Data Guard Concepts and Administration.

While Oracle 11.x does not require all the backups to be performed on the Standby Database Server, a valid strategy for an Oracle 11.x environment would be to mimic the requirements of an 10.2.x environment where only the datafiles and the 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 both Oracle 10.2.x and 11.x would be 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 on a weekly basis on the Standby Database Server and the Incremental Level 1 backups are performed on a daily basis from the Primary Database Server on a daily basis. 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 will perform backups.


	NOTE: For Oracle versions prior to 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 another 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.

Backup destination strategy

When implementing a Back up from both Primary and Standby strategy for an Oracle 10.2.x Data Guard environment, you must 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 will result 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 registered in the Recovery Catalog as well.

Later in the week, if a backup of the FRA is performed to tape from the Standby Database Server, the FRA-to-tape backup will attempt 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 same FRA, the FRA-to-tape backup will fail. RMAN will attempt to access backup sets on the Primary Database Server that are not accessible from the Standby Database Server that is performing the FRA-to-tape backup.

Therefore, for Oracle 10.2.x Data Guard environments, Dell 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-tape backups, RMAN backs up the backup sets in the FRA of the Database Server performing the FRA-to-tape backup.

For more information on performing backups to tape, see Setting backup options. For more information on FRA backups, see Flash Recovery Area (FRA) backups.

Back up from Standby only

Starting with Oracle 11.x, backups of the datafiles, archived redo log files, Control Files, and SPFILE are interchangeable between the Primary and Standby Database Server meaning that all backups can be performed from one of the Standby Database Servers. With this strategy, Plug‑in for Oracle is installed on both the Primary Database Server and at least one of the Standby Database Servers that performs backups. The plug-in must be installed on the Primary Database Server when it is targeted for a restore; that is, if you want to use the backup of the Standby Database Server to recover the Primary Database Server, you will need to install the plug-in on the Primary Database Server.


	NOTE: Because Oracle 10.2.x only allows the backing up of the datafiles and the archived redo log files to be offloaded to the Standby Database Server while requiring the backups of the Control Files and the SPFILE to be performed on the Primary Database Server, the Back Up from Standby Only strategy is not supported for Oracle 10.2.x Data Guard environments.

Deployment

Plug‑in for Oracle’s support in Data Guard environments is restricted to physical standby databases. Logical and Snapshot standby databases are not supported. A physical standby database is a transactionally consistent copy of the production database. All references to standby databases refer to physical standby databases.

The plug-in supports the following types of Data Guard deployments:

Table 6. Supported deployments
Primary Database Server Configuration		Physical Standby Server Configuration
Single-Instance	-->	Single-Instance
Multi-Instance RAC	-->	Single-Instance
Multi-Instance RAC	-->	Multi-Instance RAC