E Cascaded Standby Destinations

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. Some 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 isolate your primary database from any communication over the WAN to the second standby database. You can achieve this by creating a physical standby database in a local facility within your metropolitan area and using the SYNC network transport to achieve zero data loss protection (in Maximum Availability data protection mode). A cascaded destination is defined on the local physical standby database that will forward redo received from the primary to the remote standby database. Because the local standby manages all communication with the remote standby via a cascaded destination, there is no interaction required with 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 and without consuming any additional transatlantic network 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 three logical standby databases rather than to one.