Oracle Internet Directory (OID) and Real Application Cluster (RAC) database : Things you must know

Oracle Internet Directory (OID) uses database as the persistent store for its data (users, group, access control, configuration….). Oracle Database can be configured in number of high availability configuration including RAC (Real Application Cluster) database, Oracle Data Guard, Cold Failover Cluster …

This post covers considerations for Oracle Internet Directory configured with a high availability Oracle database, Oracle Real Application Clusters (RAC).

OID 11g consists of two type of components
a) Java Components (running on WebLogic) – DIP , ODSM
b) System Component – OID LDAP processes

Communication from Oracle Internet Directory (OID LDAP Server, odsm, dip, replication) to database can be

  • Java-based OID components deployed to Oracle WebLogic Server (ODSM, DIP)
  • Java-based OID components that are standalone Java Clients
  • Non-Java or System components for OID (C-based application) like OID LDAP Server

.

a) Java-based OID components deployed to Oracle WebLogic Server – For establishing connection pools, Oracle Fusion Middleware supports only “multi data sources” for the Oracle RAC back end. To know more about data source & multi data sources click here and here

Multi Datasource can be configured either using Fusion Middleware Control (em), Configuration Wizard (config.sh) or usign WebLogic Scripting Tool (WLST)

When an Oracle RAC node or instance fails, session requests are redirected to another node in the cluster, either by Oracle WebLogic Server or by the Oracle Thin driver. There is no failover of existing connections, however, new connection requests from the application are managed using existing connections in the Oracle WebLogic pool or by new connections to the working Oracle RAC instance. In-flight transactions are typically rolled back when the database is the transaction manager. When the WebLogic Server is the Transaction Manager, in-flight transactions are failed over, meaning they are driven to completion or rolled back, based on the state of the transaction at the time of the failure. The data sources that form a multi data source are accessed using a round-robin scheme (recommended configuration)

.

b) Java-based OID components that are standalone Java Clients

Java J2SE-based Oracle Fusion Middleware components can be deployed to use both the Oracle thin JDBC driver, or the OCI (Oracle Call Interface) based JDBC drivers.

– JDBC Thin client is a pure Java, Type IV driver and communicates with the database using TTC (Two task Common) protocol
– The JDBC OCI client is a Type II driver and provides connections to JDBC clients over the Oracle Net protocol.

c) Non-Java / System Component – These are applications written in C like OID ldap server. These components use the “Oracle Call Interface (OCI)” layer to interact with Oracle databases OID components.  High availability Event Notification provides a signal to the non-Java application if database failure occurs. Oracle Internet Directory integrates with high availability Event Notification. With high availability Event Notification, connections are automatically broken and cleaned up by OCI (Oracle Call Interface) and the application callback is invoked within seconds of failure.

.

OID (11.1.1.2 and lower) Non-Java (SYSTEM) supports only TAF (Transparent application Failover). FCF (Fast Connection Failover is not supported). More on TAF here

1. TAF is configured using either client-side specified TNS connect string or using server-side service attributes. However, if both methods are used to configure TAF, the server-side service attributes will supersede the client-side settings. The server-side service attributes are the preferred way to set up TAF in OID.

2. TAF can operate in one of two modes Session Failover and Select Failover. This is denoted by FAILOVER_TYPE in V$SESSION
a) Session Failover will re-create lost connections and sessions (SESSION)
b) Select Failover will replay queries that were in progress (SELECT)

Third value NONE means No failover configured.

SELECT is recommended mode.

3.  TAF used METOHD to determines how fast failover occurs from the primary node to the backup node.
a) BASIC – Set to establish connections at failover time. This option requires almost no work on the backup server until failover time.
b) PRECONNECT – Set to pre-established connections. This provides faster failover but requires that the backup instance be able to support all connections from every supported instance.

4. To create database service and configure server-side Transparent Application Failover (TAF) settings use

SQL> EXECUTE
DBMS_SERVICE.CREATE_SERVICE(
SERVICE_NAME => ‘oid.mycompany.com‘,
NETWORK_NAME => ‘oid.mycompany.com‘,
AQ_HA_NOTIFICATIONS => TRUE,
FAILOVER_METHOD => DBMS_SERVICE.FAILOVER_METHOD_BASIC,
FAILOVER_TYPE => DBMS_SERVICE.FAILOVER_TYPE_SELECT,
FAILOVER_RETRIES => 5, FAILOVER_DELAY => 5);

and then add service to database and assign to RAC database instances using SRVCTL

srvctl add service -d oid -s oid -r racnode1,racnode2

5. To verify TAF configuration in OID database use

SQL> SELECT MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER, COUNT(*)
FROM V$SESSION
GROUP BY MACHINE, FAILOVER_TYPE, FAILOVER_METHOD, FAILED_OVER;

.

References/Related

About the Author Masroof Ahmad

Leave a Comment:

5 comments
Add Your Reply