asgctl Operations

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

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

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

Sets the credentials (set asg credentials command) used to authenticate the OracleAS Guard client connections to OracleAS Guard servers and the

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

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

■ Discover the topology -- Discovers (discover topology command) by querying Oracle Internet Directory all instances within the topology that share the same

Overview of OracleAS Guard and asgctl

Oracle Internet Directory for a production site and generates a topology XML file that describes the topology and replicates this file to all instances in the topology. See Section 5.6, "Discovering, Dumping, and Verifying the Topology" for more information.

The command discover topology within farm discovers the topology using OPMN at a production site for special cases where Oracle Internet Directory is not

available, such as in an OracleAS 10.1.3 OPMN topology.

■ Adding or removing an instance from the local topology file -- pulls an instance into or drops an instance from an existing local topology file. This is particularly useful in an OracleAS 10.1.3 only topology, where an OracleAS Guard client can connect to an existing OracleAS 10.1.3 instance, and either perform an add

instance command that adds the specified OracleAS 10.1.3 instance to the topology file, or performs a remove instance command that removes the specified OracleAS 10.1.3 instance from the local topology file, and in either case, if specified,

propagates the updated topology file to all instances in the Disaster Recovery production environment. Any OracleAS Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby environment.

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

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

■ Standby site instantiation -- Creates the disaster recovery environment. It

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

■ Standby site synchronization -- Applies database redo logs for OracleAS Infrastructures to the standby site in conjunction with synchronizing external configuration files across the topology (sync topology command). See

Section 5.11.2, "Standby Synchronization" for more information.

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

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

■ Verification -- Validates that the primary topology is running and the configuration is valid (verify topology command) or if a standby topology is

specified, compare the primary topology to which the local host system is a member with the standby topology to validate that they are consistent with one another and conforms to the requirements for OracleAS Disaster Recovery. See Section 5.13.1, "Verifying the Topology" for more information.

■ Using a policy file -- Used as a filter to filter out unnecessary instances for supporting asymmetric topologies. The dump policies command writes detailed, default policy information to respective XML formatted files for a select set of asgctl commands. You can then edit each respective XML policy file and use it in the using policy <file> parameter with any one of these select set of asgctl commands: dump topology, verify topology, clone topology, failover, instantiate topology, switchover topology, and sync topology to define by instance the domain of execution operations that are permitted for each of these asgctl commands. Each instance list entry in an XML policy file logically tags a

production-standby peer combination with a particular attribute that defines the success requirement for its successful operation. For example, you may want to omit a node in a symmetric topology while performing one of the operations previously mentioned. Use the policy file to specify the node to be ignored. See Section 5.7, "Dumping Policy Files and Using Policy Files With Some asgctl Commands" for more information.

■ Instance management -- Enables you to shut down (shutdown topology command) and start up the topology (startup topology command). ■ Troubleshooting -- Uses the dump topology command to write detailed

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

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

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

OracleAS Guard

Operation DR Site Environment Before Operation DR Site Environment After Operation clone The production site has one or more instances

that need to be installed on the standby site and instantiated. The cloning operations perform this task.

The standby site has one or more new standby instances that are a logical mirror of the production site instances.

instantiate The standby site with its Oracle homes exists, but the OracleAS Disaster Recovery relationship across sites does not exist yet for an OracleAS Disaster Recovery operation to be performed.

A logical mirror of the production site is set up and maintained at the standby site.

sync The standby site is not consistent with the production site. OracleAS Disaster Recovery is not possible to a consistent point in time without some manual intervention.

Database redo logs are applied to OracleAS Infrastructures in combination with

synchronizing external configuration files across the topology. The sync operation is performed in the event that a failover or switchover operation is necessary, then the standby site can be restored to a consistent point in time. No manual

intervention is necessary to synchronize the sites after the asgctl sync operation is performed.

Overview of OracleAS Guard and asgctl

Figure 5–10 shows a summary of the main OracleAS Disaster Recovery operations and the command sequences used to perform these operations. For example, to get started with a new DR environment once it is set up and operational, you must always create a topology file on the production site. To do that, you perform a connect command to connect the OracleAS Guard client to the OracleAS Guard server followed by

identifying the production Infrastructure database using a set primary database command, then perform the discover topology command, finally followed by a disconnect command to disconnect the OracleAS client from the OracleAS server. In essence, to perform any OracleAS Disaster Recovery operation using asgctl

commands, you must always connect the OracleAS Guard client to the OracleAS Guard server, identify the location of the Infrastructure database, then perform the OracleAS Disaster Recovery operation or operations of interest, and finally disconnect the OracleAS client from the OracleAS server. The only exception to this general sequence is for a failover operation, in which the production site is permanently unavailable due to some unplanned problem. In this case, you connect the OracleAS Guard client to OracleAS Guard server at the standby site, identify the standby site Infrastructure as the new Infrastructure database, then perform the failover operation. Because there is no topology file created on the standby site following a failover operation, you must then perform a discover topology command to create it for the first time. Then you can disconnect the OracleAS Guard client from OracleAS Guard server.

The asgctl command sequences shown in Figure 5–10 assume the simplest topology configuration. For example, in a more complex case, if your production or standby site has multiple MR instances installed, you must identify each instance with a set

primary database command prior to performing the main Disaster Recovery operation, such as an instantiate, sync, switchover, or failover operation. Similarly, OracleAS Guard requires that you set the credentials for any OracleAS Guard server system in the topology that has different credentials from the OracleAS Guard server to which you are connected before you perform any of these main operations, such as instantiate, sync, switchover, or failover. So for both of these cases, additional asgctl commands are required in the command sequence before you can perform the main Disaster Recovery operation. See the usage notes for the set asg credentials command for more information.

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.

Table 5–4 (Cont.) Description of Disaster Recovery Production and Standby Environments Before and After Performing These OracleAS Guard Operations

OracleAS Guard

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