Oracle® Application Server Release Notes
10g (9.0.4) for Solaris Operating System (SPARC) Part No. B10629-15 |
|
![]() Previous |
![]() Next |
This chapter describes issues associated with Oracle Application Server Active Failover Clusters (AFC). It includes the following topics:
This section describes the general issues and their workarounds. It includes the following topics:
Section 6.1.1, "All AFC Nodes Must Be Up When Installing Middle Tiers"
Section 6.1.2, "Configure Database Instance to use Oracle Ultra Search Crawler"
Section 6.1.4, "Remote Listener Registration Causes Load Balancing to Fail"
Section 6.1.5, "Oracle Enterprise Manager Is Not Ready for Use with AFCs"
Section 6.1.7, "Install JDBC Patches to Prevent OracleAS Single Sign-On Failure"
Section 6.1.9, "Corruption of Baseline Configuration Files Prevents Synchronization"
Section 6.1.10, "Backup/Recovery Considerations for Active Failover Cluster"
If you use AFC for your Metadata Repository that is registered with Identity Management, make sure the database and Net listener are running on all AFC nodes before you install a middle-tier instance to use the Identity Management and AFC Metadata Repository. Otherwise, the middle-tier installation will fail with the error: Invalid Database or Database Not Running.
For AFC installations, the Oracle Ultra Search crawler is configured to run on one of the database instances. If the database instance becomes unresponsive, a different instance of the same database must be configured to use the Oracle Ultra Search crawler.
To change the database instance that uses the Oracle Ultra Search crawler, run the following command on the new database instance:
Note: The password for thewksys schema is required for this operation.
|
SQL> @?/ultrasearch/admin/wk0reconfig.sql <instance_name> <connect_url>
<instance_name>
is the name of the new database instance on which the Oracle Ultra Search crawler will reside. You can obtain <instance_name> by running the following command on the new database instance:
SQL> select instance_name from v$instance
<connect_url>
is the jdbc connect string which guarantees connection to the specified instance
For example:
(DESCRIPTION=(ADDRESS_ LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<nodename>)(PORT=<listener_port>)))(CONNECT_ DATA=(SERVICE_NAME=<service_name>)))
When a host or process becomes unresponsive in an AFC, re-configuration of the load balancer is necessary. The load balancer should be reconfigured to stop traffic to the unresponsive host or to the specific port on which the Oracle Internet Directoryor Oracle HTTP Server process is listening on. Most load balancers have features which can be configured to do this automatically. If the load balancer you are using in your system does not provide this feature, the reconfiguration can be a manual process. Refer to your load balancer documentation for the steps to configure the load balancer you are using.
When you enable remote database listener registration in your AFC, load balancing will fail for your database connection during intense logon activity.
Refer to Section 3.2.9, "Oracle Net Listener Cross Registration Should Be Disabled for Active Failover Cluster" for the steps to disable the remote database listener registration.
Oracle Enterprise Manager is not ready for use with AFC.
Refer to the following sections for the steps to use Oracle Enterprise Manager with an AFC:
In an AFC infrastructure installation, Oracle Delegated Administration Service (DAS) will be enabled only on the installation host.
In order to configure DAS on other hosts, perform the following workaround on each additional host:
Create an ldif
(das_enable.ldif
) file with the following entry:
--- BEGIN LDIF file contents--- dn: cn=Associated Mid-tiers,orclApplicationCommonName=DASApp, cn=DAS, cn=Products,cn=OracleContext changetype: modify add: uniquemember uniquemember: orclApplicationCommonName=<InstanceName>.<node>,cn=IAS Instances, cn=IAS,cn=Products, cn=OracleContext ---END LDIF file contents------
Run the following ldapmodify command:
ldapmodify -p <OIDPort> -h <Load Balancer Name> -D cn=orcladmin -w Instance Password> -v -f das_enable.ldif
DAS should now be configured on the additional hosts.
When a database instance or host becomes unresponsive, OracleAS Single Sign-On in the OC4J_SECURITY instances automatically fails over existing database connections to the remaining database instance.
To prevent failure, install JDBC patches 2513420 and 3444173. These two patches are available at:
http://metalink.oracle.com
The AFC uses the afcctl
utility to synchronize any changes to configuration files on one host to the configuration files on other hosts of a cluster. The details for installation, configuration, and usage of the afcctl
utility are documented in the Oracle Application Server 10g High Availability Guide. However, the afcctl
utility does not synchronize all of the configuration files on hosts in an AFC. The following files must be synchronized manually:
ORACLE_HOME/dcm/config/dcm.conf
ORACLE_HOME/dcm/repository/cluster.bom
ORACLE_HOME/sysman/config/emd.properties
ORACLE_HOME/sysman/config/emiasconsole.properties
ORACLE_HOME/sysman/config/emiasconsolelogging.properties
ORACLE_HOME/sysman/emd/targets.xml
ORACLE_HOME/sysman/j2ee/config/em-app.xml
ORACLE_HOME/j2ee/home/config/jazn-data.xml
ORACLE_HOME/j2ee/home/config/jazn.xml
ORACLE_HOME/j2ee/OC4J_SECURITY
The following files are always synchronized when the afcctl sync
utility is invoked:
ORACLE_HOME/config/ias.properties
ORACLE_HOME/Apache/Apache/conf/httpd.conf
ORACLE_HOME/opmn/conf/opmn.xml
In a cluster environment consider Host A and Host B, with the baseline created from Host A. Assume that there have been some changes in the configuration files in Host A followed by a synchronization with Host B using the afcctl
command. Subsequently, if the Oracle home of Host A becomes corrupted before a backup of this host can be obtained, then an attempt to synchronize Host A from Host B using the afcctl
command will fail.
To workaround this problem:
Untar the Oracle home of the computer used for the baseline configuration files.
Remove the ORACLE_HOME/config/afcctl.tm
file from Host B.
Synchronize Host A and Host B using the affcctl
command.
Following are the backup and recovery considerations for AFC:
Section 6.1.10.1, "Accessing Archive Logs of Non-local RAC Instance"
Section 6.1.10.3, "Starting and Stopping of OPMN Managed Processes on AFC Hosts"
You can access archive logs for each instance of a Real Application Cluster (RAC) database in the local file system, in a cluster file system (CFS), or in NAS. RMAN must have access to the archive logs to back up the database.
Create the following directories on one of the hosts of the RAC. For example, on Host 1:
$ARC_DEST_DIR/arc_dest1 $ARC_DEST_DIR/arc_dest2
Note the following for your archive logs location:
Archive logs in local file system of RAC instance.
Since the hosts are within a LAN, arc_dest2
on Host1 can be an NFS mount of $ARC_DEST_DIR/arc_dest2
on Host 2.
Archive logs in a CFS archiving scheme.
The directories created in Step 1 must have read and write access to the CFS. Only the archive log files can go into the CFS storage location. Oracle does not support storing the AFC Oracle home in a CFS.
Archive logs in a remote network mounted file system.
The directories listed in Step 1 are NFS mounts with read and write access from both hosts.
Create the following directory structure on Host 2
$ARC_DEST_DIR/arc_dest1 $ARC_DEST_DIR/arc_dest2
NFS mount arc_dest1
of Host 1 on Host 2.
Create entries in the spfile
parameter.
Set the log_archive_destination
on Host 1 using the following SQL command:
SQL> alter system set log_archive_dest='$ARC_DEST_DIR/arc_dest1' scope=spfile sid='<sid of node1>';
For example:
SQL> alter system set log_archive_dest='/mnt/afc/OraDB2/dbs/arch1' scope=spfile sid='bkdb1';
Perform the following steps to enable archiving in AFC:
SQL> alter system set cluster_database=false scope=spfile;
Shutdown immediate on both Hosts
startup mount;
alter database archivelog;
alter database open;
alter system set cluster_database=true scope=spfile;
shutdown immediate;
startup (on both instances)
Note: If you complete the listed steps while the RAC instances are OPEN, you will see the following error message:ERROR at line 1: ORA-01126: database must be mounted EXCLUSIVE and not open for this operation |
Stop OPMN on each Host of the RAC using the following command:
> opmnctl @instance:<instance_on_node1>:<instance_on_node2> stopproc
For example:
opmnctl @instance:bkinst.hasun41:bkinst.hasun42 stopproc
Start OPMN on each Host of the RAC using the following command:
> opmnctl @instance:<instance_on_node1>:<instance_on_node2> startproc
For example:
opmnctl @instance:bkinst.hasun41:bkinst.hasun42 startproc