| Oracle® Application Server Disaster Recovery Guide 10g Release 3 (10.1.3.3.0) Part Number E12297-02 |
|
|
View PDF |
Chapter 2, "Implementing the Solution" of this manual describes how to set up a symmetric Oracle Application Server Disaster Recovery topology, which is a configuration that is completely identical across tiers on the production site and standby site.
Oracle Application Server Disaster Recovery also supports asymmetric topologies. An asymmetric topology is a disaster recovery configuration that is different across tiers at the production site and standby site. In most asymmetric OracleAS Disaster Recovery topologies, the standby site has fewer resources than the production site.
Before you read this appendix, read Chapter 2, "Implementing the Solution" to ensure that you understand the concepts and information presented in that chapter. Many of the concepts for setting up a symmetric topology are also valid for setting up an asymmetric topology.
Section C.1, "Steps for Creating an Asymmetric Topology" describes the basic steps for creating an asymmetric topology. It does not describe in detail applicable concepts for setting up an asymmetric topology that were previously described for symmetric topologies in Chapter 2, "Implementing the Solution."
Some of the different types of supported asymmetric topologies include:
A standby site with fewer hosts and OracleAS instances than the production site. See Section C.1.1, "Creating an Asymmetric Standby Site with Fewer Hosts and Instances" for more information about this topology.
A standby site with fewer hosts and the same number of instances as the production site. See Section C.1.2, "Creating an Asymmetric Standby Site with Fewer Hosts and the Same Number of Instances" for more information about this topology.
A standby site with a different database configuration than the production site. For example, a standby site could use a single instance database instead of the Real Application Clusters database used at the production site. See Section C.1.3, "Creating an Asymmetric Standby Site with a Different Database Configuration" for more information about this topology.
Note:
All the host names used in this appendix are Application Server host names.This section describes the high level steps for creating any type of asymmetric OracleAS Disaster Recovery topology. The production site is the EDG deployment shown in Figure 2-1. The standby site will be different from the production site.
To create an asymmetric topology:
Design the production site and the standby site. Determine the resources that will be necessary at the standby site to ensure acceptable performance when the standby site assumes the production role.
Note:
The ports for the standby site instances must use the same port numbers as the peer instances at the production site. Therefore, make sure that all the port numbers that will be required at the standby site are available (not in use at the standby site).Create the OracleAS Disaster Recovery production site by performing these operations:
Create volumes on the production site's shared storage system for the OracleAS instances that will be installed for the production site. For more information, see Section 2.2.2.1, "Creating Volumes for the Application Server Host Clusters."
Create mount points and symbolic links on the production site hosts to the Oracle home directories for the OracleAS instances on the production site's shared storage system volumes. For more information, see Section 2.2.2.2, "Creating Mount Points, Symbolic Links, and Oracle Home Directories."
Create mount points and symbolic links on the production site hosts to the Oracle Central Inventory directories for the OracleAS instances on the production site's shared storage system volumes. For more information, see Section 2.2.2.3, "Creating Mount Points, Symbolic Links, and Oracle Central Inventory Directories."
Create mount points and symbolic links on the production site hosts to the static HTML pages directories for the Oracle HTTP Server instances on the production site's shared storage system volumes, if applicable. For more information, see Section 2.2.2.4, "Creating Mount Points, Symbolic Links, and Static HTML Pages Directories."
Install the OracleAS instances for the production site on the volumes in the production site's shared storage system. For more information, see Section 2.3, "Installing the Oracle Application Server Instances for the Production Site."
Create the same volumes with the same file and directory privileges on the standby site's shared storage system as you created for the OracleAS instances on the production site's shared storage system. This step is critical because it enables you to use disk replication later to create the peer OracleAS instance installations for the standby site instead of installing them using Oracle Universal Installer.
Note:
When you configure disk replication, make sure that all the volumes you set up on the production site's shared storage system are replicated to the same volumes on the standby site's shared storage system.Even though some of the instances and hosts at the production site may not exist at the standby site, you must configure disk replication for all the volumes set up for the production site's OracleAS instances.
Perform any other necessary configuration required by the shared storage vendor to enable disk replication between the production site's shared storage system and the standby site's shared storage system. Configure disk replication to asynchronously copy the volumes for the OracleAS home directories, Oracle Central Inventory directories, and Oracle HTTP Server static HTML pages directories in the production site's shared storage system to the standby site's shared storage system.
Create the initial baseline snapshot copy of the production site shared storage system to set up the replication between the production site and standby site shared storage systems. Create the initial baseline snapshot and subsequent snapshot copies using asynchronous replication mode. After the baseline snapshot copy is performed, validate that all the directories for the standby site volumes have the same contents as the directories for the production site volumes. Refer to the documentation for your shared storage vendor for information on creating the initial snapshot and enabled disk replication between the production site and standby site shared storage systems.
After the baseline snapshot has been taken, perform these steps for the OracleAS instances for the standby site hosts:
Set up a mount point directory on the standby site host to the Oracle home directory for the OracleAS instance on the standby site's shared storage system. The mount point directory you set up for the peer instance on the standby site host must be the same as the mount point directory you set up for the instance on the production site host.
Set up a symbolic link on the standby site host to the Oracle home directory for the OracleAS instance on the standby site's shared storage system. The symbolic link you set up for the peer instance on the standby site host must be the same as the symbolic link you set up for the instance on the production site host.
Set up a mount point directory on the standby site host to the Oracle Central Inventory directory for the OracleAS instance on the standby site's shared storage system. The mount point directory you set up for the peer instance on the standby site host must be the same as the mount point directory you set up for the instance on the production site host.
Set up a symbolic link on the standby site host to the Oracle Central Inventory directory for the OracleAS instance on the standby site's shared storage system. The symbolic link you set up for the peer instance on the standby site host must be the same as the symbolic link you set up for the instance on the production site host.
Set up a mount point directory on the standby site host to the Oracle HTTP Server static HTML pages directory for the Oracle HTTP Server instance on the standby site's shared storage system. The mount point directory you set up for the peer instance on the standby site host must be the same as the mount point directory you set up for the instance on the production site host.
Set up a symbolic link on the standby site host to the Oracle HTTP Server static HTML pages directory for the Oracle HTTP Server instance on the standby site's shared storage system. The symbolic link you set up for the peer instance on the standby site host must be the same as the symbolic link you set up for the instance on the production site host.
After completing these steps, the OracleAS instance installations for the production site have been replicated to the standby site. At the standby site, all of the following are true:
The OracleAS instances are installed into the same Oracle home directories on the same volumes as at the production site, and the hosts use the same mount point directories and symbolic links for the Oracle home directories as at the production site.
The Oracle Central Inventory directories are located in same directories on the same volumes as at the production site, and the hosts use the same mount point directories and symbolic links for the Oracle Central Inventory directories as at the production site.
The Oracle HTTP Server static HTML pages directories are located in same directories on the same volumes as at the production site, and the hosts use the same mount point directories and symbolic links for the Oracle HTTP Server static HTML pages directories as at the production site.
The same ports are used for the standby site OracleAS instances as were used for the same instances at the production site.
This section describes how to create an asymmetric standby site that has fewer hosts and OracleAS instances than the production site.
The production site for this OracleAS Disaster Recovery topology is the EDG deployment shown in Figure 2-1. Section 2.2, "Environment Preparation" through Section 2.3, "Installing the Oracle Application Server Instances for the Production Site" describe how to set up this production site and the volumes for its shared storage system, and how to create the necessary mount points and symbolic links.
Figure C-1 shows the asymmetric standby site for the production site shown in Figure 2-1.
Figure C-1 An Asymmetric Standby Site with Fewer Hosts and Instances

The asymmetric standby site shown in Figure C-1 has fewer hosts and instances than its production site shown in Figure 2-1.
The hosts WEBHOST2, WEBHOST4, IDMHOST2, APPHOST2, and OIDHOST2 and the instances on those hosts exist at the production site in Figure 2-1, but not at the asymmetric standby site in Figure C-1. The standby site therefore has two fewer Oracle HTTP Server instances, one fewer Identity Management instance, one fewer OC4J instance and SOA Suite instance, and one fewer Oracle Internet Directory instance than the production site.
It is important to make sure that this standby site will have sufficient resources to provide adequate performance when it assumes the production role.
When you follow the steps in Section C.1, "Steps for Creating an Asymmetric Topology" to set up this asymmetric standby site, the standby site should be properly configured to assume the production role.
Table C-1 shows the standby site hosts and the volumes to mount at the standby site.
Table C-1 Mount Points, Links, and Oracle Homes for Standby Site OracleAS Instances
| Host | Application Server Instance Type | Host Mount Point Directory to Oracle Home Directory on Volume | Link on Host to Oracle Home Directory on Volume | Oracle Home Directory on Volume |
|---|---|---|---|---|
|
OIDHOST1 |
Oracle Internet Directory |
/u02/voloidmount/oid1_oh |
/u01/app/oracle/oid_oh |
/vol/voloid/oid1_oh |
|
IDMHOST1 |
Oracle Identity Management |
/u02/volidmmount/idm1_oh |
/u01/app/oracle/idm_oh |
/vol/volidm/idm1_oh |
|
APPHOST1 |
First OC4J Instance |
/u02/volappmount/app1_oh1 |
/u01/app/oracle/app_oh |
/vol/volapp/app1_oh1 |
|
APPHOST1 |
Second OC4J Instance |
/u02/volappmount/app1_oh2 |
/u01/app/oracle/app_oh2 |
/vol/volapp/app1_oh2 |
|
WEBHOST1 |
Oracle HTTP Server |
/u02/volweb1mount/web1_oh |
/u01/app/oracle/web_oh |
/vol/volweb1/web1_oh |
|
WEBHOST3 |
Oracle HTTP Server |
/u02/volweb2mount/web3_oh |
/u01/app/oracle/web_oh |
/vol/volweb2/web3_oh |
This section describes how to create an asymmetric standby site that has fewer hosts and the same number of instances as the production site.
For the example in this section, the production site is the EDG deployment in Figure 2-1. The asymmetric standby site does not have peer hosts for hosts IDMHOST1 and IDMHOST2 at the production site. Instead, the Identity Management instances for IDMHOST1 and IDMHOST2 at the production site are available from hosts APPHOST1 and APPHOST2 at the standby site.
At the standby site, host name resolution is set up so that Application Server host name IDMHOST1 resolves to host APPHOST1 and Application Server host name IDMHOST2 resolves to host APPHOST2.
If you plan to use this type of asymmetric standby site where the same number of production site OracleAS instances will be available on fewer hosts at the standby site, then you must follow these requirements when you design the production site and standby site to ensure that the asymmetric standby site can be set up correctly:
Install the OracleAS instances for the separate production site hosts into unique Oracle home directories on the volumes. On the hosts, set up unique mount point directories and symbolic links to the Oracle homes. Using unique Oracle home directories, mount points, and symbolic links ensures that there will be no namespace conflicts when these instances are available from fewer hosts at the standby site.
Set up the Oracle Central Inventory directories for the separate production site hosts in unique directories on the volumes. On the hosts, set up unique mount point directories and symbolic links to those Oracle Central Inventory directories. Using unique Oracle Central Inventory directories, mount points, and symbolic links ensures that there will be no namespace conflicts when these Oracle Central Inventory directories are accessible from fewer hosts at the standby site.
The port numbers used for each production site OracleAS instance must be available for the instance at its standby site host.
After this asymmetric topology has been set up, Table C-2 shows the OracleAS instances, mount points, links, and Oracle home directories that will exist for hosts APPHOST1 and APPHOST2 at the standby site.
Table C-2 Mount Points, Links, and Oracle Homes for OracleAS Instances on Standby Site Hosts APPHOST1 and APPHOST2
| Host | Application Server Instance Type | Host Mount Point Directory to Oracle Home Directory on Volume | Link on Host to Oracle Home Directory on Volume | Oracle Home Directory on Volume |
|---|---|---|---|---|
|
APPHOST1 |
Oracle Identity ManagementFoot 1 |
/u02/volidmmount/idm1_oh |
/u01/app/oracle/idm_oh |
/vol/volidm/idm1_oh |
|
APPHOST1 |
First OC4J Instance |
/u02/volappmount/app1_oh1 |
/u01/app/oracle/app_oh |
/vol/volapp/app1_oh1 |
|
APPHOST1 |
Second OC4J Instance |
/u02/volappmount/app1_oh2 |
/u01/app/oracle/app_oh2 |
/vol/volapp/app1_oh2 |
|
APPHOST2 |
Oracle Identity ManagementFoot 2 |
/u02/volidmmount/idm2_oh |
/u01/app/oracle/idm_oh |
/vol/volidm/idm2_oh |
|
APPHOST2 |
First OC4J Instance |
/u02/volappmount/app2_oh1 |
/u01/app/oracle/app_oh |
/vol/volapp/app2_oh1 |
|
APPHOST2 |
Second OC4J Instance |
/u02/volappmount/app2_oh2 |
/u01/app/oracle/app_oh2 |
/vol/volapp/app2_oh2 |
Footnote 1 This instance was available from host IDMHOST1 at the production site.
Footnote 2 This instance was available from host IDMHOST2 at the production site.
Table C-3 shows the OracleAS instances, mount points, links, and Oracle Central Inventory directories that will exist for hosts APPHOST1 and APPHOST2 at the standby site.
Table C-3 Mount Points and Symbolic Links to Oracle Central Inventory Directories on Volumes
| Host | Application Server Instance Type | Host Mount Point Directory to Oracle Central Inventory Directory on Volume | Link on Host to Oracle Central Inventory Directory on Volume | Oracle Central Inventory Directory on Volume |
|---|---|---|---|---|
|
APPHOST1 |
Oracle Identity ManagementFoot 1 |
/u02/volidmmount/idm_orainv |
/u01/app/oracle/idm_orainv |
/vol/volidm/idm_orainv |
|
APPHOST1 |
First OC4J Instance |
/u02/volappmount/app_orainv |
/u01/app/oracle/app_orainv |
/vol/volapp/app_orainv |
|
APPHOST1 |
Second OC4J Instance |
/u02/volappmount/app_orainv |
/u01/app/oracle/app_orainv |
/vol/volapp/app_orainv |
|
APPHOST2 |
Oracle Identity ManagementFoot 2 |
/u02/volidmmount/idm_orainv |
/u01/app/oracle/idm_orainv |
/vol/volidm/idm_orainv |
|
APPHOST2 |
First OC4J Instance |
/u02/volappmount/app_orainv |
/u01/app/oracle/app_orainv |
/vol/volapp/app_orainv |
|
APPHOST2 |
Second OC4J Instance |
/u02/volappmount/app_orainv |
/u01/app/oracle/app_orainv |
/vol/volapp/app_orainv |
Footnote 1 This instance was available from host IDMHOST1 at the production site.
Footnote 2 This instance was available from host IDMHOST2 at the production site.
To create this asymmetric topology:
Replicate all the volumes on the production site's shared storage system to the same volumes on the standby site's shared storage system. This copies the Oracle home directories, Oracle Central Inventory directories, and Oracle HTTP Server static HTML pages directories (if applicable) from the production site volumes to the standby site volumes.
On host APPHOST1 at the standby site, set up the same mount points and symbolic links that you set up on host APPHOST1 at the production site. Also, on host APPHOST1 at the standby site, set up the same mount points and symbolic links that you set up for OracleAS instances on host IDMHOST1 at the production site.
On host APPHOST2 at the standby site, set up the same mount points and symbolic links that you set up on host APPHOST2 at the production site. Also, on host APPHOST2 at the standby site, set up the same mount points and symbolic links that you set up for OracleAS instances on host IDMHOST2 at the production site.
At the standby site, make sure that the host name IDMHOST1 resolves to host APPHOST1 and that host name IDMHOST2 resolves to host APPHOST2. Make sure that all the standby site hosts resolve host name IDMHOST1 to APPHOST1 and host name IDMHOST2 to APPHOST2. For more information on resolving an Application Server host name to a particular IP address, see Section 2.1.6, "Making /etc/hosts File Entries for Local Host Name File Resolution" if you are resolving host names using local host name file resolution or Section 2.1.7, "Resolving Host Names Using DNS Host Name Resolution" if you are resolving host names using DNS host name resolution.
This section describes how to create an asymmetric standby site with a different database configuration than the production site. For example, the standby site could use a single instance database instead of the Real Application Clusters database used at the production site. In Figure C-1, which shows an asymmetric standby site that can be set up for the EDG deployment production site in Figure 2-1, the RAC databases INFRADBHOST1 and INFRADBHOST2 and CUSTDBHOST1 and CUSTDBHOST2 at the production site are replaced by single instance databases INFRADBHOST1 and CUSTDBHOST1 at the standby site, respectively.
Oracle Data Guard is used to provide disaster protection and disaster recovery for the Oracle databases in an Oracle Application Server Disaster Recovery topology.
For general information on using Oracle Data Guard for databases in an Oracle Application Server Disaster Recovery topology, see Appendix A, "Using Databases in the OracleAS Disaster Recovery Solution."
For specific information on configuring Oracle Data Guard when the primary database is a RAC database and the standby database is a single instance database, see the appendix that describes Oracle Data Guard and Real Application Clusters in Oracle Data Guard Concepts and Administration.