|
Oracle® Application Server 10g High Availability Guide
10g (10.1.2) Part No. B14003-01 |
|
 Previous |
 Next |
|
Oracle® Application Server 10g High Availability Guide
10g (10.1.2) Part No. B14003-01 |
|
|
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 identically to the production site. Under normal operation, the production site actively services requests. The standby site is maintained to 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 (verify, dump, instantiate, synchronize, switchover, failover, startup farm, shutdown farm, show operation, and stop operation, among others. 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 farm. The following table provides a summary of the OracleAS Disaster Recovery strategy and how this Oracle software is used behind the scenes:
Table 7-1 Overview of OracleAS Disaster Recovery strategy
Note that your other databases must be covered in the Disaster Recovery strategy and that 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 7.6, "Runtime Operations -- OracleAS Guard Switchover and Failover Operations".
This chapter is organized into the following main sections:
Section 7.1, "Oracle Application Server 10g Disaster Recovery Solution"
Section 7.2, "Preparing the OracleAS Disaster Recovery Environment"
Section 7.3, "Overview of Installing Oracle Application Server 10g Software"
Section 7.5, "OracleAS Guard Operations -- Standby Instantiation and Standby Synchronization"
Section 7.6, "Runtime Operations -- OracleAS Guard Switchover and Failover Operations"
Section 7.8, "Using OracleAS Guard Command-Line Utility (asgctl)"
|
See Also: Oracle Application Server Installation Guide for instructions on how to install the OracleAS Disaster Recovery solution. |
Geographically distributed 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, OracleAS Metadata Repository, and OracleAS Single Sign-On are set up in replication and distributed across different geographic regions. Note that each OracleAS Single Sign-On site uses its own Oracle Internet Directory and OracleAS Metadata Repository located at the local site, hence the active-active configuration. The shared similarities are 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 and 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 synchornization 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 identically configured sites - one primary (production/active) and one secondary (standby). Both sites have the same number of middle-tier and 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 are identical. Both sites are usually dispersed geographically, and if so, they are connected via a wide area network.
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 need to 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 mid 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 7.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 High Availability Addressing Page 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 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 of 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 for each OracleAS installation on a node. Do not use symbolic links anywhere in the path.
OracleAS installation types:
Figure 7-1 depicts the topology of an example OracleAS Disaster Recovery solution.
Figure 7-1 Example Oracle Application Server 10g 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 between the production and standby sites. For example, the Oracle Application Server Cold Failover Cluster 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 7-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 5.3.2, "Active-Passive High Availability Solutions" for more information on OracleAS Cold Failover Clusters.
The Oracle Application Server Disaster Recovery solution is an extension to various single-site Oracle Application Server architectures. Examples of such single-site architectures include the combination of Oracle Application Server Cold Failover Cluster (Infrastructure) and active-active Oracle Application Server middle-tier architecture. For the latest information on what single-site architectures are supported, please check the following URL 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. Being 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 10g 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. 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. 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 7.5, "OracleAS Guard Operations -- Standby Instantiation and Standby Synchronization" and Section 7.8, "Using OracleAS Guard Command-Line Utility (asgctl)" for information on using the asgctl command-line interface to perform OracleAS Guard administrative tasks of instantiation, synchronization, switchover, and failover in the OracleAS Disaster Recovery solution.
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.
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 is to 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.
|
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 7.2.2, "Configuring Hostname Resolution" explains hostname resolution. |
To illustrate what should be done to plan and assign hostnames, let us use an example as shown in Figure 7-2.
Figure 7-2 Name assignment example in the production and standby sites
In Figure 7-2, 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 7–2 below details what the physical, network, and virtual hostnames are in the example:
Table 7-2 Physical, network, and virtual hostnames in Figure 7-2
| Physical Hostnames | Virtual Hostname | Network Hostnames |
|---|---|---|
asmid1 |
- |
prodmid1, standbymid1 |
asmid2 |
- |
prodmid2, standbymid2 |
- Foot 1 |
infra |
prodinfra, standbyinfra |
Co-hosting non OracleAS applications
If the hosts in the production site are running non OracleAS applications, and you wish to co-host 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 the same as 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 differing purposes in the OracleAS Disaster Recovery solution. They are also set up differently. Information on how the three types of hostnames are set up follows.
The naming of middle-tier hosts in both the production and standby sites require the changing of 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 to see what the existing physical hostname is set to. Type:
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 above steps for each host in the production and standby sites.
In Windows, to change the physical hostname of a host:
|
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 DNS. These hostnames are visible in the network that the solution uses and are resolved through DNS to the appropriate hosts via 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 7-2, the following should be the additions 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 7-2, when you install the production site's OracleAS Infrastructure, enter its virtual hostname, "infra", when you see the Specify High Availability Addressing Page screen. Enter the same virtual hostname when you install the standby site's OracleAS Infrastructure.
In the Oracle Application Server Disaster Recovery solution, one of two ways of hostname resolution can be configured to resolve the hostnames you planned and assigned in Section 7.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's documentation if you wish to find out more about /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:
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 their correct IP addresses of all middle-tier nodes in the current site. Ensure that the first entry is the hostname and IP address of the current node.
|
Note: When making entries in the hosts file, make sure the intended hostname is positioned in the second column of the hosts file; otherwise, an asgctl verify farm with <host> operation will fail indicating that the production farm is not symmetrical with the standby farm. 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. (Note that you should also include fully qualified hostnames in addition to the abbreviated hostnames. See Table 7-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 IP address of the OracleAS Infrastructure host in the standby site.
Reboot each host after editing the above files.
From each host, ping 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 7-2, on the asmid1 host, use the following commands in:
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 7-2, Table 7-3 shows 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 reflect similarly.
Table 7-3 Network and virtual hostname entries in each /etc/hosts file of example in Figure 7-2
| Host | Entries in /etc/hosts |
|---|---|
asmid1 in production site
|
123.1.2.333 asmid1.oracle.com asmid1 123.1.2.334 asmid2.oracle.com asmid2 123.1.2.111 infra.oracle.com infra 213.2.2.210 remoteinfra.oracle.com remoteinfra |
asmid2 in production site
|
123.1.2.334 asmid2.oracle.com asmid2 123.1.2.333 asmid1.oracle.com asmid1 123.1.2.111 infra.oracle.com infra 213.2.2.210 remoteinfra.oracle.com remoteinfra |
infra in production site
|
123.1.2.111 infra.oracle.com infra 123.1.2.333 asmid1.oracle.com asmid1 123.1.2.334 asmid2.oracle.com asmid2 213.2.2.210 remoteinfra.oracle.com remoteinfra |
asmid1 in standby site
|
213.2.2.443 asmid1.oracle.com asmid1 213.2.2.444 asmid2.oracle.com asmid2 213.2.2.210 infra.oracle.com infra 123.1.2.111 remoteinfra.oracle.com remoteinfra |
asmid2 in standby site
|
213.2.2.444 asmid2.oracle.com asmid2 213.2.2.443 asmid1.oracle.com asmid1 213.2.2.210 infra.oracle.com infra 123.1.2.111 remoteinfra.oracle.com remoteinfra |
infra in standby site
|
213.2.2.210 infra.oracle.com infra 213.2.2.443 asmid1.oracle.com asmid1 213.2.2.444 asmid2.oracle.com asmid2 123.1.2.111 remoteinfra.oracle.com remoteinfra |
To set up the OracleAS Disaster Recovery solution to use DNS hostname resolution, site-specific DNS servers must be set up 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 7-3 provides an overview of this setup.
|
See Also: Appendix E, "Setting Up a DNS Server" for instructions on how to set up a DNS server in a UNIX environment. |
For the topology in Figure 7-3 to work, the following requirements and assumptions are made:
The production and standby sites' DNS servers are not 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 contain entries for middle-tier physical hostnames and OracleAS Infrastructure virtual hostnames. Each DNS server contain entries of hostnames within their own site only. 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 any entries for the physical, network, or virtual hostnames of any host in either 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:
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 in Figure 7-2, 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, let's use the name "oracleas" for the domain name for the two sites in Figure 7-2. 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 7-2, the entries are as follows:
For the production site's DNS:
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 standby site's DNS:
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 above,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 5.3.2, "Active-Passive High Availability Solutions".
|
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 vice versa.
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 unique hostname with respect 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. The reason for these DNS entries is that Oracle Data Guard uses TNS Names to direct requests to the production and standby OracleAS Infrastructures. Hence, the appropriate entries must be made to the tnsnames.ora file as well. Additionally, OracleAS Guard asgctl command-line commands need to reference the network hostnames.
Using the example in Figure 7-2 and assuming that the selected name for the remote OracleAS Infrastructure is "remoteinfra", the entries in 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, for the standby site, its DNS server should have the following entries:
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. After following the instructions in Section 7.2, "Preparing the OracleAS Disaster Recovery Environment" to set up the environment for the solution, go through this section for an overview of the installation process. Thereafter, follow the detailed instructions in the Oracle Application Server Installation Guide to install the solution.
The following is the overall sequence for installing the OracleAS Disaster Recovery solution:
Install OracleAS Infrastructure in the production site (refer to Oracle Application Server Installation Guide).
Install OracleAS Infrastructure in the standby site (refer to 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 (refer to Oracle Application Server Installation Guide).
Install the middle tiers in the standby site (refer to Oracle Application Server Installation Guide).
Note the following important points when you perform the installation:
The OracleAS Infrastructure Identity Management and OracleAS Metadata Repository components must be installed on the same host. These components cannot be distributed over multiple hosts or on multiple Oracle homes within the same host. (This requirement also applies to the OracleAS Cold Failover Cluster.)
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. Utilize a static ports definition file for this purpose (see note above and the next point).
In the installer's Specify TCP/IP Ports screen, specify the full path to the staticports.ini file.
In the installer's Select Configuration Options screen, ensure that you select the High Availability and Replication option.
During OracleAS Infrastructure installation, specify the virtual address assigned to the OracleAS Infrastructure in the Specify High Availability Addressing Page screen.
For the middle-tier hosts, any of the available middle-tier installation types can be installed. (Ensure that the OracleAS Infrastructure services have been started for a site before installing any middle tiers in that site.)
During each middle-tier installation, specify the OracleAS Infrastructure's virtual hostname as the OracleAS Infrastructure database.
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, you can continue to Section 7.5, "OracleAS Guard Operations -- Standby Instantiation and Standby Synchronization". This section contains the following sections:
Section 7.4.6, "Supported OracleAS Disaster Recovery Configurations"
Section 7.4.7, "Supported Oracle Application Server Releases and Operating Systems"
asgctl is a command-line interface that encapsulates the Oracle Application Server Guard administrative tasks to:
Ensure a correct environment in which OracleAS can run.
Provide simple administrative semantics to instantiate a standby site, once the install has been performed.
Provide a simple administration synchronization operation that will perform the complex steps, in a reliable fashion, narrowing the change window for potential problems.
Provide a simple switchover administration operation that will perform the complex steps of switching from the production site to the standby site.
Provide a simple failover administration operation that will perform the complex steps of recovering from an unplanned outage by failing over from the production site to the standby site.
asgctl greatly simplifies the complexity and magnitude of the number of steps involved in setting up and managing OracleAS Disaster Recovery. asgctl provides a distributed solution that consists of a client component (OracleAS Guard client) that can be installed on a machine on the farm and a transient server component (OracleAS Guard server) that is installed by default on the systems hosting the primary and standby Oracle homes that comprise the DR 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 (Step 1 in Figure 7-4). If this is unsuccessful, then the local OPMN server is contacted (Step 2) to start the local OracleAS Guard server for the instance (Step 3). The OracleAS Guard client then connects to the OracleAS Guard server and this server becomes the coordinating server in the DR configuration for all OracleAS Guard operations. For operations that require OracleAS Guard operations across the farm, the local OPMN server is contacted to start instances across the farm (Step 4) on all systems where OracleAS Guard server software is installed. The OracleAS Guard servers communicate directly (Step 5) and the coordinating OracleAS Guard server initiates and controls all communications on behalf of the OracleAS Guard client. The OracleAS Guard server will remain active until the OracleAS Guard client disconnects, or all operations are complete and the timeout value has been reached. The OracleAS Guard client provides an asgctl command-line interface (CLI) (see Section 7.8.5) consisting of a set of commands to perform instantiation, synchronization, switchover, failover, and monitoring operations.
Figure 7-4 How an ASG Server Is Started and OPMN and ASG Servers Communicate
The OracleAS Guard server is a distributed server (installed by default) that runs on all the systems in a DR configuration. An OracleAS Guard server is a transient server that is started and stopped by OPMN on each system for the duration of a client session. The OracleAS Guard client maintains an active connection to the OracleAS Guard server on one system that has network connectivity in the DR configuration. This coordinating server communicates to the OracleAS Guard servers on the other systems in the DR configuration as necessary to complete processing during standby site instantiation, synchronization, and verification 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's session. The steps to complete an operation will execute in concert over all systems in both the production and standby farms. Most operational steps will be executed in parallel or sequentially (as required) on these systems throughout the DR configuration by the OracleAS Guard server. The DR solution requires additional client session coordination among the farms' topologies between steps. This allows for implementation of error detection, correction and retry due to the operational failures. The DSA server has the capability to query the DSA client requesting for more input during a plan execution. For example, when an environmental conflict is recognized where there is no planned execution, the DSA client may be queried to continue, retry, or resolve a problem, such as allocate more disk space prior to further execution.
asgctl operations using the asgctl commands fall into the following categories of operations:
Standby site instantiation -- discovers the current farm definition at the production and standby sites, verifies that each complies with the OracleAS Disaster Recovery rules and restrictions of the current OracleAS software deployed on these systems prior to creation (instantiate farm command).
Standby site synchronization -- synchronizes the standby site with the primary site to ensure that the two sites are transactionally consistent (sync farm command).
Switchover -- switching 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.
Failover -- failing over from the production site to the standby site after restoring configuration files and restoring the OracleAS server environment to the point of the last successful backup operation.
Verification and troubleshooting -- validates that the primary farm is running and the configuration is valid (verify farm command). If a standby farm is specified, compares the primary farm to which the local host system is a member with the standby farm to validate that they are consistent with one another and each conform to the requirements for OracleAS Disaster Recovery (verify farm command). Lets you shut down the farm (shutdown farm command) in the case that one of its members is having a problem and you need to shut everything down and then start up the farm again (startup farm command). Lets you determine what the current operations are that are running (show operations command) and lets you stop any operations that need to be halted for some reason (stop operation command).
Use as needed -- setting asgctl credentials and identifying the OracleAS Infrastructure database on the primary farm (set primary database).
OPMN can communicate with other OPMN servers within a farm (fine black lines and arrows in Figure 7-4), whereas OracleAS Guard servers and the OracleAS Guard client communicate across the network (coarse black lines and arrows in Figure 7-4) based on the configured topology of the service. With disaster recovery, these operations require communication across both farms. In this case, OracleAS Guard servers must communicate across both farms and rely on OPMN services to start local OracleAS Guard servers (see Step 5 in Figure 7-4). OPMN starts the OracleAS Guard services across the production farm when an OracleAS Guard client connects to a server node. OracleAS Guard services are executed in concert with OracleAS Guard servers across the other nodes of the production farm and by default are a transient process. The results and status are communicated back to the OracleAS Guard client through the coordinating OracleAS Guard server. OPMN is used to start, stop, and monitor the OracleAS Guard server.
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 farm. Connect to the node containing the OracleAS Infrastructure database and run the following OPMN command on UNIX systems.
> <ORACLE HOME>/opmn/bin/opmnctl startproc ias-component=DSA
On Windows systems, you can 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
Once this OracleAS Guard server is started it is non transient, while the remaining OracleAS Guard servers in the standby farm are transient servers. This configuration allows cross-farm 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 only the default OracleAS Infrastructure configuration supported on Oracle Application Server Cold Failover Cluster and single instance.
Once you have adhered to the following conditions, you are ready to use the Oracle Application Server Guard for standby instantiation and standby synchronization.
Met the requirements for the implementation of the OracleAS Disaster Recovery solution as described in Section 7.1.1, "Requirements", Section 7.1.2, "Topology", and Section 7.2, "Preparing the OracleAS Disaster Recovery Environment".
Installed the OracleAS Disaster Recovery (DR) solution as described in Section 7.3, "Overview of Installing Oracle Application Server 10g Software".
This section describes the following topics:
See Section 7.8 and Section 7.8.5 for OracleAS Guard command-line asgctl utility tutorial and asgctl reference information.
By default, OracleAS Guard and asgctl, the command-line utility for OracleAS Guard are installed for all install types with the following default configuration information, which includes:
|
Note: See the OracleAS Guardreadme.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 farm production and standby farms.
OracleAS Guard uses a default port (port) number of 7890; for example, port=7890.
|
Note: If the port number must be changed for some reason (it must be unique for each OracleAS Guard server 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 7.4.5, "OracleAS Guard Integration with OPMN") for more information.
|
OracleAS Guard has a default timeout value (exec_timeout_secs) for executing OS commands of 60 seconds; for example, exec_timeout_secs=60.
OracleAS Guard has a default server inactive timeout value (server_inactive_timeout) of 600 seconds (10 minutes); for example, server_inactive_timeout=600. That is, after 10 minutes of inactivity, OracleAS Guard server will shut down.
OracleAS Guard is a transient server that is started and stopped by OPMN on each system for the duration of the client session on the production and standby farm.
Initially, on the production farm, when a OracleAS Guard client connects to a server node, OracleAS Guard server starts and this OracleAS Guard coordinating node instructs OPMN on the remaining nodes in the farm to start OracleAS Guard server on each respective node. However, on the standby farm, an OracleAS Guard server must first be started directly using opmnctl on the node containing the OracleAS infrastructure database (see Section 7.4.5, "OracleAS Guard Integration with OPMN" for more information), which when started will automatically start the remaining OracleAS Guard servers on the remaining nodes in the standby farm. Once the OracleAS Guard server is started on the node containing the OracleAS infrastructure database, it is not transient and will remain running indefinitely, while the remaining OracleAS Guard servers on the remaining nodes in the standby farm are transient.
The OracleAS Guard operation status information for a farm (from either an asgctl show operation full or show operation history command) remains available for only the life of the current OracleAS Guard client asgctl connect session. When the OracleAS Guard client disconnects from the OracleAS Guard server this farm's operation history information becomes unavailable.
Once you start an asgctl operation, another asgctl command cannot be run 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.
The standby instantiation operation performs a number of operations to setup 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 operations performed are:
Discovers the Oracle homes that are installed as part of the OracleAS farm at both the production and standby sites.
Verifies the farm definitions to ensure they comply with the rules of the OracleAS DR environment.
Configures Oracle Data Guard to maintain the DR environment for the database repository.
Mirrors the configuration information of all the Oracle homes in the OracleAS farm to the corresponding Oracle home at the standby site.
Reports any errors found for correction.
The procedure to perform a standby instantiation operation is as follows:
|
Note: For the Windows environment only: In a DR configuration that uses CFC on the primary farm or standby farm, or both, the following information must be considered before performing an asgctl instantiate farm to, switchover farm to, or failover command.Before taking a cold backup or restoring the metadata repository database, the Oracle Backup and Recovery Tool shuts down the database first. In the Windows CFC environment, Oracle Fail Safe performs database polling and restarts the database if it is down. Hence, every time before the administrator performs an instantiate, switchover, or failover operation, the administrator must disable database polling in Oracle Fail Safe and re-enable it after the backup/restore operation (after the instantiate, switchover, or failover operation completes). The steps to perform this sequence of operations are as follows:
|
Invoke the OracleAS Guard client and connect to the OracleAS Guard server. See Section 7.8.1.1, "Invoking the OracleAS Guard Client and Connecting to the OracleAS Guard Server" for more information.
> ASGCTL ASGCTL > connect asg prodinfra ias_admin/<adminpwd> Successfully connected to prodinfra:7890 ASGCTL>
Specify the primary database. See Section 7.8.1.3, "Specifying the Primary Database" for more information.
ASGCTL> set primary database sys/testpwd@asdb
Verify the farm. See Section 7.8.1.4, "Verifying the Farm" for more information. Note that the network hostname is referenced.
ASGCTL> verify farm with standbyinfra
Instantiate the farm at the secondary site. See Section 7.8.1.5, "Instantiating the Farm at the Secondary Site" for more information. Note that the network hostname is referenced.
ASGCTL> instantiate farm to standbyinfra
Disconnect from the OracleAS Guard server and exit the OracleAS Guard client. See Section 7.8.1.7, "Disconnecting from the OracleAS Guard Server and Exiting the OracleAS Guard Client" for more information.
ASGCTL> disconnect ASGCTL> exit >
Note that whenever a standby instantiation is performed using the asgctl instantiate farm command that a synchronization operation is also performed, which is why you do not need to perform another synchronization operation immediately following the instantiation operation. Only if a period of time had passed following an instantiate operation would you want to ensure that both the primary and standby sites are transactionally consistent; then you would perform a sync farm operation to ensure that if some transaction occurred on the primary site that it is 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 are met:
Deploy a new application or the re-deployment of an existing application - both the deployment of a new application and the re-deployment 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 farm. This information has to be uniformly deployed at the standby site.
Configuration changes - specific changes to a configuration, small to large, require that these configuration changes be reflected at the standby site.
User Provisioning - The default infrastructure installation maintains the database data for Oracle Internet Directory. As new users are added to the database, they should be synchronized to the standby site to a schedule that fulfills the business availability needs.
Periodic full synchronization - By default, the synchronization operations only synchronizes the pieces of configuration that have changed since the last synchronization operation. During test cycles or occasional complex configuration changes, administrators may desire full refreshes of their configuration information to the standby site to ensure mirroring of these changes.
As part of the synchronization operation a verify operation is performed to ensure the required DR environment is maintained. Additionally, if new OracleAS instances are installed into the OracleAS farm, OracleAS Guard will discover these installations.
The procedure to perform standby synchronization is as follows:
Invoke the OracleAS Guard client and connect to the OracleAS Guard server. See Section 7.8.1.1, "Invoking the OracleAS Guard Client and Connecting to the OracleAS Guard Server" for more information.
> asgctl.sh Application Server Guard: Release 10.1.2.0.0(c) Copyright 2004 Oracle Corporation. All rights reserved ASGCTL > connect asg prodinfra ias_admin/<adminpwd> Successfully connected to prodinfra:7890 ASGCTL>
Specify the primary database. See Section 7.8.1.3, "Specifying the Primary Database" for more information.
ASGCTL> set primary database sys/testpwd@asdb
Synchronize the secondary site with the primary site. See Section 7.8.1.6, "Synchronizing the Secondary Site with the Primary Site" for more information.
ASGCTL> sync farm to standbyinfra
Disconnect from the OracleAS Guard server and exit the OracleAS Guard client. See Section 7.8.1.7, "Disconnecting from the OracleAS Guard Server and Exiting the OracleAS Guard Client" for more information.
ASGCTL> disconnect ASGCTL> exit >
Note that you should always perform an ongoing sync farm operation whenever any of the previously mentioned circumstances are met.
Runtime operations include dealing with outages, whether they are scheduled or unscheduled (see Section 7.6.1, "Outages"), and monitoring ongoing OracleAS Guard operations using the asgctl command-line utility and troubleshooting (see Section 7.6.2, "Monitoring OracleAS Guard Operations and Troubleshooting").
Outages fall into two categories:
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 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 has to be performed, which is explained in Section 7.6.1.1.1, "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 to avoid long periods of cached DNS information have to be made. Modifications to the site's DNS information, specifically time-to-live (TTL), have to performed. Refer to Section 7.7.2, "Manually Changing DNS Names" for instructions.
|
Note: All sessions to the production and standby databases need to be closed in order to perform the switchover operation. The switchover operation requires that all middle-tier and OracleAS Infrastructure instances be shut down. Also, theCJQO and QMNO database processes have sessions that need to be stopped.
Just prior to performing the switchover operation, only OPMN is running on all systems in both production and standby farms and OracleAS Guard server is explicitly started on the Infrastructure system of the standby farm. (When an opmnctl status command is performed on a system on which OracleAS Guard server is running, you will see an ias-component and process-type named DSA, which is the running OracleAS Guard server.) See Section 7.4.5, "OracleAS Guard Integration with OPMN" for more information. Prior to performing the switchover operation, on the production farm, if there are services outside of the OPMN controlled services domain (the OPMN startall domain), such as emagent (see Step 2 that follows), user applications, or the DB job system for example, they must be manually managed (stopped) by the administrator depending on the operations. Prior to performing the switchover operation, on the standby farm, all systems must be available on the network and basically nothing can be running other than OPMN and OracleAS Guard server. After the OracleAS Guard asgctl switchover operation completes, any services outside of the OPMN controlled services domain (the OPMN startall domain) and user applications that are not started by default, must be manually managed (started) on this new production farm. |
|
Note: For the Windows environment only: In a DR configuration that uses CFC on the primary farm or standby farm or both, the following information must be considered before performing an asgctl instantiate farm to, switchover farm to, or failover command.Before taking a cold backup or restoring the metadata repository database, the Oracle Backup and Recovery Tool shuts down the database first. In the Windows CFC environment, Oracle Fail Safe performs database polling and restarts the database if it is down. Hence, every time before the administrator performs an instantiate, switchover, or failover operation, the administrator must disable database polling in Oracle Fail Safe and re-enable it after the backup/restore operation (after the instantiate, switchover, or failover operation completes). The steps to perform this sequence of operations are as follows:
|
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 7.7.2, "Manually Changing DNS Names" for more information.
On the primary infrastructure system, make sure the emagent process is stopped. Otherwise, you may run into the following error 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, to stop the emagent process, stop the Application Server Control, which is called iasconsole, as follows:
> <ORACLE_HOME>/bin/emctl stop iasconsole
On UNIX systems, to check to see if there is an emagent process running, do the following:
> ps -ef | grep emagent
On UNIX systems, if after performing the stop iasconsole operation, the emagent process is still running, get its process ID (PID) as determined from the previous ps command and stop it 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.0(c) Copyright 2004 Oracle Corporation. All rights reserved ASGCTL> connect asg prodinfra ias_admin/<adminpwd>
Specify the primary database.
ASGCTL> set primary database sys/testpwd@asdb
Switchover the farm to the secondary site.
ASGCTL> switchover farm to standbyinfra
|
Note: As part of the OracleAS Guard switchover operation, an implicit sync farm operation is performed to make sure the farms are identical. In addition, OPMN automatically starts the OracleAS Guard server on the "new" standby Infrastructure node and this server will run indefinitely, and in turn, starts the OracleAS Guard server on the other nodes in the "new" standby farm and each of these is a transient server. |
Disconnect from the "old" primary site OracleAS Guard server.
ASGCTL> disconnect ASGCTL>
Now you can perform some other OracleAS Guard operations, such as a verify farm operation or a dump farm operation, though neither operation is required to be run.
Perform a wide area DNS switchover to direct requests to the new production site based on one of the options presented in Section 7.7, "Wide Area DNS Operations".
Adjust the wide area DNS TTL to an appropriate value.
An unplanned outage that impacts either or both the production and standby sites can be one of the following:
Site-wide failure. The entire site where the current production resides is unavailable. Examples of site-wide outages are disasters at the production or standby site such as fire, flood, earthquake, or power outages.
Complete failure of the middle tier. The entire middle tier is not available. Either all nodes are down or the application server instances on all nodes are down. The last surviving node of the Oracle Application Server 10g Farm for a service is no longer available.
OracleAS Cold Failover Cluster cluster-wide failure. The entire hardware cluster hosting the OracleAS Infrastructure is unavailable or crashes. This includes failure of nodes in the cluster as well as any other components that results in the hardware cluster and the OracleAS Infrastructure on this site not being available.
Unplanned outages warrant the failover of the production site to the standby site.
A site failover 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.
To failover the production site to the standby site:
|
Note: For the Windows environment only: In a DR configuration that uses CFC on the primary farm or standby farm or both, the following information must be considered before performing an asgctl instantiate farm to, switchover farm to, or failover command.Before taking a cold backup or restoring the metadata repository database, the Oracle Backup and Recovery Tool shuts down the database first. In the Windows CFC environment, Oracle Fail Safe performs database polling and restarts the database if it is down. Hence, every time before the administrator performs an instantiate, switchover, or failover operation, the administrator must disable database polling in Oracle Fail Safe and re-enable it after the backup/restore operation (after the instantiate, switchover, or failover operation completes). The steps to perform this sequence of operations are as follows:
|
If you are using asgctl to continually synchronize the secondary (standby) site with the primary site, then both sites should already be synchronized and you can continue to Step 2.
|
Note: If you have not performed a recent sync operation prior to the loss of the production farm, a failover operation will still failover to the standby farm. The failover operation will make this standby farm the new production farm with the last sync information that was available.If you are not using OracleAS Guard asgctl commands at all to ensure that the secondary (standby) site is synchronized with the primary site, you must perform regular backup operations of the primary site middle-tier and OracleAS Infrastructure configuration files as described in Section D.1.1, "Manually Backing Up the Production Site", then you will need to restore the backup configuration files as described in Section D.1.2, "Manually Restoring to Standby Site". After restoring the configuration files (OracleAS Infrastructure and Middle Tier) on the standby site, then proceed to Step 2. |
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 on the standby site. Note that standbyinfra is the network name.
> asgctl.sh Application Server Guard: Release 10.1.2.0.0(c) Copyright 2004 Oracle Corporation. All rights reserved ASGCTL> connect asg standbyinfra ias_admin/<adminpwd> Successfully connected to stanfbyinfra:7890
Specify the primary database.
ASGCTL> set primary database sys/testpwd@asdb
Specify that the primary 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.
ASGCTL> set new primary database sys/testpwd@asdb
Perform an asgctl failover operation.
ASGCTL> failover
|
Note: As part of the OracleAS Guard failover operation, OPMN automatically starts the OracleAS Guard server on the "new" standby Infrastructure node and this server will run indefinitely, and in turn, starts the OracleAS Guard server on the other nodes in the "new" standby farm and each of these is a transient server. |
To maintain disaster failover capability, a new standby site should be set up and instantiated.
Specify the primary database prior to doing an instantiate operation.
ASGCTL> set primary database sys/testpwd@asdb
Instantiate the farm at the secondary site. Note that an instantiate operation also implicitly performs a sync operation.
|
Note: For the Windows environment only: In a DR configuration that uses CFC on the primary farm or standby farm or both, the following information must be considered before performing an asgctl instantiate farm to, switchover farm to, or failover command.Before taking a cold backup or restoring the metadata repository database, the Oracle Backup and Recovery Tool shuts down the database first. In the Windows CFC environment, Oracle Fail Safe performs database polling and restarts the database if it is down. Hence, every time before the administrator performs an instantiate, switchover, or failover operation, the administrator must disable database polling in Oracle Fail Safe and re-enable it after the backup/restore operation (after the instantiate, switchover, or failover operation completes). The steps to perform this sequence of operations are as follows:
|
ASGCTL> instantiate farm to standbyinfra
Disconnect from the "new" primary site OracleAS Guard server, and exit the OracleAS Guard client.
ASGCTL> disconnect ASGCTL> exit >
Perform a wide area DNS switchover to direct requests to the new production site based on one of the options presented in Section 7.7, "Wide Area DNS Operations".
Once your DR solution is set up, and the standby farm is instantiated, and the production and standby farms are synchronized, 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 some troubleshooting tasks. A typical OracleAS Guard monitoring or troubleshooting session may involve the following tasks:
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 pushes these requests out to the other OracleAS Guard servers in the production and standby farms, status messages are returned to the OracleAS Guard client as well as any error messages should a particular task encounter a problem. Section 7.6.2.9, "Error Messages" describes where you can obtain more information about these error messages.
To validate that the primary farm 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> verify farm prodinfra(asr1012): Verifying each instance in the farm midtier(asmid2): HA directory exists for instance asmid2.midtier.us.oracle.com. midtier(asmid1): HA directory exists for instance asmid1.midtier.us.oracle.com. prodinfra(asr1012): HA directory exists for instance asr1012.infra.us.oracle.com. ASGCTL>
To compare a primary farm to which the local host is a member with a standby farm to ensure they are consistent with one another and that both farms conform to DR requirements, enter the following asgctl command at the asgctl prompt and specify the name of the standby host system.
ASGCTL> verify farm with standbyinfra prodinfra(asr1012): Verifying each instance in the farm midtier(asmid2): HA directory exists for instance asmid2.midtier.us.oracle.com. midtier(asmid1): HA directory exists for instance asmid1.midtier.us.oracle.com. prodinfra(asr1012): HA directory exists for instance asr1012.infra.us.oracle.com. midtier(asmid1): HA directory exists for instance asmid1.midtier.us.oracle.com. midtier(asmid2): HA directory exists for instance asmid2.midtier.us.oracle.com. standbyinfra(asr1012): HA directory exists for instance asr1012.infra.us.oracle.com. prodinfra(asr1012): Verifying farm IasFarm is symmetrical in both primary and standby configuration. prodinfra(asr1012): Verifying instance asmid2.midtier.us.oracle.com is symmetrical in both primary and standby configuration. prodinfra(asr1012): Host names are symmetrical for instance asmid2.midtier.us.oracle.com. prodinfra(asr1012): Home name and path are symmetrical for instance asmid2.midtier.us.oracle.com. prodinfra(asr1012): Verifying instance asmid1.midtier.us.oracle.com is symmetrical in both primary and standby configuration. prodinfra(asr1012): Host names are symmetrical for instance asmid1.midtier.us.oracle.com. prodinfra(asr1012): Home name and path are symmetrical for instance asmid1.midtier.us.oracle.com. prodinfra(asr1012): Verifying instance asr1012.infra.us.oracle.com is symmetrical in both primary and standby configuration. prodinfra(asr1012): Host names are symmetrical for instance asr1012.infra.us.oracle.com. prodinfra(asr1012): Home name and path are symmetrical for instance asr1012.infra.us.oracle.com. ASGCTL>
To display the status of all the current operations running on all nodes of the farm to which the OracleAS Guard client is connected, enter the following asgctl command at the asgctl prompt:
ASGCTL> show operation full
*************************************
OPERATION: 15
Status: running
Elapsed Time: 0 days, 0 hours, 1 minutes, 35 secs
TASK: instantiateFarm
TASK: verifyFarm
To display only operations that are not running on all nodes of the farm to which the OracleAS Guard client is connected, enter the following asgctl command at the asgctl prompt:
ASGCTL> show operation history
*************************************
OPERATION: 69
Status: success
Elapsed Time: 0 days, 0 hours, 0 minutes, 7 secs
TASK: getFarm
*************************************
OPERATION: 70
Status: success
Elapsed Time: 0 days, 0 hours, 6 minutes, 49 secs
TASK: syncFarm
TASK: backupFarm
TASK: fileCopyRemote
TASK: fileCopyRemote
TASK: fileCopyRemote
TASK: resolveHost
TASK: restoreFarm
TASK: fileCopyLocal
TASK: fileCopyLocal
TASK: fileCopyLocal
.
.
.
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: 15
Status: running
Elapsed Time: 0 days, 0 hours, 1 minutes, 35 secs
TASK: instantiateFarm
TASK: verifyFarm
ASGCTL> stop operation 15
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 traceflags to be enabled. In this case, the traceflags 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 traceflags that can be enabled. See the set trace command for a complete list of the traceflags that can be set.
ASGCTL> set trace on db
To write detailed information about the farm 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 that displays shown in the dump farm command, except it is written to a file so you can save a record of it.
ASGCTL> dump farm to c: \dump_mid_1.txt
Occasionally, you may run into a problem with a member of the farm and the farm must be shut down and then started up again to fix the problem. To perform this task on a problem farm, enter the following asgctl commands at the asgctl prompt:
ASGCTL> connect asg prodinfra ias_admin/adminpwd Successfully connected to prodinfra:7890 ASGCTL> shutdown farm prodinfra(asr1012): Shutting down each instance in the farm prodinfra(asm21012): Shutting down component wireless prodinfra(asm1012): Shutting down component WebCache prodinfra(asm1012): Shutting down component OC4J prodinfra(asm21012): Shutting down component WebCache prodinfra(asm1012): Shutting down component dcm-daemon prodinfra(asm21012): Shutting down component OC4J prodinfra(asm1012): Shutting down component LogLoader prodinfra(asm1012): Shutting down component HTTP_Server prodinfra(asm21012): Shutting down component dcm-daemon prodinfra(asm21012): Shutting down component LogLoader prodinfra(asm21012): Shutting down component HTTP_Server prodinfra(asr1012): Shutting down component OID prodinfra(asr1012): Shutting down component OC4J prodinfra(asr1012): Shutting down component dcm-daemon prodinfra(asr1012): Shutting down component HTTP_Server ASGCTL>
Occasionally, you may run into a problem with a member of the farm and the farm must be shut down and then started up again to fix the problem. To perform this task on a shutdown farm, enter the following asgctl command at the asgctl prompt:
ASGCTL> startup farm prodinfra(asr1012): Starting each instance in the farm prodinfra(asr1012): Executing opmnctl startall command. prodinfra(asm1012): Executing opmnctl startall command. prodinfra(asm21012): Executing opmnctl startall command. ASGCTL>
Appendix C, "OracleAS Guard Error Messages" categorizes and describes the error messages that may appear while using the OracleAS Disaster Recovery solution.
In order for client requests to be directed to the entry point of a production site, DNS resolution is used. When a site switchover or failover is performed, client requests have to be redirected transparently to the new site 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 in one of the following two ways:
|
Note: A hardware load balancer is assumed to be front-ending each site. Check http://metalink.oracle.com for supported load balancers. |
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 should have been brought up and 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 task:
Note the current time-to-live (TTL) value of the production site's load balancer mapping. This mapping is in the DNS cache and will be there until the TTL expires. For the purposes of discussion and providing an example, let's assume this TTL to be 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 that we noted in 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 topics:
Section 7.8.1, "Typical OracleAS Guard Session Using asgctl"
Section 7.8.2, "Periodic Scheduling of OracleAS Guard asgctl Scripts"
Section 7.8.3, "Submitting OracleAS Guard Jobs to the Enterprise Manager Job System"
Section 7.8.4, "Specifying Different Credentials for Two or More Nodes"
Section 7.8.5, "Reference Section: OracleAS Guard asgctl Command-line Commands"
A typical OracleAS Guard session using asgctl involves the following tasks:
Section 7.8.1.1, "Invoking the OracleAS Guard Client and Connecting to the OracleAS Guard Server"
Section 7.8.1.5, "Instantiating the Farm at the Secondary Site"
Section 7.8.1.6, "Synchronizing the Secondary Site with the Primary Site"
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 7.8.1.8, "Creating and Executing an asgctl Script" and then execute the script as described in Section 7.8.2, "Periodic Scheduling of OracleAS Guard asgctl Scripts" and Section 7.8.3, "Submitting OracleAS Guard Jobs to the Enterprise Manager Job System".
To invoke OracleAS Guard client command-line utility asgctl, enter the following command at the operating system command-line prompt (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.).
> asgctl.sh Application Server Guard: Release 10.1.2.0.0 (c) Copyright 2004 Oracle Corporation. All rights reserved
Then enter the following asgctl command at the asgctl command-line prompt specifying the node name (in this case, prodinfra) of the host system for the OracleAS Guard server to which you want the OracleAS Guard client to connect and specify the ias_admin account name and password for the ias_admin account created during the Oracle Application Server installation:
ASGCTL > connect asg prodinfra ias_admin/<adminpwd> Successfully connected to prodinfra:7890 ASGCTL>
To get help on a particular command, enter the asgctl command at the asgctl prompt specifying 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
dump farm [to <file>]
help [<command>]
instantiate farm to <standby_farm_host>
set asg credentials <host> ias_admin/<password> [for farm]
set trace on|off <traceflags>
set primary database <username>/<password>@<servicename> [pfile <filename> | spfile <filename>]
set new primary database <username>/<password>@<servicename> [pfile <filename> | spfile <filename>]
sync farm to <standby_farm_host> [<sync_mode>]
startup farm
shutdown farm
show op[eration] [full] [[his]tory]
stop op[eration] <op#>
verify farm [with <host>]
switchover farm to <standby_farm_host>
failover
ASGCTL>
To identify the OracleAS Infrastructure database on the primary farm, enter the following asgctl command at the asgctl prompt specifying 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 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. Note that you must always set the primary database before performing an instantiate, sync, or switchover operation.
To validate that the primary farm is running and the configuration is valid, enter the following asgctl command at the asgctl prompt specifying the name of the standby host system that is a member of the standby farm (see Section 7.6.2.1, "Verifying the Farm" for an example with output):
ASGCTL> verify farm with standbyinfra . . .
To display more detailed information about the farm to which the local host is connected as another way of verifying the farm, enter the following asgctl command at the asgctl prompt.
ASGCTL> dump farm
prodinfra(asr1012): Describing each instance in the farm
Dump Farm
Name: IasFarm
Instance: asmid2.midtier.us.oracle.com
Type: Core
.
.
.
Asg Server Port: 7890
Instance: asmid.midtier.us.oracle.com
Type: Core
Oracle Home Name: asmid1
.
.
.
Asg Server Port: 7891
Instance: asr1012.infra.us.oracle.com
Type: Infrastructure
.
.
.
Asg Server Port: 7890
To instantiate a farm to a standby site, enter the following asgctl command at the asgctl prompt specifying the name of the standby host system that is a member of the standby farm. Note that part way through the operation you will be prompted to answer a question regarding whether you want to shut down the database. Reply by entering y or yes.
|
Note: For the Windows environment only: In a DR configuration that uses CFC on the primary farm or standby farm or both, the following information must be considered before performing an asgctl instantiate farm to, switchover farm to, or failover command.Before taking a cold backup or restoring the metadata repository database, the Oracle Backup and Recovery Tool shuts down the database first. In the Windows CFC environment, Oracle Fail Safe performs database polling and restarts the database if it is down. Hence, every time before the administrator performs an instantiate, switchover, or failover operation, the administrator must disable database polling in Oracle Fail Safe and re-enable it after the backup/restore operation (after the instantiate, switchover, or failover operation completes). The steps to perform this sequence of operations are as follows:
|
ASGCTL> instantiate farm to standbyinfra prodinfra(asr1012): Instantiating each instance in the farm to standby farm prodinfra(asr1012): Verifying each instance in the farm midtier(asmid2): HA directory exists for instance asmid2.midtier.us.oracle.com. midtier(asmid1): HA directory exists for instance asmid1.midtier.us.oracle.com. prodinfra(asr1012): HA directory exists for instance asr1012.infra.us.oracle.com. . . . This operation requires the database to be shutdown. Do you want to continue? Yes or No y . . . standbyinfra(asr1012): Starting restore/synchronization of database "asdb.us.oracle.com". standbyinfra(asr1012): Shutting down the standby database. standbyinfra(asr1012): Starting the standby database. standbyinfra(asr1012): Synchronizing farm completed successfully. prodinfra(asr1012): Synchronizing farm completed successfully. ASGCTL>
A synchronization operation is also performed as part of the instantiation operation.
To synchronize the standby site with the primary site, enter the following asgctl command at the asgctl prompt specifying the name of the standby site host system and optionally the sync mode.
ASGCTL> sync farm to standbyinfra prodinfra(asr1012): Synchronizing each instance in the farm to standby farm prodinfra(asr1012): Starting backup of farm "IasFarm". prodinfra(asr1012): Loading farm information. prodinfra(asr1012): Backing up and copying data to the standby farm. prodinfra(asr1012): Backing up each instance in the farm prodinfra(asr1012): Starting backup of instance "asr1012.infra.us.oracle.com". prodinfra(asr1012): Executing config_nodb option in bkp_restore.pl script. midtier(asmid2): Starting backup of instance "asmid2.midtier.us.oracle.com". midtier(asmid2): Executing config_nodb option in bkp_restore.pl script. midtier(asmid1): Starting backup of instance "asmid1.midtier.us.oracle.com". midtier(asmid1): Executing config_nodb option in bkp_restore.pl script. prodinfra(asr1012): Executing backup_config option in bkp_restore.pl script. prodinfra(asr1012): Deleted directory "/private1/OraHome/dsa/backup". midtier(asmid2): Executing backup_config option in bkp_restore.pl script. midtier(asmid2): Deleted directory "/private1/OraHome2/dsa/backup". midtier(asmid1): Executing backup_config option in bkp_restore.pl script. midtier(asmid1): Deleted directory "/private1/OraHome/dsa/backup". . . . prodinfra(asr1012): Starting backup/synchronization of database "asdb.us.oracle.com". midtier(asmid2): Synchronizing farm completed successfully. midtier(asmid1): Synchronizing farm completed successfully. midtier(asmid1): Synchronizing farm completed successfully. midtier(asmid2): Synchronizing farm completed successfully. standbyinfra(asr1012): Starting restore/synchronization of database "asdb.us.oracle.com". standbyinfra(asr1012): Shutting down the standby database. standbyinfra(asr1012): Starting the standby database. standbyinfra(asr1012): Synchronizing farm completed successfully. ASGCTL>
Even though the instantiation operation in the previous step also performs a synchronization operation, this step showing the synchronization operation is a way to ensure that both the standby site and primary site are synchronized.
Note that you can specify a sync_mode parameter as being one of two values, incremental or full. By default sync_mode is incremental and offers the best performance. However, there may be three circumstances when sync_mode of full 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 are a large accumulation of transactional changes over a long period of time on the primary site that must be synchronized with the secondary site.
See the sync farm to command for more information about the sync_mode parameter.
To disconnect the OracleAS Guard client from the OracleAS Guard server to which it is currently connected, and then exiting the OracleAS Guard client, enter the following asgctl commands at the asgctl prompt:
ASGCTL> disconnect ASGCTL> exit >
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 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.
For OracleAS Guard operations that you want to run periodically, such as a periodic sync farm operation to keep the standby farm synchronized with the primary farm, 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 manpage 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, or monthly or at certain times. You can also purchase additional scheduler software from a third party with more options and 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) would invoke asgctl to then 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.
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 7.8.4.1, "Setting asgctl Credentials".
Use a common set of credentials in the standby farm that are the same as the credentials used in the primary farm, see Section 7.8.4.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 ASG 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 farm, 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 farm. Note that these settings are good for the current session.
ASGCTL> set asg credentials standbyinfra ias_admin/<iasadminpwd> for farm
When you specify the key words, for farm, you set the credentials for all the host systems that belong to the same farm as the specified system; otherwise, the credentials will only apply 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 farm. In the previous example, the same credentials were set for all nodes on the standby farm, so that these credentialsl are different from the credentials used in the primary farm. The following command sets the credentials for a specific node, the standbyinfra node, on the standby farm.
ASGCTL> set asg credentials standbyinfra ias_admin/<iasadminpwd>
To summarize, if you set the credentials for a farm, these credentials are inherited for the entire farm. If you set the credentials for an individual host on the farm, the credentials (for this host) override the default credentials set for the farm.
To identify the OracleAS Infrastructure database on the primary farm, 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 farm and the TNS service name of the OracleAS Infrastructure database:
ASGCTL> set primary database sys/testpwd@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.
The rest of this chapter contains reference information describing the asgctl commands. Table 7-4 summarizes all the asgctl commands. Subsequent sections provide detailed reference information about each command.
Table 7-4 Summary of asgctl Commands
| Command | Description |
|---|---|
| asgctl
|
Invokes 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.
|
| connect asg
|
Connects the OracleAS Guard client to the OracleAS Guard server. |
| disconnect
|
Disconnects the OracleAS Guard client from the OracleAS Guard server. |
| dump farm
|
Directs the OracleAS Guard server to write detailed information about the farm to the screen or if specified, to a file. |
| exit
|
Disconnects the OracleAS Guard client from any existing connections and exits the OracleAS Guard client. This has the same effect as the quit command. |
| failover
|
During an unscheduled outage of the production site, the standby site becomes the production site. |
| help
|
Displays help information at the command line. |
| instantiate farm to
|
Creates a farm at the standby site (after verifying that the primary and standby sites are valid for OracleAS Disaster Recovery; also synchronizes the standby site with the primary site such that the primary and standby sites are transactionally consistent. |
| quit
|
Disconnects the OracleAS Guard client from any existing connections and exits the OracleAS Guard client. This has the same effect as the exit command. |
| set asg credentials
|
Sets the credentials used to authenticate the OracleAS Guard client connections to OracleAS Guard servers and connections between OracleAS Guard servers. |
| set echo
|
Sets command-echoing on or off in a asgctl script. |
| set new primary database
|
Identifies the OracleAS Infrastructure database on the standby farm as the new primary OracleAS Infrastructure database. |
| set primary database
|
Identifies the OracleAS Infrastructure database on the primary farm. |
| set trace
|
Enables or disables tracing for the specified trace flag. When tracing for a flag is set to on, the output of the trace is written to the OracleAS Guard log files. |
| show operation
|
Shows the current operation. |
| shutdown farm
|
Shuts down a running farm. |
| startup farm
|
Starts up a shutdown farm. |
| stop operation
|
Stops the specified operation. |
| switchover farm to
|
During a scheduled outage of the production site, switches the roles of the production site with the standby site so that the standby site now becomes the production site. |
| sync farm to
|
Synchronizes the standby site with the primary site such that the primary and standby sites are transactionally consistent. |
| verify farm
|
Verifies that the farm is running and the configuration is valid. If a standby farm is specified, this command compares the primary and standby farms to verify that they conform to the requirements for OracleAS Disaster Recovery. |
Invokes the OracleAS Guard client from the operating system command-line prompt or runs a script, if the path name to the script is provided.
Format
asgctl@[filename]
Parameters
The path to a file that contains asgctl commands that you want to run as a script.
Usage Notes
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.
If you get an error starting asgctl.sh on UNIX systems and you are not using csh, the C shell, start asgctl.sh using csh as follow:
> csh asgctl.sh
Example
> asgctl.sh Application Server Guard: Release 10.1.2.0.0(c) Copyright 2004 Oracle Corporation. All rights reserved ASGCTL>
Connects the OracleAS Guard client to the OracleAS Guard server.
Format
connect asg <host-name>[:<port>]> <username>/<password>
Parameters
Name of the host system for the OracleAS Guard server to which you want the OracleAS Guard client to connect. This is the host system on which the OracleAS Infrastructure database is located. This OracleAS Guard server will be the coordinating server for all operations performed on the systems being configured. The host name is optional if the OracleAS Guard client and OracleAS Guard server are on the same node. The host can be a system outside the farm.
The port number of the host system.
The user name must be the ias_admin account name and the password for the ias_admin account created during the Oracle Application Server installation. This account name must be the same as the account name on at least one of the Oracle Application Server homes.
Usage Notes
The OracleAS Guard client system must have network access to the OracleAS Guard host system specified with the host-name parameter.
The OracleAS Guard host system must have network access to all systems in the DR configuration and OracleAS Guard server must be installed and configured on all of these systems to run under the operating system user account specified by the user name and password parameters.
The specified ias_admin account name must be configured with the necessary rights and privileges to permit OracleAS DR site operations (read/write access to all required files and directories, and so forth)
An IP address can be used in place of a host name.
Example
The command in the following example results in the OracleAS Guard client connecting to the OracleAS Guard server running on a host named prodinfra using the user name and password ias_admin and adminpwd respectively.
ASGCTL> connect asg prodinfra ias_admin/adminpwd Successfully connected to prodinfra:7890
Disconnects the OracleAS Guard client from the OracleAS Guard server to which it is currently connected.
Format
disconnect
Usage Notes
The OracleAS Guard client must be connected to a OracleAS Guard server when you issue this command.
Example
The command in the following example disconnects the OracleAS Guard client from the OracleAS Guard server to which it is currently connected.
ASGCTL> disconnect ASGCTL>
Directs asgctl to write detailed information about the farm to the specified file.
Format
dump farm [to <file>]
Parameters
Name of file on the OracleAS Guard client node where the detailed output is to be written.
Usage Notes
An asgctl connection must be established before issuing this command.
Example
The following example writes detailed information about the farm to a local file.
ASGCTL> dump farm to c:\dump_mid_1.txt
Contents of file c:\dump_mid_1.txt are:
prodinfra(asr1012): Describing each instance in the farm
Dump Farm
Name: IasFarm
Instance: asmid2.midtier.us.oracle.com
Type: Core
Oracle Home Name: asmid2
Oracle Home Path: /private1/OraHome2
Version: 10.1.2.0.0
OidHost: infra.us.oracle.com
OidPort: 4060
VirtualHost: midtier.us.oracle.com
Host: midtier.us.oracle.com
Ip: 123.1.2.333
Operation System Arch: sparc
Operation System Version: 5.9
Operation System Name: SunOS
Java Home: /private1/OraHome2/jdk/jre
Java Version: 1.4.1_03
Java Class Version: 48.0
Asg Server Port: 7890
Instance: asmid1.midtier.us.oracle.com
Type: Core
Oracle Home Name: asmid
Oracle Home Path: /private1/OraHome
Version: 10.1.2.0.0
OidHost: infra.us.oracle.com
OidPort: 4060
VirtualHost: midtier.us.oracle.com
Host: midtier.us.oracle.com
Ip: 123.1.2.334
Operation System Arch: sparc
Operation System Version: 5.9
Operation System Name: SunOS
Java Home: /private1/OraHome/jdk/jre
Java Version: 1.4.1_03
Java Class Version: 48.0
Asg Server Port: 7891
Instance: asr1012.infra.us.oracle.com
Type: Infrastructure
Oracle Home Name: asr1012
Oracle Home Path: /private1/OraHome
Version: 10.1.2.0.0
OidHost: infra.us.oracle.com
OidPort: 4060
VirtualHost: infra.us.oracle.com
Infrastructure DB: asdb.us.oracle.com
Host: infra.us.oracle.com
Ip: 123.1.2.111
Operation System Arch: sparc
Operation System Version: 5.8
Operation System Name: SunOS
Java Home: /private1/OraHome/jdk/jre
Java Version: 1.4.1_03
Java Class Version: 48.0
Asg Server Port: 7890
Disconnects from any existing connections to OracleAS Guard servers and exits from the OracleAS Guard client.
Format
exit
Parameters
Usage Notes
None.
Example
ASGCTL> exit >
During an unscheduled outage of the production site, performs the failover operation of the production site to the standby site.
Format
failover
Parameters
Usage Notes
For the Windows environment only: In a DR configuration that uses CFC on the primary farm or standby farm, or both, the following information must be considered before performing an asgctl instantiate farm to, switchover farm to, or failover command. Before taking a cold backup or restoring the metadata repository database, the Oracle Backup and Recovery Tool shuts down the database first. In the Windows CFC environment, Oracle Fail Safe performs database polling and restarts the database if it is down. Hence, every time before the administrator performs an instantiate, switchover, or failover operation, the administrator must disable database polling in Oracle Fail Safe and re-enable it after the backup/restore operation (after the instantiate, switchover, or failover operation completes). The steps to perform this sequence of operations are described in a note in Section 7.6.1.2.1.
The OracleAS Guard client must be connected to a OracleAS Guard server before using this command. This OracleAS Guard server will act as the coordinating server for all operations performed on the systems being configured. By default, this is the local system where the connect asg command is being executed. This local system must be a member of the standby site farm.
The OracleAS Guard server must be started on the standby host system (<standby_farm_host>. The OracleAS Guard server can be stopped and started using opmnctl as follows:
On UNIX systems: <ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=DSA On Windows systems: <ORACLE_HOME>\opmn\bin\opmnctl stopproc ias-component=DSA
The standby local system must be part of an ONS farm for the site.
The standby host must be part of an ONS farm for the standby site and must be symmetrical to the topology of the production farm.
Make sure OracleAS Infrastructure database is running on the standby farm before performing a failover operation. Also, the OracleAS Infrastructure database information must be set by using the set new primary database asgctl command.
The global DNS names are used to direct the failover. This will be different than the HA naming utilized in the DR environment. The discovery mechanism automatically maps the topology to the corresponding peer based off local name resolution.
Example
The following example performs a failover operation to a standby site.
ASGCTL> connect asg standbyinfra ias_admin/adminpwd Successfully connected to standbyinfra:7890 ASGCTL> set primary database sys/testpwd@asdb ASGCTL> set new primary database sys/testpwd@asdb ASGCTL> failover standbyinfra(asr1012): Failover each instance in the farm from standby to primary farm midtier(asmid2): Shutting down component HTTP_Server midtier(asmid2): Shutting down component OC4J midtier(asmid2): Shutting down component dcm-daemon midtier(asmid2): Shutting down component LogLoader midtier(asmid1): Shutting down component HTTP_Server midtier(asmid1): Shutting down component OC4J midtier(asmid1): Shutting down component dcm-daemon midtier(asmid1): Shutting down component LogLoader standbyinfra(asr1012): Shutting down component OID standbyinfra(asr1012): Shutting down component HTTP_Server standbyinfra(asr1012): Shutting down component OC4J standbyinfra(asr1012): Shutting down component dcm-daemon standbyinfra(asr1012): Shutting down component LogLoader standbyinfra(asr1012): Failing over standby database standbyinfra(asr1012): Failover Physical Standby Database - init. standbyinfra(asr1012): Loading credentials for new primary database. standbyinfra(asr1012): Failover Physical Standby Database - activate the standby database. standbyinfra(asr1012): Connecting to database standbyinfra(asr1012): Restarting the infrastructure standby database. standbyinfra(asr1012): Starting up database as standby standbyinfra(asr1012): Changing the database role to primary standbyinfra(asr1012): Shutting down the new primary database standbyinfra(asr1012): Starting up the new primary database standbyinfra(asr1012): Failover Physical Standby Database - new primary database is started. standbyinfra(asr1012): Starting component OID standbyinfra(asr1012): Starting component dcm-daemon midtier(asmid2): Starting component dcm-daemon midtier(asmid1): Starting component dcm-daemon standbyinfra(asr1012): Verifying each instance in the farm midtier(asmid2): HA directory exists for instance asmid2.midtier.us.oracle.com. midtier(asmid1): HA directory exists for instance asmid1.midtier.us.oracle.com. standbyinfra(asr1012): HA directory exists for instance asr1012.infra.us.oracle.com. ASGCTL>
Displays help information.
Format
help [<command>]
Parameters
Name of the command for which you want help.
Usage Notes
None.
Example
The following example displays help about all dump farm commands.
ASGCTL> help
connect asg [<host>] [ias_admin/<password>]
disconnect
exit
quit
dump farm [to <file>]
help [<command>]
instantiate farm to <standby_farm_host>
set asg credentials <host> ias_admin/<password> [for farm]
set trace on|off <traceflags>
set primary database <username>/<password>@<servicename> [pfile <filename> | spfile <filename>]
set new primary database <username>/<password>@<servicename> [pfile <filename> | spfile <filename>]
sync farm to <standby_farm_host> [<sync_mode>]
startup farm
shutdown farm
show op[eration] [full] [[his]tory]
stop op[eration] <op#>
verify farm [with <host>]
switchover farm to <standby_farm_host>
failover
ASGCTL>
Instantiates a farm to a standby site by discovering the current farm definition at the production and standby sites, verifying that each complies with the OracleAS Disaster Recovery rules and restrictions of the current OracleAS software deployed on these systems prior to creation. Also synchronizes the standby site with the primary site such that the primary and standby sites are transactionally consistent.
Format
instantiate farm to <standby_farm_host>[:<port>]
Parameters
Name of the standby host system. This is the host system on which the OracleAS Infrastructure database is located. This parameter is required because it directs the coordinating OracleAS Guard server instance to discover the instances that make up the standby site. This host system must be a member of the standby farm.
The port number of the host system.
Usage Notes
You must always set the primary database before performing an instantiate, sync, or switchover operation.
For the Windows environment only: In a DR configuration that uses CFC on the primary farm or standby farm, or both, the following information must be considered before performing an asgctl instantiate farm to, switchover farm to, or failover command. Before taking a cold backup or restoring the metadata repository database, the Oracle Backup and Recovery Tool shuts down the database first. In the Windows CFC environment, Oracle Fail Safe performs database polling and restarts the database if it is down. Hence, every time before the administrator performs an instantiate, switchover, or failover operation, the administrator must disable database polling in Oracle Fail Safe and re-enable it after the backup/restore operation (after the instantiate, switchover, or failover operation completes). The steps to perform this sequence of operations are described in a note in Section 7.5.2, "Standby Instantiation".
The OracleAS Guard client must be connected to a OracleAS Guard server before using this command. This OracleAS Guard server will act as the coordinating server for all operations performed on the systems being configured. By default, this is the local system where the connect asg command is being executed. This local system must be a member of the production site farm.
The OracleAS Guard server must be started on the standby host system (<standby_farm_host>. The OracleAS Guard server can be stopped and started using opmnctl as follows:
On UNIX systems: <ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=DSA On Windows systems: <ORACLE_HOME>\opmn\bin\opmnctl stopproc ias-component=DSA
The production local system must be part of an ONS farm for the site.
The standby host must be part of an ONS farm for the standby site and must be symmetrical to the topology of the production farm.
Make sure OracleAS Infrastructure database is running on the primary farm before performing an instantiating farm operation. Also, the OracleAS Infrastructure database information must be set by using the set primary database asgctl command.
The global DNS names are used to direct the instantiation. This will be different than the HA naming utilized in the DR environment. The discovery mechanism automatically maps the topology to the corresponding peer based off local name resolution.
Example
The following example instantiates a standby farm by attaching the coordinating OracleAS Guard server and discovering the topology of the production and standby sites, and performing site verification, establishing a DR environment with the farm containing the standby farm host known by DNS as standbyinfra. Note that part way through the operation you will be prompted to answer a question regarding whether you want to shut down the database. Reply by entering y or yes.
ASGCTL> instantiate farm to standbyinfra prodinfra(asr1012): Instantiating each instance in the farm to standby farm prodinfra(asr1012): Verifying each instance in the farm midtier(asmid2): HA directory exists for instance asmid2.midtier.us.oracle.com. midtier(asmid1): HA directory exists for instance asmid1.midtier.us.oracle.com. prodinfra(asr1012): HA directory exists for instance asr1012.infra.us.oracle.com. . . . This operation requires the database to be shutdown. Do you want to continue? Yes or No y . . . standbyinfra(asr1012): Starting restore/synchronization of database "asdb.us.oracle.com". standbyinfra(asr1012): Shutting down the standby database. standbyinfra(asr1012): Starting the standby database. standbyinfra(asr1012): Synchronizing farm completed successfully. prodinfra(asr1012): Synchronizing farm completed successfully. ASGCTL>
Instructs the OracleAS Guard client to disconnect from any existing connections and exit from asgctl.
Format
quit
Parameters
Usage Notes
None.
Example
The following example exits from asgctl.
ASGCTL> quit >
Sets the credentials used to authenticate the OracleAS Guard connections to OracleAS Guard servers.
Format
set asg credentials <host>[:<port>] <username>/<password> [for farm]
Parameters
Name of the host system to which the credentials apply. When OracleAS Guard connects to that host, it will use these credentials.
The port number of the host system.
The user name must be the ias_admin account name and the password for the ias_admin account created during the Oracle Application Server installation. This account name must be the same as the account name on at least one of the Oracle Application Server homes.
A keyword, that if present in the command line, directs OracleAS Guard to set the credentials for all of the host systems that belong to the same farm as the local host system.
Usage Notes
By default, the credentials used in the asgctl connect command are used whenever a OracleAS Guard server needs to connect to another OracleAS Guard server. However, there may be cases where you want to use different credentials for a specific server. This command allows you to use the same credentials for all nodes in a farm. For example, you may want to use a common set of credentials in the standby farm that is different from the credentials used in the primary farm.
If you set the credentials for a farm, these credentials are inherited for the entire farm. If you set the credentials for an individual host on the farm, the credentials (for this host) override the default credentials set for the farm.
The OracleAS Guard client must be connected to a OracleAS Guard server before using this command.
An IP address can be used in place of a host name.
Example
The following example sets the OracleAS Guard credentials of host system standbyinfra to all host systems that belong to this farm.
ASGCTL> set asg credentials standbyinfra <username>/<password> for farm
Sets command-echoing on or off in a asgctl script.
Format
set echo on | off
Parameters
Specifying "on" turns on command-echoing in a asgctl script. Specifying "off" turns off command-echoing in a asgctl script.
Usage Notes
This command is useful when running large asgctl scripts. For example, if the asgctl script has error test cases with comments entered before each test case or before each asgctl command, setting echo on displays the comment before each test case or before each asgctl command that is run to give you an explanation of what the test case is or what asgctl command is about to be run.
This command also works with nested scripts.
Example
The following example is a asgctl script that turns on command-echoing, runs a test case, connects to a OracleAS Guard server, displays detailed information about the farm, then turns echo off, disconnects from the OracleAS Guard server, and exits from the OracleAS Guard client.
> ASGCTL @myasgctltestscript.txt # myasgctltestscript.txt # turn on echo set echo on # make sure you're not connected disconnect # not connected, should get an error message dump farm # connect to a DSA server connect asg prodinfra ias_admin/adminpwd #display detailed info about the farm dump farm #disconnect disconnect # turn off echo echo off exit
Identifies the OracleAS Infrastructure database on the standby farm as the new primary database preceding a failover operation. This command is only used as part of a failover operation.
Format
set new primary database <username>/<password>@<servicename> [pfile <filename> | spfile <filename>]
Parameters
User name and password for the database account with sysdba privileges.
The TNS service name of the OracleAS Infrastructure database. The name must be defined on the OracleAS Infrastructure host system; it does not need to be defined on the OracleAS Guard client host system.
The filename of the primary (OracleAS Infrastructure) database initialization file that will be used when the primary database is started.
The filename of the server (OracleAS Infrastructure) initialization file that will be used when the database is started.
Usage Notes
The OracleAS Guard client must be connected to a OracleAS Guard server before using this command.
Before performing a failover operation, you are required to connect to the Infrastructure node of the standby farm and define the new primary database. Once the Oracle Infrastructure database on the standby site is identified as the new primary database, then you can proceed to begin the failover operation.
Example
The following example sets the OracleAS Infrastructure database information for the standby farm as the new primary/production farm preceding a failover operation.
ASGCTL> connect asg standbyinfra ias_admin/adminpwd Successfully connected to standbyinfra:7890 ASGCTL> set new primary database sys/testpwd@asdb ASGCTL> failover . . . ASGCTL>
Identifies the OracleAS Infrastructure database on the primary farm.
Format
set primary database <username>/<password>@<servicename> [pfile <filename> | spfile <filename>]
Parameters
User name and password for the database account with sysdba privileges.
The TNS service name of the OracleAS Infrastructure database. The name must be defined on the OracleAS Infrastructure host system; it does not need to be defined on the OracleAS Guard client host system.
The filename of the primary (OracleAS Infrastructure) database initialization file that will be used when the primary database is started.
The filename of the server (OracleAS Infrastructure) initialization file that will be used when the database is started.
Usage Notes
The OracleAS Guard client must be connected to a OracleAS Guard server before using this command.
You must always set the primary database before performing an instantiate, sync, or switchover operation.
Example
The following example sets the OracleAS Infrastructure database information for the primary/production farm.
ASGCTL> set primary database sys/testpwd@asdb ASGCTL>
Sets a trace flag on or off to log output to the OracleAS Guard log files.
Format
set trace on | off <traceflags>
Parameters
Specifying "on" enables tracing. Specifying "off" disables tracing.
The traceflags to be enabled. Two or more specified traceflags entries must be separated by a comma (,). The traceflags are as follows:
DB -- trace information regarding processing in the Oracle Database environment
HOME -- trace information with regard to Oracle homes
IAS -- trace information regarding processing in Oracle Application Server
OPMN -- trace information regarding access to OracleAS OPMN calls
IP -- trace information regarding network access and address translation
Usage Notes
This command applies to all hosts that might be involved in a asgctl command during the lifetime of the connection.
The OracleAS Guard client must be connected to a OracleAS Guard server before using this command.
Example
The following example turns on trace for database operations.
ASGCTL> set trace on db
Shows all operations on all nodes of the farm to which the OracleAS Guard client is connected.
Format
show operation [full] [history]
Parameters
For all operations, shows the operation number, the job name, the job owner's users name, the job ID, the time the operation began, the time the operation ended, the elapsed time for the operation, as well as all tasks belonging to this job.
For only operations that are not running, shows the operation number and the job name.
Usage Notes
None.
Example
The following examples show the status of the current operation.
ASGCTL> show operation full
*************************************
OPERATION: 15
Status: running
Elapsed Time: 0 days, 0 hours, 1 minutes, 35 secs
TASK: instantiateFarm
TASK: verifyFarm
ASGCTL> show operation There are no operations in progress
The following example shows the history of all operations.
ASGCTL> show operation history
*************************************
OPERATION: 69
Status: success
Elapsed Time: 0 days, 0 hours, 0 minutes, 7 secs
TASK: getFarm
*************************************
OPERATION: 70
Status: success
Elapsed Time: 0 days, 0 hours, 6 minutes, 49 secs
TASK: syncFarm
TASK: backupFarm
TASK: fileCopyRemote
TASK: fileCopyRemote
TASK: fileCopyRemote
TASK: resolveHost
TASK: restoreFarm
TASK: fileCopyLocal
TASK: fileCopyLocal
TASK: fileCopyLocal
.
.
.
Shuts down a running farm.
Format
shutdown farm
Parameters
Usage Notes
This is a useful troubleshooting command to use when the farm is having a problem with one of its members and must be shut down. Use the startup farm command to start it up again.
Example
The following example shuts down the prodinfra production farm.
ASGCTL> connect asg prodinfra ias_admin/adminpwd Successfully connected to prodinfra:7890 ASGCTL> shutdown farm prodinfra(asr1012): Shutting down each instance in the farm prodinfra(asm21012): Shutting down component wireless prodinfra(asm1012): Shutting down component WebCache prodinfra(asm1012): Shutting down component OC4J prodinfra(asm21012): Shutting down component WebCache prodinfra(asm1012): Shutting down component dcm-daemon prodinfra(asm21012): Shutting down component OC4J prodinfra(asm1012): Shutting down component LogLoader prodinfra(asm1012): Shutting down component HTTP_Server prodinfra(asm21012): Shutting down component dcm-daemon prodinfra(asm21012): Shutting down component LogLoader prodinfra(asm21012): Shutting down component HTTP_Server prodinfra(asr1012): Shutting down component OID prodinfra(asr1012): Shutting down component OC4J prodinfra(asr1012): Shutting down component dcm-daemon prodinfra(asr1012): Shutting down component HTTP_Server ASGCTL>
Starts up a shutdown farm.
Format
startup farm
Parameters
Usage Notes
This is a useful troubleshooting command to use when the farm is having a problem with one of its members and must be shut down, then started up again.
Example
The following example starts up the production farm.
ASGCTL> startup farm prodinfra(asr1012): Starting each instance in the farm prodinfra(asr1012): Executing opmnctl startall command. prodinfra(asm1012): Executing opmnctl startall command. prodinfra(asm21012): Executing opmnctl startall command. ASGCTL>
Stops a specific operation that is running on the server.
Format
stop operation <op #>
Parameters
The number of the operation.
Usage Notes
The number of the operation that is running on the server can be determined from a show operation command.
Example
The following example first shows the running operation (15) on the server and then the stop operation command stops this operation.
ASGCTL> show operation
*************************************
OPERATION: 15
Status: running
Elapsed Time: 0 days, 0 hours, 1 minutes, 35 secs
TASK: instantiateFarm
TASK: verifyFarm
ASGCTL> stop operation 15
During a scheduled outage of the production site, performs the switchover operation from the production site to the standby site. The switchover operation to the standby site makes the application of the database redo logs synchronized to match the backup and restoration of the configuration files for the middle-tier and OracleAS Infrastructure installations.
Format
switchover farm to <standby_farm_host>[:<port>]
Parameters
Name of the standby host system. This is the host system on which the OracleAS Infrastructure database is located. This parameter is required because it directs the coordinating OracleAS Guard server instance to discover the instances that make up the standby site. This host system must be a member of the standby farm.
The port number of the standby host system.
Usage Notes
You must always set the primary database before performing an instantiate, sync, or switchover operation.
For the Windows environment only: In a DR configuration that uses CFC on the primary farm or standby farm, or both, the following information must be considered before performing an asgctl instantiate farm to, switchover farm to, or failover command. Before taking a cold backup or restoring the metadata repository database, the Oracle Backup and Recovery Tool shuts down the database first. In the Windows CFC environment, Oracle Fail Safe performs database polling and restarts the database if it is down. Hence, every time before the administrator performs an instantiate, switchover, or failover operation, the administrator must disable database polling in Oracle Fail Safe and re-enable it after the backup/restore operation (after the instantiate, switchover, or failover operation completes). The steps to perform this sequence of operations are described in a note in Section 7.6.1.1.1, "Site Switchover Operations".
For the Windows environment only: Before doing a switchover operation, the administrator must use the Windows Service Control Manager and shut down the OracleDBConsole service on the primary node.
On the primary infrastructure system, make sure the emagent process is stopped. Otherwise, you may run into the following error 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, to stop the emagent process, stop the Application Server Control, which is called iasconsole, as follows:
> <ORACLE_HOME>/bin/emctl stop iasconsole
On UNIX systems, to check to see if there is an emagent process running, do the following:
> ps -ef | grep emagent
On UNIX systems, if after performing the stop iasconsole operation, the emagent process is still running, get its process ID (PID) as determined from the previous ps command and stop it as follows:
> kill -9 <emagent-pid>
On Windows systems, open the Services control panel. Locate the OracleAS10gASControl service and stop this service.
The OracleAS Guard client must be connected to a OracleAS Guard server before using this command. This OracleAS Guard server will act as the coordinating server for all operations performed on the systems being configured. By default, this is the local system where the connect asg command is being executed. This local system must be a member of the production site farm.
The OracleAS Guard server must be started on the standby host system (<standby_farm_host>. The OracleAS Guard server can be stopped and started using opmnctl as follows:
On UNIX systems: <ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=DSA On Windows systems: <ORACLE_HOME>\opmn\bin\opmnctl stopproc ias-component=DSA
The production local system must be part of an ONS farm for the site.
The standby host must be part of an ONS farm for the standby site and must be symmetrical to the topology of the production farm.
Make sure OracleAS Infrastructure database is running on the primary farm before performing a switchover operation. Also, the OracleAS Infrastructure database information must be set by using the set primary database asgctl command.
The global DNS names are used to direct the switchover. This will be different than the HA naming utilized in the DR environment. The discovery mechanism automatically maps the topology to the corresponding peer based off local name resolution.
As part of the OracleAS Guard switchover operation, an implicit sync farm operation is performed to make sure the farms are identical. In addition OPMN automatically starts the OracleAS Guard server on the "new" standby Infrastructure node and this server will run indefinitely, and in turn, starts the OracleAS Guard server on the other nodes in the "new" standby farm and each of these is a transient server.
Example
The following example performs a switchover operation to a standby site known by DNS as standbyinfra.
ASGCTL> connect asg prodinfra ias_admin/adminpwd Successfully connected to prodinfra:7890 ASGCTL> set primary database sys/testpwd@asdb ASGCTL> switchover farm to standbyinfra prodinfra(asr1012): Switchover each instance in the farm to standby farm midtier(asmid2): Shutting down component HTTP_Server midtier(asmid1): Shutting down component HTTP_Server midtier(asmid2): Shutting down component OC4J midtier(asmid1): Shutting down component OC4J midtier(asmid2): Shutting down component dcm-daemon midtier(asmid1): Shutting down component WebCache midtier(asmid1): Shutting down component dcm-daemon midtier(asmid1): Shutting down component HTTP_Server midtier(asmid1): Shutting down component OC4J midtier(asmid1): Shutting down component dcm-daemon midtier(asmid1): Shutting down component LogLoader midtier(asmid2): Shutting down component HTTP_Server midtier(asmid2): Shutting down component OC4J midtier(asmid2): Shutting down component dcm-daemon midtier(asmid2): Shutting down component LogLoader midtier(asmid1): Shutting down component LogLoader midtier(asmid2): Shutting down component LogLoader prodinfra(asr1012): Shutting down component OID standbyinfra(asr1012): Shutting down component OID standbyinfra(asr1012): Shutting down component HTTP_Server standbyinfra(asr1012): Shutting down component OC4J standbyinfra(asr1012): Shutting down component dcm-daemon standbyinfra(asr1012): Shutting down component LogLoader prodinfra(asr1012): Shutting down component HTTP_Server prodinfra(asr1012): Shutting down component OC4J prodinfra(asr1012): Shutting down component dcm-daemon prodinfra(asr1012): Shutting down component LogLoader prodinfra(asr1012): Synchronizing farm. prodinfra(asr1012): Synchronizing each instance in the farm to standby farm prodinfra(asr1012): Starting backup of farm "IasFarm". prodinfra(asr1012): Loading farm information. prodinfra(asr1012): Backing up and copying data to the standby farm. prodinfra(asr1012): Backing up each instance in the farm. . . . standbyinfra(asr1012): Verifying each instance in the farm midtier(asmid1): HA directory exists for instance asmid1.midtier.us.oracle.com. midtier(asmid2): HA directory exists for instance asmid2.midtier.us.oracle.com. standbyinfra(asr1012): HA directory exists for instance asr1012.infra.us.oracle.com. midtier(asmid2): HA directory exists for instance asmid2.midtier.us.oracle.com. midtier(asmid1): HA directory exists for instance asmid1.midtier.us.oracle.com. prodinfra(asr1012): HA directory exists for instance asr1012.infra.us.oracle.com. standbyinfra(asr1012): Verifying farm IasFarm is symmetrical in both primary and standby configuration. standbyinfra(asr1012): Verifying instance asmid1.midtier.us.oracle.com is symmetrical in both primary and standby configuration. standbyinfra(asr1012): Host names are symmetrical for instance asmid.midtier.us.oracle.com. standbyinfra(asr1012): Home name and path are symmetrical for instance asmid.midtier.us.oracle.com. standbyinfra(asr1012): Verifying instance asmid2.midtier.us.oracle.com is symmetrical in both primary and standby configuration. standbyinfra(asr1012): Host names are symmetrical for instance asmid2.midtier.us.oracle.com. standbyinfra(asr1012): Home name and path are symmetrical for instance asmid2.midtier.us.oracle.com. standbyinfra(asr1012): Verifying instance asr1012.infra.us.oracle.com is symmetrical in both primary and standby configuration. standbyinfra(asr1012): Host names are symmetrical for instance asr1012.infra.us.oracle.com. standbyinfra(asr1012): Home name and path are symmetrical for instance asr1012.infra.us.oracle.com. ASGCTL>
Synchronizes the standby site with the primary site to ensure that the two sites are transactionally consistent.
Format
sync farm to <standby_farm_host>[:<port>] [<sync_mode>]
Parameters
Name of the standby site host system. This is the host system on which the OracleAS Infrastructure database is located.This parameter is required because it directs the coordinating OracleAS Guard server instance to discover the instances that make up the standby site. This host system must be a member of the standby farm.
The port number of the standby host system.
The sync mode can be either "full" or "incremental". The default is "incremental".
Usage Notes
The OracleAS Guard client must be connected to a OracleAS Guard server before using this command.
You must always set the primary database before performing an instantiate, sync, or switchover operation.
By default sync_mode is incremental and offers the best performance. However, there may be three circumstances when specifying a sync_mode of full should be used.
When you want to force a full synchronization to happen, such as synchronizing the standby site completely at a specific point in time (currently) 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 are a large accumulation of transactional changes over a long period of time on the primary site that must be synchronized with the secondary site.
Example
The following example synchronizes the specified standby site with the coordinating OracleAS Guard server (the primary site). By default the sync mode is incremental.
ASGCTL> sync farm to standbyinfra prodinfra(asr1012): Synchronizing each instance in the farm to standby farm prodinfra(asr1012): Starting backup of farm "IasFarm". prodinfra(asr1012): Loading farm information. prodinfra(asr1012): Backing up and copying data to the standby farm. prodinfra(asr1012): Backing up each instance in the farm prodinfra(asr1012): Starting backup of instance "asr1012.infra.us.oracle.com". prodinfra(asr1012): Executing config_nodb option in bkp_restore.pl script. midtier(asmid2): Starting backup of instance "asmid2.midtier.us.oracle.com". midtier(asmid2): Executing config_nodb option in bkp_restore.pl script. midtier(asmid1): Starting backup of instance "asmid1.midtier.us.oracle.com". midtier(asmid1): Executing config_nodb option in bkp_restore.pl script. prodinfra(asr1012): Executing backup_config option in bkp_restore.pl script. prodinfra(asr1012): Deleted directory "/private1/OraHome/dsa/backup". midtier(asmid2): Executing backup_config option in bkp_restore.pl script. midtier(asmid2): Deleted directory "/private1/OraHome2/dsa/backup". midtier(asmid1): Executing backup_config option in bkp_restore.pl script. midtier(asmid1): Deleted directory "/private1/OraHome/dsa/backup". . . . prodinfra(asr1012): Starting backup/synchronization of database "asdb.us.oracle.com". midtier(asmid2): Synchronizing farm completed successfully. midtier(asmid1): Synchronizing farm completed successfully. midtier(asmid1): Synchronizing farm completed successfully. midtier(asmid2): Synchronizing farm completed successfully. standbyinfra(asr1012): Starting restore/synchronization of database "asdb.us.oracle.com". standbyinfra(asr1012): Shutting down the standby database. standbyinfra(asr1012): Starting the standby database. standbyinfra(asr1012): Synchronizing farm completed successfully. ASGCTL>
Validates that the primary farm is running and the configuration is valid. If a standby farm is specified, compares the primary farm to which the local host system is a member with the standby farm to validate that they are consistent with one another and conform to the requirements for OracleAS Disaster Recovery.
Format
verify farm [with <host>[:<port>]]
Parameters
Name of the standby host system. This is the host system on which the OracleAS Infrastructure database is located.This parameter is required because it directs the coordinating OracleAS Guard server instance to discover the instances that make up the standby site. This host system must be a member of the standby farm.
The port number of the host system.
Usage Notes
The OracleAS Guard client must be connected to a OracleAS Guard server before using this command. This OracleAS Guard server will act as the coordinating server for all operations performed on the systems being verified. By default, the name is the local system where the connect asgctl command is being executed. The local host system must be a member of the production site farm.
If the host system name is not specified, the farm in which the local host system participates will be verified for local OracleAS Disaster Recovery rules.
If the standby host system name is specified, the farm at the standby site will be verified along with the production farm for both local rules and distributed OracleAS Disaster Recovery rules.
Example
The following example validates that the primary farm is running and the configuration is valid.
ASGCTL> connect asg ias_admin/iastest2 Successfully connected to prodinfra:7890 ASGCTL> verify farm prodinfra(asr1012): Verifying each instance in the farm midtier(asmid2): HA directory exists for instance asmid2.midtier.us.oracle.com. midtier(asmid1): HA directory exists for instance asmid1.midtier.us.oracle.com. prodinfra(asr1012): HA directory exists for instance asr1012.infra.us.oracle.com. ASGCTL>
The following example validates that the farm to which the local host system is a member is consistent with the standby farm to which the host system standbyinfra is a member.
ASGCTL> verify farm with standbyinfra prodinfra(asr1012): Verifying each instance in the farm midtier(asmid2): HA directory exists for instance asmid2.midtier.us.oracle.com. midtier(asmid1): HA directory exists for instance asmid1.midtier.us.oracle.com. prodinfra(asr1012): HA directory exists for instance asr1012.infra.us.oracle.com. midtier(asmid1): HA directory exists for instance asmid1.midtier.us.oracle.com. midtier(asmid2): HA directory exists for instance asmid2.midtier.us.oracle.com. standbyinfra(asr1012): HA directory exists for instance asr1012.infra.us.oracle.com. prodinfra(asr1012): Verifying farm IasFarm is symmetrical in both primary and standby configuration. prodinfra(asr1012): Verifying instance asmid2.midtier.us.oracle.com is symmetrical in both primary and standby configuration. prodinfra(asr1012): Host names are symmetrical for instance asmid2.midtier.us.oracle.com. prodinfra(asr1012): Home name and path are symmetrical for instance asmid2.midtier.us.oracle.com. prodinfra(asr1012): Verifying instance asmid1.midtier.us.oracle.com is symmetrical in both primary and standby configuration. prodinfra(asr1012): Host names are symmetrical for instance asmid1.midtier.us.oracle.com. prodinfra(asr1012): Home name and path are symmetrical for instance asmid1.midtier.us.oracle.com. prodinfra(asr1012): Verifying instance asr1012.infra.us.oracle.com is symmetrical in both primary and standby configuration. prodinfra(asr1012): Host names are symmetrical for instance asr1012.infra.us.oracle.com. prodinfra(asr1012): Home name and path are symmetrical for instance asr1012.infra.us.oracle.com. ASGCTL>
