Cascaded Standby Databases in Oracle 10g/11g (文档 ID 409013.1)

Oracle Database - Enterprise Edition - Version 9.0.1.0 to 11.2.0.1 [Release 9.0.1 to 11.2]
Information in this document applies to any platform.
***Checked for relevance on 02-OCT-2014***
** checked for relevance '23-Nov-2015' **

GOAL

The information below replaces Appendix E Cascaded Destinations of Oracle Data Guard Concepts and Administration 10g Release 2 (10.2) part number B14239.

This information also applies to Oracle10g Release 1 and Oracle9i releases.

For information on Cascaded Destinations in Data Guard 11g Release 1, please see Appendix E here.

For 11g Release 2, see Chapter 6 Redo Transport Services :- http://docs.oracle.com/cd/E11882_01/server.112/e41134/log_transport.htm#SBYDB00400

Please note that as of Version 11.2.0.2 many of the restrictions with cascaded standby databases have been lifted. Please refer to the documentation link above for up to date information in 11.2.0.2 and cascaded standby databases.

SOLUTION

Summary:

The significant changes from the previous Oracle Database 10g Release 2 documentation include:

Cascading logical standby databases from a logical standby database is not supported.
Cascading standby databases (logical or physical) from a primary database that is part of an Oracle Real Application Cluster (RAC) is not supported (This restriction has been lifted in 11.2.0.2)
Using Cascaded standby databases in a Data Guard Broker environment is not supported.

Details:

To reduce the load on your primary system, or to reduce the bandwidth requirements imposed when your standbys are separated from the primary database through a Wide Area Network (WAN), you can implement cascaded destinations, whereby a standby database receives its redo data from another standby database, instead of directly from the primary database.

In a Data Guard configuration using a cascaded destination, a physical standby database can forward the redo data it receives from the primary database to another standby database. Only a physical standby database can be configured to forward redo data to another standby database. A logical standby database cannot forward redo to another standby database.

You cannot set up a physical standby to forward redo if the primary database is part of an Oracle Real Application Cluster (RAC) (lifted as of 11.2.0.2) or part of a Data Guard Broker environment.

The following Data Guard configurations using cascaded destinations are supported.

Primary Database > Physical Standby Database with cascaded destination > Physical Standby Database
Primary Database > Physical Standby Database with cascaded destination > Logical Standby Database

While a logical standby database cannot forward redo to another standby database, it can be configured to have its own physical standby database. In such a case, the physical standby database is not considered a Cascaded Destination because it does not receive redo that is forwarded from the primary database. Instead, it is receiving redo generated by the logical standby. However this can only be used for Rolling Upgrades since a failover to the Logical standby database's Physical standby would not result in a new Logical Standby. Instead it would become another Primary and no longer be part of the original Data Guard configuration.

A physical standby database can support a maximum of nine (30 as of Version 11.2) remote destinations. When a cascaded destination is defined on a physical standby database, the physical standby will forward redo it receives from the primary to a second standby database after its standby redo log becomes full and is archived. Thus, the second standby database receiving the forwarded redo as a result of a cascaded destination will necessarily lag behind the primary database.

Oracle recommends that cascaded destinations be used only for offloading reporting or for applications that do not require access to data that is completely up-to-date with the primary system. This is because the very nature of a cascaded destination means that the standby database that is the end-point will be one or more log files behind the primary database. Oracle also recommends that standby databases whose primary role is to be involved in role transitions receive their redo data directly from the primary database.

The remainder of this note contains information about the following:

Configuring a cascaded destination
Role transitions in the presence of a cascaded destination
Examples of cascaded destinations

Configuring a Cascaded Destination

To enable a physical standby database to forward incoming redo data to a cascaded destination perform the following steps:
- Create standby redo log files on the physical standby database (if not already created).
  - If standby redo log files are not already defined, you can define them dynamically on the standby database. The standby database will begin using them after the next log switch on the primary database.
- Define a LOG_ARCHIVE_DEST_n initialization parameter on the primary database to set up a physical standby database that will forward redo to a cascaded destination.
  Define the destination to use:
  - LGWR ASYNC or
  - LGWR SYNC
  Optionally, set the VALID_FOR attribute so that redo forwarding is enabled even after a role transition happens between the original primary database and the intermediate standby database that is forwarding redo. This may be meaningful in cases where the databases are separated over Wide Area Networks.
- Ensure that archiving is enabled on the physical standby database where the cascaded destinations are defined (the standby database that will forward redo).
- Configure a LOG_ARCHIVE_DEST_n parameter (on the physical standby that will forward redo data) for each cascaded destination.
Below are the initialization parameters for a primary database named Boston, which sends redo to a physical standby database named Chicago, that forwards the redo it receives to a cascaded standby database named Denver. In this example, the database named Denver is a logical standby database, but note that a physical standby database can forward redo to either a physical or a logical standby database.

When the cascaded destination is a logical standby database, remember that you will create it just as if the logical standby will be directly connected to the primary database (see Chapter 4 Creating a Logical Standby Database of Oracle Data Guard Concepts and Administration 10g Release 2).

Boston Database (Primary Role)

DB_UNIQUE_NAME=boston
STANDBY_ARCHIVE_DEST=/arch1/boston/
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/boston/ VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2= 'SERVICE=denver VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_3='SERVICE=chicago VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'

Chicago Database (Standby Role)

DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'
STANDBY_ARCHIVE_DEST=/arch1/chicago/
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2='SERVICE=denver VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_3='SERVICE=boston VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'

Denver Database (Standby Role)

DB_UNIQUE_NAME=denver
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'
STANDBY_ARCHIVE_DEST=/arch2/denver/
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/denver/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_2='LOCATION=/arch2/denver/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'

In the example parameters above for the standby database Denver, STANDBY_ARCHIVE_DEST is set to /arch2/denver/ because this is a logical standby database. If Denver were a physical standby database, it would not be necessary to change STANDBY_ARCHIVE_DEST - it would match LOG_ARCHIVE_DEST_1.

Both the Boston primary database and the Chicago physical standby database define the LOG_ARCHIVE_DEST_2 initialization parameter as 'SERVICE=denver VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE). Hence, even if the Boston and Chicago databases switch roles, the redo data will continue to be forwarded to the Denver database. Remember, as part of the original setup of the physical standby database, you should define a local destination as VALID_FOR=(ONLINE_LOGFILE, PRIMARY_ROLE), that will be used for local archiving when the physical standby database transitions to the primary role.
Role Transitions with Cascaded Destinations

Oracle recommends that standby databases primarily intended for disaster recovery purposes receive redo data directly from the primary database. This will result in the optimum level of data protection. A cascaded destination may be used as a second line of defense, but by definition it will always be further behind than a standby database that is receiving redo directly from the primary.
Examples of using Cascaded Destinations

The following scenarios demonstrate configuration options and uses for cascaded destinations.

Scenario 1: Physical Standby Forwarding Redo to a Remote Physical Standby

You have a primary database in your corporate offices and you want to create a standby database at another facility within your metropolitan area to provide zero data loss protection should there be a failure at your primary site. In addition to the local standby, you wish to maintain a geographically remote standby database 2,000 miles away at a disaster recovery site. A small amount of data loss is acceptable should failover to the remote standby be required (an acceptable trade-off in return for the extra protection against events that can impact a large geographic area and cause both the primary site and the local standby database to fail). The remote standby database also provides continuous data protection after a failover to the local standby database and improves security by enabling backups to be created and stored at the remote location, eliminating the need to ship tapes off-site.

While you could configure your primary database to ship redo directly to both standby databases, you may want to eliminate the potential overhead of the primary database shipping redo over a WAN to the second standby database. You solve this problem by creating the first physical standby in a local facility within your metropolitan area using the SYNC network transport to achieve zero data loss protection. A cascaded destination is defined on the local physical standby database that will forward redo received from the primary to the remote standby database using ASYNC network transport. Because the local standby manages all communication with the remote standby via a cascaded destination, there is no impact to the primary database to maintain a second standby.

Scenario 2: Physical Standby Forwarding Redo to a Logical Standby

You have a primary database in a city in the United States and you wish to deploy three complete replicas of this database to be used for end-user query and reporting in three different manufacturing plants in Europe. Your objective is to eliminate the need for users and applications at your European locations to access data that resides in the US to prevent network disruptions from making data unavailable for local access. While you can accept some latency between the time an update is made in the primary and the time it is replicated to all three European sites, you desire the data to be as up-to-date as possible and available to query and to run reports. You require a solution that is completely application transparent, and one where additional replicas can be deployed to sites in Europe if the need arises. A final requirement is the need to make this work with the limited bandwidth and very high network latency of the network connection between your US and European facilities.

You address your requirements by first creating a physical standby database in Europe for the primary database located in the US. You then create three logical standby databases, one in each of your European plants, and define each logical standby as a cascaded destination on your physical standby database. One copy of the redo is shipped over the transatlantic link from the US to the physical standby in Europe. The physical standby in Europe forwards the redo to the three logical standby databases in the Europe manufacturing plants providing local access to corporate data for end-user query and reports. Room for future growth is built in - additional standby databases can be deployed in Europe without any modification to applications, without any additional overhead on your primary system, and without consuming any additional transatlantic bandwidth.

Configure the physical standby database to forward redo data to the logical standby databases in each of your manufacturing sites as in the example above. The only difference from the example parameters, above, is that you will define two additional LOG_ARCHIVE_DEST_n parameters on the physical standby so that redo will be forwarded to all three logical standby databases.