Oracle® Application Server Release Notes 10g Release 2 (10.1.2) for Linux x86 B19312-12 |
|
![]() Previous |
![]() Next |
This chapter describes issues related to highly available topologies. This chapter contains the following issues:
Section 4.1, "OracleAS Disaster Recovery: Discover Topology Command"
Section 4.2, "OracleAS Disaster Recovery: Real Application Clusters Database Supported"
Section 4.3, "OracleAS Guard Standalone Kit on Linux Systems Is Missing a File Named libcxa.so.3"
Section 4.5, "Cloning Infrastructure Using OracleAS Guard Not Supported"
Section 4.6, "Distributed Identity Management is a Supported Topology"
Section 4.7, "Correct Information for Application Server Guard clone_unpack_cmd parameter"
Section 4.8, "Clarification of Clustering for OracleAS Integration B2B"
If you run the discover topology
command on a node that contains more than one Oracle home, and one of the Oracle homes is invalid for some reason (that is, the Oracle home does not appear in the Oracle Universal Installer), the discover topology
command generates a warning:
ASGCTL> discover topology oidpass=welcome1 Discovering topology on host "hasun1" with IP address "123.45.67.89" hasun1:7890 Connecting to the OID server on host "hasun12vip1.mydomain.com" using SSL port "636" and username "orcladmin" Getting the list of databases from OID Gathering database information for SID "orcl" from host "hasun12vip1.mydomain.com" Getting the list of instances from OID Gathering instance information for "immr.hasun12vip1.mydomain.com" from host "hasun12vip1.mydomain.com" Gathering instance information for "asmid.haqadr01.mydomain.com" from host "haqadr01.mydomain.com" ********** WARNING ********** hasun1: -->ASG_IAS-15779: Error getting instance information for instance "asmid.haqadr01.mydomain.com" from host "haqadr01.mydomain.com". This instance will be excluded from the topology.xml file drmt: -->ASG_IAS-15632: The home that contains instance "asmid.haqadr01.mydomain.com" could not be found drmt: -->ASG_DUF-4950: An error occurred on host "drmt" with IP "130.35.45.23" and port "7890" ******** END WARNING ******** The topology has been discovered. A topology.xml file has been written to each home in the topology.
To work around this issue, delete the entry for the invalid Oracle home from the Inventory.xml
file in the oraInventory
directory, then rerun the discover topology
command.
Table 1-3 in the Oracle Application Server High Availability Guide incorrectly stated that OracleAS Disaster Recovery does not support OracleAS Infrastructure in active-active topologies. OracleAS Disaster Recovery does support OracleAS Infrastructure in active-active topologies, as well as active-passive topologies. In OracleAS Infrastructure active-active topologies, the OracleAS Metadata Repository runs on a Real Application Clusters database.
The following table shows the updated Table 1-3 (bold text shows the updates):
Table 4-1 Service level requirements and architecture choices
Business Requirements | Architecture Choices | |||
---|---|---|---|---|
Local High Availability | Scalability | Disaster Recovery | Instance Redundancy | Disaster Recovery |
N |
N |
N |
Base |
N |
Y |
N |
N |
Active-passive |
N |
N |
Y |
N |
Active-active |
N |
N |
N |
Y |
Base |
Y |
Y |
Y |
N |
Active-active |
N |
Y |
N |
Y |
Active-passive |
Y |
N |
Y |
Y |
Active-active (middle tier) Base (Infrastructure) |
Y |
Y |
Y |
Y |
Active-active (middle tier) Active-passive and active-active (Infrastructure) |
Y |
Note: OracleAS Disaster Recovery supports the base, active-passive, and active-active Infrastructure architectures. For additional scalability in a base, active-passive, or active-active architecture, extra computing power can be added to the infrastructure hardware (for example, high capacity CPUs, more memory) |
If after installing the OracleAS Guard standalone kit on Linux systems, you start up OracleAS Guard server with an asgctl asgctl.sh startup
command, the following DufException is returned along with other error information:
oracle.duf.DufException: oracle.duf.DufException
If you have tracing turned on, the duf_client.log
file will contain the following error message buried part way down in the trace output:
. . . java.lang.UnsatisfiedLinkError: /private/mydb/product/10.1.0/asg/dsa/lib/libOsUtils.so: libcxa.so.3: cannot open shared object file: No such file or directory . . .
If you are using standalone OracleAS Guard release 10.1.2.0.2 kit, the workaround to this problem is to copy the libcxa.so.3
file from an Oracle Application Server Oracle home in <ORACLE_HOME>/lib
to the standalone OracleAS Guard home in <ORACLE_HOME>/dsa/lib
before starting the OracleAS Guard client or server.
You must perform this libcxa.so.3
file copy operation on all systems on which you installed the OracleAS Guard release 10.1.2.0.2 standalone kit.
Chapter 13 OracleAS Disaster Recovery, Section 13.10, Runtime Operations -- OracleAS Guard Switchover and Failover Operations of the 10.1.2.0.2 Oracle Application Server High Availability Guide, states the following, "A site switchover is performed for planned outages of the production site. Both the production and standby sites have to be available during the switchover."
The term "available" means that the following components must be up and running:
Listener
DSA
Database
The following information should be included in Chapter 13 OracleAS Disaster Recovery, Section 13.8, OracleAS Guard Operations -- Standby Site Cloning of One or More Production Instances to a Standby System, of the 10.1.2.0.2 Oracle Application Server High Availability Guide:
OracleAS Guard does not support the cloning of any Infrastructure installations, including Identity Management only, Collocated IM and Metadata Repository, or MR on its own.
The "Supported Topologies" section in the Oracle Application Server High Availability Guide for 10g Release 2 (10.1.2) and later releases did not mention whether a distributed Identity Management configuration (Oracle Internet Directory and Directory Integration Platform on one host and Oracle Single Sign-On and Delegated Administration Services on a second host) is a supported topology for Oracle Application Server Disaster Recovery.
Similarly, the "Supported Topologies" section in the Oracle Application Server Disaster Recovery Guide for 10g Release 2 (10.1.2.3) also did not mention whether a distributed Identity Management configuration is a supported topology for Oracle Application Server Disaster Recovery.
The distributed Identity Management configuration is a supported Oracle Application Server Disaster Recovery topology.
The Oracle Application Server Disaster Recovery Guide for 10g Release 2 (10.1.2.3) provided incorrect information about the Oracle Application Server Guard clone_unpack_cmd
parameter in the "Configuring Oracle Application Server Guard and Other Relevant Information" section.
The following information about the Oracle Application Server Guard clone_unpack_cmd
parameter is correct and replaces the information in the Oracle Application Server Disaster Recovery Guide for 10g Release 2 (10.1.2.3):
clone_unpack_cmd
- this optional parameter specifies the tar command for Oracle Application Server Guard to use when unpacking the jar file created during a clone instance or clone topology operation. For example, by default on UNIX platforms Oracle Application Server Guard uses the version of tar returned by the which tar
command to unpack clone instance and clone topology jar files. You can use the clone_unpack_cmd parameter to specify a different version of tar and the tar command parameters for Oracle Application Server Guard to use to unpack these jar files.
Value: string, tar command and parameters to use when unpacking a jar file created during a cloning operation. For example:
clone_unpack_cmd = /sys/prod/software/tar -xpf
In the Oracle Application Server High Availability Guide, Section 5.6, "OracleAS Integration B2B", contains this paragraph:
"This tier consists of Oracle HTTP Server and the OC4J transport servlet instances. The servlets are deployed in OC4J containers and can utilize the high availability properties of the containers. They can be grouped together into OracleAS Clusters (OC4J) and be synchronized by DCM for consistent configuration. The OC4J instances are load balanced by mod_oc4j."
Some points to note:
The transport servlet is different from the B2B server.
While you can use DCM to keep the configuration of the transport servlet consistent across multiple OC4J instances, you cannot use DCM to cluster the B2B servers. The B2B servers run outside OC4J as Java applications, and they are not under the control of DCM.