clone topology - Oracle Application Server

Clones two or more production middle tier instances to standby middle tier systems.

Format

clone topology to <standby_topology_host> [using policy <file>] [no standby]

Parameters

standby_topology_host

The name of the standby topology host system. using policy <file>

Full path and file specification for the XML policy file. no standby

A keyword, that if present in the command-line, directs OracleAS Guard to clone the instance without setting up the instances in Disaster Recovery (no Data Guard). In a MR home only, an instantiate operation would normally be done, but in this case it is not performed.

Usage Notes

This command is useful for cloning two or more production instances on middle tier systems to a standby middle tier host system. The clone topology operation eliminates the task of having to install these Oracle instances on the standby middle tier systems and perform an instantiate operation.

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

The production instances to be cloned cannot exist on the standby systems. The following are prerequisites for performing the clone topology operation to standby site systems.

■ The OracleAS Guard standalone kit must be installed on each standby system ■ Backup and Restore must be installed on each OracleAS Guard home on each

standby system

■ A Java development kit with its jar utility must be installed on each standby system

■ For Windows systems only, the services kit (sc.exe) must be installed on each standby system

When the no standby keyword is specified in the command-line, the topology entry (<topology> </topology>) containing the entries <nodes list = "nodes"/>, <discover list = "nodes"/>, and <gateway list = "nodes"/> is removed from the opmn.xml file so as not to conflict with the primary configuration. Normally, a switchover or failover operation rewrites this topology entry back into the opmn.xml file; but because neither operation occurred, the opmn.xml file on the standby site will be missing this information.

clone topology

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

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

Pre-Clone Steps (For UNIX Systems Only)

For each instance on the production and standby sites, perform the following steps: 1. Log in as su - root.

2. CD to the instance home.

3. Shut down any OracleAS Guard servers.

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

4. On UNIX systems only: make sure dsaServer.sh in <ORACLE_

HOME>/dsa/bin is executable by everyone. If it is not, record the permission, then change the executable permission by issuing the following command:

chmod +x dsaServer.sh chmod u+x asgexec

5. Invoke asgctl and issue the startup command.

> asgctl.sh startup

6. Log out as root on UNIX systems.

Clone Steps

From any instance on the production site, perform the following steps: 1. Log in as user (non root user on UNIX systems).

2. CD to any production instance home.

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

4. Log out of the system.

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

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

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

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

See Section 6.1, "Information Common to OracleAS Guard asgctl Commands" and Section 6.2, "Information Specific to a Small Set of OracleAS Guard Commands" for more information.

Example

The command in the following example results in the OracleAS Guard client cloning the topology to the standby topology host system standbyinfra.

1. Check the prerequisites as described in the Usage Notes. 2. Perform the Pre-Clone steps as described in the Usage Notes. 3. Perform the Clone steps as described in the Usage Notes. a. Log in as user to any production system.

b. CD to any production instance Oracle home.

c. Invoke asgctl and perform the clone instance command. > asgctl.sh

Application Server Guard: Release 10.1.3.0.0

Successfully connected to prodoc4j:7890 ASGCTL> set primary database sys/testpwd@asdb Checking connection to database asdb

ASGCTL> clone topology to standbyinfra Generating default policy for this operation .

. .

# Command to use if you are using a policy file # clone topology to standbyinfra using policy <file> . . . ASGCTL> disconnect ASGCTL> exit >

In document Oracle Application Server (Page 141-144)