Skip Headers
Oracle® Application Server Release Notes
10g (9.0.4) for Solaris Operating System (SPARC)
Part No. B10629-15
  Go To Documentation Library
Home
Go To Table Of Contents
Contents

Previous
Previous
Next
Next
 

6 Oracle Application Server Active Failover Clusters Issues

This chapter describes issues associated with Oracle Application Server Active Failover Clusters (AFC). It includes the following topics:

6.1 General Issues and Workarounds

This section describes the general issues and their workarounds. It includes the following topics:

6.1.1 All AFC Nodes Must Be Up When Installing Middle Tiers

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.

6.1.2 Configure Database Instance to use Oracle Ultra Search Crawler

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 the wksys 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>)))
    

6.1.3 Load Balancer Failover

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.

6.1.4 Remote Listener Registration Causes Load Balancing to Fail

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.

6.1.5 Oracle Enterprise Manager Is Not Ready for Use with AFCs

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:

6.1.6 DAS Enabled Only on Installation Host

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:

  1. 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------
    
    
  2. 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.

6.1.7 Install JDBC Patches to Prevent OracleAS Single Sign-On Failure

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

6.1.8 Manual Synchronization of Files

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

6.1.9 Corruption of Baseline Configuration Files Prevents Synchronization

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:

  1. Untar the Oracle home of the computer used for the baseline configuration files.

  2. Remove the ORACLE_HOME/config/afcctl.tm file from Host B.

  3. Synchronize Host A and Host B using the affcctl command.

6.1.10 Backup/Recovery Considerations for Active Failover Cluster

Following are the backup and recovery considerations for AFC:

6.1.10.1 Accessing Archive Logs of Non-local RAC Instance

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.

  1. 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:

    1. 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.

    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.

    3. 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.

  2. Create the following directory structure on Host 2

    $ARC_DEST_DIR/arc_dest1
    $ARC_DEST_DIR/arc_dest2
    
    
  3. NFS mount arc_dest1 of Host 1 on Host 2.

  4. 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'; 
    
    

6.1.10.2 Enabling Archivelog in a RAC Instance

Perform the following steps to enable archiving in AFC:

  1. SQL> alter system set cluster_database=false scope=spfile;

  2. Shutdown immediate on both Hosts

  3. startup mount;

  4. alter database archivelog;

  5. alter database open;

  6. alter system set cluster_database=true scope=spfile;

  7. shutdown immediate;

  8. 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

6.1.10.3 Starting and Stopping of OPMN Managed Processes on AFC Hosts

  1. 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
    
    
  2. 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