Database
Middleware
Developer Tools
Enterprise Management
Applications Technology
Products A-Z

TECHNOLOGIES

BI & Data Warehousing
Embedded
Java
Linux
.NET
PHP
Security
Technologies A-Z

ARCHITECTURE

Enterprise Architecture
Enterprise 2.0
Grid
Service-Oriented Architecture
Virtualization

COMMUNITY

Join OTN
Oracle ACEs
Oracle Mix
Oracle Wiki
Blogs
Podcasts
Events
Newsletters
Oracle Magazine
Oracle Books
Certification
User Groups
Partner White Papers

Printer View

E-mail this page

Bookmark

Configuring Oracle CM SDK for RAC

Technical Brief: Configuring Oracle CM SDK for Oracle Real Application Clusters (RAC)

Author: Oracle CM SDK Team, Version 1.0, January 2004

Introduction
RAC Fundamentals
Oracle CM SDK Connect Descriptor Settings for RAC
Oracle CM SDK Load Balancing and Failover in a RAC Environment
Oracle CM SDK Configuration Tasks for RAC
Configuring OID for use with Oracle CM SDK on RAC
References

Introduction

This document describes how to configure Oracle Content Management SDK to leverage the features of Oracle Real Application Clusters (RAC). The use of RAC is mostly transparent to applications running on Oracle CM SDK; however, there is some configuration that must be performed in order for the system to run smoothly.

In this document, we first provide a fairly high-level background discussion of Real Application Clusters (RAC). We then discuss the configuration steps that must be performed to allow Oracle CM SDK to function properly with a RAC configuration. We also discuss the configuration steps required to allow Oracle CM SDK applications using Oracle Internet Directory (OID) to use RAC.

Real Application Clusters Fundamentals

A cluster is a group of computers acting together that behave like a single system. Clustering requires both hardware (interconnect) and software (clusterware) support. Traditionally, clusters were used in high availability read-only applications, such as data warehouses. These days, clusters are increasingly becoming a lower-cost approach to computing applications that require very high availability and scalability.

An Oracle Real Application Cluster (RAC) consists of two or more computers configured to interact to provide the appearance of a single Oracle database. These two or more nodes are linked by an interconnect. The interconnect serves as the communication path between each node in the cluster database. Each Oracle instance uses the interconnect for the messaging that synchronizes each instance's use of shared resources. Oracle also uses the interconnect to transmit data blocks that the multiple instances share. The primary type of shared resource is the datafiles that all the nodes access.

Real Application Clusters require that all nodes have simultaneous access to the shared disks to give the instances concurrent access to the database. The implementation of the shared disk subsystem is based on your operating system: you can use either a cluster file system, or place the files on raw devices. Cluster file systems greatly simplify the installation and administration of Real Application Clusters.

More information on RAC can be found in the references.

Figure 1: An example of a RAC Configuration

Oracle CM SDK Connect Descriptor Settings for RAC

The components of Oracle CM SDK that we need to configure for RAC are:

The Oracle CM SDK Node and HTTP Node services. These components, not to be confused with database nodes, provide the protocol servers and agents as well as service connection management and user sessions.
The Domain Controller, which is responsible for starting (bootstrapping) and monitoring the domain.
The administration tools, such as ifsctl, Oracle Enterprise Manager Application Server Control, and Oracle Enterprise Manager Grid Control. These are used for managing the Oracle CM SDK components.

When configuring Oracle CM SDK, the system administrator has two options for specifying an explicit value for the database connect descriptor of an Oracle CM SDK service configuration: either by specifying a <DatabaseUrl> entry in the registry.xml configuration file on each middle tier host, or by using the service configuration property named IFS.SERVICE.JDBC.DatabaseUrl.

Unless set by one of these two methods, this property defaults to null, which means "synthesize a minimally-defined connect descriptor from the domain name." However, if specified, this property will be used in creating the service's database connections.

Setting the DatabaseUrl property allows you to specify a connect identifier for any naming service supported by the underlying JDBC driver, such as the Local Naming Service (better known as tnsnames.ora). Note that the JDBC thin driver does not support any naming services. In the naming service, a more fully-defined connect descriptor can be defined for that connect identifier. This applies when creating an Oracle CM SDK service's database connections. Example settings are shown in the following sections.

Note: This behavior comes standard with Oracle CM SDK 10g (9.0.4) but has also been made available for Oracle CM SDK 9.0.3. To obtain this functionality, download the following patches from the ARU Web site:

ARU Patch 4940953

ARU Patch 4940956

Which value should I update?

From a RAC point of view, setting the <DatabaseUrl> entry in the registry.xml file is the preferred method since this value can be used by the Domain Controller, the management and administration tools, and the Oracle CM SDK Nodes during their operation. The only drawback is that this entry has to be set on all of the middle-tier machines.

The IFS.SERVICE.JDBC.DatabaseUrl is a convenient way of setting this parameter for all of the middle tiers from a central location using the Application Server Control. The problem is that during startup, the Domain Controller and ifsctl utility don't have access to the database, and so will need to synthesize the connect descriptor. This will still work, but will not be able to take advantage of the multiple RAC nodes and if the required listener is down, Oracle CM SDK will not be able to start up.

Note: Be sure to specify a correct value for the IFS.SERVICE.JDBC.DatabaseUrl parameter. If you specify an incorrect value, Oracle CM SDK processes cannot connect to the Oracle CM SDK schema. The only way to effectively change this parameter in this situation is to modify the value directly in the database.

So, when planning to use Oracle CM SDK in a RAC environment, Oracle Corporation recommends that you set the <DatabasUrl> property in registry.xml.

Oracle Enterprise Manager Settings for RAC

In the Application Server Control, for Oracle CM SDK SQL metrics (like Document Statistics, Documents By MIME Type, and Users) to work against a RAC database, you need to specify the target instance property DBConnectDescriptor for the Oracle CM SDK target. You can specify this in the targets.xml file in the Oracle home of the Application Server: $ORACLE_HOME/sysman/emd. The value of DBConnectDescriptor can be either a naming service connect identifier in the tnsnames.ora, or an explicit identifier for the database connect descriptor.

The Grid Control relies on a Management Agent being installed on each middle tier in its own separate Oracle home. If this Grid Control Agent is installed after you configure the Oracle CM SDK middle tier for use in a RAC environment, then the DBConnectDescriptor will be automatically configured in the targets.xml of the Grid Control Agent's Oracle home. This is done using the targets.xml values from the Application Server Control Oracle home on the Oracle CM SDK middle tier.

If a Grid Control Management Agent is installed on an Oracle CM SDK middle tier before you enable RAC support, you will need to configure DBConnectDescriptor for the Oracle CM SDK target in the targets.xml of the Grid Control Agent Oracle home. This value can be obtained from targets.xml values specified in the Application Server Control Oracle home on the Oracle CM SDK middle tier. (See Post-configuration Tasks for more information on updating the targets.xml file.)

Oracle CM SDK Load Balancing and Failover in a RAC Environment

Listener Load Balancing

Oracle RAC is a set of instances operating against the same database. The instances have a common service name, but distinct instance names. A database listener sits in front of these instances to provide load balancing across them. The listener is aware of each instance, whether it is running or down, and its load. In creating a database connection, a client generally specifies only the service name, and not the instance name, in order to defer instance selection to the listener's load balancing algorithm. This is called listener or connect load balancing.

Figure 2: Listener load balancing (for example, lsnr 1 can balance the load between both instances)

With Oracle CM SDK, in this scenario, using the default connect descriptor is fine, because it specifies the service name but not the instance name.

Client load balancing

Rather than have a single listener, there can be a set of listeners. As before, each of these listeners is aware of all instances for the database. Clients can balance connection requests across these listeners by supplying a list of listener addresses in their connect descriptor, which Net8 will use on a round-robin basis.

Figure 3: Client load balancing

Example: Sample tnsnames.ora entry enabling load balancing

RAC =
  (DESCRIPTION = 
  (ADDRESS = (PROTOCOL = TCP)(HOST = rac1)(PORT = 1521))
  (ADDRESS = (PROTOCOL = TCP)(HOST = rac2)(PORT = 1521))
  (LOAD_BALANCE = ON)
  (FAILOVER = ON)
  (CONNECT_DATA =
  (SERVICE_NAME = rac)
  (failover_mode = (type=select)(method=basic))
  )
  )

For Oracle CM SDK, the default connect descriptor specifies the hostname and port of only a single listener, and cannot balance loads across multiple listeners. However, by setting the IFS.SERVICE.JDBC.DatabaseUrl property or the <DatabaseUrl> entry in the registry.xml configuration file, Oracle CM SDK services can opt-out of the default connect descriptor and specify a connect identifier whose corresponding connect descriptor specifies a list of listeners.

Connect time failover

Another benefit of multiple listeners is fault-tolerance of listener failure. Clients can failover to alternate listeners at connect time by supplying a list of listeners in their connect descriptor.

Figure 4: When lsnr1 fails, requests can be re-routed to lsnr2

Example: Sample tnsnames.ora entry enabling failover

RAC =
  (DESCRIPTION = 
  (ADDRESS = (PROTOCOL = TCP)(HOST = rac1)(PORT = 1521))
  (ADDRESS = (PROTOCOL = TCP)(HOST = rac2)(PORT = 1521))
  (LOAD_BALANCE = off)
  (FAILOVER = ON)
  (CONNECT_DATA =
  (SERVICE_NAME = rac)
  (FAILOVER_MODE = (TYPE=SELECT)(METHOD=BASIC))
  )
  )

Transparent application failover

Transparent Application Failover (TAF) allows an existing connection to failover to another listener, without needing to reestablish the connection. The in-progress transaction must be rolled back, but there is no need to reestablish the database connection. Cursors may be optionally preserved (with a performance overhead for all normal select operations). Clients request TAF through the connect descriptor.

In Oracle CM SDK, the default connect descriptor does not specify the desired FAILOVER_MODE or the failover listeners. However, as previously stated, by setting the IFS.SERVICE.JDBC.DatabaseUrl property or the <DatabaseUrl> entry in the registry.xml configuration file, Oracle CM SDK services can opt-out of the default connect descriptor and specify a connect identifier whose corresponding connect descriptor specifies the FAILOVER_MODE and failover listeners.

Note: Network protocol timeout parameters between the middle tier application and the database tier may affect the failover operation since their values will determine the length of time that is waited before switching over to another node. It is important to ensure that these are set to an appropriately short time. On some systems, the default values for the tcp_ip_abort_interval and the tcp_keepalive_interval are set to several minutes, and this could increase the time it takes for the system to failover if a server node fails.

Oracle CM SDK Configuration Tasks for RAC

Preconfiguration

You can choose to run Oracle CM SDK against a Real Applications Clusters (RAC) database at any time, either preconfiguration or post-configuration. However, if you know that you want to point to a RAC database for your initial Oracle CM SDK deployment, performing the following preconfiguration steps allows you to specify a RAC database during the Oracle CM SDK configuration process. Note that there are additional post-configuration tasks that must also be completed.

Set the following system parameter in the RAC database: MAX_COMMIT_PROPAGATION_DELAY=1
During Oracle CM SDK configuration and operation, objects are often created and then read back straight away for various reasons, like the creation of subclasses or keeping middle-tier caches up-to-date. In a RAC configuration, looking for a data value from instance A that was committed by instance B can cause problems if instance A does not yet have the updated information. For this reason, you should set the MAX_COMMIT_PROPAGATION_DELAY to a very small value so that the information is instantaneously made available to all instances.

Setting MAX_COMMIT_PROPAGATION_DELAY to zero or to any value below 100 will have the same effect, that is to use the broadcast on commit System Change Number (SCN) generation scheme. By default the system uses a scheme called the Lamport scheme and a MAX_COMMIT_PROPAGATION_DELAY value of 700 hundredths of a second, or seven seconds. You can see this in the alert.log file ("Picked xxx scheme to generate SCNs"). The only exception to that is Tru-64: on that platform, setting MAX_COMMIT_PROPAGATION_DELAY to zero is not recommended because it causes excessive system CPU consumption. Unfortunately, zero is the default on Tru-64, so this value must be changed for this platform. Setting the parameter to anything between 1 and 99 will have the desired broadcast on commit behavior, although it will not be reported as such in the alert.log file (instead it will say "Picked Lamport Server scheme to generate SCNs"). The bottom line is that if you want to set it to a value that guarantees broadcast on commit for all platforms, select a value between 1 and 99. The fact that the parameter is a number in hundredths of a second is misleading, as anything between 1 and 99 works exactly the same way. This is recommended for both Oracle CM SDK and Oracle Files.
Ensure that the JOB_QUEUE_PROCESSES parameter is set to a value of 10 or higher. This parameter is required for running Oracle CM SDK database jobs and is typically not set high enough (it may even be 0 by default).
Make a TNS entry in the tnsnames.ora file for load balancing and connection failover options in each Oracle Home used by Oracle CM SDK. See the RAC Administrator�s Guide for more information on making a TNS entry for these options. Here is a sample TNS entry which specifies multiple hosts for use in a RAC environment using sample address values:

    ifsrac.us.oracle.com =
    (DESCRIPTION =
      (ENABLE = BROKEN)
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = TCP)(HOST = ifsrac1.us.oracle.com)(PORT = 1521))
        (ADDRESS = (PROTOCOL = TCP)(HOST = ifsrac2.us.oracle.com)(PORT = 1521))
      )
      (LOAD_BALANCE = ON)
      (FAILOVER = ON)
      (CONNECT_DATA =
        (service_name = ifsrc.us.oracle.com)
        (FAILOVER_MODE=(TYPE=select)(METHOD=basic)(RETRIES=20)(DELAY=15))
      )
    )

Configuration

Configure Oracle CM SDK, specifying the name of the RAC database on the Database Selection screen of the Oracle CM SDK Configuration Assistant.

Note: In order to use RAC, you must configure Oracle CM SDK against a specific node in the target RAC configuration, and this node must have load balancing disabled during the Oracle CM SDK configuration process.

Post-configuration Tasks

The following tasks are required after configuring Oracle CM SDK if you are using Oracle CM SDK with an Oracle RAC database.

On each middle tier, back up and then edit the registry.xml file (located in $ORACLE_HOME/ifs/common/) to add a <DatabaseUrl> entry. You can add the <DatabaseUrl> entry anywhere under the <Instance> tag. In the following example, the entry is added directly under the tag. Note that the value for tnsentry should be the same as that specified in the RAC pre-configuration steps.
The following example shows a registry.xml entry showing the setting of the <DatabaseURL> value for RAC:
```
<Instance>
<DatabaseUrl>jdbc:oracle:oci8:@my_tnsentry</DatabaseUrl>
<Domain>ifs://DBHOME:1521:dbservice:ifssys</Domain>
<DomainType>files</DomainType>
<Registered>1018925008096</Registered>
<LastModified>1028330926700</LastModified>
<LastStarted>1028329087966</LastStarted>
<Ports></Ports>
</Instance>
```
The next post-configuration step ensures that the Application Server Control and the Grid Control are correctly configured for Oracle CM SDK in a RAC environment.
On each middle tier, back up and the edit the the targets.xml file in the Oracle home of the Application Server in the folder $ORACLE_HOME/sysman/emd, so that it has the correct value for the DBConnectDescriptor parameter.

If the local tnsnames.ora (in the same Oracle home) is configured with an entry for the RAC database, for example, ifsrac.us.oracle.com, then the value of the property DBConnectDescriptor can be specified as <Property NAME="DBConnectDescriptor" VALUE="ifsrac.us.oracle.com"/>

You can also more fully specify the connect descriptor as shown in the example below. Property values in double quotes should have no line breaks or spaces.
<Target TYPE="oracle_ifs" NAME="m21i.qa8-sun.us.oracle.com_cmsdk_ifsrac1-linux.us.oracle.com:1521:ifsrac.us.oracle.com:CLSimple" DISPLAY_NAME="Content Management SDK (CLSimple)" VERSION="9.0.4.0.0" ON_HOST="qa8-sun.us.oracle.com">
<Property NAME="Version" VALUE="9.0.4.0.0"/> <Property NAME="RunReposMetric" VALUE="TRUE"/>
<Property NAME="RunResponseTimeMetric" VALUE="TRUE"/>
<Property NAME="RunLoadBalancerResponseTimeMetric" VALUE="FALSE"/>
<Property NAME="IfsRootHome" VALUE="/data/m21i/ifs"/>
<Property NAME="IfsHome" VALUE="/data/m21i/ifs/cmsdk"/>
<Property NAME="DomainName" VALUE="ifs://ifsrac1-linux.us.oracle.com:1521:ifsrac.us.oracle.com:CLSimple"/>
<Property NAME="DomainType" VALUE="cmsdk"/>
<Property NAME="SchemaPassword" VALUE="c838cb5e9930c1cd" ENCRYPTED="TRUE"/>
<Property NAME="SysadminUsername" VALUE="system"/>
<Property NAME="SysadminPassword" VALUE="7f25b7470f060c85d10d95d959d7151b" ENCRYPTED="TRUE"/>
<Property NAME="ApplicationUrl" VALUE="http://qa8-sun.us.oracle.com:7777/cmsdk/admin"/>
<Property NAME="LoadBalancerUrl" VALUE=""/>
<Property NAME="DBConnectDescriptor" VALUE="(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=ifsrac1.us.oracle.com)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=ifsrac2.us.oracle.com)(PORT=1521)))(CONNECT_DATA=(service_name=ifsrc.us.oracle.com)(FAILOVER_MODE=(TYPE=select)(METHOD=basic)(RETRIES=20)(DELAY=15))))"/> <CompositeMembership>
<MemberOf TYPE="oracle_ias" NAME="m21i.qa8-sun.us.oracle.com"/>
</CompositeMembership>
</Target>
If you have installed the Grid Control Management Agent before you install Oracle CM SDK on a middle-tier machine, then you will have to ensure that the targets.xml file in the Oracle home for the Management Agent is updated with the DBConnectDescriptor property information that you added to the Application Server Oracle home targets.xml file.

Configuring Oracle Internet Directory for use with Oracle CM SDK on RAC

When Oracle CM SDK is used in conjunction with Oracle Internet Directory for user management, it relies on OID being able to post events to Oracle CM SDK via its database. For this to happen correctly in a RAC database environment, OID has to be made aware that Oracle CM SDK is in fact running against a RAC database.

For OID, it is not enough to just set the appropriate entries in the tnsnames.ora file. You must also specify the database service information in an input parameter file that uses the LDAP Data Interchange Format (LDIF).

This section describes the steps required to configure your Oracle Internet Directory (OID) installation to work with Oracle CM SDK running in a RAC configuration, including specifying the LDIF syntax-compliant configuration information. There are five major steps to perform:

Configure the TNS entry for the OID server so that it can properly handle the multiple RAC database instances.
Find the Oracle CM SDK application Global Unique Identifier (GUID).
Obtain the OID provisioning profile name and interface connect information. This will be used to supply the RAC database service information to the OID server.
Create an LDIF-compliant parameter file using the information obtained in the previous steps.
Update OID with the RAC database service information.

Step 1 - Configure the TNS Entry for the OID Server

Create the following TNS entry in $ORACLE_HOME/network/admin/tnsnames.ora file on the OID machine (on the machine where the DIP server is running) for RAC configuration. You will have to provide the appropriate addresses for your configuration.

	ifsrac.us.oracle.com =
	  (DESCRIPTION =
	  (ENABLE = BROKEN)
	  (ADDRESS_LIST =
	  	(ADDRESS = (PROTOCOL = TCP)(HOST = ifsrac1.us.oracle.com)(PORT = 1521))
	  	(ADDRESS = (PROTOCOL = TCP)(HOST = ifsrac2.us.oracle.com)(PORT = 1521))
	  )
	(CONNECT_DATA =
		(service_name = ifsrc.us.oracle.com)
		(FAILOVER_MODE=
			(TYPE=select)
			(METHOD=basic)
			(RETRIES=20)
			(DELAY=15))
		)
	)

Step 2 - Finding the Application Global Unique Identifier

The application Globally Unique Identifier (GUID) allows us to retrieve and update the Oracle CM SDK application information stored in the OID repository. For historical reasons, the common name used for Oracle CM SDK is "IFS."

On your OID server, execute the following command:


  ldapsearch -h <oid host> -p <oid port> -D cn=orcladmin -w <oid 
  orcladmin password> -b "cn=IFS,cn=Products,cn=OracleContext" -s 
  sub "ObjectClass=*" orclguid

Each returned result will appear in the following format:


orclApplicationCommonName=<DB Host Name>:<DB Listener Port>:<DB Service Name>:<CM SDK Schema Name>,cn=IFS,cn=Products,cn=OracleContext
 
orclguid=<32 character GUID>

The following lines are an example of the format of the information returned from the ldapsearch command:

orclApplicationCommonName=database1.us.oracle.com:1521:orcl:IFSSYS,cn=IFS,cn=Products,cn=OracleContext orclguid=C80BC6C12F1A1C20E034080020B4F232 orclApplicationCommonName=database2.us.oracle.com:1521:orcl:IFSUSER,cn=IFS,cn=Products,cn=OracleContext orclguid=C89DE53A0EC51B49E034080020B4F232

There may be more results, but there should be at least one.

From the result obtained in the previous step, find out which orclApplicationCommonName value matches the Oracle CM SDK domain you are working with. Note its GUID, indicated by the orclguid parameter, and write it down or save it to a file, as you will need it in subsequent steps. This GUID is called the Application GUID. We will refer it to as appguid from now on.

Step 3 - Obtain the OID Provisioning Profile Name and Interface Connect Information

Now execute the following command, substituting the appguid from the previous ldapsearch command:

ldapsearch -h <oid host> -p <oid port> -D cn=orcladmin -w <oid orcladmin password> -b "cn=Provisioning Profiles, cn=Changelog Subscriber, cn=Oracle Internet Directory" -L -v -s sub "orclODIPProfileName=*_<appguid>" orclodipprofileinterfaceconnectinformation

You should get a result in the following format:

dn: orclODIPProfileName=<some 32 digit GUID>_<appguid>, cn=Provisioning Profiles, cn=Changelog Subscriber, cn=Oracle Internet Directory orclodipprofileinterfaceconnectinformation: <DB Host Name>:<DB Listener Port>:<DB Service Name>:<CM SDK Schema Name>$id:<20 character schema password>

For example:

dn: orclODIPProfileName=C7A54DF5C1402607E034080020B4F232_C80BC6C12F1A1C20E034080020B4F232, 
cn=Provisioning Profiles, cn=Changelog Subscriber, cn=Oracle Internet Directory 
orclodipprofileinterfaceconnectinformation: database1.us.oracle.com:1521:orcl:ifssys$id:ZEISOAUNVFCQRNPKMHOF

Step 4 - Create an LDIF-Compliant Parameter File

Create a text file (for example, updateoid) containing the following four lines based on the values obtained so far (the line numbers were added for clarity and are not present in the actual file):

1 dn: orclODIPProfileName=C7A54DF5C1402607E034080020B4F232_C89DE53A0EC51B49E034080020B4F232, cn=Provisioning Profiles, cn=Changelog Subscriber, cn=Oracle Internet Directory 2 changetype: modify 3 replace: orclodipprofileinterfaceconnectinformation 4 orclodipprofileinterfaceconnectinformation: database1.us.oracle.com:1521:orcl:ifssys$id:ZEISOAUNVFCQRNPKMHOF

The first and fourth lines have been copied from the result obtained from the previous step. Change the fourth line so that it uses the RAC service name entry from the tnsnames.ora file entries created in Step 1. For example,

orclodipprofileinterfaceconnectinformation: database1.us.oracle.com:1521:orcl:ifssys$id:ZEISOAUNVFCQRNPKMHOF

becomes

orclodipprofileinterfaceconnectinformation: DBSVC=ifsrac.us.oracle.com:ifssys$id:ZEISOAUNVFCQRNPKMHOF

Here is an example of a complete update file:

dn: orclODIPProfileName=C7A54DF5C1402607E034080020B4F232_C89DE53A0EC51B49E034080020B4F232, cn=Provisioning Profiles, cn=Changelog Subscriber, cn=Oracle Internet Directory 
changetype: modify 
replace: orclodipprofileinterfaceconnectinformation 
orclodipprofileinterfaceconnectinformation: DBSVC=ifsrac.us.oracle.com:ifssys$id:ZEISOAUNVFCQRNPKMHOF

Caution: Unnecessary space characters in the LDIF input file, such as a space at the end of an attribute value, will cause the LDAP operations to fail.

Step 5 - Update OID with the RAC Database Service Information

On your OID server, execute the following command:

 ldapmodify -h <oid host> -p <oid port> -D cn=orcladmin -w <oid 
orcladmin password> -f updateoid

Your OID instance is now configured to run against an Oracle CM SDK schema which has been created on a RAC database.

The exact syntax of the ldapmodify command and how to use the command can be found in the Oracle Internet Directory Administrator's Guide Release 9.2.