Skip Headers

Oracle® Application Server High Availability Guide 10g Release 3 (10.1.3) B15977-01 |
| Home | Solution Area | Contents | Index

Previous | Next |

# 5 OracleAS Disaster Recovery

Disaster recovery refers to how a system recovers from catastrophic site failures caused by natural or unnatural disasters. Examples of catastrophic failures include earthquakes, tornadoes, floods, or fire. Additionally, disaster recovery can also refer to how a system is managed for planned outages. For most disaster recovery situations, the solution involves replicating an entire site, not just pieces of hardware or subcomponents. This also applies to the Oracle Application Server Disaster Recovery (OracleAS Disaster Recovery) solution.

This chapter describes the OracleAS Disaster Recovery solution, how to configure and set up its environment, and how to manage the solution for high availability. The discussion involves both OracleAS middle tiers and OracleAS Infrastructure tiers in two sites: production and standby. The standby site is configured either identically and symmetrically (same number of instances) or asymmetrically to the production site (fewer instances or OracleAS Disaster Recovery capability for the Infrastructure services is only supported). Under normal operation, the production site actively services requests. The standby site is maintained to mirror or closely mirror the applications and content hosted by the production site.

The OracleAS Disaster Recovery aspects of these sites are managed using Oracle Application Server Guard, which contains a command-line utility (asgctl) that encapsulates administrative tasks (see Chapter 6, "OracleAS Guard asgctl Command-line Reference" for reference information about these administrative commands). The OracleAS Disaster Recovery solution leverages the following services among other system services that are available across the entire site. Behind the scenes OracleAS Guard automates the use of OracleAS Recovery Manager (for managing configuration files in the file system) and Oracle Data Guard (for managing the OracleAS Infrastructure database) in a distributed fashion across the topology. Table 5-1 provides a summary of the OracleAS Disaster Recovery strategy and how this Oracle software is used behind the scenes:

Table 5-1 Overview of OracleAS Disaster Recovery strategy

Coverage | Procedure | Purpose
--- | --- | ---
Middle-tier Configuration Files | OracleAS Recovery Manager | To back up and clone configuration files in the production site middle-tier nodes and restore the files to the standby site middle-tier nodes.
OracleAS Infrastructure Configuration Files | OracleAS Recovery Manager | To back up and clone OracleAS configuration files in the production site OracleAS Infrastructure node and restore them to the standby site OracleAS Infrastructure node.
OracleAS Infrastructure Database | Oracle Data Guard | To ship archive logs from production site OracleAS Infrastructure database to standby site OracleAS Infrastructure database. Logs are not applied immediately.

Beginning with OracleAS release 10.1.2.0.2, to simplify the concepts presented to describe the OracleAS Disaster Recovery solution, the term topology is introduced to mean all farms on either the production or standby site with the same Oracle Internet Directory instance. With the exception of the OracleAS Disaster Recovery solution for OracleAS release 10.1.3, the term topology replaces the previous concept of a farm as described in the OracleAS Disaster Recovery solution documentation for OracleAS release 10.1.2.0.0. The term topology refers to all instances that share the same Oracle Internet Directory for a production site. The discover topology command queries Oracle Internet Directory to determine the list of instances and then generates a topology XML file that describes the production topology. The discover topology within farm command is used in cases where Oracle Internet Directory is not available and then OracleAS Guard uses OPMN to discover the topology within the farm.

Note: Your other databases must be covered in the overall disaster recovery strategy, and you must use Oracle Data Guard as the solution.

In addition to the recovery strategies, configuration and installation of both sites are discussed. For these tasks, two different ways of naming the middle-tier nodes are covered as well as two ways of resolving hostnames intra-site and inter-site.

With OracleAS Disaster Recovery, planned outages of the production site can be performed without interruption of service by switching over to the standby site using the OracleAS Guard switchover operation. Unplanned outages are managed by failing over to the standby site using the OracleAS Guard failover operation. Procedures for switchover and failover are covered in this chapter in Section 5.12, "Runtime Operations -- OracleAS Guard Switchover and Failover Operations".

This chapter is organized into the following sections:

- Section 5.1, "Oracle Application Server 10g Disaster Recovery Solution"

- Section 5.2, "Preparing the OracleAS Disaster Recovery Environment"

- Section 5.3, "Overview of Installing Oracle Application Server"

- Section 5.4, "Overview of OracleAS Guard and asgctl"

- Section 5.5, "Authentication of Databases"

- Section 5.6, "Discovering, Dumping, and Verifying the Topology"

- Section 5.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands"

- Section 5.8, "Discovering OracleAS 10.1.3 Instances in Redundant Multiple OracleAS 10.1.3 Homes J2EE Topology"

- Section 5.9, "Adding or Removing OracleAS 10.1.3 Instances to Redundant Single OracleAS 10.1.3 Home J2EE Topology Integrated with an Existing Oracle Identity Management 10.1.2.0.2 Topology"

- Section 5.10, "OracleAS Guard Operations -- Standby Site Cloning of One or More Production Instances to a Standby System"

- Section 5.11, "OracleAS Guard Operations -- Standby Instantiation and Standby Synchronization"

- Section 5.12, "Runtime Operations -- OracleAS Guard Switchover and Failover Operations"

- Section 5.13, "Monitoring OracleAS Guard Operations and Troubleshooting"

- Section 5.14, "Wide Area DNS Operations"

- Section 5.15, "Using OracleAS Guard Command-Line Utility (asgctl)"

- Section 5.16, "Special Considerations for Some OracleAS Metadata Repository Configurations"

- Section 5.17, "Special Considerations for OracleAS Disaster Recovery Environments"

See Also: Oracle Application Server Installation Guide for instructions about how to install the OracleAS Disaster Recovery solution.

Geographically Distributed Identity Management Infrastructure Deployment

Geographically distributed Identity Management (IM) Infrastructure deployment replication, though an example of an active-active configuration, shares some features similar to an OracleAS Disaster Recovery solution in that Oracle Internet Directory (OID), OracleAS Metadata Repository (MR), and OracleAS Single Sign-On (SSO) are set up in replication and distributed across different geographic regions. Each OracleAS Single Sign-On site uses its own Oracle Internet Directory and OracleAS Metadata Repository located at the local site, thus resulting in the active-active configuration. The shared similarities serve two purposes. First, in case a database failure is detected at one site, Oracle Internet Directory and OracleAS Single Sign-On servers are reconfigured to route user requests to the closest geographic area. Second, in case an OracleAS Single Sign-On middle-tier failure is detected, the network is reconfigured to route traffic to a remote middle tier. However, this solution does not provide synchronization for OracleAS Portal, OracleAS Wireless, and Distributed Configuration Management (DCM) schemas in the Infrastructure database because neither supports the replica model used for Oracle Internet Directory and OracleAS Single Sign-On information. See Oracle Identity Management Concepts and Deployment Planning Guide for more information about a geographically distributed Identity Management Infrastructure deployment.

## 5.1 Oracle Application Server 10g Disaster Recovery Solution

The Oracle Application Server Disaster Recovery solution consists of two configured sites - one primary (production/active) and one secondary (standby). Both sites may or may not have the following: same number of middle tiers and the same number of OracleAS Infrastructure nodes, and the same number of components installed. In other words, the installations on both sites, middle tier and OracleAS Infrastructure could be identical (symmetrical topology) or not identical (asymmetrical topology). Both sites are usually dispersed geographically, and if so, they are connected through a wide area network.

Some important points to emphasize for the Oracle Application Server Disaster Recovery solution are the following:

- The number of instances required on the standby site to run your site can be identical to (symmetric) or fewer (asymmetric) than the production site.

- The set of instances needed must be created and installed on the standby site for Disaster Recovery set up.

- The standby site needs the minimum set of instances required to run your site.

This section describes the overall layout of the solution, the major components involved, and the configuration of these components. It has the following sections:

- Section 5.1.1, "OracleAS Disaster Recovery Requirements"

- Section 5.1.2, "Supported Oracle Application Server Releases and Operating Systems"

- Section 5.1.3, "Supported Topologies"

### 5.1.1 OracleAS Disaster Recovery Requirements

To ensure that your implementation of the OracleAS Disaster Recovery solution performs as designed, the following requirements must be adhered to:

- On each host in the standby site, make sure the following is identical to its equivalent peer in the production site:

  - For the middle-tier hosts, physical hostnames.

    Note: If you already have installed systems, you only need to modify the physical names for the middle-tier systems at the standby site and then create a virtual hostname for the physical hostname of the OracleAS Infrastructure (see the next bullet). See Section 5.2.1, "Planning and Assigning Hostnames" for information about how to change these physical hostnames and the virtual hostname. See Section 1.2.1, "Terminology" for a description of physical hostname and virtual hostname.

  - Virtual hostname and port numbers for the OracleAS Infrastructure. The virtual hostname can be specified in the Specify Virtual Hostname screen presented by the installer.

  - Hardware platform

  - Operating system release and patch levels

- All installations conform to the requirements listed in the Oracle Application Server Installation Guide to install Oracle Application Server.

- Oracle Application Server software is installed in identical directory paths between each host in the production site and its equivalent peer in the standby site.

- The following details must be the same between a host in the production site and a peer in the standby site:

  - User name and password of the user who installed Oracle Application Server must be the same between a host in the production site and its peer in the standby site.

  - Numerical user ID of the user who installed Oracle Application Server on that particular node

  - Group name of the user who installed Oracle Application Server on that particular node

  - Numerical group ID of the group for the user who installed Oracle Application Server on that particular node

  - Environment profile

  - Shell (command-line environment)

  - Directory structure, Oracle home names, and path of the Oracle home directory for each OracleAS installation on a node. Do not use symbolic links anywhere in the path.

  - Oracle Application Server installation types (Any instance installed on the standby system must be identical to that installed on the production system):

    - Middle Tier: J2EE and Web Cache, and Portal and Wireless

    - OracleAS Infrastructure: Metadata Repository (MR) and Identity Management (IM)

### 5.1.2 Supported Oracle Application Server Releases and Operating Systems

OracleAS Guard supports Oracle Application Server releases 10g (9.0.4) and 10g (10.1.2.0.0, 10.1.2.0.2, and 10.1.3.0.0).

The OracleAS Guard kit located on the Companion CD #2 must be installed on all systems with Oracle homes or Oracle Application Server instances in the topology. See the OracleAS Disaster Recovery installation information in Oracle Application Server Installation Guide for more information.

OracleAS Guard is installed by default on every 10.1.2 and 10.1.3 install type that already installs a JDK or JRE environment. In environments in which OracleAS Guard is not installed by default, for example Web Server and Process Management in OracleAS 10g release (10.1.3) and OracleAS Portal in OracleAS 10g release (10.1.2.0.2), the standalone OracleAS Guard kit must be installed from the Companion CD #2 into these Oracle homes.

OracleAS Guard supports mixed environments that are supported by the underlying services. For example, OracleAS Guard supports a mixed OracleAS 10g (9.0.4) and OracleAS 10g (10.1.2) or higher release environment, such as may occur during an upgrade scenario. In this case, you may have upgraded the standby site to OracleAS 10g (10.1.2) Oracle homes in the middle tier but the Infrastructure is still an OracleAS 10g (9.0.4) Infrastructure. This mixed release environment will work as long as the OracleAS Disaster Recovery peer home for the given production middle tier Oracle homes are also upgraded to the same release, for example OracleAS 10g (10.1.2) and as long as its Infrastructure is still an earlier release, for example OracleAS 10g (9.0.4) Infrastructure. So the rule of thumb is that all Oracle home peer middle tiers within the topology must match exactly in release number for all peers (that is, on both the standby and production sites). Also the Infrastructures must match exactly in release number on both the standby and production sites and Oracle AS Guard must be the same version on both sites. However, as an upgrade based requirement, the Infrastructure can be at a lower release than the middle tiers because this happens during an upgrade scenario.

### 5.1.3 Supported Topologies

OracleAS Disaster Recovery supports a number of basic topologies for the configuration of the Infrastructure and middle tier on production and standby sites. OracleAS Disaster Recovery supports these basic topologies:

- Symmetrical Topologies - Strict Mirror of the Production Site with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure

- Asymmetrical Topologies - Simple Asymmetric Standby Topology with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure

- Separate OracleAS Metadata Repository for OracleAS Portal with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure (the Departmental Topology)

- Distributed Application OracleAS Metadata Repositories with Non Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure

- Redundant Multiple OracleAS 10.1.3 Homes J2EE Topology

- Redundant Single OracleAS 10.1.3 Oracle Home J2EE Topology Integrated with an Existing Oracle Identity Management 10.1.2.0.2 Topology

#### 5.1.3.1 Symmetrical Topologies - Strict Mirror of the Production Site with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure

For OracleAS Disaster Recovery Release 10.1.2.0.1, only the OracleAS Disaster Recovery symmetrical topology environment was supported. This OracleAS Disaster Recovery environment has two major requirements:

- The deployment must use a single default Infrastructure install that contains a collocated OracleAS Metadata Repository and Oracle Identity Management.

- The standby site has to be a strict mirror of the production site with the same number of instances (symmetrical topology).

Figure 5-1 depicts an example OracleAS Disaster Recovery solution having a symmetrical topology with a Cold Failover Cluster on the primary site. This is considered a symmetrical topology because from an Oracle Application Server perspective both sites contain two OracleAS middle tiers and one Infrastructure.

Figure 5-1 Example Oracle Application Server Site-to-Site Disaster Recovery Solution (Load Balancer Appliance Is Optional If Only One Middle-Tier Node Is Present)

Description of "Figure 5-1 Example Oracle Application Server Site-to-Site Disaster Recovery Solution (Load Balancer Appliance Is Optional If Only One Middle-Tier Node Is Present)"

The procedures and steps for configuring and operating the OracleAS Disaster Recovery solution support 1 to n number of middle-tier installations in the production site. The same number of middle-tier installations must exist in the standby site. The middle tiers must mirror each other in the production and standby sites.

For the OracleAS Infrastructure, a uniform number of installations is not required (names or instances must be equal) between the production and standby sites. For example, the OracleAS Cold Failover Cluster (Infrastructure) solution can be deployed in the production site, and a single node installation of the OracleAS Infrastructure can be deployed in the standby site as shown in Figure 5-1. This way, the production site's OracleAS Infrastructure has protection from host failure using an OracleAS Cold Failover Cluster. This solution provides hardware redundancy by utilizing a virtual hostname. Refer to the Section 6.2.2, "Active-Passive High Availability Topologies" on page 6-5 of the Oracle Application Server High Availability Guide in the OracleAS Release 10.1.2.0.2 documentation set for more information on OracleAS Cold Failover Clusters.

The OracleAS Disaster Recovery solution is an extension to various single-site Oracle Application Server architectures. Examples of such single-site architectures include the combination of OracleAS Cold Failover Cluster (Infrastructure) and active-active Oracle Application Server middle-tier architecture. For the latest information on what single-site architectures are supported, check the Oracle Technology Network (OTN) Web site for the latest certification matrix.

`http://www.oracle.com/technology/products/ias/hi_av/index.html`

The following are important characteristics of the symmetric OracleAS Disaster Recovery solution:

- Middle-tier installations are identical between the production and standby sites. In other words, each middle-tier installation in the production site has an identical installation in the standby site. More than one middle-tier node is recommended because this enables each set of middle-tier installations on each site to be redundant. Because they are on multiple machines, problems and outages within a site of middle-tier installations are transparent to clients.

- The OracleAS Disaster Recovery solution is restricted to identical site configuration to ensure that processes and procedures are kept the same between sites, making operational tasks easier to maintain and execute. Identical site configuration also allows for a higher success rate for manually maintaining the synchronization of Oracle Application Server component configuration files between sites.

- When the production site becomes unavailable due to a disaster, the standby site can become operational within a reasonable time. Client requests are always routed to the site that is operating in the production role. After a failover or switchover operation occurs due to an outage, client requests are routed to another site that assumes the production role. For a symmetric topology, the quality of service offered by the new production site should be the same as that offered by the original production site before the outage.

- From the standpoint of a single site, the sites are set up in active-passive configuration. An active-passive setup has one primary site used for production and one secondary site that is initially passive (on standby). The secondary site is made active only after a failover or switchover operation is performed. Since the sites are symmetrical, after failover or switchover, the original standby site can be kept active as the new production site. After repairing or upgrading the original production site, it can be made into the new standby site as long as the OracleAS Disaster Recovery site requirements are maintained. Either site should offer the same level of service to clients as the other. Note that in an active-passive setup, the standby site can be comprised of different Oracle homes that can be active on the same hosts as long as the Oracle homes being used in the Disaster Recovery environment are passive (inactive).

- For a database recovery (DBR) site as explained shortly (an OracleAS 10g release (10.1.3) site is most likely not involved, whereas an OracleAS 10g release (10.1.2.0.2) site is involved), the site playing the standby role contains a physical standby of the Oracle Application Server Infrastructure coordinated by Oracle Data Guard. OracleAS Guard automates the configuration and use of Oracle Data Guard together with procedures for backing up and restoring OracleAS Infrastructure configuration files and provides configuration synchronization between the production and standby sites. Switchover and failover operations allow the roles to be traded between the OracleAS Infrastructures in the two sites. Refer to Section 5.10, "OracleAS Guard Operations -- Standby Site Cloning of One or More Production Instances to a Standby System", Section 5.11, "OracleAS Guard Operations -- Standby Instantiation and Standby Synchronization", Section 5.12, "Runtime Operations -- OracleAS Guard Switchover and Failover Operations", and Section 5.15, "Using OracleAS Guard Command-Line Utility (asgctl)" for information about using the asgctl command-line interface to perform OracleAS Guard administrative tasks of cloning, instantiation, synchronization, switchover, and failover in the OracleAS Disaster Recovery solution.

#### 5.1.3.2 Asymmetrical Topologies - Simple Asymmetric Standby Topology with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure

Beginning with OracleAS Disaster Recovery Release 10.1.2.0.2, support for asymmetric topologies includes support for the following simple asymmetric standby topologies:

- A standby site having reduced resources (fewer middle tiers); this means support for all production services except the scaling. This approach guarantees all services are maintained, but not scaled (see Figure 5-2 for an example of this OracleAS Disaster Recovery solution).

  Figure 5-2 Simple Asymmetric Standby with Reduced Resources

  Description of "Figure 5-2 Simple Asymmetric Standby with Reduced Resources"

  Figure 5-2 shows a production site of four middle tier instances and one Infrastructure (collocated Oracle Identity Management and OracleAS Metadata Repository). In this example, the services and applications deployed to middle tier 1 are scaled to include middle tier 2. In addition, the services and applications deployed to middle tier 3 are scaled to include middle tier 4. To satisfy the requirements for reduced resources for disaster recovery, the scaling is not necessary at the standby site. Therefore, the services deployed at production middle tiers 1 and 2 are satisfied by a disaster recovery peer middle tier 1 at the standby site, which will be synchronized with the production middle tier 1. Likewise, the services deployed at production middle tiers 3 and 4 are satisfied by a disaster recovery peer middle tier 3 at the standby site, which will be synchronized with the production middle tier 3.

- A standby site that maintains OracleAS Disaster Recovery support for the Infrastructure services only, while the middle-tier instances are supported only through production site management. This approach guarantees that only the Infrastructure services are maintained (see Figure 5-3 for an example of this OracleAS Disaster Recovery solution).

  Figure 5-3 Simple Asymmetric Standby with Guaranteed Infrastructure

  Description of "Figure 5-3 Simple Asymmetric Standby with Guaranteed Infrastructure"

  Figure 5-3 shows a production site consisting of four middle tiers instances, with two middle tiers (1 and 2) collocated with the production Infrastructure services and two middle tiers (3 and 4) remotely located at the standby site. The standby site is used to provide disaster recovery capability for only the Infrastructure services. In this configuration, middle tier resources are configured in an active/active model and technically as a single production topology.

  Under normal conditions, application requests can be serviced from middle tiers 1 through 4. This model assumes that the services and applications deployed to middle tiers 3 and 4 can tolerate the latency, firewall, and network issues associated with this topology. For disaster recovery operations, only the Infrastructure services must be maintained, while the deployment and maintenance of the middle tier instances is done through routine production site management.

In general, support for asymmetrical topologies means that the OracleAS Disaster Recovery standby site has or potentially has reduced resources, maintains a reduction of Oracle homes, and also guarantees a certain minimum level of service capability.

#### 5.1.3.3 Separate OracleAS Metadata Repository for OracleAS Portal with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure (the Departmental Topology)

This topology (Figure 5-4), consists of an OracleAS Infrastructure with two OracleAS Metadata Repositories and multiple middle tiers. One OracleAS Metadata Repository is used by Oracle Identity Management components, such as Oracle Internet Directory and OracleAS Single Sign-On. All middle tiers use this OracleAS Metadata Repository for Oracle Identity Management services, as well as any additional middle tiers that might be added to this topology as it expands. The other OracleAS Metadata Repository is used for product metadata by the OracleAS Portal and OracleAS Wireless middle tier components. With two metadata repositories, this deployment can best be described as two DCM production farms.

An OracleAS Disaster Recovery standby configuration could be set up as either a symmetrical topology as described in Section 5.1.3.1, "Symmetrical Topologies - Strict Mirror of the Production Site with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure", thereby requiring two DCM standby farms be configured or as a simple asymmetric topology as described in Section 5.1.3.2, "Asymmetrical Topologies - Simple Asymmetric Standby Topology with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure", with service guaranteed requiring minimally that a single DCM standby farm be configured.

Figure 5-4 Collocated Oracle Identity Management and OracleAS Metadata Repository with a Separate OracleAS Metadata Repository

Description of "Figure 5-4 Collocated Oracle Identity Management and OracleAS Metadata Repository with a Separate OracleAS Metadata Repository"

#### 5.1.3.4 Distributed Application OracleAS Metadata Repositories with Non Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure

The topologies in Section 5.1.3.1, "Symmetrical Topologies - Strict Mirror of the Production Site with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure", Section 5.1.3.2, "Asymmetrical Topologies - Simple Asymmetric Standby Topology with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure", and Section 5.1.3.3, "Separate OracleAS Metadata Repository for OracleAS Portal with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure (the Departmental Topology)" describe a deployment for a default database repository collocated for both the Oracle Identity Management and OracleAS Metadata Repository Infrastructure, while Section 5.1.3.3, "Separate OracleAS Metadata Repository for OracleAS Portal with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure (the Departmental Topology)" also describes a topology with a separate OracleAS Metadata Repository.

In a topology with distributed application OracleAS Metadata Repositories and non collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure, the Oracle Identity Management Infrastructure and one OracleAS Metadata Repository Infrastructure are installed on separate hosts, and other OracleAS Metadata Repositories are installed to reside with respective applications on different hosts. Thus, one OracleAS Metadata Repository can be the result of a deployment using a single default Infrastructure install, while one or more OracleAS Metadata Repositories can be the result of an OracleAS user using a tool, such as the OracleAS Metadata Repository Creation Assistant, to install one or more application OracleAS Metadata Repositories on one or more systems with the application data, for management or policy reasons, or both.

Figure 5-5 shows an example OracleAS Disaster Recovery solution having non collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure and distributed OracleAS Metadata Repositories.

Figure 5-5 Non-Collocated Oracle Identity Management (IM) and OracleAS Metadata Repository (MR) Infrastructure Topology with Distributed OracleAS Metadata Repositories

Description of "Figure 5-5 Non-Collocated Oracle Identity Management (IM) and OracleAS Metadata Repository (MR) Infrastructure Topology with Distributed OracleAS Metadata Repositories"

#### 5.1.3.5 Redundant Multiple OracleAS 10.1.3 Homes J2EE Topology

Figure 5-6 shows an example OracleAS Disaster Recovery solution having a configuration supporting high availability of J2EE servers in an OracleAS 10.1.3 topology consisting of four nodes, known as a cluster (also called an OPMN instance). The install type of Web Server (Oracle HTTP Server or OHS) and Process Management (OPMN) is installed on nodes 1 and 2 and the install type of J2EE Server (OC4J) and Process Management (OPMN) is installed on nodes 3 and 4. There is no Identity Management.

Figure 5-6 Redundant Multiple OracleAS 10.1.3 Homes J2EE Topology

Description of "Figure 5-6 Redundant Multiple OracleAS 10.1.3 Homes J2EE Topology"

Beginning with OracleAS 10.1.3, a new dynamic node discovery mechanism is operational within Oracle Notification Server (ONS), a component of OPMN. Dynamic node discovery enables the cluster to manage itself. When a new ONS node is added to the cluster, each existing ONS node announces its presence with a multicast message and each existing node then adds the new node and its connection information to its map of the current cluster, while at the same time the new ONS node adds all the existing nodes to its map. This fulfills one of the requirements for OracleAS Disaster Recovery that the OracleAS cluster be currently configured. In this case, the OPMN configuration file, `opmn.xml`, is updated whenever a new OracleAS server node is added to or removed from the cluster. This clustering configuration applies to all instances of OracleAS Server components, including OHS and OC4J, installed on the node.

By default, OracleAS Guard is installed in each Oracle Home on each node in the OracleAS cluster. When an OracleAS Guard client connects to an OracleAS Guard server, and the Disaster Recovery Administrator performs a discover topology within farm command, OracleAS Guard utilizes OPMN to discover all the instances on nodes within the cluster, creates the Disaster Recovery XML topology file on the OracleAS Guard server, and then propagates this file to all systems across the Disaster Recovery production topology. Any OracleAS Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby topology.

Thereafter, the Disaster Recovery Administrator can use the discover topology within farm command following the addition or removal of one or more nodes to the OracleAS cluster knowing that the ONS dynamic node discovery mechanism will automatically manage the cluster configuration information and keep it current. See Oracle Containers for J2EE Configuration and Administration Guide for more information about the ONS dynamic discovery mechanism. You can also manage instances in the local topology file using the add instance and remove instance commands, and if specified propagate this updated local topology file to all instances in the Disaster Recovery production environment. Any OracleAS Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby environment. See Section 5.8, "Discovering OracleAS 10.1.3 Instances in Redundant Multiple OracleAS 10.1.3 Homes J2EE Topology" for a use case example. Thus, the key point is that you must perform a discover topology within farm command if any nodes have been added to the cluster and if any instances have been added to these nodes that are part of your Disaster Recovery environment.

#### 5.1.3.6 Redundant Single OracleAS 10.1.3 Oracle Home J2EE Topology Integrated with an Existing Oracle Identity Management 10.1.2.0.2 Topology

Figure 5-7 shows an example OracleAS Disaster Recovery solution supporting a mixed version topology, where OracleAS 10.1.3 instances are integrated into an existing OID based topology (OracleAS Cluster (IM) 10.1.2.0.2). In this case, multiple OracleAS 10g (10.1.3) installations of the Integrated Web server, J2EE Server, and OPMN installation option in a single Oracle Home on individual systems create the redundant single OracleAS 10.1.3 Oracle Home J2EE topology.

Figure 5-7 Redundant Single Oracle Homes J2EE Topology Plus OracleAS Cluster (IM) 10.1.2.0.2 (OracleAS Mixed Version Topology)

Description of "Figure 5-7 Redundant Single Oracle Homes J2EE Topology Plus OracleAS Cluster (IM) 10.1.2.0.2 (OracleAS Mixed Version Topology)"

By default, OracleAS Guard is installed in each Oracle Home. When an OracleAS Guard client connects to an OracleAS Guard server in the IM 10.1.2.0.2 OracleAS topology, and performs a discover topology command, OracleAS Guard utilizes OID and automatically recognizes all OracleAS 10.1.2.0.2 instances within the existing OID based topology. The discover topology operation creates the Disaster Recovery topology file and propagates it to all instances across the production topology. Any OracleAS Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby topology.

A Disaster Recovery Administrator can use the asgctl add instance or remove instance command to add or remove from the local topology file single OracleAS 10.1.3 J2EE instances to or from an existing OID based 10.1.2.0.2 production topology. With either operation, the local topology file is updated and if specified, the local updated topology file is propagated to all instances across the production topology. Any OracleAS Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby topology. The resulting topology is then described as a redundant single OracleAS 10.1.3 Oracle Home J2EE topology integrated with an existing OID based topology (OracleAS Cluster (IM) 10.1.2.0.2). See Section 5.9, "Adding or Removing OracleAS 10.1.3 Instances to Redundant Single OracleAS 10.1.3 Home J2EE Topology Integrated with an Existing Oracle Identity Management 10.1.2.0.2 Topology" for a use case example. See Section 6.2, "Information Specific to a Small Set of OracleAS Guard Commands" for more information about topology files.

## 5.2 Preparing the OracleAS Disaster Recovery Environment

Prior to the installation of OracleAS software for the OracleAS Disaster Recovery solution, a number of system level configurations are required or optional as specified. The tasks that accomplish these configurations are:

- Section 5.2.1, "Planning and Assigning Hostnames"

- Section 5.2.2, "Configuring Hostname Resolution"

- Chapter 10, "Secure Shell (SSH) Port Forwarding" (optional)

This section covers the steps needed to perform these tasks for the symmetrical topology. These same steps are also applicable to simple asymmetrical standby sites as well as to topologies for non collocated Oracle Identity Management and OracleAS Metadata Repository with or without distributed OracleAS Metadata Repositories.

### 5.2.1 Planning and Assigning Hostnames

Before performing the steps to set up the physical and network hostnames, plan the physical and network hostnames you wish to use with respect to the entire OracleAS Disaster Recovery solution. The overall approach to planning and assigning hostnames must meet the following goals:

- OracleAS components in the middle tier and OracleAS Infrastructure must use the same physical hostnames in their configuration settings regardless of whether the components are in the production or standby site. In addition, you must also create a virtual hostname for the physical hostname of the OracleAS Infrastructure.

  For example, if a middle-tier component in the production site uses the name "`asmid1`" to reach a host in the same site, the same component in the standby site must use the same name to reach `asmid1`'s equivalent peer in the standby site. Likewise, if the virtual hostname of the OracleAS Infrastructure on the production site uses the name "`infra`", the virtual hostname for the physical hostname of the OracleAS Infrastructure on the standby site must be named "`infra`".

- No changes to hostnames (physical, network, or virtual) are required when the standby site takes over the production role. However, a DNS switchover must be performed, see Section 5.14, "Wide Area DNS Operations" for more information.

  Note: Although the physical hostnames in the production and standby sites must remain uniform between the two sites, the resolution of these physical hostnames to the correct hosts can be different. Section 5.2.2, "Configuring Hostname Resolution" explains hostname resolution.

Figure 5-8 illustrates the process of planning and assigning hostnames.

Figure 5-8 Name Assignment Example in the Production and Standby Sites

Description of "Figure 5-8 Name Assignment Example in the Production and Standby Sites"

In Figure 5-8, two middle-tier nodes exist in the production site. The OracleAS Infrastructure can be a single node or an OracleAS Cold Failover Cluster solution (represented by a single virtual hostname and a virtual IP, as for a single node OracleAS Infrastructure). The common names in the two sites are the physical hostnames of the middle-tier nodes and the virtual hostname of the OracleAS Infrastructure. Table 5-2 details what the physical, network, and virtual hostnames are in the example:

Table 5-2 Physical, network, and virtual hostnames in Figure 5-8

Physical Hostnames | Virtual Hostname | Network Hostnames
--- | --- | ---
    asmid1
    -
    prodmid1, standbymid1
    asmid2
    -
    prodmid2, standbymid2
    - Foot 1
    infra
    prodinfra, standbyinfra

Footnote 1 In this example, the physical hostname is the network hostname. Therefore, the network host name is used in the appropriate asgctl commands for the respective <host>, <host-name>, or <standby_topology_host> parameter arguments.

- Cohosting non OracleAS applications

  If the hosts in the production site are running non OracleAS applications, and you wish to cohost OracleAS on the same hosts, changing the physical hostnames of these hosts may break these applications. In such a case, you can keep these hostnames in the production site and modify the physical hostnames in the standby site to match those in the production site. The non OracleAS applications can then also be installed on the standby hosts so that they can act in a standby role for these applications.

As explained in Section 1.2.1, "Terminology", physical, network, and virtual hostnames have different purposes in the OracleAS Disaster Recovery solution. They are also set up differently. The following sections provide information about how the three types of hostnames are set up.

#### 5.2.1.1 Physical Hostnames

The naming of middle-tier hosts in both the production and standby sites requires changing the physical hostname in each host.

In Solaris, to change the physical hostname of a host:

Note: For other UNIX variants, consult your system administrator for equivalent commands in each step.

1. Check the setting for the existing hostname as follows:

       prompt> hostname

2. Use a text editor, such as `vi`, to edit the name in `/etc/nodename` to your planned physical hostname.

3. For each middle-tier host, reboot it for the change to take effect.

4. Repeat Step 1 to verify the correct hostname has been set.

5. Repeat the previous steps for each host in the production and standby sites.

In Windows, to change the physical hostname of a host, follow these steps:

Note: The user interface elements in your version of Windows may vary from those described in the following steps.

1. In the Start menu, select Control Panel.

2. Double-click the System icon.

3. Select the Advance tab.

4. Select Environment variables.

5. Under the User Environment variables for the installer account, select New to create a new variable.

6. Enter the name of the variable as "`_CLUSTER_NETWORK_NAME_`".

7. For the value of this variable, enter the planned physical hostname.

#### 5.2.1.2 Network Hostnames

The network hostnames used in the OracleAS Disaster Recovery solution are defined in domain name system (DNS). These hostnames are visible in the network that the solution uses and are resolved through DNS to the appropriate hosts by the assigned IP address in the DNS system. You need to add these network hostnames and their corresponding IP addresses to the DNS system.

Using the example in Figure 5-8, the following additions should be made to the DNS system serving the entire network that encompasses the production and standby sites:

    prodmid1.oracle.com        IN     A     123.1.2.333
    prodmid2.oracle.com        IN     A     123.1.2.334
    prodinfra.oracle.com       IN     A     123.1.2.111
    standbymid1.oracle.com     IN     A     213.2.2.443
    standbymid2.oracle.com     IN     A     213.2.2.444
    standbyinfra.oracle.com    IN     A     213.2.2.210

#### 5.2.1.3 Virtual Hostname

As defined in Section 1.2.1, "Terminology", virtual hostname applies to the OracleAS Infrastructure only. It is specified during installation of the OracleAS Infrastructure. When you run the OracleAS Infrastructure installation type, a screen called Specify Virtual Hostname appears to provide a text box to enter the virtual hostname of the OracleAS Infrastructure that is being installed. Refer to the Oracle Application Server Installation Guide for more details.

For the example in Figure 5-8, when you install the production site's OracleAS Infrastructure, enter its virtual hostname, "`infra`", when you see the Specify Virtual Hostname screen. Enter the same virtual hostname when you install the standby site's OracleAS Infrastructure.

Note: If the OracleAS Infrastructure is installed in an OracleAS Cold Failover Cluster solution, the virtual hostname is the name that is associated with the virtual IP of the OracleAS Cold Failover Cluster. For high availability deployment with multiple OracleAS instances using a load balancer on the production site, but no load balancer on the standby site, the virtual hostname is the DNS based virtual hostname for the load balancer, for example `lbr01.us.oracle.com`. For more information, see the white paper on using load balancers and OracleAS High Availability on the Oracle Technology Network (OTN).

### 5.2.2 Configuring Hostname Resolution

In the OracleAS Disaster Recovery solution, you can configure hostname resolution in one of two ways to resolve the hostnames you planned and assigned in Section 5.2.1, "Planning and Assigning Hostnames". These are:

- Section 5.2.2.1, "Using Local Hostnaming File Resolution"

- Section 5.2.2.2, "Using DNS Resolution"

In UNIX, the order of the method of name resolution can be specified using the "`hosts`" parameter in the file `/etc/nsswitch.conf`. The following is an example of the `hosts` entry:

    hosts:     files dns nis

In the previous statement, local hostnaming file resolution is preferred over DNS and NIS (Network Information Service) resolutions. When a hostname is required to be resolved to an IP address, the `/etc/hosts` file (UNIX) or `C:\WINDOWS\system32\drivers\etc\hosts` file is consulted first. In the event that a hostname cannot be resolved using local hostnaming resolution, DNS is used. (NIS resolution is not used for the OracleAS Disaster Recovery solution.) Refer to your UNIX system documentation to find out more about name resolution using the file `/etc/nsswitch.conf`.

#### 5.2.2.1 Using Local Hostnaming File Resolution

This method of hostname resolution relies on a local hostnaming file to contain the requisite hostname-to-IP address mappings. In UNIX, this file is `/etc/hosts`. In Windows, this file is `C:\WINDOWS\system32\drivers\etc\hosts`.

To use the local hostnaming file to resolve hostnames for the OracleAS Disaster Recovery solution in UNIX for each middle tier and OracleAS Infrastructure host in both the production and standby sites, perform the following steps:

1. Use a text editor, such as `vi`, to edit the `/etc/nsswitch.conf` file. With the "`hosts:`" parameter, specify "`files`" as the first choice for hostname resolution.

2. Edit the `/etc/hosts` file to include the following:

   - The physical hostnames and the correct IP addresses for all middle-tier nodes in the current site. The first entry must be the hostname and IP address of the current node.

     Note: When making entries in the hosts file, make sure the intended hostname is positioned in the second column of the hosts file; otherwise, an asgctl `verify topology with <host>` operation will fail indicating that the production topology is not symmetrical with the standby topology. See Appendix A, "Troubleshooting High Availability" for more information about troubleshooting and resolving this type of problem.

     For example, if you are editing the `/etc/hosts` file of a middle-tier node in the production site, enter all the middle-tier physical hostnames and their IP addresses in the production site beginning the list with the current host. (You should also include fully qualified hostnames in addition to the abbreviated hostnames. See Table 5-3.)

   - The virtual hostname of the OracleAS Infrastructure in the current site.

     For example, if you are editing the `/etc/hosts` of a middle-tier node in the standby site, enter the virtual hostname, fully qualified and abbreviated, and the IP address of the OracleAS Infrastructure host in the standby site.

3. Reboot each host after editing the files mentioned in the previous steps.

4. From each host, use the ping command for each physical hostname that is valid in its particular site to ensure that the IP addresses have been assigned correctly.

   For the example in Figure 5-8, on the `asmid1` host, use the following commands in succession:

       ping asmid1

   The returned IP address should be 123.1.2.333.

       ping asmid2

   The returned IP address should be 123.1.2.334.

       ping infra

   The returned IP address should be 123.1.2.111.

   Note: Some UNIX variants, such as Solaris, require the `-s` option to return an IP address.

In Windows, the method of ordering hostname resolution varies depending on the Windows version. Refer to the documentation for your version of Windows for the appropriate steps.

Using the example in Figure 5-8, Table 5-3 shows that the `/etc/hosts` file entries on each production node contains the required entries in the of each UNIX host. The entries in the Windows `C:\WINDOWS\system32\drivers\etc\hosts` file should be similar.

Table 5-3 Network and Virtual Hostname Entries in Each `/etc/hosts` File of Example in Figure 5-8

Host | Entries in /etc/hosts
--- | ---
`asmid1` in production site |
    123.1.2.333 asmid1.oracle.com asmid1
    123.1.2.334 asmid2.oracle.com asmid2
    123.1.2.111 infra.oracle.com infra
    213.2.2.210 remoteinfra.oracle.com remoteinfra
`asmid2` in production site |
    123.1.2.334 asmid2.oracle.com asmid2
    123.1.2.333 asmid1.oracle.com asmid1
    123.1.2.111 infra.oracle.com infra
    213.2.2.210 remoteinfra.oracle.com remoteinfra
`infra` in production site |
    123.1.2.111 infra.oracle.com infra
    123.1.2.333 asmid1.oracle.com asmid1
    123.1.2.334 asmid2.oracle.com asmid2
    213.2.2.210 remoteinfra.oracle.com remoteinfra
`asmid1` in standby site |
    213.2.2.443 asmid1.oracle.com asmid1
    213.2.2.444 asmid2.oracle.com asmid2
    213.2.2.210 infra.oracle.com infra
    123.1.2.111 remoteinfra.oracle.com remoteinfra
`asmid2` in standby site |
    213.2.2.444 asmid2.oracle.com asmid2
    213.2.2.443 asmid1.oracle.com asmid1
    213.2.2.210 infra.oracle.com infra
    123.1.2.111 remoteinfra.oracle.com remoteinfra
`infra` in standby site |
    213.2.2.210 infra.oracle.com infra
    213.2.2.443 asmid1.oracle.com asmid1
    213.2.2.444 asmid2.oracle.com asmid2
    123.1.2.111 remoteinfra.oracle.com remoteinfra

#### 5.2.2.2 Using DNS Resolution

To set up the OracleAS Disaster Recovery solution to use DNS hostname resolution, you must set up site-specific DNS servers in the production and standby sites in addition to the overall corporate DNS servers (usually more than one DNS server exists in a corporate network for redundancy). Figure 5-9 provides an overview of this setup.

See Also: Chapter 9, "Setting Up a DNS Server" for instructions on how to set up a DNS server in a UNIX environment.

Figure 5-9 DNS Resolution Topology Overview

Description of "Figure 5-9 DNS Resolution Topology Overview"

For the topology in Figure 5-9 to work, the following requirements and assumptions must be made:

- The DNS servers for the production and standby sites must not be aware of each other. They make non authoritative lookup requests to the overall corporate DNS servers if they fail to resolve any hostnames within their specific sites.

- The production site and standby site DNS servers must contain entries for middle-tier physical hostnames and OracleAS Infrastructure virtual hostnames. Each DNS server contains entries of only the hostnames within its own site. The sites have a common domain name that is different from that of the overall corporate domain name.

- The overall corporate DNS servers contain network hostname entries for the middle-tier hosts and OracleAS Infrastructure hosts of both production and standby sites.

- In UNIX, the `/etc/hosts` file in each host does not contain entries for the physical, network, or virtual hostnames of any host in either the production or standby site. In Windows, this applies to the file `C:\WINDOWS\system32\drivers\etc\hosts`.

To set up the OracleAS Disaster Recovery solution for DNS resolution, follow these steps:

1. Configure each of the overall corporate DNS servers with the network hostnames of all the hosts in the production and standby sites. Using the example presented in Figure 5-8, the following entries are made:

       prodmid1.oracle.com      IN    A    123.1.2.333
       prodmid2.oracle.com      IN    A    123.1.2.334
       prodinfra.oracle.com     IN    A    123.1.2.111
       standbymid1.oracle.com   IN    A    213.2.2.443
       standbymid2.oracle.com   IN    A    213.2.2.444
       standbyinfra.oracle.com  IN    A    213.2.2.210

2. For each site, production and standby, create a unique DNS zone by configuring a DNS server as follows:

   1. Select a unique domain name to use for the two sites that is different from the corporate domain name. As an example, use the name "`oracleas`" for the domain name for the two sites in Figure 5-8. The high level corporate domain name is `oracle.com`.

   2. Configure the DNS server in each site to point to the overall corporate DNS servers for unresolved requests.

   3. Populate the DNS servers in each site with the physical hostnames of each middle-tier host and the virtual hostname of each OracleAS Infrastructure host. Include the domain name selected in the previous step.

      For the example in Figure 5-8, the entries are as follows:

      For the DNS server on the production site:

          asmid1.oracleas      IN    A    123.1.2.333
          asmid2.oracleas      IN    A    123.1.2.334
          infra.oracleas       IN    A    123.1.2.111

      For the DNS server on the standby site:

          asmid1.oracleas      IN    A    213.2.2.443
          asmid2.oracleas      IN    A    213.2.2.444
          infra.oracleas       IN    A    213.2.2.210

      Note: If you are using a load balancer, you must alias the IP addresses inside the host file with DNS based virtual hostnames. This is essential for OracleAS Guard on the local host to perform a local write of the topology file from a discover topology within farm command and to correctly perform an add instance command and update the topology file. If you are using the OracleAS Cold Failover Cluster solution for the OracleAS Infrastructure in either site, enter the cluster's virtual hostname and virtual IP address. For example, in the previous step, `infra` is the virtual hostname and `123.1.2.111` is the virtual IP of the cluster in the production site. For more information on the OracleAS Cold Failover Cluster solution, see Section 6.2.2, "Active-Passive High Availability Topologies" on page 6-5 of the Oracle Application Server High Availability Guide in the OracleAS Release 10.1.2.0.2 documentation set.

##### 5.2.2.2.1 Additional DNS Server Entries for Oracle Data Guard

Because OracleAS Guard automates the use of Oracle Data Guard technology, which is used to synchronize the production and standby OracleAS Infrastructure databases, the production OracleAS Infrastructure must be able to reference the standby OracleAS Infrastructure and conversely.

For this to work, the IP address of the standby OracleAS Infrastructure host must be entered in the production site's DNS server with a hostname that is unique to the production site. Similarly, the IP address of the production OracleAS Infrastructure host must be entered in the standby site's DNS server with the same hostname. These DNS entries are required because Oracle Data Guard uses TNS Names to direct requests to the production and standby OracleAS Infrastructures. Hence, the appropriate entries must also be made to the `tnsnames.ora` file. Additionally, OracleAS Guard asgctl command-line commands must reference the network hostnames.

Using the example in Figure 5-8 and assuming that the selected name for the remote OracleAS Infrastructure is "`remoteinfra`," the entries for the DNS server in the production site are:

    asmid1.oracleas        IN    A    123.1.2.333
    asmid2.oracleas        IN    A    123.1.2.334
    infra.oracleas         IN    A    123.1.2.111
    remoteinfra.oracleas   IN    A    213.2.2.210

And, in the standby site, the DNS server entries should be as follows:

    asmid1.oracleas        IN    A    213.2.2.443
    asmid2.oracleas        IN    A    213.2.2.444
    infra.oracleas         IN    A    213.2.2.210
    remoteinfra.oracleas   IN    A    123.1.2.111

## 5.3 Overview of Installing Oracle Application Server

This section provides an overview of the steps for installing the OracleAS Disaster Recovery solution. These steps are applicable to the topologies described in Section 5.1.3, "Supported Topologies". After following the instructions in Section 5.2, "Preparing the OracleAS Disaster Recovery Environment" to set up the environment for the solution, read this section for an overview of the installation process. Then, follow the detailed instructions in the Oracle Application Server Installation Guide to install the solution.

Note: To assign identical ports for use by symmetrical hosts in the production and standby sites, you can use static port definitions. These definitions are defined in a file, (for example, named `staticports.ini`). Then, specify the `staticports.ini` file in the Specify Ports Configuration Options screen in the installer. (Detailed information on the static ports file is found in the Oracle Application Server Installation Guide.)

The following steps represent the overall sequence for installing the OracleAS Disaster Recovery solution:

1. Install OracleAS Infrastructure in the production site (see Oracle Application Server Installation Guide).

2. Install OracleAS Infrastructure in the standby site (see Oracle Application Server Installation Guide).

3. Start the OracleAS Infrastructure in each site before installing the middle tiers for that site.

4. Install the middle tiers in the production site (see Oracle Application Server Installation Guide).

5. Install the middle tiers in the standby site (see Oracle Application Server Installation Guide).

The following points are important when you perform the installation:

- Ensure that the same ports are used by equivalent peer hosts in both sites. For example, the `asmid1` host in the standby site must use the same ports as the `asmid1` host in the production site. Use a static ports definition file. (see the previous note in this section and the following point).

- Specify the full path to the `staticports.ini` file in the installer's Specify Ports Configuration Options screen.

- Ensure that you select the High Availability and Replication option in the installer's Select Configuration Options screen.

- Specify the virtual address assigned to the OracleAS Infrastructure in the Specify Virtual Hostname screen during OracleAS Infrastructure installation.

- Install for the middle-tier hosts, any of the available middle-tier installation types. (Ensure that the OracleAS Infrastructure services have been started for a site before installing any middle tiers in that site.)

- Specify the OracleAS Infrastructure's virtual hostname as the OracleAS Infrastructure database during each middle-tier installation.

- Start the OracleAS services on the hosts in each site starting with the OracleAS Infrastructure.

## 5.4 Overview of OracleAS Guard and asgctl

This section provides an overview of OracleAS Guard and its command-line interface asgctl. If you are already familiar with this overview information, go to Section 5.5, "Authentication of Databases". This section contains the following subsections:

- Section 5.4.1, "Overview of asgctl"

- Section 5.4.2, "OracleAS Guard Client"

- Section 5.4.3, "OracleAS Guard Server"

- Section 5.4.4, "asgctl Operations"

- Section 5.4.5, "OracleAS Guard Integration with OPMN"

- Section 5.4.6, "Supported OracleAS Disaster Recovery Configurations"

- Section 5.4.7, "Configuring OracleAS Guard and Other Relevant Information"

### 5.4.1 Overview of asgctl

The asgctl command-line utility greatly simplifies the complexity and magnitude of the steps involved in setting up and managing OracleAS Disaster Recovery. This utility provides a distributed solution that consists of a client component and a server component. The client component (OracleAS Guard client) can be installed on a system on the topology. The server component (OracleAS Guard server) is installed by default on the systems hosting the primary and standby Oracle homes that comprise the OracleAS Disaster Recovery environment.

### 5.4.2 OracleAS Guard Client

The OracleAS Guard client is installed on every OracleAS install type. The OracleAS Guard client attempts to open and maintain a connection to the OracleAS Guard server.

The OracleAS Guard client provides an asgctl command-line interface (CLI) (see Chapter 6, "OracleAS Guard asgctl Command-line Reference") consisting of a set of commands to perform administrative tasks described in Section 5.4.4, "asgctl Operations".

### 5.4.3 OracleAS Guard Server

The OracleAS Guard server is a distributed server (installed by default) that runs on all the systems in an OracleAS Disaster Recovery configuration. The OracleAS Guard client maintains an active connection to the OracleAS Guard server on one system that has network connectivity in the OracleAS Disaster Recovery configuration. This coordinating server communicates to the OracleAS Guard servers on the other systems in the OracleAS Disaster Recovery configuration as necessary to complete processing during standby site cloning, instantiation, synchronization, verification, switchover, and failover operations. The OracleAS Guard server carries out asgctl commands issued directly by the OracleAS Guard client or issued on behalf of the OracleAS Guard client by another OracleAS Guard server in the network for the client session. The steps to complete an operation will execute throughout all systems in both the production and standby topologies. Most operational steps will be executed either in parallel or sequentially (as required) on these systems throughout the OracleAS Disaster Recovery configuration by the OracleAS Guard server.

### 5.4.4 asgctl Operations

Major asgctl operations using the asgctl commands belong in the following categories of operations:

- Authentication -- Identifies the OracleAS Infrastructure database on the primary topology (set primary database command). If there are topologies with multiple Infrastructures, each must be identified using this command prior to performing an operation involving both production and standby topologies.

  Identifies the new OracleAS Infrastructure database on the standby topology (set new primary database command) prior to a failover operation.

  Sets the credentials (set asg credentials command) used to authenticate the OracleAS Guard client connections to OracleAS Guard servers and the connections between OracleAS Guard servers to a specific host. See the set asg credentials command for an example, and see Section 5.16.1.1, "Setting asgctl Credentials" for more information.

  When OracleAS Guard discovers the topology (discover topology command), it requires you provide Oracle Internet Directory authentication credentials (Oracle Internet Directory password) in order to query Oracle Internet Directory to obtain instance information for the production site.

- Discover the topology -- Discovers (discover topology command) by querying Oracle Internet Directory all instances within the topology that share the same Oracle Internet Directory for a production site and generates a topology XML file that describes the topology and replicates this file to all instances in the topology. See Section 5.6, "Discovering, Dumping, and Verifying the Topology" for more information.

  The command discover topology within farm discovers the topology using OPMN at a production site for special cases where Oracle Internet Directory is not available, such as in an OracleAS 10.1.3 OPMN topology.

- Adding or removing an instance from the local topology file -- pulls an instance into or drops an instance from an existing local topology file. This is particularly useful in an OracleAS 10.1.3 only topology, where an OracleAS Guard client can connect to an existing OracleAS 10.1.3 instance, and either perform an add instance command that adds the specified OracleAS 10.1.3 instance to the topology file, or performs a remove instance command that removes the specified OracleAS 10.1.3 instance from the local topology file, and in either case, if specified, propagates the updated topology file to all instances in the Disaster Recovery production environment. Any OracleAS Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby environment.

  This command is also useful for adding an OracleAS 10.1.3 J2EE instance to an OID based 10.1.2.0.2 local topology file to support a mixed version Disaster Recovery environment. For example, you can use the add instance command to add an OracleAS 10.1.3 J2EE instance to your OID based 10.1.2.0.2 local topology file. See Section 5.9, "Adding or Removing OracleAS 10.1.3 Instances to Redundant Single OracleAS 10.1.3 Home J2EE Topology Integrated with an Existing Oracle Identity Management 10.1.2.0.2 Topology" for a use case.

- Standby site cloning -- Clones a single production instance to a standby system (clone instance command) or clones two or more production instances to standby systems (clone topology command). See Section 5.10, "OracleAS Guard Operations -- Standby Site Cloning of One or More Production Instances to a Standby System" for more information. The standby site cloning operation eliminates the task of having to install these Oracle instances on the standby middle tier systems and perform an instantiate operation.

- Standby site instantiation -- Creates the disaster recovery environment. It establishes the relationship between standby and production instances, mirrors the configuration, creates the standby Infrastructure, then synchronizes the standby site with the primary site (instantiate topology command). See Section 5.11.1, "Standby Instantiation" for more information.

- Standby site synchronization -- Applies database redo logs for OracleAS Infrastructures to the standby site in conjunction with synchronizing external configuration files across the topology (sync topology command). See Section 5.11.2, "Standby Synchronization" for more information.

- Switchover -- Switches from the production site to the standby site after the standby site is synchronized with the production site with the application of the database redo logs (switchover topology command). See Section 5.12.1.1, "Scheduled Outages" for more information.

- Failover -- Makes the standby site the production site after restoring configuration files and restoring the OracleAS server environment to the point of the last successful sync operation (failover command). See Section 5.12.1.2, "Unplanned Outages" for more information.

- Verification -- Validates that the primary topology is running and the configuration is valid (verify topology command) or if a standby topology is specified, compare the primary topology to which the local host system is a member with the standby topology to validate that they are consistent with one another and conforms to the requirements for OracleAS Disaster Recovery. See Section 5.13.1, "Verifying the Topology" for more information.

- Using a policy file -- Used as a filter to filter out unnecessary instances for supporting asymmetric topologies. The dump policies command writes detailed, default policy information to respective XML formatted files for a select set of asgctl commands. You can then edit each respective XML policy file and use it in the `using policy <file>` parameter with any one of these select set of asgctl commands: dump topology, verify topology, clone topology, failover, instantiate topology, switchover topology, and sync topology to define by instance the domain of execution operations that are permitted for each of these asgctl commands. Each instance list entry in an XML policy file logically tags a production-standby peer combination with a particular attribute that defines the success requirement for its successful operation. For example, you may want to omit a node in a symmetric topology while performing one of the operations previously mentioned. Use the policy file to specify the node to be ignored. See Section 5.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.

- Instance management -- Enables you to shut down (shutdown topology command) and start up the topology (startup topology command).

- Troubleshooting -- Uses the dump topology command to write detailed information about the topology to the screen or to a file. Lets you determine the current operations that are running (show operation command) and stop any operations that need to be halted (stop operation command).

Table 5-4 describes the OracleAS Disaster Recovery production and standby site environment before and after performing an asgctl clone, instantiate, sync, failover, and switchover operation.

Table 5-4 Description of Disaster Recovery Production and Standby Environments Before and After Performing These OracleAS Guard Operations

OracleAS Guard Operation | DR Site Environment Before Operation | DR Site Environment After Operation
--- | --- | ---
clone | The production site has one or more instances that need to be installed on the standby site and instantiated. The cloning operations perform this task. | The standby site has one or more new standby instances that are a logical mirror of the production site instances.
instantiate | The standby site with its Oracle homes exists, but the OracleAS Disaster Recovery relationship across sites does not exist yet for an OracleAS Disaster Recovery operation to be performed. | A logical mirror of the production site is set up and maintained at the standby site.
sync | The standby site is not consistent with the production site. OracleAS Disaster Recovery is not possible to a consistent point in time without some manual intervention. | Database redo logs are applied to OracleAS Infrastructures in combination with synchronizing external configuration files across the topology. The sync operation is performed in the event that a failover or switchover operation is necessary, then the standby site can be restored to a consistent point in time. No manual intervention is necessary to synchronize the sites after the asgctl sync operation is performed.
switchover | A planned outage at the production site will make the standby site the production site for a period of time; that is the roles of each site will be switched. | The standby site has become the production site. All OPMN services are started. The production site may become available again after the planned outage, at which time, another switchover operation could be performed to return activity back to the original production site from the standby site.
failover | An unscheduled outage at the production site has left the production site down or unavailable for an unknown period of time. The production site is lost due to some unforeseen circumstance. | The standby site has permanently become the production site. Configuration and Infrastructure data are restored to a consistent point in time on the standby site. Site services are brought up in a consistent fashion to the point of the last sync operation. All OPMN services are started.

Figure 5-10 shows a summary of the main OracleAS Disaster Recovery operations and the command sequences used to perform these operations. For example, to get started with a new DR environment once it is set up and operational, you must always create a topology file on the production site. To do that, you perform a connect command to connect the OracleAS Guard client to the OracleAS Guard server followed by identifying the production Infrastructure database using a set primary database command, then perform the discover topology command, finally followed by a disconnect command to disconnect the OracleAS client from the OracleAS server. In essence, to perform any OracleAS Disaster Recovery operation using asgctl commands, you must always connect the OracleAS Guard client to the OracleAS Guard server, identify the location of the Infrastructure database, then perform the OracleAS Disaster Recovery operation or operations of interest, and finally disconnect the OracleAS client from the OracleAS server. The only exception to this general sequence is for a failover operation, in which the production site is permanently unavailable due to some unplanned problem. In this case, you connect the OracleAS Guard client to OracleAS Guard server at the standby site, identify the standby site Infrastructure as the new Infrastructure database, then perform the failover operation. Because there is no topology file created on the standby site following a failover operation, you must then perform a discover topology command to create it for the first time. Then you can disconnect the OracleAS Guard client from OracleAS Guard server.

The asgctl command sequences shown in Figure 5-10 assume the simplest topology configuration. For example, in a more complex case, if your production or standby site has multiple MR instances installed, you must identify each instance with a set primary database command prior to performing the main Disaster Recovery operation, such as an instantiate, sync, switchover, or failover operation. Similarly, OracleAS Guard requires that you set the credentials for any OracleAS Guard server system in the topology that has different credentials from the OracleAS Guard server to which you are connected before you perform any of these main operations, such as instantiate, sync, switchover, or failover. So for both of these cases, additional asgctl commands are required in the command sequence before you can perform the main Disaster Recovery operation. See the usage notes for the set asg credentials command for more information.

Figure 5-10 Main Disaster Recovery Operations Performed Using the Following OracleAS Guard asgctl Command Sequences

Description of "Figure 5-10 Main Disaster Recovery Operations Performed Using the Following OracleAS Guard asgctl Command Sequences"

### 5.4.5 OracleAS Guard Integration with OPMN

A typical Oracle Application Server site has multiple farms. OracleAS Guard server and its ias-component ASG process is not started by default by OPMN because it is only necessary in the context of disaster recovery sites. You must start this ias-component ASG process in all Oracle homes as described later in this section. To check the status of this component and determine if the component is running, run the following opmnctl command on each system in your topology:

    On UNIX systems
    > <ORACLE HOME>/opmn/bin/opmnctl status

    On windows systems
    > <ORACLE HOME>\opmn\bin\opmnctl status

Because there is no way an OracleAS Guard client nor OPMN on the production site can start OracleAS Guard services on the standby site, OracleAS Guard must be started directly using opmnctl on the Infrastructure node in the standby topology. Connect to a node and run the following OPMN command on UNIX systems:

    > <ORACLE HOME>/opmn/bin/opmnctl startproc ias-component=ASG

On Windows systems, issue the following OPMN command to start OracleAS Guard if your Oracle home is located on drive C:.

    C:\<ORACLE HOME>\opmn\bin\opmnctl startproc ias-component=ASG

After the OracleAS Guard server is started it is non transient, while the remaining OracleAS Guard servers in the standby topology are transient servers. This configuration allows cross-topology communication.

Note: When you perform an opmnctl status command on a system on which OracleAS Guard is running, you will see an ias-component and process-type named ASG. This is the OracleAS component name and server process name for the OracleAS Guard server.

### 5.4.6 Supported OracleAS Disaster Recovery Configurations

For OracleAS 10g release (10.1.2), OracleAS Guard supports not only the default OracleAS Infrastructure configuration supported on Oracle Application Server Cold Failover Clusters and single instance, but also the topologies described in Section 5.1.3, "Supported Topologies".

### 5.4.7 Configuring OracleAS Guard and Other Relevant Information

By default, OracleAS Guard and asgctl, the command-line utility for OracleAS Guard, are installed for all install types with the following default configuration information, which includes:

- The following OracleAS Guard parameters are configurable. The value is described and the default value is indicated. The OracleAS Guard `readme.txt` file in the ```<ORACLE_HOME>\dsa\doc` directory also lists these OracleAS Guard parameters that are configurable.

  - `port` - the TCP/IP port for OracleAS Guard server and client. OracleAS Guard uses a default port (port) number of 7890; for example, port=7890. If there is a second Oracle home installed on a system, this second Oracle home must have a different OracleAS Guard port number, usually incremented by one, for example, port=7891, and so on.

    Value: integer, any valid TCP/IP port number. Default is 7890.

  - `exec_timeout_secs` - timeout value for executing operating system command.

    Value: integer, number of seconds. Default is 60 seconds.

  - `trace_flags` - trace flags to be turned on.

    Value: string list, separated by ",". Default is none.

  - `backup_mode` - indicates whether to perform a full or incremental backup.

    Value: string, "full" or "incremental". Default is "incremental".

  - `backup_path` - the backup directory path to be used by OracleAS Guard server.

    Value: string, a directory path. Default is `<ORACLE_HOME>/dsa/backup`.

  - `ha_path` - the High Availability directory path where the backup scripts are located.

    Value: string, a directory path. Default is `<ORACLE_HOME>/backup_restore`.

  - `port.<host>` - the TCP/IP port for a given host.

    Value: integer, any valid TCP/IP port number.

    Note: If the port number must be changed for some reason (it must be unique for each OracleAS Guard server in each Oracle home on a machine, which is automatically handled during installation), you can change its value in the `<ORACLE_HOME>/dsa/dsa.conf` file. Then, stop the OracleAS Guard server(`<ORACLE_HOME>/opmn/bin/opmnctl stopproc ias-component=ASG`) and start the OracleAS Guard server (`<ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=ASG`) to activate the change. See Section 5.4.5, "OracleAS Guard Integration with OPMN") for more information.

  - `copyfile_buffersize` - the buffer size for copy file operation, in kilobytes.

    Value: integer, maximum buffer size is 500K.

  - `server_inactive_timeout` - the number of seconds server will wait before shutting down due to inactivity.

    Value: integer, number of seconds. Default value is 600 seconds (10 minutes).

  - `inventory_location` - the alternative Oracle Inventory location

    Value: string, a directory path.

- OracleAS Guard command-line utility asgctl is installed in the `<ORACLE_HOME>/dsa/bin` directory on UNIX systems and `<ORACLE_HOME>\dsa\bin` directory on Windows systems on all nodes in the topology production and standby topologies.

- OracleAS Guard starts up the OracleAS component services across the production topology.

- The OracleAS Guard operation status information for a topology (from either an asgctl show operation full or show operation history command) remains available for the life of the current OracleAS Guard client asgctl connect session only. When the OracleAS Guard client disconnects from the OracleAS Guard server, this topology's operation history information becomes unavailable.

- After you start an asgctl operation, you cannot run another asgctl command on the same OracleAS Guard server until the previous command that is running completes or is forced to stop (see the asgctl stop operation command for more information.) In addition, you cannot run an asgctl operation in background and then quit or exit the asgctl utility.

- See the OracleAS Guard `readme.txt` file in the `<ORACLE_HOME>\dsa\doc` directory for more information about OracleAS Guard parameters that are configurable.

- OracleAS Guard command-line utility asgctl is installed in the `<ORACLE_HOME>/dsa/bin` directory on UNIX systems and `<ORACLE_HOME>\dsa\bin` directory on Windows systems on all nodes in the topology production and standby topologies.

- OracleAS Guard starts up the OracleAS component services across the production topology.

- The OracleAS Guard operation status information for a topology (from either an asgctl show operation full or show operation history command) remains available for the life of the current OracleAS Guard client asgctl connect session only. When the OracleAS Guard client disconnects from the OracleAS Guard server, this topology's operation history information becomes unavailable.

- After you start an asgctl operation, you cannot run another asgctl command on the same OracleAS Guard server until the previous command that is running completes or is forced to stop (see the asgctl stop operation command for more information.) In addition, you cannot run an asgctl operation in background and then quit or exit the asgctl utility.

## 5.5 Authentication of Databases

Several levels of authentication are required when an OracleAS Guard client connects to an OracleAS guard server and begins a session to perform administrative operations within the production topology or across both production and standby topologies:

- Infrastructure authentication

- OracleAS Guard client authentication to OracleAS Guard servers

- Oracle Internet Directory authentication

Infrastructure Authentication

When initiating an OracleAS Guard administrative session, after establishing the connection between the OracleAS Guard client and OracleAS Guard server, you must identify all the OracleAS Infrastructure databases on the primary topology using the set primary database command. Infrastructure authentication must be performed before you initiate any operation that involves either the production topology or both the production and standby topologies.

Another form of Infrastructure authentication occurs as part of a failover operation. In this scenario, the production site is down and you must failover to the standby site and make this site the new production site. First, identify the new OracleAS Infrastructure database on the standby topology using the set new primary database command before performing the failover operation. See Section 5.12.1.2, "Unplanned Outages" for more information.

OracleAs Guard Client Authentication to OracleAS Guard Servers

By default, these are the same authentication credentials used for instance level authentication with the Oracle Application Server account (`ias_admin`/password) that was created during the Oracle Application Server installation and used in the connect asg command.

Note: If this is an OracleAS 10.1.3 installation, the user name must be `oc4jadmin` and the password for the `oc4jadmin` account created during the Oracle Application Server 10.1.3 installation.

These same credentials are used when the OracleAS Guard client connects to any OracleAS Guard server in the production and standby topology when executing administrative operations.

There may be cases where you want to use different credentials for a specific OracleAS Guard server or set a common set of credentials in the standby topology that differs from the credentials used in the primary topology. To set credentials for an OracleAS Guard server, use the set asg credentials command and one or more of its parameter options by either specifying the host name to which the credentials apply or the topology along with the new set of credentials (username/password).

If you set the credentials for a topology, these credentials are inherited for the entire topology. If you set the credentials for an individual host on the topology, the credentials for this host override the default credentials set for the topology. After you set the credentials so that they are different from the default connection credentials for a host system or an entire topology, whenever you initiate an OracleAS Guard administrative session, you must specify all credentials that are different from the default connection credentials for any host system or topology before you perform an operation involving all the OracleAS Guard servers within a production topology or across both production and standby topologies. Otherwise, the operation will fail with an authentication error. See the connect asg command for an example.

Oracle Internet Directory Authentication

The discover topology command requires you provide Oracle Internet Directory authentication credentials (Oracle Internet Directory password) in order to query Oracle Internet Directory to obtain instance information for the production site. See the section that follows for more information and the discover topology command.

## 5.6 Discovering, Dumping, and Verifying the Topology

The discover topology command discovers by querying Oracle Internet Directory all instances within the topology that share the same Oracle Internet Directory for a production site. A topology XML file is created and distributed to all Oracle homes within the topology that describes all instances for the topology. This topology file is used by all OracleAS Guard operations.

You must perform a discover topology command when you first set up your OracleAS Disaster Recovery environment in order to initially create the topology XML file. Thereafter, you should perform a discover topology operation whenever you procure another Oracle home in a production site or change roles from a production to a standby site through a switchover or failover operation. See the discover topology command for more information.

You should perform a dump topology command to inspect the information that describes your topology. See the dump topology command for more information. See Section 6.2, "Information Specific to a Small Set of OracleAS Guard Commands" for more information about topology files.

You should perform a verify topology command to validate that the primary topology is running and that the configuration is valid. In addition, if you specify the `with host` parameter, the verify operation compares the primary topology of which the local host system is a member with the standby topology to validate that they are consistent with one another and conform to the requirements for OracleAS Disaster Recovery. See Section 5.13.1, "Verifying the Topology" and the verify topology command for more information.

With both the dump topology and verify topology commands, if you want to use a policy file, edit and use the respective dump and verify policy files (`dump_policy.xml` and `verify_policy.xml`). Specify this file in the `using policy <file>` parameter of each command to dump or verify only those instances specified accordingly. See Section 5.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.

## 5.7 Dumping Policy Files and Using Policy Files With Some asgctl Commands

OracleAS Disaster Recovery provides support for a variety of application server topologies as described in Section 5.1.3, "Supported Topologies". As part of this support, a set of XML formatted policy files are maintained, local to the OracleAS Guard client that performs the dump policies command, to record by instance the domain of execution operations that are permitted for each of the following asgctl commands: dump topology, verify topology, clone topology, failover, instantiate topology, switchover topology, and sync topology.

To understand the default policies in use for any these asgctl commands, enter the following command at the asgctl prompt:

    ASGCTL> dump policies
    Generating default policy for this operation
    Creating policy files on local host in directory "/private1/OraHome2/asr1012/dsa/conf/"
    ASGCTL>

Each instance list entry in each of the XML policy files logically tags by default a production-standby peer combination with a particular attribute that defines the success requirement for the successful operation of each command. This approach provides greater flexibility in regulating how each of these OracleAS Guard operations are to be successfully used among the supported topologies, see Section 5.1.3, "Supported Topologies" for more information.

After inspecting each of the XML formatted policy files, you can subsequently edit the respective policy file and use it with the particular asgctl command using the parameter syntax `using policy <file>` and indicate the name of the policy file to be used. In this way, you can employ a particular disaster recovery policy that defines the success requirement attribute value by instance for each of these OracleAS Guard operations mentioned earlier in this chapter.

Note: If you want to maintain a set of custom policy files, you must copy, edit, and maintain them in a location other than the default location; otherwise, your custom set of policy files will be overwritten whenever you perform a discover topology command followed subsequently by a dump policies command.

The success requirement attribute value can be one of the following: [`optional | mandatory | ignore | group <MinSucceeded=<number>>`], where:

- `Optional` -- means if there is a failure for that instance continue processing other instances.

- `Mandatory` -- means if an error occurs for this instance, the entire operation fails.

- `Ignore` -- means the instance is not part of the operation.

- `Group <MinSucceeded=<number>` -- means to combine groups of Oracle instances, and if the specified number of group members is successful, then the operation is successful; otherwise, if less than the number of group members that is specified is successful, the operation fails.

Each attribute value determines the success requirement for that peer group and will be referenced during failure cases of asgctl operations to determine whether or not to continue with the OracleAS Guard operation. For example, when the success requirement is specified as mandatory, the particular OracleAS Guard operation must be successful for the specified instance for that production-standby peer combination; otherwise, the OracleAS Guard operation ceases, execution is rolled back to its starting point of execution, and an error message is returned.

For example, the following XML policy file in use for an asymmetric topology for the failover operation specifies that this asgctl operation is mandatory for the infra instance, optional for the portal_1 and portal_2 instances, can be ignored for the portal_3 instance, and must be successful for a minimum of any two of the group of three instances, BI_1, BI_2, and BI_3.

    <policy>
      <instanceList successRequirement="Mandatory">
         <instance>infra</instance>
      </instanceList >
      <instanceList successRequirement="Optional">
         <instance>portal_1</instance>
         <instance>portal_2</instance>
      </instanceList >
      <instanceList successRequirement="Ignore">
         <instance>portal_3</instance>
      </instanceList >
      <instanceList successRequirement="Group" minSucceed="2">
         <instance>BI_1</instance>
         <instance>BI_2</instance>
         <instance>BI_3</instance>
      </instanceList >
    </policy>

## 5.8 Discovering OracleAS 10.1.3 Instances in Redundant Multiple OracleAS 10.1.3 Homes J2EE Topology

As described in Section 5.1.3.5, "Redundant Multiple OracleAS 10.1.3 Homes J2EE Topology", you can discover OracleAS 10.1.3 instance changes in a redundant multiple OracleAS 10.1.3 Homes J2EE topology. In a typical scenario, OracleAS 10.1.3 J2EE is installed on a node with an OC4J instance and you want to add this node and instance to the existing redundant multiple OracleAS 10.1.3 Homes J2EE topology. The following steps take you through a typical scenario:

1. Connect to the OracleAS Guard server.

       ASGCTL > connect asg prodinfra ias_admin/<adminpwd>
       Successfully connected to prodinfra:7890
       ASGCTL>

2. Assume a Disaster Recovery Administrator has installed OracleAS 10.1.3 J2EE on a new node with an OC4J instance. Through dynamic node discovery, the cluster manages itself and automatically updates the information in each OPMN configuration file, `opmn.xml`on each node within the cluster.

3. Next, perform a discover topology within farm command. This operation determines all instances within the OracleAS 10.1.3 cluster for this production site, generates the Disaster Recovery topology XML file that describes the production topology, and then propagates this topology XML file to all instances in the Disaster Recovery production environment. Note that any OracleAS Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby environment.

       ASGCTL> discover topology within farm

4. Now, having recently installed another oc4j instance named oc4j3 on the existing midtier host system named prodmid2, add to the local topology file an instance named oc4j3 specifying the host system named prodmid2. To propagate this updated local topology file to all instances in the Disaster Recovery production environment for this OracleAS 10.1.3 cluster, specify the `to topology` keyword. Note that any OracleAS Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby topology.

       ASGCTL> add instance oc4j3 on prodmid2 to topology

## 5.9 Adding or Removing OracleAS 10.1.3 Instances to Redundant Single OracleAS 10.1.3 Home J2EE Topology Integrated with an Existing Oracle Identity Management 10.1.2.0.2 Topology

As described in Section 5.1.3.6, "Redundant Single OracleAS 10.1.3 Oracle Home J2EE Topology Integrated with an Existing Oracle Identity Management 10.1.2.0.2 Topology", you can add or remove OracleAS 10.1.3 single home J2EE instances to or from an existing OID 10.1.2.0.2 topology, thus creating or modifying a mixed version Disaster Recovery environment. The following steps take you through a typical scenario:

1. Connect to the OracleAS Guard server.

       ASGCTL > connect asg prodinfra ias_admin/<adminpwd>
       Successfully connected to prodinfra:7890
       ASGCTL>

2. Assume that a discover topology command was performed when you first set up the Disaster Recovery environment on the existing OID 10.1.2.0.2 topology, thus creating a topology XML file that was propagated to all instances in the Disaster Recovery environment. Also assume that no other changes have been made to the topology, so the topology XML files are current or up-to-date.

3. Assume that you have completed OracleAS 10.1.3 installations using the Integrated Web server, J2EE Server, and OPMN installation option in a single Oracle Home on four individual systems. This creates the redundant single Oracle Home J2EE topology. Assume that the OracleAS Disaster Recovery solution is configured for each new node. Now you want to add the OracleAS 10.1.3 instances named OC4J1 and OC4J2 to the existing OID 10.1.2.0.2 topology. To do this, perform the following asgctl commands:

       ASGCTL> add instance oc4j1 on prodinfra to topology
       ASGCTL> add instance oc4j2 on prodinfra to topology

   Performing each add instance command updates the local topology file on the OracleAS Guard server to which the OracleAS Guard client is connected. To propagate the updated topology file to all instances in the Disaster Recovery production environment, specify the `to topology` key word. This operation then results in a redundant single OracleAS 10.1.3 Oracle Home J2EE topology with instances oc4j1 and oc4j2 being integrated with an existing OID 10.1.2.0.2 production topology. Note that any OracleAS Guard operation that affects the standby site, such as verify, instantiate, sync, switchover, and failover will automatically propagate the production topology file across the standby topology.

## 5.10 OracleAS Guard Operations -- Standby Site Cloning of One or More Production Instances to a Standby System

Standby site cloning is the process of cloning a single production instance to a standby system (using the clone instance command) or cloning two or more production instances to standby systems (using the clone topology command). In either case, the topology XML file for each instance is copied over with the clone operation and is consistent for each instance and can be said to be updated only locally on that standby system; however, as soon as any OracleAS Guard operation is performed that affects the standby sites, such as a verify, instantiate, sync, switchover, or failover operation, then the XML topology file on the local system in the production topology is automatically propagated to all instances on nodes throughout the standby topology.

Clone Instance

The clone instance command is used to create a new standby instance target from an existing production instance source.

One of the underlying technologies used by OracleAS Guard to perform this operation is the OracleAS Backup and Restore loss of host capability. See the section on recovering a loss of host automatically in Oracle Application Server Administrator's Guide for more information including a list of prerequisites. This capability assumes that the target machine is a newly procured Oracle environment because it overwrites the Oracle software registry. Additionally, some of the underlying operations require elevated privileges, `root` for the UNIX environments and `Administrator` for Windows. On Windows, the user must ensure that the client and OracleAS Guard server are started with `Administrator` privileges.

There are two phases of clone. The first phase is to create the Oracle home and register it within the system environment. The second phase is to perform the OracleAS Guard instantiate operation to link it into the OracleAS Disaster Recovery environment and logically match the Oracle home with it's corresponding production home.

A series of clone instance operations on different instances are equivalent to a clone topology operation.

Clone Topology

The clone topology command performs a clone instance operation across a group of systems. The clone operation is performed on every OracleAS home that does not contain a database or it can be filtered using a policy file. For OracleAS homes that contain a database, a clone topology operation will perform the instantiate phase of the operation, skipping the creation of the Oracle home at the standby site. The operation can be performed on a subset of a topology by utilizing a policy file.

There are three methodologies that you must be aware of when planning for an OracleAS Disaster Recovery site setup:

- Creating a pure OracleAS Disaster Recovery site

- Adding OracleAS homes to an existing site with OracleAS Disaster Recovery enabled

- Integrating OracleAS Metadata Repositories within an existing database

Each operation requires a different methodology to integrate the newly installed Oracle homes into the existing site or combine them into a standby site for a production site.

Creating a Pure OracleAS Disaster Recovery Site

Prior to OracleAS 10g release 10.1.2.0.2, this was the only type of site OracleAS Guard could support. An OracleAS Disaster Recovery configuration was supported only for the default Infrastructure and OracleAS middle-tier install types. With this type of configuration, all the OracleAS homes were created using the Oracle installer. The OracleAS Guard instantiate command creates the relationships between the production and standby Oracle homes and the underlying standby Oracle database repositories.

Adding OracleAS Homes to an Existing Site with OracleAS Disaster Recovery Enabled

After an OracleAS site is OracleAS Disaster Recovery enabled, the relationship between the production and standby Oracle homes has been created. For releases previous to OracleAS 10g release 10.1.2.0.2, the only way to add new instances to the site was to break the standby relationship, add the new instance at the production site using Oracle Installer, add the new instance to the standby site using Oracle Installer, and re-create the standby site. With OracleAS 10g release 10.1.2.0.2, you can use the clone instance command to add instances to a standby site.

For example, if you need a new middle tier to scale out the services in the middle tier the new instance is installed at the production site. This operation creates the OracleAS home for the instance and establishes the necessary relationships within the OracleAS repositories.

With OracleAS 10g release 10.1.2.0.2, OracleAS Guard asymmetrical topology support, this Oracle home can optionally be ignored in regard to the site's OracleAS Disaster Recovery solution. If you want to add this instance to the standby site, the clone topology command will create the OracleAS Oracle home at the standby target host and establish the production-standby relationship for this instance. Before issuing this command, the standalone OracleAS Guard kit must be installed and started at the target host (see the OracleAS Disaster Recovery installation information in Oracle Application Server Installation Guide for more information) and a site discovery topology operation should be performed to discover the new instance in the production topology.

Integrating OracleAS Metadata Repositories within an Existing Database

OracleAS supports the ability to create Metadata Repository schemas in an existing database. Although OracleAS Guard recognizes and manages these databases to synchronize the Metadata Repository configuration data with the rest of the site's distributed configuration data, OracleAS Guard does not create the standby repository nor the production to standby relationship. This environment is supported using the clone topology operation.

To utilize the clone topology command, first install and start the standalone OracleAS Guard server on each standby host. Additionally, the OracleAS Backup/Restore utility is installed in the Oracle home created by the standalone OracleAS Guard install. See the section on recovering a loss of host automatically in Oracle Application Server Administrator's Guide for more information including a list of prerequisites. The clone topology command creates the instance Oracle homes and configuration information at the standby site. For Infrastructure instances, an implicit instantiate operation is performed to initialize the OracleAS Disaster Recovery environment. The clone topology operation can use a profile file to filter out instances for an asymmetric topology.

Warning: Do not perform a clone operation to a standby system that contains an existing Oracle home because it will get overwritten. Perform a clone operation only to a standby system where no Oracle home is installed.

Some situations in which cloning operations are useful are:

- When you want to add one or more production instances to a standby host site.

- When you want to add a single production instance to a standby host system.

The steps to perform these cloning operations are described in the following sections.

### 5.10.1 Cloning Single or Multiple Production Instances to a Standby System

Whether you are cloning a single production instance or multiple production instances to a standby site, the prerequisites and steps to follow are identical; the only difference is the actual asgctl command you would use for either cloning operation. For this reason, this section combines the cloning information and indicates where there are some minor differences.

Cloning a Single Production Instance to a Standby Site

As an example, you want to add a production instance to a standby system. The clone instance operation eliminates the task of having to install the Oracle instance on the standby middle-tier system and then perform an instantiate operation.

Cloning Multiple Production Instances to a Standby Site

As an example, you want to add two or more production instances to a standby middle-tier host system. The clone topology operation eliminates the task of having to install these Oracle instances on the standby middle-tier systems and then perform an instantiate operation.

As part of the clone topology operation, the production instances are cloned and the OracleAS Metadata Repository is instantiated. However, for a OracleAS Metadata Repository configuration created using OracleAS Metadata Repository Creation Assistant, no instantiate operation is performed.

If you want to use a policy file, edit and use the clone policy file (`clone_policy.xml`). Specify this file in the `using policy <file>` parameter of the clone topology command to clone a standby topology for only those instances specified accordingly. See Section 5.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.

Prerequisites

The production instance or instances to be cloned cannot exist on the standby system.

The following are prerequisites for performing the clone instance and clone topology operation to the standby site system:

- The OracleAS Guard standalone kit must be installed on the standby system.

- Backup and Restore must be installed in the OracleAS Guard home on the standby system.

- A Java development kit with its jar utility must be installed on the standby system.

- For Windows systems, the services kit (`sc.exe`) must be installed on the standby system.

Procedure

The basic procedure consists of the following pre-clone (UNIX systems only) and clone steps.

Note: For OracleAS Disaster Recovery release 10.1.2.0.2 on Windows systems, see the pre-clone and post-clone steps in this same section in the Oracle Application Server High Availability Guide in the OracleAS Release 10.1.2.0.2 documentation set.

Pre-Clone Steps (For UNIX Systems Only)

For each instance on the production and standby sites, perform the following steps:

1. Log in as su - root.

2. CD to the instance home.

3. Shut down any OracleAS Guard servers.

       > <ORACLE HOME>/opmn/bin/opmnctl stopproc ias-component=ASG

4. Make sure `dsaServer.sh` in `<ORACLE_HOME>``/dsa/bin` is executable by everyone. If it is not, record the permission, then change the executable permission by issuing the following command:

       chmod +x dsaServer.sh
       chmod u+x asgexec

5. Invoke asgctl and issue the startup command.

       > asgctl.sh startup

6. Log out as root on UNIX systems.

Clone Steps

From any instance on the production site, perform the following steps:

1. Log in as user (non root user on UNIX systems).

2. CD to the production instance home.

3. Invoke asgctl and run the clone instance command to clone the instance to the standby topology host system.

   Note: In the command output, you will see a number of connect messages. This is normal as the OracleAS Guard server is recycled during these operations.

       > asgctl.sh
       Application Server Guard: Release 10.1.3.0.0
       (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved
       ASGCTL> connect asg prodoc4j oc4jadmin/adminpwd
       Successfully connected to prodoc4j:7890
       ASGCTL> set primary database sys/testpwd@asdb
       Checking connection to database asdb

       CLONE INSTANCE -- CLONE AN INSTANCE EXAMPLE

       ASGCTL> clone instance portal_2 to asmid2
       Generating default policy for this operation
       .
       .
       .

       CLONE TOPOLOGY -- CLONE MULTIPLE INSTANCES EXAMPLE

       # Command to use if you are using a policy file where <file>
       # is the full path and file spec of the clone policy file.
       ASGCTL> clone topology to standbyinfra using policy <file>
       Generating default policy for this operation
       .
       .
       .

       ASGCTL> disconnect
       ASGCTL> exit
       >

4. Log out of the system.

Note: If OracleAS Guard does not run as root on UNIX systems, the user will be prompted by the OracleAS Guard client to run the underlying operations at each of the instance homes as root (manually) in order to continue with the operation.

The last step completes the cloning instance operation and brings the systems back to where they were before you started the operation. At this point, you could invoke asgctl, connect to a production system, discover the topology, and then perform a verify operation to determine if the production and standby topologies were valid and consistent with one another as you would expect them to be.

## 5.11 OracleAS Guard Operations -- Standby Instantiation and Standby Synchronization

After adhering to the following conditions, you are ready to use the Oracle Application Server Guard for standby instantiation and standby synchronization.

- Meet the requirements for the implementation of the OracleAS Disaster Recovery solution as described in Section 5.1.1, "OracleAS Disaster Recovery Requirements", Section 5.1.3, "Supported Topologies", and Section 5.2, "Preparing the OracleAS Disaster Recovery Environment".

- Install the OracleAS Disaster Recovery (DR) solution as described in Section 5.3, "Overview of Installing Oracle Application Server".

The following subsections describe standby instantiation and standby synchronization.

See Chapter 6, "OracleAS Guard asgctl Command-line Reference" for OracleAS Guard command-line asgctl utility reference information.

### 5.11.1 Standby Instantiation

The standby instantiation operation performs a number of operations to set up and maintain a logical mirror of the production site at the standby site. OracleAS Guard is used to coordinate the distributed operations across the production and standby sites to ensure the disaster recovery functionality is enabled. The setup operations are:

- Uses a previous topology file created by performing a discovery topology operation.

- Verifies the topology definitions to ensure they comply with the rules of the OracleAS Disaster Recovery environment.

- Configures Oracle Data Guard to maintain the OracleAS Disaster Recovery environment for the database repository.

- Mirrors the configuration information of all the Oracle homes in the OracleAS topology to the corresponding Oracle home at the standby site.

- If you want to use a policy file, edit and use the instantiate policy file (`instantiate_policy.xml`). Specify this file in the `using policy <file>` parameter of the instantiate topology command to instantiate a standby topology for only those instances specified accordingly. See Section 5.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.

- Reports any errors found for correction.

The procedure to perform a standby instantiation operation uses the following example, which assumes that you have invoked the OracleAS Guard client and performed a discover topology command to create a topology file.

See Section 6.2.1.1, "Special Considerations for Running Instantiate and Failover Operations in CFC Environments" if you have an OracleAS Disaster Recovery configuration in a CFC environment and are about to perform an instantiate operation.

1. Connect to the OracleAS Guard server.

       ASGCTL > connect asg prodinfra ias_admin/<adminpwd>
       Successfully connected to prodinfra:7890
       ASGCTL>

2. Specify the primary OracleAS Metadata Repository database. See Section 5.15.1.2, "Specifying the Primary Database" for more information. If you have multiple OracleAS Metadata Repositories in your topology, you must authenticate each one using the set primary database command.

       ASGCTL> set primary database sys/testpwd@asdb

3. Dump the policies (dump policies command), then edit and use the verify policy file (`verify_policy.xml`) and the instantiate policy file (`instantiate_policy.xml`) to specify the success requirement attribute for each instance in the file. See Section 5.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.

       ASGCTL> dump policies
       Generating default policy for this operation
       Creating policy files on local host in directory "/private1/OraHome2/asr1012/dsa/conf/"

4. Verify the topology. The network hostname `standbyinfra` is used.

       ASGCTL> verify topology with standbyinfra

5. Instantiate the topology at the secondary site. The network hostname `standbyinfra` is used. This command assumes that all Oracle homes have been installed using Oracle installer software. Specify the `using policy <file>` parameter where `<file>` represents the path and file specification for the `instantiate_policy.xml` file.

       ASGCTL> instantiate topology to standbyinfra using policy <file>

Whenever a standby instantiation is performed using the asgctl instantiate topology command a synchronization operation is also performed. Thus, you do not need to perform another synchronization operation immediately following the instantiation operation. If a period of time had passed following an instantiate operation, ensure that both the primary and standby sites are consistent. Then, perform a sync topology operation to ensure any changes that occurred on the primary site are applied to the secondary site.

### 5.11.2 Standby Synchronization

The OracleAS Guard synchronization operation synchronizes the standby site with the primary site to ensure that the two sites are logically consistent. This operation is necessary whenever any of the following circumstances exist:

- Deploy a new application or redeploy an existing application - Both the deployment of a new application and the redeployment of an existing application require changes to schema-based information in the metadata repository as well as component configuration information distributed among the Oracle homes in an OracleAS topology. This information has to be uniformly deployed at the standby site.

- Configuration changes - Specific changes, small to large, to a configuration, must be reflected at the standby site.

- User Provisioning - The default Infrastructure installation maintains the database for Oracle Internet Directory. As new users are added to the database, they should be synchronized to the standby site on a schedule that fulfills the business availability requirements.

- Periodic full synchronization - By default, the synchronization operations synchronizes only the pieces of configuration that have changed since the last synchronization operation. During test cycles or occasional complex configuration changes, administrators may want to fully refresh of their configuration information to the standby site to ensure mirroring of these changes.

You can specify a full or incremental synchronization. By default, an incremental synchronization is performed, which offers the best performance. However, in the following three circumstances a full synchronization should be specified:

- When you want to force a full synchronization to happen for some reason, such as synchronizing the standby site completely with the primary site.

- When you know there are many transactional changes over a short period of time on the primary site that must be synchronized with the secondary site.

- When you know that there is a large accumulation of transactional changes over a long period of time on the primary site that must be synchronized with the secondary site.

As part of the synchronization operation, a verify operation is performed to ensure the required OracleAS Disaster Recovery environment is maintained. Additionally, if new OracleAS instances are installed into the OracleAS topology, OracleAS Guard will discover these installations.

If you want to use a policy file, edit and use the synchronization policy file (`sync_policy.xml`). Specify this file in the `using policy <file>` parameter of the sync topology command for synchronizing a standby topology for only those instances specified accordingly. See Section 5.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.

The following example assumes that you have invoked the OracleAS Guard client and performed a discover topology command to create a topology file.

The procedure to perform standby synchronization is as follows:

1. Connect to the OracleAS Guard server.

       ASGCTL > connect asg prodinfra ias_admin/<adminpwd>
       Successfully connected to prodinfra:7890
       ASGCTL>

2. Specify the primary database. See Section 5.15.1.2, "Specifying the Primary Database" for more information.

       ASGCTL> set primary database sys/testpwd@asdb

3. Synchronize the secondary site with the primary site.

       ASGCTL> sync topology to standbyinfra

## 5.12 Runtime Operations -- OracleAS Guard Switchover and Failover Operations

Runtime operations include dealing with outages, whether they are scheduled or unscheduled (see Section 5.12.1, "Outages"), and monitoring ongoing OracleAS Guard operations using the asgctl command-line utility and troubleshooting (see Section 5.13, "Monitoring OracleAS Guard Operations and Troubleshooting").

### 5.12.1 Outages

Outages fall into two categories scheduled and unplanned.

The following subsections describe these outages.

#### 5.12.1.1 Scheduled Outages

Scheduled outages are planned outages. They are required for regular maintenance of the technology infrastructure supporting the business applications and include tasks such as hardware maintenance, repair and upgrades, software upgrades and patching, application changes and patching, and changes to improve the performance and manageability of systems. Scheduled outages can occur either for the production or standby site. Descriptions of scheduled outages that impact the production or standby site are:

- Site-wide maintenance

  The entire site where the current production resides is unavailable. Examples of site-wide maintenance are scheduled power outages, site maintenance, and regularly planned switchover operations.

- OracleAS Cold Failover Cluster cluster-wide maintenance

  This is scheduled downtime of the OracleAS Cold Failover Cluster for hardware maintenance. The scope of this downtime is the whole hardware cluster. Examples of cluster-wide maintenance are repair of the cluster interconnect and upgrade of the cluster management software.

- Testing and validating the standby site as a means to test OracleAS Disaster Recovery readiness.

For scheduled outages, a site switchover operation has to be performed, which is explained in the section that follows.

Site Switchover Operations

A site switchover is performed for planned outages of the production site. Both the production and standby sites have to be available during the switchover. The application of the database redo logs is synchronized to match the backup and restoration of the configuration files for the middle tier and OracleAS Infrastructure installations.

Note: During a switchover operation, the `opmn.xml` file is copied from the primary site to the standby site. For this reason, the value of the TMP variable must be defined the same in the `opmn.xml` file on both the primary and standby sites, otherwise this switchover operation will fail with a message that it could not find a directory. Therefore, make sure the TMP variable is defined identically and resolves to the same directory structure on both sites before attempting a switchover operation.

During site switchover, considerations must be made to avoid long periods of cached DNS information. Modifications to the site's DNS information, specifically time-to-live (TTL), must be performed. See Section 5.14.2, "Manually Changing DNS Names" for instructions.

If you want to use a policy file, edit and use the switchover policy file (`switchover_policy.xml`). Specify this file in the `using policy <file>` parameter of the switchover topology command for switching over to the standby topology only those instances specified accordingly. See Section 5.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information. This example does not show the use of a policy file.

See Section 6.2.1.3, "Special Considerations for Running a Switchover Operations in CFC Environments" if you have an OracleAS Disaster Recovery configuration in a CFC environment and are planning a switchover operation.

To switchover from the production site to the standby site, perform the following steps:

1. Reduce the wide area DNS TTL value for the site. See Section 5.14.2, "Manually Changing DNS Names" for more information.

2. On the primary Infrastructure system, make sure the emagent process is stopped. Otherwise, the following error may occur when doing a switchover operation because the emagent has a connection to the database:

       prodinfra: -->ASG_DGA-13051: Error performing a physical standby switchover.
       prodinfra: -->ASG_DGA-13052: The primary database is not in the proper state to perform a switchover.  State is "SESSIONS ACTIVE"

   On UNIX systems, stop the Application Server Control (iasconsole) and stop the emagent process, as follows:

       > <ORACLE_HOME>/bin/emctl stop iasconsole

   On UNIX systems, to check to see if there is an emagent process running, enter the following command:

       > ps -ef | grep emagent

   On UNIX systems, if after performing the stop iasconsole operation, the emagent process is still running, obtain the process ID (PID) as shown in the previous ps command, and stop the emagent process as follows:

       > kill -9 <emagent-pid>

   On Windows systems, open the Services control panel. Locate the OracleAS10gASControl service and stop this service.

3. Invoke the OracleAS Guard client command-line utility asgctl (on UNIX systems, `asgctl.sh` is located in `<ORACLE_HOME>``/dsa/bin` and on Windows systems, `asgctl.bat` is located in `<ORACLE_HOME>``\dsa\bin`.) and connect to the OracleAS Guard server.

       > asgctl.sh
       Application Server Guard: Release 10.1.2.0.2
       (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved
       ASGCTL> connect asg prodinfra ias_admin/<adminpwd>

4. Switchover the topology to the secondary site. If you want to use a policy file, specify the `using policy <file>` parameter where `<file>` represents the path and file specification for the `switchover_policy.xml` file.

       ASGCTL> switchover topology to standbyinfra

   Note: As part of the OracleAS Guard switchover operation, an implicit sync topology operation is performed to make sure the topologies are identical. In addition, all OPMN services are stopped and then restarted on the production site.

5. Disconnect from the old primary site OracleAS Guard server.

       ASGCTL> disconnect
       ASGCTL>

6. Perform a wide area DNS switchover to direct requests to the new production site based on one of the options presented in Section 5.14, "Wide Area DNS Operations".

7. Adjust the wide area DNS TTL to an appropriate value.

Special Switchover Operation Considerations

This section describes the following special considerations relating to the switchover operation.

- When performing a switchover operation from a primary site with two Oracle Identity Management instances running to a standby site representing an asymmetric topology with only one Oracle Identity Management instance running, which means that the other node is to be ignored on the switchover site, the system administrator must not only edit the `switchover_policy.xml` policy file to indicate that this other node is to be set to Ignore, but must also shutdown all processes running on that node in order for the switchover operation to be successful. For example, if the two Oracle Identity Management instances running on the primary site are im.machineA.us.oracle.com and im.machineB.us.oracle.com, and the other node (im.machineB.us.oracle.com) is to be ignored on the switchover site, the system administrator must also shutdown all processes running on that node (im.machineB.us.oracle.com) in order for the switchover operation to succeed.

- When the discover topology command is issued following a switchover operation and the asymmetric standby site topology originally had one or more fewer middle tiers (for example, instA and instB) than there were in the original production site topology (instA, instB, and instC), a warning error message displays for each missing instance of a middle tier (instC, in this case). This warning error message is expected and can be ignored. When a discover topology command is issued following a switchover operation, OracleAS Server Guard reads the Oracle Internet Directory information, which is an exact copy of the original primary site Oracle Internet Directory information on this new primary site (former standby site). Because this Oracle Internet Directory information is identical to the original primary site Oracle Internet Directory information, when OracleAS Server Guard visits the host or home of each instance of these middle tiers to verify their existence, it discovers that some of the middle tiers do not exist, and issues warnings.

#### 5.12.1.2 Unplanned Outages

An unplanned outage that impacts a production site occurs when it becomes unavailable and there is no possibility of restoring the production site to service within a reasonable period of time. This includes site-wide outages at the production site such as fire, flood, earthquake, or power outages.

Unplanned outages warrant performing a failover operation of the production site to the standby site.

Site Failover Operations

A site failover operation is performed for unplanned outages for the production site. Failover operations require the restoration of the configuration and Infrastructure data to a consistent point in time. OracleAS Guard ensures that the site services are brought up in a consistent fashion to the point of the last sync operation. A failover operation restores to the last synchronization point.

If you want to use a policy file, edit and use the failover policy file (`failover_policy.xml`). Specify this file in the `using policy <file>` parameter of the failover command for failing over to the standby topology only those instances specified accordingly. See Section 5.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.

See Section 6.2.1.1, "Special Considerations for Running Instantiate and Failover Operations in CFC Environments" if you have an OracleAS Disaster Recovery configuration in a CFC environment and are about to perform a failover operation.

To fail over the production site to the standby site, follow these steps:

1. Connect to the OracleAS Guard server on the standby site. The network name is standbyinfra.

       ASGCTL> connect asg standbyinfra ias_admin/<adminpwd>
       Successfully connected to stanfbyinfra:7890

2. Specify that the primary OracleAS Metadata Repository database on the standby site is now identified as the new primary database on this new production site. The keyword new is shown as bold text in the following example to indicate its importance as a key word. If you have multiple OracleAS Metadata Repositories in your topology, you must authenticate each one using the set new primary database command.

       ASGCTL> set new primary database sys/testpwd@asdb

3. Perform an asgctl failover operation.

       ASGCTL> failover

4. Discover the topology. You must perform this operation to create a new topology file for this production site.

       ASGCTL> discover topology oidpassword=oidpwd

## 5.13 Monitoring OracleAS Guard Operations and Troubleshooting

After setting up your OracleAS Disaster Recovery solution, and instantiating the standby topology, and synchronizing the standby topology, you can use the OracleAS Guard client command-line utility asgctl to issue commands through the coordinating OracleAS Guard server to monitor asgctl operations and perform troubleshooting tasks. A typical OracleAS Guard monitoring or troubleshooting session may involve the following tasks:

1. Section 5.13.1, "Verifying the Topology"

2. Section 5.13.2, "Displaying the Current Operation"

3. Section 5.13.3, "Displaying a List of Completed Operations"

4. Section 5.13.4, "Stopping an Operation"

5. Section 5.13.5, "Tracing Tasks"

6. Section 5.13.6, "Writing Information About the Topology to a File"

As asgctl commands are issued through the OracleAS Guard client and requests are then made to the coordinating OracleAS Guard server, the coordinating OracleAS Guard server communicates these requests to the other OracleAS Guard servers in the production and standby topologies, and status messages are returned to the OracleAS Guard client as well as any error messages should a particular task encounter a problem. Section 5.13.7, "Error Messages" describes where you can obtain more information about these error messages.

### 5.13.1 Verifying the Topology

To validate that the primary topology is running and the configuration is valid, enter the following asgctl command at the asgctl prompt.

    ASGCTL> connect asg ias_admin/iastest2
    Successfully connected to prodinfra:7890
    ASGCTL> discover topology oidpassword=oidpwd
    ASGCTL> verify topology
    Generating default policy for this operation
    prodinfra:7890
         HA directory exists for instance asr1012.infra.us.oracle.com
    asmid2:7890
         HA directory exists for instance asmid2.asmid2.us.oracle.com
    asmid1:7890
         HA directory exists for instance asmid1.asmid1.us.oracle.com
    ASGCTL>

If you want to use a policy file, edit and use the verify policy file (`verify_policy.xml`) to specify the success requirement attribute for each instance in the file. Then specify the `using policy <file>` parameter in the verify command where `<file>` represents the path and file specification for the `verify_policy.xml` file. See Section 5.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.

To compare a primary topology to which the local host is a member with a standby topology and ensure that they are consistent with one another and that both topologies conform to OracleAS Disaster Recovery requirements, enter the following asgctl command at the asgctl prompt and specify the name of the standby host system.

    ASGCTL> dump policies
    Generating default policy for this operation
    Creating policy files on local host in directory "/private1/OraHome2/asr1012/dsa/conf/"

    ASGCTL> verify topology with standbyinfra
    Generating default policy for this operation
    prodinfra:7890
         HA directory exists for instance asr1012.infra.us.oracle.com
    asmid2:7890
         HA directory exists for instance asmid2.asmid2.us.oracle.com
    asmid1:7890
         HA directory exists for instance asmid1.asmid1.us.oracle.com
    standbyinfra:7890
         HA directory exists for instance asr1012.infra.us.oracle.com
    asmid2:7890
         HA directory exists for instance asmid2.asmid2.us.oracle.com
    asmid1:7890
         HA directory exists for instance asmid1.asmid1.us.oracle.com
    prodinfra:7890
        Verifying that the topology is symmetrical in both primary and standby configuration
    ASGCTL>

    # Command to use if you want to use a policy file
    # verify topology with standbyinfra using policy <file>

### 5.13.2 Displaying the Current Operation

To display the status of all the current operations running on all nodes of the topology to which the OracleAS Guard client is connected, enter the following asgctl command at the asgctl prompt:

    ASGCTL> show operation
    *************************************
    OPERATION: 19
      Status: running
      Elapsed Time: 0 days, 0 hours, 0 minutes, 28 secs
      TASK: syncFarm
        TASK: backupFarm
          TASK: fileCopyRemote
          TASK: fileCopyRemote
        TASK: restoreFarm
          TASK: fileCopyLocal

### 5.13.3 Displaying a List of Completed Operations

To display only operations that have completed (are not running on any nodes of the topology to which the OracleAS Guard client is connected for the current session), enter the following asgctl command at the asgctl prompt:

    ASGCTL> show operation history
    *************************************
    OPERATION: 7
      Status: success
      Elapsed Time: 0 days, 0 hours, 0 minutes, 0 secs
      TASK: getTopology
        TASK: getInstance
    *************************************
    OPERATION: 16
      Status: success
      Elapsed Time: 0 days, 0 hours, 0 minutes, 0 secs
      TASK: getTopology
        TASK: getInstance
    *************************************
    OPERATION: 19
      Status: success
      Elapsed Time: 0 days, 0 hours, 1 minutes, 55 secs
      TASK: syncFarm
        TASK: backupFarm
          TASK: fileCopyRemote
          TASK: fileCopyRemote
        TASK: restoreFarm
          TASK: fileCopyLocall

### 5.13.4 Stopping an Operation

To stop a specific operation that is running on the server, enter the following asgctl command at the asgctl prompt and specify the operation number you want to stop. You can obtain the operation number you want to stop by entering a asgctl show operation full command.

    ASGCTL> show operation full
    *************************************
    OPERATION: 19
      Status: running
      Elapsed Time: 0 days, 0 hours, 0 minutes, 28 secs
      Status: running
    .
    .
    .
    ASGCTL> stop operation 19

### 5.13.5 Tracing Tasks

To set a trace flag for a specific event and to log the output to the asgctl log files, enter the following asgctl command at the asgctl prompt and specify the on keyword and enter the trace flags to be enabled. In this case, the trace flag `DB` indicates that trace information regarding processing in the Oracle Database environment will be displayed. See the set trace command for more information about other trace flags that can be enabled. See the set trace command for a complete list of the trace flags that can be set.

    ASGCTL> set trace on db

### 5.13.6 Writing Information About the Topology to a File

To write detailed information about the topology to which the local host is connected, enter the following asgctl command at the asgctl prompt and specify the path name and file name where the detailed output is to be written. The output is the same as the display shown in the dump topology command, except it is written to a file that you can save for future reference.

    ASGCTL> dump topology to c:\dump_mid_1.txt

### 5.13.7 Error Messages

Appendix B, "OracleAS Guard Error Messages" categorizes and describes the error messages that may appear while using the OracleAS Disaster Recovery solution.

## 5.14 Wide Area DNS Operations

To direct client requests to the entry point of a production site, use DNS resolution. When a site switchover or failover is performed, client requests have to be redirected transparently to the new site that is playing the production role. To accomplish this redirection, the wide area DNS that resolves requests to the production site has to be switched over to the standby site. The DNS switchover can be accomplished by either using a wide area load balancer or manually changing DNS names.

Note: A hardware load balancer is assumed to be front-ending each site. Check `http://metalink.oracle.com` for supported load balancers.

The following subsections describe the DNS switchover operation.

### 5.14.1 Using a Wide Area Load Balancer

When a wide area load balancer (global traffic manager) is deployed in front of the production and standby sites, it provides fault detection services and performance-based routing redirection for the two sites. Additionally, the load balancer can provide authoritative DNS name server equivalent capabilities.

During normal operations, the wide area load balancer can be configured with the production site's load balancer name-to-IP mapping. When a DNS switchover is required, this mapping in the wide area load balancer is changed to map to the standby site's load balancer IP. This allows requests to be directed to the standby site, which now has the production role.

This method of DNS switchover works for both site switchover and failover. One advantage of using a wide area load balancer is that the time for a new name-to-IP mapping to take effect can be almost immediate. The downside is that an additional investment needs to be made for the wide area load balancer.

### 5.14.2 Manually Changing DNS Names

This method of DNS switchover involves the manual change of the name-to-IP mapping that is originally mapped to the IP address of the production site's load balancer. The mapping is changed to map to the IP address of the standby site's load balancer. Follow these instructions to perform the switchover:

1. Make a note the current time-to-live (TTL) value of the production site's load balancer mapping. This mapping is in the DNS cache and it will remain there until the TTL expires. As an example, let's assume that the TTL is 3600 seconds.

2. Modify the TTL value to a short interval (for example, 60 seconds).

3. Wait one interval of the original TTL. This is the original TTL of 3600 seconds from Step 1.

4. Ensure that the standby site is switched over to receive requests.

5. Modify the DNS mapping to resolve to the standby site's load balancer giving it the appropriate TTL value for normal operation (for example, 3600 seconds).

This method of DNS switchover works for planned site switchover operations only. The TTL value set in Step 2 should be a reasonable time period where client requests cannot be fulfilled. The modification of the TTL is effectively modifying the caching semantics of the address resolution from a long period of time to a short period. Due to the shortened caching period, an increase in DNS requests can be observed.

## 5.15 Using OracleAS Guard Command-Line Utility (asgctl)

This section includes the following subsections:

- Section 5.15.1, "Typical OracleAS Guard Session Using asgctl"

- Section 5.15.2, "Periodic Scheduling of OracleAS Guard asgctl Scripts"

- Section 5.15.3, "Submitting OracleAS Guard Jobs to the Enterprise Manager Job System"

- Section 5.16.1, "Special Considerations for Multiple OracleAS Metadata Repository Configurations"

- Chapter 6, "OracleAS Guard asgctl Command-line Reference"

### 5.15.1 Typical OracleAS Guard Session Using asgctl

A typical OracleAS Guard session using asgctl involves the following tasks, which are described in the following subsections:

- Section 5.15.1.1, "Getting Help"

- Section 5.15.1.2, "Specifying the Primary Database"

- Section 5.15.1.3, "Discovering the Topology"

One of the advantages of supporting an asgctl command-line interface is that you can place these asgctl commands in a proper sequence in a script as described in Section 5.15.1.4, "Creating and Executing an asgctl Script" and then execute the script as described in Section 5.15.2, "Periodic Scheduling of OracleAS Guard asgctl Scripts" and Section 5.15.3, "Submitting OracleAS Guard Jobs to the Enterprise Manager Job System".

#### 5.15.1.1 Getting Help

To get help on a particular command, enter the asgctl command at the asgctl prompt and specify the command name you for which you want help information. Otherwise, to get help on all commands, enter the following asgctl command at the asgctl prompt:

    ASGCTL> help
        connect asg [<host>] [<ias_administrator_account>/<password>]
        disconnect
        exit
        quit
        add instance <instance_name> on <instance_host> [to topology]
        clone topology to <standby_topology_host> [using policy <file>] [no standby]
        clone instance <instance> to <standby_topology_host> [no standby]
        discover topology [oidhost=<host>] [oidsslport=<sslport>] [oiduser=<user>] oidpassword=<pass>
        discover topology within farm
        dump farm [to <file>]  (Deprecated)
        dump topology  [to <file>] [using policy <file>]
        dump policies
        failover [using policy <file>]
        help [<command>]
        instantiate farm to <standby_farm_host> (Deprecated)
        instantiate topology to <standby_topology_host> [using policy <file>]
        remove instance <instance_name> [from topology]
        set asg credentials <host> <ias_administrator_account>/<password> [for topology]
        set asg credentials <host> ias_admin/<password> [for farm] (Deprecated)
        set primary database <username>/<password>@<servicename> [pfile <filename> | spfile <filename>]
        set new primary database <username>/<password>@<servicename> [pfile <filename> | spfile <filename>]
        set noprompt
        set trace on|off <traceflags>
        sync farm to <standby_farm_host> [full | incr[emental]] (Deprecated)
        sync topology to <standby_topology_host> [full | incr[emental]] [using policy <file>]
        startup [asg]
        startup farm (Deprecated)
        startup topology
        shutdown [local]
        shutdown farm (Deprecated)
        shutdown topology
        show op[eration] [full] [[his]tory]
        show env
        stop op[eration] <op#>
        switchover farm to <standby_farm_host> (Deprecated)
        switchover topology to <standby_topology_host> [using policy <file>]
        verify farm [with <host>](Deprecated)
        verify topology [with <host>] [using policy <file>]
    ASGCTL>

#### 5.15.1.2 Specifying the Primary Database

To identify the OracleAS Infrastructure database on the primary topology, enter the following asgctl command at the asgctl prompt and specify the user name and password for the database account with sysdba privileges to access the OracleAS Infrastructure database and the TNS service name of the OracleAS Infrastructure database:

    ASGCTL> set primary database sys/testpwd@asdb
    Checking connection to database asdb
    ASGCTL>

The standby site uses the same values as specified for the primary database because the service name and password for both the primary and standby OracleAS Infrastructure Databases must be the same. You must always set the primary database before performing an instantiate, sync, switchover, or failover operation.

If you have multiple OracleAS Metadata Repositories in your topology, you must authenticate each one using the set primary database command.

#### 5.15.1.3 Discovering the Topology

You must perform a discover topology command when you first set up your OracleAS Disaster Recovery environment in order to initially create the topology XML file. There after, you should perform a discover topology operation whenever you procure another Oracle home in a production site or change roles from a production to a standby site through a switchover or failover operation. The discover topology command queries Oracle Internet Directory for all instances within the topology that share the same Oracle Internet Directory for the production site. See Section 6.2, "Information Specific to a Small Set of OracleAS Guard Commands" for more information about topology files. Enter the following asgctl command at the asgctl prompt to discover the topology:

    ASGCTL> discover topology oidpassword=oidpwd
    Discovering topology on host "infra" with IP address "123.1.2.111" prodinfra:7890
        Connecting to the OID server on host "infra.us.oracle.com" using SSL port "636" and username "orcladmin"
        Getting the list of databases from OID
        Gathering database information for SID "asdb" from host "infra.us.oracle.com"
        Getting the list of instances from OID
        Gathering instance information for "asr1012.infra.us.oracle.com" from host "infra.us.oracle.com"
        Gathering instance information for "asmid1.asmid1.us.oracle.com" from host "asmid1.us.oracle.com"
        Gathering instance information for "asmid2.asmid2.us.oracle.com" from host "asmid2.us.oracle.com"
    The topology has been discovered. A topology.xml file has been written to each home in the topology.

    ASGCTL>

After the production topology is known by OracleAS Guard for a production site, you can execute any one of the subsequent commands to perform a subsequent asgctl operation that involves the standby site. See discover topology for more information.

#### 5.15.1.4 Creating and Executing an asgctl Script

To create a script containing a sequence of asgctl command names and their arguments, open an edit session with your favorite editor, enter the asgctl commands in the proper sequence according to the operations you want to perform, save the script file, then execute the script when you invoke asgctl as shown in the following command:

    > ASGCTL @myasgctlscript.txt

See the set echo command for an example of a script containing a series of asgctl commands.

You can also set the noprompt state for use in executing commands in an asgctl script in which all interactive prompts are later ignored. See the asgctl set noprompt command for more information.

### 5.15.2 Periodic Scheduling of OracleAS Guard asgctl Scripts

For OracleAS Guard operations that you want to run periodically, such as a periodic sync topology operation to keep the standby topology synchronized with the primary topology, you can automate the periodic running of an OracleAS Guard asgctl script.

On UNIX systems, you can set up a cron job to run the asgctl script. Copy your asgctl script into the appropriate `/etc` subdirectory `cron.hourly`, `cron.daily`, `cron.weekly`, or `cron.monthly`. It will run either hourly, daily, weekly, or monthly, depending on the name of the subdirectory in which you choose to place your script. Or you can edit a crontab and create an entry that will be specific for the time on which you want to run the asgctl script. See the one or two manpages on cron and crontab for more information.

On Windows systems, you can use the task scheduler or scheduled tasks from the Control Panel to choose the time to run the asgctl script, daily, weekly, monthly, or at specific times. You can also purchase additional scheduler software with more options from a third party and then set the time and frequency to run the asgctl script. See the Windows operating system help for more information.

### 5.15.3 Submitting OracleAS Guard Jobs to the Enterprise Manager Job System

You can use the Enterprise Manager Job System to automate the execution of any asgctl script to be run at a specified time interval or at a specified time and date, or both, in addition to setting other custom settings. To do this, access the EM Job Activity page and create your own host command job to execute your asgctl script, which is called a job task. Your job task (script) will invoke asgctl to run the asgctl commands in the order in which they are listed. After you create your OracleAS Guard job, save it to the EM Job Library, which is a repository for frequently used jobs, where it can be executed based on the custom settings and time specifications you selected. See the Enterprise Manager online help and Oracle Enterprise Manager Concepts for more information.

## 5.16 Special Considerations for Some OracleAS Metadata Repository Configurations

This section describes special considerations for multiple OracleAS Metadata Repositories and OracleAS Metadata Repositories created using the OracleAS Metadata Repository Creation Assistant.

### 5.16.1 Special Considerations for Multiple OracleAS Metadata Repository Configurations

By default, the credentials you specified in the asgctl connect command are used whenever one OracleAS Guard server connects to another OracleAS Guard server. However, there may be cases where you want to do either of the following:

- Use different credentials for each system on a given site, see Section 5.16.1.1, "Setting asgctl Credentials".

- Use a common set of credentials in the standby topology that are the same as the credentials used in the primary topology, see Section 5.16.1.2, "Specifying the Primary Database".

If the credentials for any host system are not the same as those used in the asgctl connect command, you must set the OracleAS Guard credentials so that the OracleAS Guard server can connect to each host system in the configuration.

#### 5.16.1.1 Setting asgctl Credentials

To set different credentials for all the host systems belonging to the same topology, enter the following asgctl command at the asgctl prompt. Specify the node name of the host system to which the credentials apply and the `ias_admin` account name and password for the `ias_admin` account created during the Oracle Application Server installation, and the key words for topology.

Note: If this is an OracleAS 10.1.3 installation, the user name must be `oc4jadmin` and the password for the `oc4jadmin` account created during the Oracle Application Server 10.1.3 installation.

These settings are good for the current session.

    ASGCTL> set asg credentials standbyinfra ias_admin/<iasadminpwd> for topology

When you specify the key words, for topology, you set the credentials for all the host systems that belong to the same topology as the specified system; otherwise, the credentials will apply only for the specified host system.

The set asg credentials command is also useful when you want to use different credentials for a specific server on the topology. In the previous example, the same credentials were set for all nodes on the standby topology, so that these credentials differ from the credentials used in the primary topology. The following command sets the credentials for a specific node, the standbyinfra node, on the standby topology.

    ASGCTL> set asg credentials standbyinfra ias_admin/<iasadminpwd>

To summarize, if you set the credentials for a topology, these credentials are inherited for the entire topology. If you set the credentials for an individual host on the topology, the credentials (for this host) override the default credentials set for the topology.

In addition, for topologies that have more than one Infrastructure, such as a collocated Oracle Internet Directory+OracleAS Metadata Repository and a separate Portal OracleAS Metadata Repository, OracleAS Guard requires that you set the credentials for each system on which an Infrastructure resides before performing any important OracleAS Guard operations, such as instantiate, sync, switchover, and failover. See set asg credentials for an example.

#### 5.16.1.2 Specifying the Primary Database

To identify the OracleAS Infrastructure database on the primary topology, enter the following asgctl command at the asgctl prompt. Specify the user name and password for the database account with sysdba privileges to access the OracleAS Infrastructure Database on the primary topology and the TNS service name of the OracleAS Infrastructure database:

    ASGCTL> set primary database sys/testpwd@asdb
    Checking connection to database asdb
    ASGCTL>

The standby site uses the same values as specified for the primary database because the service name and password for both the primary and standby OracleAS Infrastructure databases must be the same.

If a production or standby site has multiple OracleAS Metadata Repository instances installed and you are performing an instantiate, sync, switchover, or failover operation, you must identify all of the OracleAS Metadata Repository instances by performing a set primary database command for each OracleAS Metadata Repository instance before performing either an instantiate, sync, switchover, or failover operation. See set asg credentials for an example.

#### 5.16.1.3 Setting OracleAS Guard Port Numbers

OracleAS Guard uses a default port (port) number of 7890; for example, `port=7890`. If there are any additional Oracle homes installed on a system, each additional Oracle home must have a unique OracleAS Guard port number, that is usually incremented by the value one, for example, `port=7891`, and so forth. See Section 5.4.6, "Supported OracleAS Disaster Recovery Configurations" for more information.

### 5.16.2 Special Considerations for OracleAS Metadata Repository Configurations Created Using OracleAS Metadata Repository Creation Assistant

The following items are special considerations for an OracleAS Metadata Repository configuration created using OracleAS Metadata Repository Creation Assistant. These Metadata Repository databases are installed in Oracle homes with schemas containing user data. For this reason, there are some special considerations regarding OracleAS Disaster Recovery.

- On the standby site, no Metadata Repository is created by OracleAS Disaster Recovery. The System Administrator must use the OracleAS Metadata Repository Creation Assistant on the standby site and create this Metadata Repository.

- During a clone topology operation to the standby site no instantiate operation is performed on the Metadata Repository.

- Warning: Do not perform a clone operation to a standby system containing an existing Oracle home because it will get overwritten. Only perform a clone operation to a standby system where there is no Oracle home installed.

- The OracleAS Disaster Recovery solution assumes that user schemas are already configured for Oracle Data Guard.

- The OracleAS Disaster Recovery solution assumes that when using Oracle Data Guard, that the Metadata Repository is not in managed recovery mode.

- OracleAS Disaster Recovery will not change the recovery mode of Oracle Data Guard for the Metadata Repository if it is found to be in managed recovery mode; instead, OracleAS Guard will issue a warning indicating that the database is in managed recovery mode and this feature must be set differently.

- OracleAS Guard must be installed in every Oracle home on every system that is part of your production and standby topology configured for the OracleAS Disaster Recovery solution. OracleAS Guard can be installed as a standalone install a kit located on OracleAS Utility media #2. See the OracleAS Disaster Recovery installation information in Oracle Application Server Installation Guide for more information.

## 5.17 Special Considerations for OracleAS Disaster Recovery Environments

The following sections describe some additional special considerations for OracleAS Disaster Recovery environments.

### 5.17.1 Some Special Considerations That Must Be Taken When Setting Up Some OracleAS Disaster Recovery Sites

Some special considerations must be taken when setting up OracleAS Disaster Recovery for sites that include:

- Middle-tier CFC configurations

- OracleAS Guard release 10g (9.0.4) cloning

In both cases, the instance name stored in Oracle Internet Directory is comprised of the original host name on which the production site installation was performed. In the case of an OracleAS Disaster Recovery site having a symmetric topology, the standby OracleAS Disaster Recovery peer must be installed identically to the production site and for an OracleAS Guard Release 10.1.2.0.2 or higher clone instance or clone topology operation, the operation must be performed to mirror the configuration.

In an asymmetric standby topology, where the production site physical host does not exist at the standby site, the instance name should be filtered out of the topology using the policy file capabilities (see Section 5.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information). The hosts file of the host on which a discover topology operation is performed must map the original host name to the corresponding IP of the new host system on which it was cloned.

### 5.17.2 Handling ons.conf and dsa.conf Configuration Files for Asymmetric Topologies

The OracleAS Guard operation synchronizes the configuration files of the standby site with those of the production site through a backup operation on the primary site and restores them to the standby site.

For asymmetric topologies the standby site has fewer nodes, thus node name list in the `ons.conf` configuration file is different from the one on the production site. Therefore, the `ons.conf` configuration file should be excluded from the backup list of files so it is not restored on the standby site. If not excluded, the nodes listed in the `ons.conf` configuration file will reflect the node list of the production site and not the actual node list of the standby site. This will cause inefficiencies as OPMN will continue to ping non existing nodes.

Additionally, for asymmetric topologies the `dsa.conf` configuration file for an Oracle home may contain special settings on the production site that are different from the standby site. For example, the `inventory_location` parameter setting may be different on the standby site than it is on the primary site. In this case, you should also exclude the `dsa.conf` configuration file from the backup list of files so it is not restored on the standby site. Otherwise, in this example, the location of the OraInventory will not be correct on the standby site following a switchover or failover operation.

In both these cases, you should modify the Backup and Restore exclusion file as follows to exclude both of these configuration files from the backup list of files so neither is then restored to the standby site:

    # Exclude Files
    # - Add additional files to this list that you want to be ignored
    # - during the configuration file backup/restore
    c:\oracle\ias1012\opmn\conf\ons.conf
    c:\oracle\ias1012\dsa\dsa.conf

If the directives set in the `dsa.conf` file are necessary at the site that currently functions as the production site, it may be desirable to include the `dsa.conf` file for synchronization and add a post switchover or failover step to edit physical site specific directives.

### 5.17.3 Other Special Considerations for OracleAS Disaster Recovery Environments

See Section 6.2, "Information Specific to a Small Set of OracleAS Guard Commands" for information describing some additional special considerations.