| Oracle® Application Server High Availability Guide 10g Release 2 (10.1.2) B14003-05 |
|
 Previous |
 Next |
| Oracle® Application Server High Availability Guide 10g Release 2 (10.1.2) B14003-05 |
|
Previous |
Next |
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 or asymmetrically to the production site. 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 sites are managed using Oracle Application Server Guard, which contains a command-line utility (asgctl) that encapsulates administrative tasks (see Chapter 14, "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 Backup and Recovery Tool (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 13-1 provides a summary of the OracleAS Disaster Recovery strategy and how this Oracle software is used behind the scenes:
Table 13-1 Overview of OracleAS Disaster Recovery strategy
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. 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 13.10, "Runtime Operations -- OracleAS Guard Switchover and Failover Operations".
This chapter is organized into the following sections:
Section 13.1, "Oracle Application Server 10g Disaster Recovery Solution"
Section 13.2, "Preparing the OracleAS Disaster Recovery Environment"
Section 13.3, "Overview of Installing Oracle Application Server"
Section 13.6, "Discovering, Dumping, and Verifying the Topology"
Section 13.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands"
Section 13.9, "OracleAS Guard Operations -- Standby Instantiation and Standby Synchronization"
Section 13.10, "Runtime Operations -- OracleAS Guard Switchover and Failover Operations"
Section 13.11, "Monitoring OracleAS Guard Operations and Troubleshooting"
Section 13.13, "Using OracleAS Guard Command-Line Utility (asgctl)"
Section 13.14, "Special Considerations for Some OracleAS Metadata Repository Configurations"
Section 13.15, "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 (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 a 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.
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 and types 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 in case of failover.
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:
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 13.2.1, "Planning and Assigning Hostnames" for information about how to change these physical hostnames and the virtual hostname. |
Virtual hostname 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):
OracleAS Guard supports Oracle Application Server releases 10g (9.0.4) and 10g (10.1.2.0.0 and 10.1.2.0.2). The OracleAS Guard kit located on the 10g (10.1.2.0.2) Utility media #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 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 OracleAS 10g (10.1.2) and as long as its Infrastructure is still an 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 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.
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:
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 13-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 13-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 13-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 Section 6.2.2, "Active-Passive High Availability Topologies" 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 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.
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.
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 13.8, "OracleAS Guard Operations -- Standby Site Cloning of One or More Production Instances to a Standby System", Section 13.9, "OracleAS Guard Operations -- Standby Instantiation and Standby Synchronization", Section 13.10, "Runtime Operations -- OracleAS Guard Switchover and Failover Operations", and Section 13.13, "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.
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 13-2 for an example of this OracleAS Disaster Recovery solution).
Figure 13-2 Simple Asymmetric Standby with Reduced Resources
Figure 13-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 13-3 for an example of this OracleAS Disaster Recovery solution).
Figure 13-3 Simple Asymmetric Standby with Guaranteed Infrastructure
Figure 13-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.
This topology (Figure 13-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 13.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 13.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 13-4 Collocated Oracle Identity Management and OracleAS Metadata Repository with a Separate OracleAS Metadata Repository
The topologies in Section 13.1.3.1, "Symmetrical Topologies - Strict Mirror of the Production Site with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure", Section 13.1.3.2, "Asymmetrical Topologies - Simple Asymmetric Standby Topology with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure", and Section 13.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 13.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 13-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 13-5 Non-Collocated Oracle Identity Management (IM) and OracleAS Metadata Repository (MR) Infrastructure Topology with Distributed OracleAS Metadata Repositories
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:
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.
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 13.12, "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 13.2.2, "Configuring Hostname Resolution" explains hostname resolution. |
Figure 13-6 illustrates the process of planning and assigning hostnames.
Figure 13-6 Name Assignment Example in the Production and Standby Sites
In Figure 13-6, 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 13-2 details what the physical, network, and virtual hostnames are in the example:
Table 13-2 Physical, network, and virtual hostnames in Figure 13-6
| 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.
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. |
Check the setting for the existing hostname as follows:
prompt> hostname
Use a text editor, such as vi, to edit the name in /etc/nodename to your planned physical hostname.
For each middle-tier host, reboot it for the change to take effect.
Repeat Step 1 to verify the correct hostname has been set.
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. |
In the Start menu, select Control Panel.
Double-click the System icon.
Select the Advance tab.
Select Environment variables.
Under the User Environment variables for the installer account, select New to create a new variable.
Enter the name of the variable as "_CLUSTER_NETWORK_NAME_".
For the value of this variable, enter the planned physical hostname.
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 13-6, 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
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 High Availability" 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 13-6, 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.
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 13.2.1, "Planning and Assigning Hostnames". These are:
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.
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:
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.
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 asgctlverify 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 13-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.
Reboot each host after editing the files mentioned in the previous steps.
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 13-6, 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 13-6, Table 13-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 13-3 Network and Virtual Hostname Entries in Each /etc/hosts File of Example in Figure 13-6
| Host | Entries in /etc/hosts |
|---|---|
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
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 13-7 provides an overview of this setup.
|
See Also: Chapter 17, "Setting Up a DNS Server" for instructions on how to set up a DNS server in a UNIX environment. |
Figure 13-7 DNS Resolution Topology Overview
For the topology in Figure 13-7 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:
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 13-6, 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
For each site, production and standby, create a unique DNS zone by configuring a DNS server as follows:
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 13-6. The high level corporate domain name is oracle.com.
Configure the DNS server in each site to point to the overall corporate DNS servers for unresolved requests.
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 13-6, 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 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". |
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 13-6 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
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 13.1.3, "Supported Topologies". After following the instructions in Section 13.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, namedstaticports.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:
Install OracleAS Infrastructure in the production site (see Oracle Application Server Installation Guide).
Install OracleAS Infrastructure in the standby site (see Oracle Application Server Installation Guide).
Start the OracleAS Infrastructure in each site before installing the middle tiers for that site.
Install the middle tiers in the production site (see Oracle Application Server Installation Guide).
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.
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 13.5, "Authentication of Databases". This section contains the following subsections:
Section 13.4.6, "Supported OracleAS Disaster Recovery Configurations"
Section 13.4.7, "Configuring OracleAS Guard and Other Relevant Information"
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.
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 14, "OracleAS Guard asgctl Command-line Reference") consisting of a set of commands to perform administrative tasks described in Section 13.4.4, "asgctl Operations".
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.
Major asgctl operations using the asgctl commands belong in the following categories of operations:
Authentication -- Identify 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.
Identify the new OracleAS Infrastructure database on the standby topology (set new primary database command) prior to a failover operation.
Set 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 13.14.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 -- Discover (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 generate a topology XML file that describes the topology and replicates this file to all instances in the topology. See Section 13.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.
Standby site cloning -- Clone a single production instance to a standby system (clone instance command) or clone two or more production instances to standby systems (clone topology command). See Section 13.8, "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, create the standby Infrastructure, then synchronize the standby site with the primary site (instantiate topology command). See Section 13.9.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 13.9.2, "Standby Synchronization" for more information.
Switchover -- Switch 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 13.10.1.1, "Scheduled Outages" for more information.
Failover -- Make 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 13.10.1.2, "Unplanned Outages" for more information.
Verification -- Validate 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 conform to the requirements for OracleAS Disaster Recovery. See Section 13.11.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 13.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 13-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 13-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. |
A typical Oracle Application Server site has multiple farms. OracleAS Guard server and its ias-component DSA 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 DSA 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=DSA
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=DSA
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 DSA. This is the OracleAS component name and server process name for the OracleAS Guard server. |
For OracleAS 10g release (10.1.2), OracleAS Guard supports not only the default OracleAS Infrastructure configuration supported on Oracle Application Server Cold Failover Cluster and single instance, but also the topologies described in Section 13.1.3, "Supported Topologies".
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:
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 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.
|
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=DSA) and start the OracleAS Guard server (<ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=DSA) to activate the change. See Section 13.4.5, "OracleAS Guard Integration with OPMN") for more information. |
OracleAS Guard has a default timeout value (exec_timeout_secs) for executing operating system commands of 60 seconds, for example, exec_timeout_secs=60.
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.
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 13.10.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. 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.
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.
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 13.11.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 13.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.
OracleAS Disaster Recovery provides support for a variety of application server topologies as described in Section 13.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 13.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>
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).
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 middle-tier 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. It is assumed that a separate OracleAS install has already been performed on the standby host. 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.
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.
The production instance to be cloned cannot exist on the standby system.
The following are prerequisites for performing the clone instance 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.
The basic procedure consists of the following pre-clone, clone, and post-clone steps.
Pre-Clone Steps
For each instance on the production and standby sites, perform the following steps:
Log in as su - root on UNIX systems or as Administrator on Windows systems.
CD to the instance home.
Shut down any OracleAS Guard servers.
On UNIX systems: > <ORACLE HOME>/opmn/bin/opmnctl stopproc ias-component=DSA On Windows systems: C:\<ORACLE HOME>\opmn\bin\opmnctl stopproc ias-component=DSA
On UNIX systems only: 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
Invoke asgctl and issue the startup command.
>On UNIX systems from the <ORACLE_HOME>/dsa/bin directory > asgctl.sh startup On Windows systems fom the <ORACLE_HOME>\dsa\bin directory C:\> asgctl startup
Log out as root on UNIX systems.
Clone Steps
From any instance on the production site, perform the following steps:
Log in as user (non root user on UNIX systems).
CD to the production instance home.
Invoke asgctl and run the clone instance command to clone the instance to the standby topology host system.
> 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 Successfully connected to prodinfra:7890 ASGCTL> set primary database sys/testpwd@asdb Checking connection to database asdb ASGCTL> clone instance portal_2 to asmid2 Generating default policy for this operation . . . ASGCTL> disconnect ASGCTL> exit >
Log out of the system.
Post-Clone Steps
For the instance on the production and standby sites, perform the following steps:
Log in as su - root on UNIX systems or as Administrator on Windows systems.
CD to the instance home.
On the production site systems, CD to the instance home.
On the standby site systems, CD to the OracleAS Guard standalone home.
Perform an asgctl shutdown command.
>On UNIX systems from the <ORACLE_HOME>/dsa/bin directory > asgctl.sh shutdown On Windows systems fom the <ORACLE_HOME>\dsa\bin directory C:\> asgctl shutdown
Log out as root on UNIX systems.
On UNIX systems only: Restore the permission for dsaServer.sh to what you recorded it as in Pre-Clone Step 4.
On the standby site only, CD to the newly cloned home.
Start up OracleAS Guard using the following opmnctl command:
On Unix systems: > <ORACLE HOME>/opmn/bin/opmnctl startproc ias-component=DSA On Windows systems: C:\<ORACLE HOME>\opmn\bin\opmnctl startproc ias-component=DSA
|
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.
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.
The production instances to be cloned cannot exist on the standby systems.
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 13.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.
The following are prerequisites for performing the clone topology operation to standby site systems:
The OracleAS Guard standalone kit must be installed on each standby system.
Backup and Restore must be installed on each OracleAS Guard home on each standby system.
A Java development kit with its jar utility must be installed on each standby system.
For Windows systems only, the services kit (sc.exe) must be installed on each standby system.
The basic procedure consists of the following pre-clone, clone, and post-clone steps.
Pre-Clone Steps
For each instance on the production and standby sites, perform the following steps:
Log in as su - root on UNIX systems or as Administrator on Windows systems.
CD to the instance home.
Shut down any OracleAS Guard servers.
On UNIX systems: > <ORACLE HOME>/opmn/bin/opmnctl stopproc ias-component=DSA On Windows systems: C:\<ORACLE HOME>\opmn\bin\opmnctl stopproc ias-component=DSA
On UNIX systems only: 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
Invoke asgctl and issue the startup command.
>On UNIX systems from the <ORACLE_HOME>/dsa/bin directory > asgctl.sh startup On Windows systems fom the <ORACLE_HOME>\dsa\bin directory C:\> asgctl startup
Log out as root on UNIX systems.
Clone Steps
From any instance on the production site, perform the following steps:
Log in as user (non root user on UNIX systems).
CD to any production instance home.
Invoke asgctl and run the clone topology command to clone the topology to the standby topology host system.
> 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 Successfully connected to prodinfra:7890 ASGCTL> set primary database sys/testpwd@asdb Checking connection to database asdb ASGCTL> # 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 >
Log out from the system.
Post-Clone Steps
For each instance on the production and standby sites, perform the following steps:
Log in as su - root on UNIX systems or as Administrator on Windows systems.
CD to the instance home.
On the production site systems, CD to the instance home.
On the standby site systems, CD to the OracleAS Guard standalone home.
Perform an asgctl shutdown command.
>On UNIX systems from the <ORACLE_HOME>/dsa/bin directory > asgctl.sh shutdown On Windows systems fom the <ORACLE_HOME>\dsa\bin directory C:\> asgctl shutdown
Log out as root on UNIX systems.
On UNIX systems only: Restore the permission for dsaServer.sh to what you recorded it as in Pre-Clone Step 4.
On the standby site only, CD to the newly cloned homes.
Start up OracleAS Guard using the following opmnctl command:
On Unix systems: > <ORACLE HOME>/opmn/bin/opmnctl startproc ias-component=DSA On Windows systems: C:\<ORACLE HOME>\opmn\bin\opmnctl startproc ias-component=DSA
|
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 topology 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.
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 13.1.1, "OracleAS Disaster Recovery Requirements", Section 13.1.3, "Supported Topologies", and Section 13.2, "Preparing the OracleAS Disaster Recovery Environment".
Install the OracleAS Disaster Recovery (DR) solution as described in Section 13.3, "Overview of Installing Oracle Application Server".
The following subsections describe standby instantiation and standby synchronization.
See Chapter 14, "OracleAS Guard asgctl Command-line Reference" for OracleAS Guard command-line asgctl utility reference information.
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 13.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 14.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.
Connect to the OracleAS Guard server.
ASGCTL > connect asg prodinfra ias_admin/<adminpwd> Successfully connected to prodinfra:7890 ASGCTL>
Specify the primary OracleAS Metadata Repository database. See Section 13.13.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
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 13.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/"
Verify the topology. The network hostname standbyinfra is used.
ASGCTL> verify topology with standbyinfra
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.
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 13.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:
Connect to the OracleAS Guard server.
ASGCTL > connect asg prodinfra ias_admin/<adminpwd> Successfully connected to prodinfra:7890 ASGCTL>
Specify the primary database. See Section 13.13.1.2, "Specifying the Primary Database" for more information.
ASGCTL> set primary database sys/testpwd@asdb
Synchronize the secondary site with the primary site.
ASGCTL> sync topology to standbyinfra
Runtime operations include dealing with outages, whether they are scheduled or unscheduled (see Section 13.10.1, "Outages"), and monitoring ongoing OracleAS Guard operations using the asgctl command-line utility and troubleshooting (see Section 13.11, "Monitoring OracleAS Guard Operations and Troubleshooting").
Outages fall into two categories scheduled and unplanned.
The following subsections describe these 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.
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 13.12.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 13.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 14.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:
Reduce the wide area DNS TTL value for the site. See Section 13.12.2, "Manually Changing DNS Names" for more information.
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.
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>
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. |
Disconnect from the old primary site OracleAS Guard server.
ASGCTL> disconnect ASGCTL>
Perform a wide area DNS switchover to direct requests to the new production site based on one of the options presented in Section 13.12, "Wide Area DNS Operations".
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.
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 13.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.
See Section 14.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:
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
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
Perform an asgctl failover operation.
ASGCTL> failover
Discover the topology. You must perform this operation to create a new topology file for this production site.
ASGCTL> discover topology oidpassword=oidpwd
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:
Section 13.11.3, "Displaying a List of Completed Operations"
Section 13.11.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 13.11.7, "Error Messages" describes where you can obtain more information about these error messages.
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 13.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>
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
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
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
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
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
Appendix C, "OracleAS Guard Error Messages" categorizes and describes the error messages that may appear while using the OracleAS Disaster Recovery solution.
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. Checkhttp://metalink.oracle.com for supported load balancers. |
The following subsections describe the DNS switchover operation.
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.
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:
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.
Modify the TTL value to a short interval (for example, 60 seconds).
Wait one interval of the original TTL. This is the original TTL of 3600 seconds from Step 1.
Ensure that the standby site is switched over to receive requests.
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.
This section includes the following subsections:
Section 13.13.1, "Typical OracleAS Guard Session Using asgctl"
Section 13.13.2, "Periodic Scheduling of OracleAS Guard asgctl Scripts"
Section 13.13.3, "Submitting OracleAS Guard Jobs to the Enterprise Manager Job System"
Section 13.14.1, "Special Considerations for Multiple OracleAS Metadata Repository Configurations"
A typical OracleAS Guard session using asgctl involves the following tasks, which are described in the following subsections:
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 13.13.1.4, "Creating and Executing an asgctl Script" and then execute the script as described in Section 13.13.2, "Periodic Scheduling of OracleAS Guard asgctl Scripts" and Section 13.13.3, "Submitting OracleAS Guard Jobs to the Enterprise Manager Job System".
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_admin/<password>]
disconnect
exit
quit
clone topology to <standby_topology_host> [using policy <file>]
clone instance <instance> to <standby_topology_host>
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>]
set asg credentials <host> ias_admin/<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
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>
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.
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. 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.
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.
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.
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.
This section describes special considerations for multiple OracleAS Metadata Repositories and OracleAS Metadata Repositories created using the OracleAS Metadata Repository Creation Assistant.
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 13.14.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 13.14.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.
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. 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.
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.
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 13.4.6, "Supported OracleAS Disaster Recovery Configurations" for more information.
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.
The following sections describe some additional special considerations for OracleAS Disaster Recovery environments.
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 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 13.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.
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.
See Section 14.2, "Information Specific to a Small Set of OracleAS Guard Commands" for information describing some additional special considerations.
