E Cascaded Destinations

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.

Note:

You cannot set up a physical standby to forward redo if the primary database is part of an Oracle Real Application Clusters (RAC) environment or 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

A physical standby database can support a maximum of nine 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 rest of this appendix contains information about the following:

Configuring Cascaded Destinations
Role Transitions with Cascaded Destinations
Examples of Using Cascaded Destinations

E.1 Configuring Cascaded Destinations

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:
- ASYNC or 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.

Example E-1 shows 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.

Note:

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" for more information.

Example E-1 Sample Use of Initialization Parameters in Cascaded Destinations

Boston Database (Primary Role)

DB_UNIQUE_NAME=boston
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
 
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'
 
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/boston/ VALID_FOR=(ALL_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)'
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
 
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/  VALID_FOR=(ALL_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)'
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'

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, VALID_FOR=(ALL_LOGFILES, PRIMARY_ROLE), that will be used for local archiving when the physical standby database transitions to the primary role.

E.2 Rol e 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.

E.3 Examples of Using Cascaded Destinations

This section describes the following scenarios which demonstrate configuration options and uses for cascaded destinations:

Physical Standby Forwarding Redo to a Remote Physical Standby
Physical Standby Forwarding Redo to a Logical Standby

E.3.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 if there is a failure at your primary site. In addition to the local standby, you wish to maintain a geographically remote standby database 2000 miles away at a disaster recovery site. A small amount of data loss is acceptable if failover to the remote standby is required (an acceptable trade-off in return for the extra protection against events that can affect 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.

You could configure your primary database to ship redo directly to both standby databases; however, 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 on the primary database to maintain a second standby.

E.3.2 Physical Standby Forwarding Redo to a Logical Standby

In this scenario, 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 queries 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 European 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 parameters in Example E-1 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.