| Oracle® Application Server Disaster Recovery Guide Using OracleAS Guard 10g Release 2 (10.1.2.3) Part Number E11078-02 |
|
|
View PDF |
| Oracle® Application Server Disaster Recovery Guide Using OracleAS Guard 10g Release 2 (10.1.2.3) Part Number E11078-02 |
|
|
View PDF |
This chapter describes how to use Oracle Application Server Guard and the asgctl command-line utility to perform OracleAS Disaster Recovery tasks. It includes the following sections:
Section 2.1, "Overview of Oracle Application Server Guard and asgctl"
Section 2.3, "Discovering, Dumping, and Verifying the Topology"
Section 2.4, "Dumping Policy Files and Using Policy Files With Some asgctl Commands"
Section 2.10, "Monitoring Oracle Application Server Guard Operations and Troubleshooting"
Section 2.11, "Using Oracle Application Server Guard Command-Line Utility (asgctl)"
This section provides an overview of Oracle Application Server Guard and its command-line interface asgctl. If you are already familiar with this overview information, go to Section 2.2, "Authentication of Databases". This section contains the following subsections:
Section 2.1.5, "Oracle Application Server Guard Integration with OPMN"
Section 2.1.6, "Supported OracleAS Disaster Recovery Configurations"
Section 2.1.7, "Configuring Oracle Application Server Guard and Other Relevant Information"
The asgctl command-line utility greatly simplifies the complexity and magnitude of the steps involved in setting up and managing OracleAS Disaster Recovery. This utility provides a distributed solution that consists of a client component and a server component. The client component (Oracle Application Server Guard client) can be installed on a system on the topology. The server component (Oracle Application Server Guard server) is installed by default on the systems hosting the primary and standby Oracle homes that comprise the OracleAS Disaster Recovery environment.
The Oracle Application Server Guard client is installed on every Oracle Application Server install type. The Oracle Application Server Guard client attempts to open and maintain a connection to the Oracle Application Server Guard server.
The Oracle Application Server Guard client provides an asgctl command-line interface (CLI) (see Chapter 5, "Oracle Application Server Guard asgctl Command-line Reference") consisting of a set of commands to perform administrative tasks described in Section 2.1.4, "asgctl Operations".
The Oracle Application Server Guard server is a distributed server (installed by default) that runs on all the systems in an OracleAS Disaster Recovery configuration. The Oracle Application Server Guard client maintains an active connection to the Oracle Application Server Guard server on one system that has network connectivity in the OracleAS Disaster Recovery configuration. This coordinating server communicates to the Oracle Application Server Guard servers on the other systems in the OracleAS Disaster Recovery configuration as necessary to complete processing during standby site cloning, instantiation, synchronization, verification, switchover, and failover operations. The Oracle Application Server Guard server carries out asgctl commands issued directly by the Oracle Application Server Guard client or issued on behalf of the Oracle Application Server Guard client by another Oracle Application Server Guard server in the network for the client session. The steps to complete an operation will execute throughout all systems in both the production and standby topologies. Most operational steps will be executed either in parallel or sequentially (as required) on these systems throughout the OracleAS Disaster Recovery configuration by the Oracle Application Server Guard server.
Major asgctl operations using the asgctl commands belong in the following categories of operations:
Authentication -- Identifies the OracleAS Infrastructure database on the primary topology (set primary database command). If there are topologies with multiple Infrastructures, each must be identified using this command prior to performing an operation involving both production and standby topologies. Use the connect asg command first to connect to an ASG server, then issue the set primary database command multiple times until you identify each Infrastructure database.
Use the connect asg command first to connect to an ASG server and then identify the new OracleAS Infrastructure database on the standby topology using the set new primary database command before performing a failover operation.
Sets the credentials (set asg credentials command) used to authenticate the Oracle Application Server Guard client connections to Oracle Application Server Guard servers and the connections between Oracle Application Server Guard servers to a specific host. See the set asg credentials command for an example, and see Section 4.1.1.1, "Setting asgctl Credentials" for more information.
When Oracle Application Server Guard discovers the topology (discover topology command), it requires that you provide Oracle Internet Directory authentication credentials (Oracle Internet Directory password) in order to query Oracle Internet Directory to obtain instance information for the production site.
Discover the topology -- Discovers (discover topology command) by querying Oracle Internet Directory all instances within the topology that share the same Oracle Internet Directory for a production site and generates a topology XML file (topology.xml) that describes the topology and replicates this file to all instances in the topology. See Section 2.3, "Discovering, Dumping, and Verifying the Topology" for more information.
The command discover topology within farm discovers the topology using OPMN at a production site for special cases where Oracle Internet Directory is not available, such as in an Oracle Application Server 10.1.3 OPMN topology.
Adding or removing an instance from the local topology file -- pulls an instance into or drops an instance from an existing local topology file. This is particularly useful in an Oracle Application Server 10.1.3 only topology, where an Oracle Application Server Guard client can connect to an existing Oracle Application Server 10.1.3 instance, and either perform an add instance command that adds the specified Oracle Application Server 10.1.3 instance to the topology file, or performs a remove instance command that removes the specified Oracle Application Server 10.1.3 instance from the local topology file, and in either case, if specified (by using the to topology parameter for the add instance command or the from topology parameter for the remove instance command), propagates the updated topology file to all instances in the Disaster Recovery production environment. Any Oracle Application Server Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby environment.
This command is also useful for adding an Oracle Application Server 10.1.3 J2EE instance to an Oracle Internet Directory (OID) based 10.1.2.0.2 local topology file to support a mixed version Disaster Recovery environment. For example, you can use the add instance command to add an Oracle Application Server 10.1.3 J2EE instance to your OID based 10.1.2.0.2 local topology file. See Section 2.6, "Adding or Removing Oracle Application Server 10.1.3 Instances to Redundant Single Oracle Application Server 10.1.3 Home J2EE Topology Integrated with an Existing Oracle Identity Management 10.1.4.2 Topology" for a use case.
Standby site cloning -- Copies a single Application Server instance on a production site host to a standby site host (clone instance command) or copies two or more Application Server instances on production site hosts to standby site hosts (clone topology command). See Section 2.7, "Oracle Application Server Guard Operations -- Standby Site Cloning of One or More Production Instances to a Standby System" for more information. The standby site cloning commands provide an alternative to installing Application Server instances on standby site hosts using Oracle Universal Installer.
Standby site instantiation -- Creates the disaster recovery environment. It establishes the relationship between standby and production instances, mirrors the configuration, then synchronizes the standby site with the primary site (instantiate topology command). See Section 2.8.1, "Standby Instantiation" for more information.
Standby site synchronization -- Applies database redo logs for OracleAS Infrastructures to the standby site in conjunction with synchronizing external configuration files across the topology (sync topology command). See Section 2.8.2, "Standby Synchronization" for more information.
Switchover -- Switches from the production site to the standby site after the standby site is synchronized with the production site with the application of the database redo logs (switchover topology command). See Section 2.9.1.1, "Scheduled Outages" for more information.
Failover -- Makes the standby site the production site after restoring configuration files and restoring the Oracle Application Server server environment to the point of the last successful sync operation (failover command). See Section 2.9.1.2, "Unplanned Outages" for more information.
Verification -- Validates that the primary topology is running and the configuration is valid (verify topology command) or if a standby topology is specified, compares the primary topology to which the local host system is a member with the standby topology to validate that they are consistent with one another and conform to the requirements for OracleAS Disaster Recovery. See Section 2.10.1, "Verifying the Topology" for more information.
Using a policy file -- Used as a filter to filter out unnecessary instances for supporting asymmetric topologies. The dump policies command writes detailed, default policy information to respective XML formatted files for a select set of asgctl commands. You can then edit each respective XML policy file and use it in the using policy <file> parameter with any one of these select set of asgctl commands: dump topology, verify topology, clone topology, failover, instantiate topology, switchover topology, and sync topology to define by instance the domain of execution operations that are permitted for each of these asgctl commands. Each instance list entry in an XML policy file logically tags a production-standby peer combination with a particular attribute that defines the success requirement for its successful operation. For example, you may want to omit a node in a symmetric topology while performing one of the operations previously mentioned. Use the policy file to specify the node to be ignored. See Section 2.4, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.
Instance management -- Enables you to shut down (shutdown topology command) and start up the topology (startup topology command).
Troubleshooting -- Uses the dump topology command to write detailed information about the topology to the screen or to a file. Lets you determine the current operations that are running (show operation command) and stop any operations that must be halted (stop operation command). Uses the set trace command to log output about operations to the Oracle Application Server Guard log files.
Table 2-1 describes the OracleAS Disaster Recovery production and standby site environment before and after performing an asgctl clone, instantiate, sync, failover, and switchover operation.
Table 2-1 Description of Disaster Recovery Production and Standby Environments Before and After Performing These Oracle Application Server Guard Operations
| OracleAS Guard Operation | Disaster Recovery Site Environment Before Operation | Disaster Recovery Site Environment After Operation |
|---|---|---|
|
clone |
The production site has one or more instances that must be installed on the standby site and instantiated. The cloning operations perform this task. |
The standby site has one or more new standby instances that are a logical mirror of the production site instances. |
|
instantiate |
The standby site with its Oracle homes exists, but the OracleAS Disaster Recovery relationship across sites does not exist yet for an OracleAS Disaster Recovery operation to be performed. |
A logical mirror of the production site is set up and maintained at the standby site. |
|
sync |
The standby site is not consistent with the production site. OracleAS Disaster Recovery is not able to restore the standby site to a consistent point in time without some manual intervention. |
Database redo logs are applied to OracleAS Infrastructures in combination with synchronizing external configuration files across the topology. The sync operation is performed in the event that a failover or switchover operation is necessary, then the standby site can be restored to a consistent point in time. No manual intervention is necessary to synchronize the sites after the asgctl sync operation is performed. |
|
switchover |
A planned outage at the production site will make the standby site the production site for a period of time; that is, the roles of each site will be switched. |
The standby site has become the production site. All OPMN services are started. The production site may become available again after the planned outage, at which time, another switchover operation could be performed to return activity back to the original production site from the standby site. |
|
failover |
An unscheduled outage at the production site has left the production site down or unavailable for an unknown period of time. The production site is lost due to some unforeseen circumstance. |
The standby site has permanently become the production site. Configuration and Infrastructure data are restored to a consistent point in time on the standby site. Site services are brought up in a consistent fashion to the point of the last sync operation. All OPMN services are started. |
Figure 2-1 shows a summary of the main OracleAS Disaster Recovery operations and the command sequences used to perform these operations. For example, to get started with a new Disaster Recovery environment once it is set up and operational, you must always create a topology file on the production site. To do that, you perform a connect asg command to connect the Oracle Application Server Guard client to the Oracle Application Server Guard server followed by identifying the production Infrastructure database using a set primary database command, then perform the discover topology command, finally followed by a disconnect command to disconnect the Oracle Application Server client from the Oracle Application Server server. In essence, to perform any OracleAS Disaster Recovery operation using asgctl commands, you must always connect the Oracle Application Server Guard client to the Oracle Application Server Guard server, identify the location of the Infrastructure database, then perform the OracleAS Disaster Recovery operation or operations of interest, and finally disconnect the Oracle Application Server client from the Oracle Application Server server. The only exception to this general sequence is for a failover operation, in which the production site is permanently unavailable due to some unplanned problem. In this case, you connect the Oracle Application Server Guard client to Oracle Application Server Guard server at the standby site, use the set new primary database command to identify the standby site Infrastructure as the new Infrastructure database, then perform the failover operation. Because there is no topology file created on the standby site following a failover operation, you must then perform a discover topology command to create it for the first time. Then you can disconnect the Oracle Application Server Guard client from Oracle Application Server Guard server.
The asgctl command sequences shown in Figure 2-1 assume the simplest topology configuration. For example, in a more complex case, if your production or standby site has multiple Metadata Repository instances installed, you must identify each instance with a set primary database command prior to performing the main Disaster Recovery operation, such as an instantiate, sync, or switchover operation. Similarly, Oracle Application Server Guard requires that you set the credentials for any Oracle Application Server Guard server system in the topology that has different credentials from the Oracle Application Server Guard server to which you are connected before you perform any of these main operations, such as instantiate, sync, or switchover. So for both of these cases, additional asgctl commands are required in the command sequence before you can perform the main Disaster Recovery operation. See the usage notes for the set asg credentials command for more information.
Figure 2-1 Main Disaster Recovery Operations Performed Using the Following Oracle Application Server Guard asgctl Command Sequences
A typical Oracle Application Server site has multiple farms. Oracle Application Server Guard server and its ias-component ASG process (or ias-component DSA process) is not started by default by OPMN because it is only necessary in the context of disaster recovery sites. You must start this ias-component ASG or ias-component DSA process in all Oracle homes as described later in this section. To check the status of this component and determine if the component is running, run the following opmnctl command on each system in your topology:
On UNIX systems > <ORACLE HOME>/opmn/bin/opmnctl status On Windows systems > <ORACLE HOME>\opmn\bin\opmnctl status
Because there is no way an Oracle Application Server Guard client nor OPMN on the production site can start Oracle Application Server Guard services on the standby site, Oracle Application Server Guard must be started directly using opmnctl on the Infrastructure node in the standby topology. Connect to a node and run the appropriate OPMN command for your release on UNIX systems:
For 10.1.2.x and 10.1.4.x releases, this command starts OracleAS Guard on UNIX: > <ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=DSA For 10.1.3.x releases, this command starts OracleAS Guard on UNIX: > <ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=ASG
On Windows systems, issue the appropriate OPMN command for your release to start Oracle Application Server Guard if your Oracle home is located on drive C:.
For 10.1.2.x and 10.1.4.x releases, this command starts OracleAS Guard on Windows: C:\<ORACLE HOME>\opmn\bin\opmnctl startproc ias-component=DSA For 10.1.3.x releases, this command starts OracleAS Guard on Windows: C:\<ORACLE HOME>\opmn\bin\opmnctl startproc ias-component=ASG
After the Oracle Application Server Guard server is started it is non transient, while the remaining Oracle Application Server Guard servers in the standby topology are transient servers. This configuration allows cross-topology communication.
Note:
When you perform an opmnctl status command on a system on which Oracle Application Server Guard is running, you will see an ias-component and process-type named DSA for 10.1.2.x and 10.1.4.x releases (for 10.1.3.x releases, the ias-component and process-type is named ASG). This is the Oracle Application Server component name and server process name for the Oracle Application Server Guard server.For Oracle Application Server 10g release (10.1.2), Oracle Application Server Guard supports not only the default OracleAS Infrastructure configuration supported on Oracle Application Server Cold Failover Clusters and single instance, but also the topologies described in Section 1.1.3, "Supported Topologies."
By default, Oracle Application Server Guard and asgctl, the command-line utility for Oracle Application Server Guard, are installed for every Application Server installation type that installs a JDK or JRE environment. For any Application Server installation type that does not install a JDK or JRE environment, install the standalone Oracle Application Server Guard kit into the Application Server home. The Oracle Application Server Guard standalone kit is downloadable from Oracle Technology Network at:
http://www.oracle.com/technology/index.html
Oracle Application Server Guard and asgctl are installed with the following default configuration information:
The following Oracle Application Server Guard parameters are configurable in the dsa.conf file (for 10.1.2.x and 10.1.4.x releases) or asg.conf file (for 10.1.3.x releases). The value is described and the default value is indicated. The Oracle Application Server Guard readme.txt file in the <ORACLE_HOME>\dsa\doc directory also lists these Oracle Application Server Guard parameters that are configurable.
port - the TCP/IP port for Oracle Application Server Guard server and client. Oracle Application Server Guard uses a default port (port) number of 7890; for example, port=7890. If there is a second Oracle home installed on a system, this second Oracle home must have a different Oracle Application Server Guard port number, usually incremented by one, for example, port=7891, and so on.
Value: integer, any valid TCP/IP port number. Default is 7890.
Use the same port numbers for ASG on primary site and standby site(s) Oracle homes in Disaster Recovery configurations to prevent cloning problems.
exec_timeout_secs - timeout value for executing operating system command.
Value: integer, number of seconds. Default is 60 seconds.
trace_flags - trace flags to be turned on.
Value: string list, separated by ",". Default is none.
backup_mode - indicates whether to perform a full or incremental backup.
Value: string, "full" or "incremental". Default is "incremental".
backup_path - the backup directory path to be used by Oracle Application Server Guard server.
Value: string, a directory path. Default is <ORACLE_HOME>/dsa/backup.
ha_path - the High Availability directory path where the backup scripts are located.
Value: string, a directory path. Default is <ORACLE_HOME>/backup_restore.
port.<host> - the TCP/IP port for a given host.
Value: integer, any valid TCP/IP port number.
Note:
If the port number must be changed for some reason (it must be unique for each Oracle Application Server Guard server in each Oracle home on a system, which is automatically handled during installation), you can change its value in the
<ORACLE_HOME>/dsa/dsa.conf file (for 10.1.2.x and 10.1.4.x releases) or <ORACLE_HOME>/dsa/asg.conf file (for 10.1.3.x releases). Then, stop the Oracle Application Server Guard server (using <ORACLE_HOME>/opmn/bin/opmnctl stopproc ias-component=DSA for 10.1.2.x and 10.1.4.x releases and <ORACLE_HOME>/opmn/bin/opmnctl stopproc ias-component=ASG) for 10.1.3.x releases) and start the Oracle Application Server Guard server (using <ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=DSA for 10.1.2.x and 10.1.4.x releases and <ORACLE_HOME>/opmn/bin/opmnctl startproc ias-component=ASG for 10.1.3.x releases) to activate the change. See Section 2.1.5, "Oracle Application Server Guard Integration with OPMN") for more information.
Within a topology, if the port number must be changed, use the asgctl shutdown command to stop the Oracle Application Server Guard server and then use the asgctl start command to start the Oracle Application Server Guard server. These shutdown and start operations must be performed in each Oracle home that is part of the Oracle Application Server Guard topology.
clone_unpack_cmd - specifies the tar command for Application Server Guard to use when unpacking the jar file created during a clone instance or clone topology operation.
Value: string, tar command to use when unpacking a jar file created during a cloning operation. For example:
clone_unpack_cmd = tar -c /xpf
copyfile_buffersize - the buffer size for copy file operation, in kilobytes.
Value: integer, maximum buffer size is 500K.
server_inactive_timeout - the number of seconds server will wait before shutting down due to inactivity.
Value: integer, number of seconds. Default value is 600 seconds (10 minutes).
inventory_location - the alternative Oracle Inventory location
Value: string, the full path of the location of oraInst.loc file.
_realm_override - overrides the dsa realm. This is an Oracle internal parameter that is valid only for Application Server Guard releases 10.1.2.2 and later. The realm_override parameter is set by default by the installer for the Application Server Guard 10.1.2.x releases. It is not set for Application Server Guard 10.1.3.x releases.
Value: integer, 1=override, 0=no override
dufhosts_location - specifies the location of a file to use for resolving hostnames instead of using the normal hostname resolution described in Section 1.2, "Preparing the OracleAS Disaster Recovery Environment." This parameter is available only in Application Server release 10.1.2.3.
Value: string, full path to the file to use for resolving hostnames. For example:
dufhosts_location = <ORACLE_HOME>/dsa/conf/dufhosts.txt
You can create a file named dufhosts.txt in the default location, which is the <ORACLE_HOME>/dsa/conf directory for Application Server Guard. The entries in this file use the same syntax as /etc/hosts files. If you create this file with the name dufhosts.txt in the default location, then it will be used for hostname resolution even if you do not use the dufhosts_location parameter in the dsa.conf file.
You can also use a different name or location for the file. In this case, you must use the dufhosts_location parameter in the dsa.conf file to specify the path to the file in order for the file to be used for hostname resolution.
The Oracle Application Server 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.
See the Oracle Application Server Guard readme.txt file in the <ORACLE_HOME>\dsa\doc directory for more information about Oracle Application Server Guard parameters that are configurable.
Oracle Application Server Guard starts up the Oracle Application Server component services across the production topology.
The Oracle Application Server Guard operation status information for a topology (from either an asgctl show operation full or show operation history command) remains available for the life of the current Oracle Application Server Guard client asgctl connect session only. When the Oracle Application Server Guard client disconnects from the Oracle Application Server Guard server, this topology's operation history information becomes unavailable.
After you start an asgctl operation, you cannot run another asgctl command on the same Oracle Application Server 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 the background and then quit or exit the asgctl utility.
When you are running Oracle Application Server Guard in an Oracle RAC environment, be sure to have only one Oracle RAC instance running while performing Oracle Application Server Guard operations.
Several levels of authentication are required when an Oracle Application Server Guard client connects to an Oracle Application Server Guard server and begins a session to perform administrative operations within the production topology or across both production and standby topologies:
Infrastructure authentication
Oracle Application Server Guard client authentication to Oracle Application Server Guard servers
Oracle Internet Directory authentication
Infrastructure Authentication
When initiating an Oracle Application Server Guard administrative session, after establishing the connection between the Oracle Application Server Guard client and Oracle Application Server Guard server, you must identify all the OracleAS Infrastructure databases on the primary topology using the set primary database command. Infrastructure authentication must be performed before you initiate any operation that involves either the production topology or both the production and standby topologies. Use the connect asg command first to connect to an ASG server, then issue the set primary database command multiple times until you identify each Infrastructure database.
Another form of Infrastructure authentication occurs as part of a failover operation. In this scenario, the production site is down and you must failover to the standby site and make this site the new production site. Use the connect asg command first to connect to an ASG server and then identify the new OracleAS Infrastructure database on the standby topology using the set new primary database command before performing the failover operation. See Section 2.9.1.2, "Unplanned Outages" for more information.
Oracle Application Server Guard Client Authentication to Oracle Application Server Guard Servers
By default, these are the same authentication credentials used for instance level authentication with the Oracle Application Server account (ias_admin/password) that was created during the Oracle Application Server installation and used in the connect asg command.
Note:
If this is an Oracle Application Server 10.1.3 installation, the user name must beoc4jadmin and the password for the oc4jadmin account created during the Oracle Application Server 10.1.3 installation.These same credentials are used when the Oracle Application Server Guard client connects to any Oracle Application Server Guard server in the production and standby topology when executing administrative operations.
There may be cases where you want to use different credentials for a specific Oracle Application Server Guard server or set a common set of credentials in the standby topology that differs from the credentials used in the primary topology. To set credentials for an Oracle Application Server Guard server, use the set asg credentials command and one or more of its parameter options by either specifying the host name to which the credentials apply or the topology along with the new set of credentials (username/password).
If you set the credentials for a topology, these credentials are inherited for the entire topology. If you set the credentials for an individual host on the topology, the credentials for this host override the default credentials set for the topology. After you set the credentials so that they are different from the default connection credentials for a host system or an entire topology, whenever you initiate an Oracle Application Server Guard administrative session, you must specify all credentials that are different from the default connection credentials for any host system or topology before you perform an operation involving all the Oracle Application Server Guard servers within a production topology or across both production and standby topologies. Otherwise, the operation will fail with an authentication error. See the connect asg command for an example.
Oracle Internet Directory Authentication
The discover topology command requires you provide Oracle Internet Directory authentication credentials (Oracle Internet Directory password) in order to query Oracle Internet Directory to obtain instance information for the production site. See the section that follows for more information and the discover topology command.
The discover topology command discovers by querying Oracle Internet Directory all instances within the topology that share the same Oracle Internet Directory for a production site. A topology XML file is created and distributed to all Oracle homes within the topology that describes all instances for the topology. This topology file is used by all Oracle Application Server Guard operations.
You must perform a discover topology command when you first set up your OracleAS Disaster Recovery environment in order to initially create the topology XML file. Thereafter, you should perform a discover topology command whenever you procure another Oracle home in a production site or change roles from a production to a standby site through a switchover or failover operation. See the discover topology command for more information.
You should perform a dump topology command to inspect the information that describes your topology. See the dump topology command for more information. See Section 5.2, "Information Specific to a Small Set of Oracle Application Server Guard Commands" for more information about topology files.
You should perform a verify topology command to validate that the primary topology is running and that the configuration is valid. In addition, if you specify the with host parameter, the verify operation compares the primary topology of which the local host system is a member with the standby topology to validate that they are consistent with one another and conform to the requirements for OracleAS Disaster Recovery. See Section 2.10.1, "Verifying the Topology" and the verify topology command for more information.
With both the dump topology and verify topology commands, if you want to use a policy file, edit and use the respective dump and verify policy files (dump_policy.xml and verify_policy.xml). Specify this file in the using policy <file> parameter of each command to dump or verify only those instances specified accordingly. See Section 2.4, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.
OracleAS Disaster Recovery provides support for a variety of Application Server topologies as described in Section 1.1.3, "Supported Topologies." As part of this support, a set of XML formatted policy files are maintained, local to the Oracle Application Server Guard client that performs the dump policies command, to record by instance the domain of execution operations that are permitted for each of the following asgctl commands: dump topology, verify topology, clone topology, failover, instantiate topology, switchover topology, and sync topology.
To understand the default policies in use for any these asgctl commands, enter the following command at the asgctl prompt:
ASGCTL> dump policies Generating default policy for this operation Creating policy files on local host in directory "/private1/OraHome2/asr1012/dsa/conf/" ASGCTL>
Each instance list entry in each of the XML policy files logically tags by default a production-standby peer combination with a particular attribute that defines the success requirement for the successful operation of each command. This approach provides greater flexibility in regulating how each of these Oracle Application Server Guard operations are to be successfully used among the supported topologies. See Section 1.1.3, "Supported Topologies" for more information.
After inspecting each of the XML formatted policy files, you can edit a policy file and then use the using policy <file> parameter with a particular asgctl command to use that policy fiile with the command. In this way, you can employ a particular Disaster Recovery policy that defines the success requirement attribute value by instance for each of these Oracle Application Server Guard operations mentioned earlier in this chapter.
Note:
If you want to maintain a set of custom policy files, you must copy, edit, and maintain them in a location other than the default location; otherwise, your custom set of policy files will be overwritten whenever you perform adiscover topology command followed subsequently by a dump policies command.The success requirement attribute value can be one of the following: [optional | mandatory | ignore | group <MinSucceeded=<number>>], where:
Optional -- means if there is a failure for that instance continue processing other instances.
Mandatory -- means if an error occurs for this instance, the entire operation fails.
Ignore -- means the instance is not part of the operation.
Group <MinSucceeded=<number> -- means to combine groups of Oracle instances, and if the specified number of group members is successful, then the operation is successful; otherwise, if less than the number of group members that is specified is successful, the operation fails.
Each attribute value determines the success requirement for that peer group and will be referenced during failure cases of asgctl operations to determine whether or not to continue with the Oracle Application Server Guard operation. For example, when the success requirement is specified as mandatory, the particular Oracle Application Server Guard operation must be successful for the specified instance for that production-standby peer combination; otherwise, the Oracle Application Server Guard operation ceases, execution is rolled back to its starting point of execution, and an error message is returned.
For example, the following XML policy file in use for an asymmetric topology for the failover operation specifies that this asgctl operation is mandatory for the infra instance, optional for the portal_1 and portal_2 instances, can be ignored for the portal_3 instance, and must be successful for a minimum of any two of the group of three instances, BI_1, BI_2, and BI_3.
<policy>
<instanceList successRequirement="Mandatory">
<instance>infra</instance>
</instanceList >
<instanceList successRequirement="Optional">
<instance>portal_1</instance>
<instance>portal_2</instance>
</instanceList >
<instanceList successRequirement="Ignore">
<instance>portal_3</instance>
</instanceList >
<instanceList successRequirement="Group" minSucceed="2">
<instance>BI_1</instance>
<instance>BI_2</instance>
<instance>BI_3</instance>
</instanceList >
</policy>
As described in Section 1.1.3.5, "Redundant Multiple Oracle Application Server 10.1.3 Homes J2EE Topology," you can discover Oracle Application Server 10.1.3 instance changes in a redundant multiple Oracle Application Server 10.1.3 Homes J2EE topology. In a typical scenario, Oracle Application Server 10.1.3 J2EE is installed on a node with an OC4J instance and you want to add this node and instance to the existing redundant multiple Oracle Application Server 10.1.3 Homes J2EE topology. The following steps take you through a typical scenario:
Connect to the Oracle Application Server Guard server.
For 10.1.2.x and 10.1.4.x releases: ASGCTL> connect asg prodinfra ias_admin/<adminpwd> Successfully connected to prodinfra:7890 ASGCTL> For 10.1.3.x releases: ASGCTL> connect asg prodinfra oc4jadmin/<adminpwd> Successfully connected to prodinfra:7890 ASGCTL>
Assume a Disaster Recovery Administrator has installed OracleAS 10.1.3 J2EE on a new node with an OC4J instance. Through dynamic node discovery, the cluster manages itself and automatically updates the information in each OPMN configuration file, opmn.xml on each node within the cluster.
Next, perform a discover topology within farm command. This operation determines all instances within the Oracle Application Server 10.1.3 cluster for this production site, generates the Disaster Recovery topology XML file that describes the production topology, and then propagates this topology XML file to all instances in the Disaster Recovery production environment. Note that any Oracle Application Server Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby environment.
ASGCTL> discover topology within farm
Now, having recently installed another oc4j instance named oc4j3 on the existing midtier host system named prodmid2, add to the local topology file an instance named oc4j3 specifying the host system named prodmid2. To propagate this updated local topology file to all instances in the Disaster Recovery production environment for this Oracle Application Server 10.1.3 cluster, specify the to topology keyword. Note that any Oracle Application Server Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby topology.
ASGCTL> add instance oc4j3 on prodmid2.oracle.com to topology
As described in Section 1.1.3.6, "Redundant Single Oracle Application Server 10.1.3 Oracle Home J2EE Topology Integrated with an Existing Oracle Identity Management 10.1.4.2 Topology," you can add or remove Oracle Application Server 10.1.3 single home J2EE instances to or from an existing Oracle Interenet Directory (OID) 10.1.4.2 topology, thus creating or modifying a mixed version Disaster Recovery environment. The following steps take you through a typical scenario:
Connect to the Oracle Application Server Guard server.
ASGCTL > connect asg prodinfra ias_admin/<adminpwd> Successfully connected to prodinfra:7890 ASGCTL>
Assume that a discover topology command was performed when you first set up the Disaster Recovery environment on the existing OID 10.1.4.2 topology, thus creating a topology XML file that was propagated to all instances in the Disaster Recovery environment. Also assume that no other changes have been made to the topology, so the topology XML files are current or up-to-date.
Assume that you have completed Oracle Application Server 10.1.3 installations using the Integrated Web server, J2EE Server, and OPMN installation option in a single Oracle home on four individual systems. This creates the redundant single Oracle home J2EE topology. Assume that the OracleAS Disaster Recovery solution is configured for each new node. Now you want to add the Oracle Application Server 10.1.3 instances named OC4J1 and OC4J2 to the existing OID 10.1.4.2 topology. To do this, perform the following asgctl commands:
ASGCTL> add instance oc4j1 on prodinfra.oracle.com to topology ASGCTL> add instance oc4j2 on prodinfra.oracle.com to topology
Performing each add instance command updates the local topology file on the Oracle Application Server Guard server to which the Oracle Application Server Guard client is connected. To propagate the updated topology file to all instances in the Disaster Recovery production environment, specify the to topology key word. This operation then results in a redundant single Oracle Application Server 10.1.3 Oracle home J2EE topology with instances oc4j1 and oc4j2 being integrated with an existing OID 10.1.4.2 production topology. Note that any Oracle Application Server Guard operation that affects the standby site, such as verify, instantiate, sync, switchover, and failover will automatically propagate the production topology file across the standby topology.
Standby site cloning is the process of copying a single Oracle Application Server instance at a production site host to a standby site peer host (using the clone instance command) or copying two or more Oracle Application Server instances at production site hosts to standby site peer hosts (using the clone topology command).
One of the underlying technologies used by Oracle Application Server Guard to perform a cloning operation is the OracleAS Recovery Manager's backup and restore loss of host capability. See the section on recovering a loss of host automatically in Oracle Application Server Administrator's Guide for more information, including a list of prerequisites.
Note:
When you use aclone instance or clone topology command, the target host or hosts at the standby site should have only the Oracle Application Server Guard standalone kit installed in the Oracle Application Server Guard home. This software is required to copy the Oracle Application Server homes to the standby site hosts.
No other Oracle software should be installed on the standby site target host or hosts for the cloning operation. The reason for this is that during the clone operation, the entire Oracle Universal Installer Central Inventory for each production site host involved in the clone operation is copied to the standby site peer host during the clone operation, which means that the Central Inventory from each production site host involved in the clone operation overwrites the Central Inventory on the standby site peer host.
Some of the underlying operations require elevated privileges, root for the UNIX environments and Administrator for Windows. On Windows, the user must ensure that the Oracle Application Server Guard client and server are started with Administrator privileges.
Clone Instance
The clone instance command is used to create a new Oracle Application Server instance at a standby site host from an existing Oracle Application Server instance at a production site host.
There are two phases of clone. The first phase is to create the Oracle home and register it within the system environment. The second phase is to perform the Oracle Application Server Guard instantiate operation to link it into the OracleAS Disaster Recovery environment and logically match the Oracle home with its corresponding production home.
A series of clone instance commands for different instances is equivalent to a clone topology operation.
Read the clone instance reference information before using the clone instance command.
Clone Topology
The clone topology command performs a clone instance operation across a group of hosts. By default, the clone topology command copies all of the Oracle Application Server homes on all of the production site hosts to the standby site peer hosts. However, you can use a policy file with a clone topology command, which allows the clone operation to copy only a subset of the Oracle Application Server homes at the production site hosts to the standby site peer hosts.
There are two methodologies that you must be aware of when planning for an OracleAS Disaster Recovery site setup:
Creating a pure OracleAS Disaster Recovery site
Adding Oracle Application Server homes to an existing site with OracleAS Disaster Recovery enabled
Each operation requires a different methodology to integrate the newly installed Oracle homes into the existing site or combine them into a standby site for a production site.
Read the clone topology reference information before using the clone topology command.
Creating a Pure OracleAS Disaster Recovery Site
Prior to Oracle Application Server 10g release 10.1.2.0.2, this was the only type of site Oracle Application Server Guard could support. An OracleAS Disaster Recovery configuration was supported only for the default OracleAS Infrastructure and OracleAS middle-tier install types. With this type of configuration, all the Oracle homes on the production site hosts and standby site hosts were created using the Oracle Universal Installer. The Oracle Application Server Guard instantiate topology command created the Disaster Recovery relationships between the production and standby Oracle homes.
Adding OracleAS Homes to an Existing Site with OracleAS Disaster Recovery Enabled
After an OracleAS site is OracleAS Disaster Recovery enabled, the relationship between the Oracle homes at the production and standby sites has been created. For releases previous to Oracle Application Server 10g release 10.1.2.0.2, the only way to add new instances to the site was to break the standby relationship, add the new instance at the production site using Oracle Installer, add the new instance to the standby site using Oracle Installer, and then re-create the standby site. With Oracle Application Server 10g 10.1.2.0.2 and later releases, you can use the clone instance command to add instances to a standby site.
For example, if you need a new middle tier to scale out the services in the middle tier, you can install the new instance at the production site. This operation creates the Oracle Application Server home for the instance and establishes the necessary relationships within the Oracle Application Server repositories at the production site.
With Oracle Application Server Guard asymmetrical topology support in Oracle Application Server 10g 10.1.2.0.2 and later releases, this Oracle home can optionally be ignored in regard to the site's OracleAS Disaster Recovery solution. If you want to add this instance to the standby site, the clone topology command will create the OracleAS Oracle home at the standby target host and establish the production-standby relationship for this instance. Before issuing this command, the standalone Oracle Application Server Guard kit must be installed and started at the target host (see the OracleAS Disaster Recovery installation information in Oracle Application Server Installation Guide for more information) and a discover topology command should be performed to discover the new instance in the production topology.
Warning:
Do not perform a clone operation to a standby site host that contains an existing Oracle home, other than the standalone Oracle Application Server Guard home, because it will get overwritten. Perform a clone operation only to a standby site host where no Oracle home is installed other than the standalone Oracle Application Server Guard home.Some situations in which cloning operations are useful are:
When you want to add two or more production instances to standby site hosts.
When you want to add a single production instance to a standby site host.
More information about cloning is provided in the following section.
Whether you are cloning a single production instance or multiple production instances to a standby site, the prerequisites and steps to follow are identical; the only difference is the actual asgctl command you would use for either cloning operation. For this reason, this section combines the cloning information and indicates where there are some minor differences.
Cloning a Single Production Instance to a Standby Site
As an example, you want to add a production Oracle Application Server instance to a standby site host. You can use the clone instance command, which copies the Application Server instance at the production site host to the same directory on the standby site peer host and then performs an instantiate operation.
Cloning Multiple Production Instances to a Standby Site
As an example, you want to add two or more production instances to a standby site host. You can use the clone topology command, which copies these Application Server instances to the same directories on the standby site peer hosts and then performs an instantiate operation.
If you want to use a policy file, edit and use the clone policy file (clone_policy.xml). Specify this file in the using policy <file> parameter of the clone topology command to clone a standby topology for only those instances specified accordingly. See Section 2.4, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information about using a policy file.
Special Considerations
Before cloning multiple production instances to a standby site, consider the following:
Each node should have its own virtual hostname mapped to the physical hostname's IP address in the hosts file. For example, edit the following:
Windows: %SystemRoot%\system32\drivers\etc\hosts
UNIX: /etc/hosts
ip_address prodnode1.domain.com prodnode1 vhostdr.domain.com vhostdr
The only type of database that is cloned by either a clone instance command or a clone topology command is a database with the Metadata Repository schemas that is created during an Application Server Infrastructure installation in the Application Server home. For more information on including databases in your OracleAS Disaster Recovery topology and configuring Oracle Data Guard for those databases, refer to Section 1.1.1.1, "Configuring Oracle Data Guard for Databases in an OracleAS Disaster Recovery Topology."
For UNIX platforms only, the tar utility is used by the ASG clone instance and clone topology commands. The target host(s) for these operations must have a version of GNU tar in the default PATH of the system user account in which the standalone ASG install runs. GNU tar can be obtained at the following location:
http://www.gnu.org/software/tar/
For the Windows platform, add the directory that contains the jar utility to the PATH when installing a JDK on the standby site host. Otherwise, the ASG on the standalone site host cannot access the jar.exe utility.
Prerequisites
The production instance or instances to be cloned cannot exist on the standby site host.
The following are prerequisites for performing the clone instance and clone topology operation to the standby site host:
Install the Oracle Application Server Guard standalone kit in its own Oracle home on each standby site host. Do not install any other Oracle components on the standby site host.
A Java development kit with its jar utility must be installed on the standby site host.
For Windows hosts, release 5.0.2134.1 or higher of the services kit (sc.exe) must be installed under C:\WINDOWS\system32 on the production and standby site hosts.
If you do not take this step prior to performing a cloning operation on Windows, you may see errors similar to these during a cloning operation:
stajz09: -->ASG_DUF-4040: Error executing the external program or script. The error code is "255" "IM.asinfra.us.oracle.com" stajz09P: -->ASG_IAS-15689: Error running the backup script stajz09: -->ASG_IAS-15685: Failed to backup configuration data for instance "IM.asinfra.us.oracle.com" stajz09: -->ASG_DUF-3027: Error while executing Clone Instance at step - backup step. stajz09: -->ASG_DUF-3027: Error while executing Clone Topology at step - clone home step.
For the dcm-daemon component in the %ORACLE_HOME%\opmn\conf\opmn.xml file on Windows hosts, increase the start timeout parameter's retry interval to 5 seconds. The following example shows the section of the opmn.xml file for the dcm-daemon component with the start timeout parameter's retry interval set to 5:
<ias-component id="dcm-daemon" status="enabled" id-matching="true">
<process-type id="dcm-daemon" module-id="DCMDaemon">
<start timeout="600" retry="5"/>
<stop timeout="120"/>
<process-set id="dcm" numprocs="1">
If you do not take this step prior to performing a cloning operation on Windows, you may see errors similar to these during a cloning operation:
stajz09: -->ASG_SYSTEM-100: Command "C:\work\im/opmn/bin/opmnctl.exe shutdown" failed, check log file C:\work\im\dsa\bkup\log/2007-07-17_01-41-51_loha.log for detail. stajz09: -->ASG_SYSTEM-100: Failure : prepare failed. stajz09: -->ASG_SYSTEM-100: stajz09: -->ASG_SYSTEM-100: OPMN managed processes could not be stopped. stajz09: -->ASG_SYSTEM-100: Status code: stajz09: -->ASG_SYSTEM-100: opmnctl shutdown failed.
Procedure
The basic procedure consists of the following pre-clone steps and clone steps.
Pre-Clone Steps
Perform the following steps:
For the clone instance command, log in as su - root on UNIX or as Administrator on Windows to the production site host where the Application Server instance that you want to clone is installed. For the clone topology command, log in as su - root on UNIX or as Administrator on Windows to each production site host where an Application Server instance that you want to clone is installed.
For the clone instance command, CD to the instance home on the production site host that you want to clone. For the clone topology command, CD to the instance homes on the production site hosts for each instance that you want to clone.
On Windows, make sure that release 5.0.2134.1 or higher of the services kit (sc.exe) is installed in the C:\WINDOWS\system32 directory on the production site hosts.
Shut down the Oracle Application Server Guard server.
For 10.1.2.x and 10.1.4.x releases, this command stops OracleAS Guard on UNIX: > <ORACLE_HOME>/opmn/bin/opmnctl stopproc ias-component=DSA For 10.1.3.x releases, this command stops OracleAS Guard on UNIX: > <ORACLE_HOME>/opmn/bin/opmnctl stopproc ias-component=ASG For 10.1.2.x and 10.1.4.x releases, this command stops OracleAS Guard on Windows: > <ORACLE_HOME>\opmn\bin\opmnctl stopproc ias-component=DSA For 10.1.3.x releases, this command stops OracleAS Guard on Windows: > <ORACLE_HOME>\opmn\bin\opmnctl stopproc ias-component=ASG
On UNIX, log in as root on each standby site host that an Application Server instance home will be cloned to and make sure dsaServer.sh in <ORACLE_HOME>/dsa/bin is executable by everyone. If it is not, record the permission, then change the executable permission by issuing the following command:
chmod +x dsaServer.sh chmod u+x asgexec
On Windows, on the standby site host or hosts that an Application Server instance home will be cloned to:
Add the jdk\bin path to the system path on the standby site host.
Create a new command window.
In the new command window, run the jar command with no parameters to make sure the jar utility is found.
Make sure that release 5.0.2134.1 or higher of the services kit (sc.exe) is installed in the C:\WINDOWS\system32 directory on the standby site host or hosts.
On both the production site host or hosts and the standby site host or hosts that will be involved in the clone operation, invoke asgctl and issue the startup command.
From the <ORACLE_HOME>/dsa/bin directory on a UNIX host: > asgctl.sh startup From the <ORACLE_HOME>\dsa\bin directory in the new command window on a Windows host: > asgctl startup
On UNIX hosts, log out as root.
Clone Steps
Perform the following steps:
Log in as user (non root user on UNIX hosts) to the production site host or hosts where the Application Server instance or instances that you want to clone are installed.
For the clone instance command, CD to the instance home on the production site host for the Application Server instance that you want to clone. For the clone topology command, CD to the instance homes on the production site hosts for each Application Server instance that you want to clone.
Invoke asgctl on the production site host and run the clone instance command to clone the Application Server instance and home to the same directory on the standby site peer host. Invoke asgctl on any of the production site hosts and run the clone topology command to clone the Application Server instances and homes for all of the production site hosts to the same directories on the standby site peer hosts. Remember that you can use a policy file to exclude specific instance homes from a clone topology operation.
Note:
In the command output, you will see a number of connect messages. This is normal as the Oracle Application Server Guard server is recycled during these operations.> asgctl.sh For 10.1.2.x and 10.1.4.x releases, use this command to connect to an ASG server: ASGCTL> connect asg prodoc4j ias_admin/adminpwd Successfully connected to prodoc4j:7890 For 10.1.3.x releases, use this command to connect to an ASG server: ASGCTL> connect asg prodoc4j oc4jadmin/adminpwd Successfully connected to prodoc4j:7890 ASGCTL> set primary database sys/testpwd@asdb Checking connection to database asdb CLONE INSTANCE -- CLONE AN INSTANCE EXAMPLE ASGCTL> clone instance portal_2 to asmid2.oracle.com . . . CLONE TOPOLOGY -- CLONE MULTIPLE INSTANCES EXAMPLE # Command to use if you are cloning all the Application Server # instances at all the production site hosts to the standby site # peer hosts: ASGCTL> clone topology to standbyinfra.oracle.com . . . # Command to use if you are using a policy file (where <file> # is the full path and file specification of the clone policy file) # to clone a subset of the Application Server instances at the production # site hosts to the standby site peer hosts: ASGCTL> clone topology to standbyinfra.oracle.com using policy <file> . . . ASGCTL> disconnect ASGCTL> exit >
Log out of the production site host or hosts.
Note:
If Oracle Application Server Guard does not run as root on UNIX hosts, the user will be prompted by the Oracle Application Server Guard client to run the underlying operations at each of the instance homes as root (manually) in order to continue with the operation.The last step completes the cloning operation and brings the hosts back to where they were before you started the operation. At this point, you could invoke asgctl, connect to a production site host, discover the topology, and then perform a verify operation to determine if the production and standby topologies are valid and consistent with one another as you would expect them to be.
After adhering to the following conditions, you are ready to use the Oracle Application Server Guard for standby instantiation and standby synchronization.
Meet the requirements for the implementation of the OracleAS Disaster Recovery solution as described in Section 1.1.1, "OracleAS Disaster Recovery Requirements," Section 1.1.3, "Supported Topologies," and Section 1.2, "Preparing the OracleAS Disaster Recovery Environment."
Install the OracleAS Disaster Recovery solution as described in Section 1.4, "Overview of Installing Oracle Application Server."
The following sections describe standby instantiation and standby synchronization:
See Chapter 5, "Oracle Application Server Guard asgctl Command-line Reference" for Oracle Application Server Guard command-line asgctl utility reference information.
The standby instantiation operation performs a number of operations to set up and maintain a logical mirror of the production site at the standby site. Oracle Application Server Guard is used to coordinate the distributed operations across the production and standby sites to ensure the disaster recovery functionality is enabled. The setup operations are:
Uses a previous topology file created by performing a discovery topology operation.
Verifies the topology definitions to ensure they comply with the rules of the OracleAS Disaster Recovery environment.
Mirrors the configuration information of all the Oracle homes in the OracleAS topology to the corresponding Oracle home at the standby site.
If you want to use a policy file, edit and use the instantiate policy file (instantiate_policy.xml). Specify this file in the using policy <file> parameter of the instantiate topology command to instantiate a standby topology for only those instances specified accordingly. See Section 2.4, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.
Reports any errors found for correction.
The procedure to perform a standby instantiation operation uses the following example, which assumes that you have invoked the Oracle Application Server Guard client and performed a discover topology command to create a topology file.
See Section 5.2.1.1, "Special Considerations for Running Instantiate and Failover Operations in CFC Environments" if you have an OracleAS Disaster Recovery configuration in a CFC environment and are about to perform an instantiate operation.
Connect to the Oracle Application Server Guard server.
ASGCTL > connect asg prodinfra ias_admin/<adminpwd> Successfully connected to prodinfra:7890 ASGCTL>
Specify the primary OracleAS Metadata Repository database. See Section 2.11.1.2, "Specifying the Primary Database" for more information. If you have multiple OracleAS Metadata Repositories in your topology, you must authenticate each one using the set primary database command.
ASGCTL> set primary database sys/testpwd@asdb
Dump the policies (dump policies command), then edit and use the verify policy file (verify_policy.xml) and the instantiate policy file (instantiate_policy.xml) to specify the success requirement attribute for each instance in the file. See Section 2.4, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.
ASGCTL> dump policies Generating default policy for this operation Creating policy files on local host in directory "/private1/OraHome2/asr1012/dsa/conf/"
Verify the topology. The network hostname standbyinfra is used.
ASGCTL> verify topology with standbyinfra
Instantiate the topology at the secondary site. The network hostname standbyinfra is used. This command assumes that all the Oracle homes have been installed using Oracle Universal Installer software or cloned using the clone instance command or clone topology command. Specify the using policy <file> parameter where <file> represents the path and file specification for the instantiate_policy.xml file.
ASGCTL> instantiate topology to standbyinfra using policy <file>
Whenever a standby instantiation is performed using the asgctl instantiate topology command, a synchronization operation is also performed. Thus, you do not need to perform another synchronization operation immediately following the instantiation operation. If a period of time had passed following an instantiate operation, ensure that both the primary and standby sites are consistent. Then, perform a sync topology operation to ensure any changes that occurred on the primary site are applied to the secondary site.
The Oracle Application Server Guard synchronization operation synchronizes the standby site with the primary site to ensure that the two sites are logically consistent. This operation is necessary whenever any of the following circumstances exist:
Deploy a new application or redeploy an existing application - Both the deployment of a new application and the redeployment of an existing application require changes to schema-based information in the metadata repository as well as component configuration information distributed among the Oracle homes in an Oracle Application Server topology. This information has to be uniformly deployed at the standby site.
Configuration changes - Specific changes, small to large, to a configuration, must be reflected at the standby site.
User Provisioning - The default Infrastructure installation maintains the database for Oracle Internet Directory. As new users are added to the database, they should be synchronized to the standby site on a schedule that fulfills the business availability requirements.
Periodic full synchronization - By default, the synchronization operations synchronizes only the pieces of configuration that have changed since the last synchronization operation. During test cycles or occasional complex configuration changes, administrators may want to fully refresh of their configuration information to the standby site to ensure mirroring of these changes.
You can specify a full or incremental synchronization. By default, an incremental synchronization is performed, which offers the best performance. However, in the following three circumstances a full synchronization should be specified:
When you want to force a full synchronization to happen for some reason, such as synchronizing the standby site completely with the primary site.
When you know there are many transactional changes over a short period of time on the primary site that must be synchronized with the secondary site.
When you know that there is a large accumulation of transactional changes over a long period of time on the primary site that must be synchronized with the secondary site.
As part of the synchronization operation, a verify operation is performed to ensure the required OracleAS Disaster Recovery environment is maintained. Additionally, if new Oracle Application Server instances are installed into the Oracle Application Server topology, Oracle Application Server Guard will discover these installations.
If you want to use a policy file, edit and use the synchronization policy file (sync_policy.xml). Specify this file in the using policy <file> parameter of the sync topology command for synchronizing a standby topology for only those instances specified accordingly. See Section 2.4, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.
The following example assumes that you have invoked the Oracle Application Server Guard client and performed a discover topology command to create a topology file.
The procedure to perform standby synchronization is as follows:
Connect to the Oracle Application Server Guard server.
ASGCTL > connect asg prodinfra ias_admin/<adminpwd> Successfully connected to prodinfra:7890 ASGCTL>
Specify the primary database. See Section 2.11.1.2, "Specifying the Primary Database" for more information.
ASGCTL> set primary database sys/testpwd@asdb
Synchronize the secondary site with the primary site.
ASGCTL> sync topology to standbyinfra
Runtime operations include dealing with outages, whether they are scheduled or unscheduled (see Section 2.9.1, "Outages"), and monitoring ongoing Oracle Application Server Guard operations using the asgctl command-line utility and troubleshooting (see Section 2.10, "Monitoring Oracle Application Server Guard Operations and Troubleshooting").
Outages fall into two categories: scheduled and unplanned.
The following subsections describe these outages.
Scheduled outages are planned outages. They are required for regular maintenance of the technology infrastructure supporting the business applications and include tasks such as hardware maintenance, repair and upgrades, software upgrades and patching, application changes and patching, and changes to improve the performance and manageability of systems. Scheduled outages can occur either for the production or standby site. Descriptions of scheduled outages that impact the production or standby site are:
Site-wide maintenance
The entire site where the current production resides is unavailable. Examples of site-wide maintenance are scheduled power outages, site maintenance, and regularly planned switchover operations.
OracleAS Cold Failover Cluster clusterwide 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 clusterwide maintenance are repair of the cluster interconnect and upgrade of the cluster management software.
Testing and validating the standby site as a means to test OracleAS Disaster Recovery readiness.
For scheduled outages, a site switchover operation has to be performed, which is explained in the section that follows.
Site Switchover Operations
A site switchover is performed for planned outages of the production site. At the production site, the ASG server must be started on each of the hosts, and the listener and database must be started on the Infrastructure host. At the standby site, the ASG server must be started on each of the hosts, and the listener must be started and the database must be in standby mode on the Infrastructure host. Before you perform the switchover, execute the asgctl verify topology command on the production site to confirm that the production topology is running and the configuration is valid. Then execute the asgctl verify topology command (specifying the standby infrastructure host) to confirm that the standby site is consistent with the production site and meets Disaster Recovery requirements. After you have confirmed that the topologies are valid, perform the switchover operation. During the site switchover operation, the application of the database redo logs is synchronized to match the backup and restoration of the configuration files for the middle tier and OracleAS Infrastructure installations.
Note:
During a switchover operation, theopmn.xml file is copied from the primary site to the standby site. For this reason, the value of the TMP variable must be defined the same in the opmn.xml file on both the primary and standby sites, otherwise this switchover operation will fail with a message that it could not find a directory. Therefore, make sure the TMP variable is defined identically and resolves to the same directory structure on both sites before attempting a switchover operation.During site switchover, considerations must be made to avoid long periods of cached DNS information. Modifications to the site's DNS information, specifically time-to-live (TTL), must be performed. See Section 1.5, "Wide Area DNS Operations" for instructions.
If you want to use a policy file, edit and use the switchover policy file (switchover_policy.xml). Specify this file in the using policy <file> parameter of the switchover topology command for switching over to the standby topology only those instances specified accordingly. See Section 2.4, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information. This example does not show the use of a policy file.
See Section 5.2.1.3, "Special Considerations for Running a Switchover Operation in CFC Environments" if you have an OracleAS Disaster Recovery configuration in a CFC environment and are planning a switchover operation.
To switchover from the production site to the standby site, perform the following steps:
If you are manually changing DNS names to manage DNS switchover, reduce the wide area DNS TTL value for the site. See Section 1.5, "Wide Area DNS Operations" for a description of the two methods of performing a DNS switchover. See Section 1.5.2, "Manually Changing DNS Names" for more information about manually changing DNS names.
Invoke the Oracle Application Server 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 Oracle Application Server Guard server.
Use these commands for 10.1.2.x and 10.1.4.x releases: > asgctl.sh Application Server Guard: Release 10.1.2.0.2 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg prodinfra ias_admin/<adminpwd> Use these commands for 10.1.3.x releases: > asgctl.sh Application Server Guard: Release 10.1.3.2.0 (c) Copyright 2004, 2005 Oracle Corporation. All rights reserved ASGCTL> connect asg prodinfra oc4jadmin/<adminpwd>
Specify the primary database. See Section 2.11.1.2, "Specifying the Primary Database" for more information.
ASGCTL> set primary database sys/testpwd@asdb
Switchover the topology to the secondary site. If you want to use a policy file, specify the using policy <file> parameter where <file> represents the path and file specification for the switchover_policy.xml file.
ASGCTL> switchover topology to standbyinfra
Note:
As part of the Oracle Application Server Guard switchover operation, an implicitsync topology command is performed to make sure the topologies are identical. In addition, all OPMN services are stopped and then restarted on the production site.Disconnect from the old primary site Oracle Application Server Guard server.
ASGCTL> disconnect
Perform a wide area DNS switchover to direct requests to the new production site based on one of the methods presented in Section 1.5, "Wide Area DNS Operations".
If you are manually changing DNS names to manage DNS switchover, adjust the wide area DNS TTL to an appropriate value.
Special Switchover Operation Considerations
This section describes the following special considerations relating to the switchover operation.
When performing a switchover operation from a primary site with two Oracle Identity Management instances running to a standby site representing an asymmetric topology with only one Oracle Identity Management instance running, which means that the other node is to be ignored on the switchover site, the system administrator must not only edit the switchover_policy.xml policy file to indicate that this other node is to be set to Ignore, but must also shutdown all processes running on that node in order for the switchover operation to be successful. For example, if the two Oracle Identity Management instances running on the primary site are im.systemA.us.oracle.com and im.systemB.us.oracle.com, and the other node (im.systemB.us.oracle.com) is to be ignored on the switchover site, the system administrator must also shutdown all processes running on that node (im.systemB.us.oracle.com) in order for the switchover operation to succeed.
When the discover topology command is issued following a switchover operation and the asymmetric standby site topology originally had one or more fewer middle tiers (for example, instA and instB) than there were in the original production site topology (instA, instB, and instC), a warning error message displays for each missing instance of a middle tier (instC, in this case). This warning error message is expected and can be ignored. When a discover topology command is issued following a switchover operation, OracleAS Server Guard reads the Oracle Internet Directory information, which is an exact copy of the original primary site Oracle Internet Directory information on this new primary site (former standby site). Because this Oracle Internet Directory information is identical to the original primary site Oracle Internet Directory information, when OracleAS Server Guard visits the host or home of each instance of these middle tiers to verify their existence, it discovers that some of the middle tiers do not exist, and issues warnings.
Prior to performing an asgctl switchover operation in an asymmetric topology for instances that do not have a standby peer, you must perform an opmnctl stopall command to shutdown all components on each of these ignored instances on the primary site. When an XML policy file is in use for an asymmetric topology and has the <instanceList successRequirement ="Ignore" set for an instance, in a switchover operation Oracle Application Server Guard ignores that instance. Oracle Application Server Guard, on a switchover operation shuts down all components on the old primary site except for Oracle Application Server Guard and OPMN and ignores instance B because the policy file specifies to do so. The switchover operation fails because all components are not shut down on the primary site, in this case instance B, because the policy file specifies to ignore instance B on the primary site, which has no standby peer. To avoid this problem, perform an opmnctl stopall operation for all components on instance B prior to the switchover operation in order for the switchover operation to succeed in this asymmetric topology.
After a switchback operation (switchover topology to <primary site>), the database will be started up on only one of the Oracle RAC nodes by Oracle Application Server Guard; however, the remaining Oracle RAC instances on the primary site must be started up manually.
An unplanned outage that impacts a production site occurs when it becomes unavailable and there is no possibility of restoring the production site to service within a reasonable period of time. This includes site-wide outages at the production site such as fire, flood, earthquake, or power outages.
Unplanned outages warrant performing a failover operation of the production site to the standby site.
Site Failover Operations
A site failover operation is performed for unplanned outages for the production site. Failover operations require the restoration of the configuration and Infrastructure data to a consistent point in time. Oracle Application Server Guard ensures that the site services are brought up in a consistent fashion to the point of the last sync operation. A failover operation restores to the last synchronization point.
If you want to use a policy file, edit and use the failover policy file (failover_policy.xml). Specify this file in the using policy <file> parameter of the failover command for failing over to the standby topology only those instances specified accordingly. See Section 2.4, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.
See Section 5.2.1.1, "Special Considerations for Running Instantiate and Failover Operations in CFC Environments" if you have an OracleAS Disaster Recovery configuration in a CFC environment and are about to perform a failover operation.
To fail over the production site to the standby site, follow these steps:
Connect to the Oracle Application Server Guard server on the standby site. The network name is standbyinfra.
For 10.1.2.x and 10.1.4.x releases: ASGCTL> connect asg standbyinfra ias_admin/<adminpwd> Successfully connected to standbyinfra:7890 For 10.1.3.x releases: ASGCTL> connect asg standbyinfra oc4jadmin/<adminpwd> Successfully connected to standbyinfra:7890
Specify that the primary OracleAS Metadata Repository database on the standby site is now identified as the new primary database on this new production site. The keyword new is shown as bold text in the following example to indicate its importance as a key word. If you have multiple OracleAS Metadata Repositories in your topology, you must authenticate each one using the set new primary database command.
ASGCTL> set new primary database sys/testpwd@asdb
Perform an asgctl failover operation.
ASGCTL> set trace on all ASGCTL> failover ASGCTL> disconnect
Discover the topology. You must perform this operation to create a new topology file for this production site.
For 10.1.2.x and 10.1.4.x environments, discover the topology as follows:
ASGCTL> discover topology oidpassword=oidpwd
For 10.1.3.x environments, discover the topology as follows:
ASGCTL> discover topology within farm
You can also use the add instance command to add the standalone database instances to the Disaster Recovery topology as follows:
ASGCTL> add instance asdb on vhostdr.oracle.com
After setting up your OracleAS Disaster Recovery solution, and instantiating the standby topology, and synchronizing the standby topology, you can use the Oracle Application Server Guard client command-line utility asgctl to issue commands through the coordinating Oracle Application Server Guard server to monitor asgctl operations and perform troubleshooting tasks. A typical Oracle Application Server Guard monitoring or troubleshooting session may involve the following tasks:
As asgctl commands are issued through the Oracle Application Server Guard client and requests are then made to the coordinating Oracle Application Server Guard server, the coordinating Oracle Application Server Guard server communicates these requests to the other Oracle Application Server Guard servers in the production and standby topologies, and status messages are returned to the Oracle Application Server Guard client as well as any error messages should a particular task encounter a problem. Section 2.10.7, "Error Messages" describes where you can obtain more information about these error messages.
To validate that the primary topology is running and the configuration is valid, enter the following asgctl command at the asgctl prompt.
For Application Server 10.1.2.x and 10.1.4.x releases:
ASGCTL> connect asg ias_admin/<adminpwd>
Successfully connected to prodinfra:7890
ASGCTL> discover topology oidpassword=<oidpwd>
ASGCTL> verify topology
Generating default policy for this operation
prodinfra:7890
HA directory exists for instance asr1012.infra.us.oracle.com
asmid2:7890
HA directory exists for instance asmid2.asmid2.us.oracle.com
asmid1:7890
HA directory exists for instance asmid1.asmid1.us.oracle.com
ASGCTL>
For Application Server 10.1.3.x releases:
ASGCTL> connect asg oc4jadmin/<adminpwd>
Successfully connected to prodinfra:7890
ASGCTL> discover topology within farm
ASGCTL> verify topology
Generating default policy for this operation
prodinfra:7890
HA directory exists for instance asr1013.infra.us.oracle.com
asmid2:7890
HA directory exists for instance asmid2.asmid2.us.oracle.com
asmid1:7890
HA directory exists for instance asmid1.asmid1.us.oracle.com
ASGCTL>
If you want to use a policy file, edit and use the verify policy file (verify_policy.xml) to specify the success requirement attribute for each instance in the file. Then specify the using policy <file> parameter in the verify topology command where <file> represents the path and file specification for the verify_policy.xml file. See Section 2.4, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.
To compare a primary topology to which the local host is a member with a standby topology and ensure that they are consistent with one another and that both topologies conform to OracleAS Disaster Recovery requirements, enter the following asgctl command at the asgctl prompt and specify the name of the standby host system.
ASGCTL> dump policies
Generating default policy for this operation
Creating policy files on local host in directory "/private1/OraHome2/asr1012/dsa/conf/"
ASGCTL> verify topology with standbyinfra
Generating default policy for this operation
prodinfra:7890
HA directory exists for instance asr1012.infra.us.oracle.com
asmid2:7890
HA directory exists for instance asmid2.asmid2.us.oracle.com
asmid1:7890
HA directory exists for instance asmid1.asmid1.us.oracle.com
standbyinfra:7890
HA directory exists for instance asr1012.infra.us.oracle.com
asmid2:7890
HA directory exists for instance asmid2.asmid2.us.oracle.com
asmid1:7890
HA directory exists for instance asmid1.asmid1.us.oracle.com
prodinfra:7890
Verifying that the topology is symmetrical in both primary and standby configuration
ASGCTL>
# Command to use if you want to use a policy file
# verify topology with standbyinfra using policy <file>
To display the status of all the current operations running on all nodes of the topology to which the Oracle Application Server Guard client is connected, enter the following asgctl command at the asgctl prompt:
ASGCTL> show operation
*************************************
OPERATION: 19
Status: running
Elapsed Time: 0 days, 0 hours, 0 minutes, 28 secs
TASK: syncFarm
TASK: backupFarm
TASK: fileCopyRemote
TASK: fileCopyRemote
TASK: restoreFarm
TASK: fileCopyLocal
To display only operations that have completed (are not running on any nodes of the topology to which the Oracle Application Server Guard client is connected for the current session), enter the following asgctl command at the asgctl prompt:
ASGCTL> show operation history
*************************************
OPERATION: 7
Status: success
Elapsed Time: 0 days, 0 hours, 0 minutes, 0 secs
TASK: getTopology
TASK: getInstance
*************************************
OPERATION: 16
Status: success
Elapsed Time: 0 days, 0 hours, 0 minutes, 0 secs
TASK: getTopology
TASK: getInstance
*************************************
OPERATION: 19
Status: success
Elapsed Time: 0 days, 0 hours, 1 minutes, 55 secs
TASK: syncFarm
TASK: backupFarm
TASK: fileCopyRemote
TASK: fileCopyRemote
TASK: restoreFarm
TASK: fileCopyLocall
To stop a specific operation that is running on the server, enter the following asgctl command at the asgctl prompt and specify the operation number you want to stop. You can obtain the operation number you want to stop by entering a asgctl show operation full command.
ASGCTL> show operation full ************************************* OPERATION: 19 Status: running Elapsed Time: 0 days, 0 hours, 0 minutes, 28 secs Status: running . . . ASGCTL> stop operation 19
The operation is stopped at the most recently successfully completed sync point.
To set a trace flag for a specific event and to log the output to the asgctl log files, enter the following asgctl command at the asgctl prompt and specify the on keyword and enter the trace flags to be enabled. In this case, the trace flag DB indicates that trace information regarding processing in the Oracle Database environment will be displayed. See the set trace command for more information about other trace flags that can be enabled. See the set trace command for a complete list of the trace flags that can be set.
ASGCTL> set trace on db
To write detailed information about the topology to which the local host is connected, enter the following asgctl command at the asgctl prompt and specify the path name and file name where the detailed output is to be written. The output is the same as the display shown in the dump topology command, except it is written to a file that you can save for future reference.
ASGCTL> dump topology to c:\dump_mid_1.txt
Appendix B, "Oracle Application Server Guard Error Messages" categorizes and describes the error messages that may appear while using the OracleAS Disaster Recovery solution.
This section includes the following subsections:
Section 2.11.1, "Typical Oracle Application Server Guard Session Using asgctl"
Section 2.11.2, "Periodic Scheduling of Oracle Application Server Guard asgctl Scripts"
Section 4.1.1, "Special Considerations for Multiple OracleAS Metadata Repository Configurations"
Chapter 5, "Oracle Application Server Guard asgctl Command-line Reference"
A typical Oracle Application Server Guard session using asgctl involves the following tasks, which are described in the following subsections:
One of the advantages of supporting an asgctl command-line interface is that you can place these asgctl commands in a proper sequence in a script as described in Section 2.11.1.4, "Creating and Executing an asgctl Script" and then execute the script as described in Section 2.11.2, "Periodic Scheduling of Oracle Application Server Guard asgctl Scripts" and Section 2.11.3, "Submitting Oracle Application Server Guard Jobs to the Enterprise Manager Job System".
To get help on a particular command, enter the asgctl command at the asgctl prompt and specify the command name you for which you want help information. Otherwise, to get help on all commands, enter the following asgctl command at the asgctl prompt:
ASGCTL> help
connect asg [<host>] [<ias_administrator_account>/<password>]
disconnect
exit
quit
add instance <instance_name> on <instance_host> [to topology]
clone topology to <standby_topology_host> [using policy <file>] [no standby]
clone instance <instance> to <standby_topology_host> [no standby
discover topology [oidhost=<host>] [oidsslport=<sslport>] [oiduser=<user>] oidpassword=<pass>
discover topology within farm
dump farm [to <file>] (Deprecated)
dump topology [to <file>] [using policy <file>]
dump policies
failover [using policy <file>]
help [<command>]
instantiate farm to <standby_farm_host> (Deprecated)
instantiate topology to <standby_topology_host> [using policy <file>]
remove instance <instance_name> [from topology]
set asg credentials <host> <ias_administrator_account>/<password> [for topology]
set asg credentials <host> ias_admin/<password> [for farm] (Deprecated)
set primary database <username>/<password>@<servicename> [pfile <filename> | spfile <filename>]
set new primary database <username>/<password>@<servicename> [pfile <filename> | spfile <filename>]
set noprompt
set trace on|off <traceflags>
sync farm to <standby_farm_host> [full | incr[emental]] (Deprecated)
sync topology to <standby_topology_host> [full | incr[emental]] [using policy <file>]
startup [asg]
startup farm (Deprecated)
startup topology
shutdown [local]
shutdown farm (Deprecated)
shutdown topology
show op[eration] [full] [[his]tory]
show env
stop op[eration] <op#>
switchover farm to <standby_farm_host> (Deprecated)
switchover topology to <standby_topology_host> [using policy <file>]
verify farm [with <host>](Deprecated)
verify topology [with <host>] [using policy <file>]
ASGCTL>
To identify the OracleAS Infrastructure database on the primary topology, enter the following asgctl command at the asgctl prompt and specify the user name and password for the database account with sysdba privileges to access the OracleAS Infrastructure database and the TNS service name of the OracleAS Infrastructure database:
ASGCTL> set primary database sys/testpwd@asdb Checking connection to database asdb ASGCTL>
The standby site uses the same values as specified for the primary database because the service name and password for both the primary and standby OracleAS Infrastructure Databases must be the same. You must always set the primary database before performing an instantiate, sync, or switchover operation.
If you have multiple OracleAS Metadata Repositories in your topology, you must authenticate each one using the set primary database command.
You must perform a discover topology command when you first set up your OracleAS Disaster Recovery environment in order to initially create the topology.xml file. There after, you should perform a discover topology operation whenever you procure another Oracle home in a production site or change roles from a production to a standby site through a switchover or failover operation. The discover topology command queries Oracle Internet Directory for all instances within the topology that share the same Oracle Internet Directory for the production site. See Section 5.2, "Information Specific to a Small Set of Oracle Application Server Guard Commands" for more information about topology files. Enter the following asgctl command at the asgctl prompt to discover the topology:
For Application Server 10.1.2.x and 10.1.4.x releases:
ASGCTL> connect asg prodinfra ias_admin/<adminpwd>
Successfully connected to prodinfra:7890
ASGCTL> discover topology oidpassword=<oidpwd>
Discovering topology on host "infra" with IP address "123.1.2.111" prodinfra:7890
Connecting to the OID server on host "infra.us.oracle.com" using SSL port "636" and username "orcladmin"
Getting the list of databases from OID
Gathering database information for SID "asdb" from host "infra.us.oracle.com"
Getting the list of instances from OID
Gathering instance information for "asr1012.infra.us.oracle.com" from host "infra.us.oracle.com"
Gathering instance information for "asmid1.asmid1.us.oracle.com" from host "asmid1.us.oracle.com"
Gathering instance information for "asmid2.asmid2.us.oracle.com" from host "asmid2.us.oracle.com"
The topology has been discovered. A topology.xml file has been written to each home in the topology.
ASGCTL>
For Application Server 10.1.3.x releases:
ASGCTL> connect asg prodinfra oc4jadmin/<adminpwd>
Successfully connected to prodinfra:7890
ASGCTL> discover topology within farm
Warning: If OID is part of your environment, you should use it for discovery
Discovering topology on host "infra" with IP address "a.b.c.d" asmid:7890
Discovering instances within the topology using OPMN
Gathering instance information for "1013inst.asmid.oracle.com" from host
"asmid.us.oracle.com"
The topology has been discovered. A topology.xml file has been written to each home in the topology.
ASGCTL>
You can also use the add instance command to add the standalone database instances to the Disaster Recovery topology as follows:
ASGCTL> add instance asdb on vhostdr.oracle.com
After the production topology is known by Oracle Application Server Guard for a production site, you can execute any one of the subsequent commands to perform a subsequent asgctl operation that involves the standby site. See discover topology for more information.
To create a script containing a sequence of asgctl command names and their arguments, open an edit session with your favorite editor, enter the asgctl commands in the proper sequence according to the operations you want to perform, save the script file, then execute the script when you invoke asgctl as shown in the following command:
> ASGCTL @myasgctlscript.txt
See the set echo command for an example of a script containing a series of asgctl commands.
You can also set the noprompt state for use in executing commands in an asgctl script in which all interactive prompts are later ignored. See the asgctl set noprompt command for more information.
For Oracle Application Server Guard operations that you want to run periodically, such as a periodic sync topology operation to keep the standby topology synchronized with the primary topology, you can automate the periodic running of an Oracle Application Server Guard asgctl script.
On UNIX systems, you can set up a cron job to run the asgctl script. Copy your asgctl script into the appropriate /etc subdirectory cron.hourly, cron.daily, cron.weekly, or cron.monthly. It will run either hourly, daily, weekly, or monthly, depending on the name of the subdirectory in which you choose to place your script. Or you can edit a crontab and create an entry that will be specific for the time on which you want to run the asgctl script. See the one or two manpages on cron and crontab for more information.
On Windows systems, you can use the task scheduler or scheduled tasks from the Control Panel to choose the time to run the asgctl script, daily, weekly, monthly, or at specific times. You can also purchase additional scheduler software with more options from a third party and then set the time and frequency to run the asgctl script. See the Windows operating system help for more information.
You can use the Oracle 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 Oracle Enterprise Manager Job Activity page and create your own host command job to execute your asgctl script, which is called a job task. Your job task (script) will invoke asgctl to run the asgctl commands in the order in which they are listed. After you create your Oracle Application Server Guard job, save it to the Oracle Enterprise Manager 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 Oracle Enterprise Manager online help and Oracle Enterprise Manager Concepts for more information.
