1. Tuning Performance Guide
  2. Oracle Identity and Access Management
  3. Oracle Internet Directory Performance Tuning

11 Oracle Internet Directory Performance Tuning

This chapter provides guidelines for tuning and sizing an Oracle Internet Directory installation.

It contains these topics:

Parent topic: Oracle Identity and Access Management

About Oracle Internet Directory

Oracle Internet Directory is Oracle's Lightweight Directory Application Protocol (LDAP) version 3 Directory Server.

Oracle Internet Directory is highly scalable, available, and manageable. It has a multi-threaded, multiprocess, multi-instance process architecture with Oracle Database as the directory store. This unique physical architecture enables Oracle Internet Directory to be deployed on several hardware architectures including Symmetric Multi-Processor (SMP), Non-Uniform Memory Access (NUMA) and Cluster hardware. Oracle Internet Directory's physical architecture enables linear performance scalability with hardware resources and numerous high availability configurations.

For more information see Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

Note:

Oracle Internet Directory's ready—to—use configuration is not optimal for most production or test deployments. You must follow at least the steps listed in Section 23.3, "Basic Tuning Considerations" to achieve optimal performance and availability.

Parent topic: Oracle Internet Directory Performance Tuning

Monitoring Oracle Internet Directory Performance

To identify performance bottlenecks, you can monitor real-time performance metrics for the Oracle Internet Directory database. For more information on how to monitor other Oracle Fusion Middleware components, see Monitoring.

Parent topic: Oracle Internet Directory Performance Tuning

Monitoring Performance on UNIX and Windows Systems

Knowledge of the following tools is recommended for Linux, Solaris, and other UNIX-like operating systems:

Tool Description

top

Displays the top CPU consumers on a system

vmstat

Shows running statistics on various parts of the system including the Virtual Memory Manager

mpstat

Shows an output similar to vmstat but split across various CPUs in the system. This is available on Solaris only.

iostat

Shows the disk I/O statistics from various disk controllers

sar

Collect, report, or save system activity information.

Knowledge of the following tools is recommended for Microsoft Windows:

Tool Description

Windows Performance Monitor

Provides a customized view of the events in the system

Windows Task Manager

Provides a high level output (like top on UNIX) of the major things happening in the system.

Knowledge of the following tools is recommended for the Oracle Database:

  • utlbstat.sql and utlestat.sql, or statspack

  • The ANALYZE function in the DBMS_STATS package

    See Also:

In addition to the operating system tools, the LDAP applications being used in a customer environment must be able to provide latency and throughput measurement.

In addition, the Database Statistics Collection Tool (oidstats.sql), located at $ORACLE_HOME/ldap/admin, is provided to analyze the various database 'ods' schema objects to estimate the statistics. See Updating Database Statistics by Using oidstats.sql.

Parent topic: Monitoring Oracle Internet Directory Performance

Updating Database Statistics by Using oidstats.sql

Database statistics are updated automatically, OIDMON runs oidstats.sql for every configured number of updates to the database. By default, for every 5000 entries added OIDMON runs the oidstats.sql. This frequency can be changed using ldapmodify commad as shown below 

$ORACLE_HOME/bin/ldapmodify -p <oidPort> -h <oidHost> -D cn=orcladmin -w <adminPassword> << eof
dn:  cn=configset,cn=oidmon,cn=subconfigsubentry
changetype: modify
replace: orclstatsperiodicity
orclstatsperiodicity: <desired_number>
eof

See Also:

The oidstats.sql command-line tool reference in Reference for Oracle Identity Management

Parent topic: Monitoring Oracle Internet Directory Performance

Setting Performance-Related Replication Configuration Attributes

To set the replication attributes, you can use either the Replication Wizard in Oracle Enterprise Manager Fusion Middleware Control or the command line.

The attributes orclthreadspersupplier, orclchangeretrycount, and orclconflresolution are replication configuration set attributes.

See Also:

for information about

The attributes orclhiqschedule and orclupdateschedule are replication agreement entry attributes.

See Also:

See Also:

  • "Setting Up a One-Way, Two-Way, or Multimaster LDAP-Based Replication Agreement by Using the Replication Wizard in Fusion Middleware Control" in Administering Oracle Internet Directory or information on setting replication attributes by using the Replication Wizard.

  • "Configuring Attributes of the Replication Configuration Set by Using ldapmodify" in Administering Oracle Internet Directory.

Parent topic: Monitoring Oracle Internet Directory Performance

Managing System Configuration Attributes

You can set most performance-related system configuration attributes from Oracle Enterprise Manager Fusion Middleware Control or from the command line. You can also use the Data Browser in Oracle Directory Services Manager to modify system configuration attributes.

For information on setting system configuration attributes for Oracle Internet Directory, see "Managing System Configuration Attributes" in the Administering Oracle Internet Directory:

Parent topic: Monitoring Oracle Internet Directory Performance

Setting Garbage Collection Configuration Attributes

The attributes orclpurgetargetage and orclpurgeinterval reside in the changelog purging configuration entry. You can change them with ldapmodify or Oracle Directory Services Manager.

Parent topic: Monitoring Oracle Internet Directory Performance

Modifying Changelog Purging Attributes by Using ldapmodify

The following example is an LDIF file used to configure change log purging.

See Also:

"Change Log Purging" in Administering Oracle Internet Directory for a description of change log purging.

This example configures time-based purging for 120 hours (5 days). Use an LDIF file similar to this:

dn: cn=changelog purgeconfig,cn=purgeconfig,cn=subconfigsubentry
changetype:modify
replace: orclpurgetargetage
orclpurgetargetage: 240

To apply the LDIF file mod.ldif, type: 

ldapmodify -D "cn=orcladmin" -q -p port -h host -D dn -q -f mod.ldif

See Also:

"Configuring Time-Based Change Log Purging" in Administering Oracle Internet Directory.

Parent topic: Setting Garbage Collection Configuration Attributes

Modifying Changelog Purging in Oracle Directory Services Manager

You can modify orclpurgetargetage and orclpurgeinterval by using the data browser in Oracle Directory Services Manager. You cannot navigate to the changelog purging configuration entry directly in the data tree, but you can get to it by using an advanced search as follows:

  1. On the Data Browser tab, click Advanced.

  2. Expand Garbage Collection in the left pane, then select changelog purgeconfig. The Garbage Collector Window appears in the right pane.

  3. In the right pane, enter the changes you want to make to the Purge Target Age and Purge Interval.

  4. Choose Apply.

Basic Tuning Considerations

Tuning is the adjustment of parameters to improve directory performance. The default Oracle Internet Directory configuration must be tuned in almost all deployments. Please review the requirements and recommendations in this section carefully.

Parent topic: Oracle Internet Directory Performance Tuning

Database Parameters

The suggested minimum values for Oracle Database instance parameters are described in Table 11-1:

Table 11-1 Minimum Values for Oracle Database Instance Parameters

Parameter Value Notes

sga_target and

sga_max_size

1700M for 32-bit systems

Applicable when SGA Auto Tuning using sga_target and sga_max_size is being used. Especially important for bulkdelete performance.

A higher value may be required if the directory size exceeds 1 million entries or a high rate of I/O is observed. In case of 64-bit systems, one can go up to 60-70% of the RAM available for the Oracle Database on the box.

db_cache_size

1200M for 32-bit systems.

Applicable when SGA Auto Tuning using sga_target and sga_max_size is not being used. (SGA auto tuning using sga_target and sga_max_size is recommended instead of this parameter.)

A higher value may be required if the directory size exceeds 1 million entries or a high rate of I/O is observed. In case of 64-bit systems, one can go up to 60-70% of the RAM available for the Oracle Database on the box.

shared_pool_size

300M

Applicable when SGA Auto Tuning using sga_target and sga_maxsize is not being used

session_cached_cursors

100

processes

500

pga_aggregate_target

300M

Before performing a large bulkload operation, set this to 1-4GB, if sufficient RAM is available. Set it back after the operation has completed

job_queue_processes

1 or more.

Tune this parameter only if you are using Advanced Replication-based multimaster replication

max_commit_propagation_delay

99 or lower

Tune this parameter only in Oracle RAC Database deployments, RDBMS v10.1.

See the Oracle Database Performance Tuning Guide for information on setting Oracle Database instance parameters.

Parent topic: Basic Tuning Considerations

LDAP Server Attributes

The recommendations in this section are summarized in Table 11-2.

  • Tune the number of processes and threads for the Oracle Internet Directory server instance that services LDAP application traffic. This has a major impact on overall performance. See the recommended settings for orclmaxcc and orclserverprocs in Table 11-2.

  • Disable change log generation if you are not deploying either replication or Oracle Directory Integration Platform. Set the attribute orclgeneratechangelog to 0.

  • Skip referrals in LDAP searches if you have no referral entries in the directory. Set orclskiprefinsql to 1. This can have a major impact on performance.

  • Close idle LDAP connections after a period of time instead of leaving them open. This prevents the unnecessary buildup of connections. For example, you can set orclldapconntimeout to 60 minutes.

    As of 10g (10.1.4.0.1), you can only set this for users who are not configured for operation statistics tracking. Connections by users configured for statistics collection do not time out as per this setting.

    See Also:

    "Configuring a User for Statistics Collection by Using Fusion Middleware Control" in Administering Oracle Internet Directory.

  • If no clients require detailed MatchDN information when the Base DN of an LDAP search operation is not present in the directory, disable it. Change orclmatchdnenabled to 0.

The following values are appropriate for most deployments:

Table 11-2 LDAP Server Attributes to Tune

Attribute Default Recommended Value Notes

orclmaxcc

2

10

Server restart required.

orclserverprocs

1

Number of CPU cores on the system

orclskiprefinsql

0

1

This change is highly recommended. Do not change if you have LDAP referral entries. LDAP referral entries are not common.

Server restart required.

orclgeneratechangelog

1

0

Disable change log generation only if you do not deploy either replication or Oracle Directory Integration Platform.

orclldapconntimeout

0 (no timeout)

Varies, 60 minutes is reasonable

Users configured for statistics tracking do not time out.

orclmatchdnenabled

1

0

Disable only if no application needs detailed MatchDN information when base DN of a search is not present.

For information about configuring orclserverprocs, orclldapconntimeout, and orclmatchdnenabled with Oracle Enterprise Manager Fusion Middleware Control, see "Attributes of the Instance-Specific Configuration Entry" in the Administering Oracle Internet Directory.

For information about configuring orclskiprefinsql or orclmatchdnenabled with Oracle Enterprise Manager Fusion Middleware Control, see "Configuring Shared Properties" in the Administering Oracle Internet Directory.

For information about configuring these attributes, as well as orclgeneratechangelog, from the command line, see "Setting System Configuration Attributes by Using ldapmodify" in the Administering Oracle Internet Directory.

Parent topic: Basic Tuning Considerations

Database Statistics

If you use LDAP commands to add a large number entries to Oracle Internet Directory, it can affect directory performance. If this occurs, update the database statistics. See Updating Database Statistics by Using oidstats.sql.

Typically, you only need to do this when you add entries in bulk for the first time after installing the Oracle Internet Directory. You do not need to do it again because the database statistics are updated nightly automatically. If, however, you suddenly experience slow LDAP operations, without a corresponding change in data footprint, consider running oidstats.sql once to see if that improves performance. The impact may be due to changes in database SQL execution plans, which oidstats.sql can help to improve.

You do not need to update database statistics if you use the bulkload tool to add the entries. The bulkload command automatically updates the database statistics.

Parent topic: Basic Tuning Considerations

Low-Priority Tuning Considerations

This section describes attributes that can sometimes improve performance, but are considered low-priority.

Parent topic: Basic Tuning Considerations

Number of Entries to be Returned by a Search

The attribute orclsizelimit controls the maximum number of entries to be returned by a search. The default value is 10000. Setting it very high impacts server performance. It also plays a role in limiting the maximum number of changelogs the replication server can process at a time.

See "Setting System Configuration Attributes by Using ldapmodify" in the Administering Oracle Internet Directory.

Enabling the Group Cache

The instance-specific subentry attribute orclenablegroupcache controls whether privilege groups and ACL groups are cached. Using this cache can improve the performance of access control evaluation for users.

Use the group cache when a privilege group membership does not change frequently. If a privilege group membership does change frequently, then it is best to turn off the group cache. It is important to note that computing a group cache may affect performance. The default is 1 (enabled). Change to 0 (zero) to disable.

See "Setting System Configuration Attributes by Using ldapmodify" in the Administering Oracle Internet Directory.

Timeout for Write Operations

When an LDAP client initiates an operation, then does not respond to the server for a configured number of seconds, the server closes the connection. The number of seconds is controlled by the orclnwrwtimeout attribute of the instance-specific configuration entry. The default is 30 seconds.

You can modify orclnwrwtimeout by using Fusion Middleware Control or the command line. See "Attributes of the Instance-Specific Configuration Entry" in the Administering Oracle Internet Directory.

Advanced Tuning Considerations

After you have performed the modifications recommended in the previous section, you can make additional changes that are specific to your deployment. Consider carefully whether the recommendations in this section are appropriate for your environment.

Parent topic: Oracle Internet Directory Performance Tuning

Replication or Oracle Directory Integration Platform

When you deploy Oracle Internet Directory with the Oracle Directory Integration Platform or with replication, you can improve performance by having a dedicated LDAP server instance for those two servers. This allows the default Oracle Internet Directory LDAP instance to serve the LDAP application traffic and the second instance to serve LDAP requests from the replication and Oracle Directory Integration Platform servers.

  1. Create an additional server instance, as described in the chapter "Managing Oracle Internet Directory Instances" in Administering Oracle Internet Directory.
  2. Set orclmaxcc to 10 and orclserverprocs to 1 in the new instance configuration.
  3. Restart the server, as described in the chapter "Managing Oracle Internet Directory Instances" in Administering Oracle Internet Directory.
  4. Set the SSL and non-SSL ports used by the new instance and configure the replication and Oracle Directory Integration Platform to point to them.

To configure orclmaxcc and orclserverprocs, see "Attributes of the Instance-Specific Configuration Entry" in the Administering Oracle Internet Directory. and "Setting System Configuration Attributes by Using ldapmodify" in the Administering Oracle Internet Directory.

Note:

In an Oracle Internet Directory Cluster configuration (rack-mounted or multi-box), the replication server must be started on one hardware node only. The LDAP server instance dedicated to replication must be started on the same node. The Oracle Directory Integration Platform server can be on a different node.

Parent topic: Advanced Tuning Considerations

Replication Server Configuration

The following recommendations can be useful when replication traffic is heavy. Be sure you understand the trade-offs before making these changes. The recommended values are summarized in Table 11-3.

  • If you are deploying a single master with read-only replica consumers, you may reduce performance impacts by turning off conflict resolution. To do so, change the value of orclconflresolution to 0.

  • If the supplier is a bottleneck, increase orclthreadspersupplier on the supplier. You can also increase orclthreadspersupplier at the consumer if is a bottleneck, but be aware that increased parallelism causes race conditions in the application of changelogs, resulting in more human intervention queue (HIQ) changes.

  • Decrease orclchangeretrycount so that new changelogs get more resources. If there are conflicts, however, this increases the human intervention queue (HIQ) changes.

  • Change orclupdateschedule to 0 to make the server process changelogs immediately, instead of at the default, 60-second intervals. Do this on both the supplier and consumer.

  • Increase the orclhiqschedule to a higher value. For example, if accessing the human intervention queue (HIQ) four times a day is sufficient and appropriate for your deployment, set the orclhiqschedule to 21600 seconds (6 hours).

Table 11-3 summarizes these recommendations.

Table 11-3 Replication Attributes

Attribute Default Recommended Value Notes

orclthreadspersupplier

transport=1

apply=5

Set transport threads to 1 and apply threads to 10 or greater

Most useful if the supplier is the bottleneck.

orclchangeretrycount

10

4

Provides more resources to changelogs but might increase HIQ.

orclupdateschedule

60 seconds

0

Causes changelogs to be processed immediately

orclhiqschedule

600 seconds

21600 seconds

Provides more resources to process new changes.

orclconflresolution

1

0

Change only if you are deploying a single master with read-only replica consumers.

See Setting Performance-Related Replication Configuration Attributes for information on setting these replication attributes.

Parent topic: Advanced Tuning Considerations

Garbage Collection Configuration

By default, Oracle Internet Directory runs database jobs to purge change logs, server manageability statistics, and other data beginning at midnight, with each job starting 15 minutes after the previous one. You can change this configuration to suite your deployment needs by modifying the parameters shown in Table 11-4.

Table 11-4 Garbage Collection Configuration Parameters

Parameter Value Notes

orclpurgetargetage

Less than 10days (240 hours)

Only if there is no requirement to retain change logs

orclpurgeinterval

6–12 hours

You can modify these attributes by using ldapmodify or Oracle Directory Services Manager. See Setting Garbage Collection Configuration Attributes.

Parent topic: Advanced Tuning Considerations

Oracle Internet Directory with Oracle RAC Database

As described in Replication Server Configuration, you can have a dedicated LDAP server for Oracle Directory Integration Platform and replication, in addition to the default server. In an Oracle Internet Directory Cluster, start the default LDAP instance on all Oracle Internet Directory nodes, but start the dedicated instance only on the node where Oracle Directory Integration Platform and replication are running.

Consider carefully which database instance Oracle Internet Directory should connect to:

  • You can configure the Oracle Internet Directory for load balancing between Oracle Database instances in the cluster, or failover mode.

  • If you use a dedicated LDAP server instance for replication and Oracle Directory Integration Platform, you can configure the connection strings of that instance for failover. You would use the following in tnsnames.ora: 

    (FAILOVER=ON)(LOAD_BALANCE=OFF)

  • When performing a bulk operation, such as bulkload, connect the tool to just one Oracle Database instance for the entire operation.

  • Configure Oracle Internet Directory instances as follows:

    • One Oracle Internet Directory instance on each of the nodes to service LDAP application traffic

    • An instance of the Oracle Internet Directory replication server and Oracle Directory Integration Platform server on one node

Parent topic: Advanced Tuning Considerations

Password Policies and Verifier Profiles

Oracle Internet Directory has password policies and password verifier profiles enabled out of box. If Oracle Internet Directory is not required to enforce password policies in a given deployment, then the password policies can be disabled. The password verifier profiles enabled out of box control the generation of certain password verifiers required by Oracle products like Enterprise User Security and Oracle Collaboration Suite. If Oracle Internet Directory is not being deployed for other Oracle products, you can disable all the password verifier profiles.

You can disable password policies and password verifiers by using Oracle Directory Services Manager or ldapmodify.

See Also:

Parent topic: Advanced Tuning Considerations

Server Entry Cache

The Oracle Internet Directory server entry cache enables LDAP entries to be cached on the Oracle Internet Directory server process heap for better performance. Configuring the entry cache provides benefits if, and only if, all or most entries can be cached.

Note:

The server entry cache is beneficial for small directory deployments only. Some of the tuning recommendations here contradict the tuning recommendations in the earlier sections. Review the applicability of entry cache to a given deployment and incorporate the tuning mentioned in this section only if all considerations enumerated here are met.

Parent topic: Advanced Tuning Considerations

Benefits of Using the Entry Cache

One of the key benefits of using the entry cache is that the LDAP search operations with base scope are about five times as fast. This applies only when all or most entries can be cached. A cache miss is more expensive than disabling the entry cache.

Parent topic: Server Entry Cache

Values for Configuring the Entry Cache

You can configure and optimize the server entry cache by setting the values shown in Table 11-5.

Table 11-5 Server Entry Cache Configuration

Attribute Default Recommended Value Notes

orclmaxcc

2

10

Restart the server after changing this attribute.

orclserverprocs

1

Total number of cores on the system.

orclecacheenabled

2

2

orclecachemaxsize

200000000 Bytes

Total size of the directory, in bytes

To determine the optimal setting for this attribute, use the number of entries in the Directory Information Tree and multiply by the average entry size.

Estimate three times the size of the entries in LDIF format.

orclecachemaxentries

100000

Total number of entries in the DIT

orclecachemaxentsize

1000000

Size, in bytes, of the largest entry in the DIT

The largest entry is usually a group entry or an entry with binary attribute values.

For example, if the total size of the Directory Information Tree is 300K and the total size of 300K entries in LDAP Data Interchange Files (LDIF) format is 500M, you would set orclecacheenabled to 1, orclecachemaxsize to 1,500,000,000, and orclecachemaxentries to 300,000. If the size of the largest group entry or entry with binary value is 10M, you would set orclecachemaxentsize to 10,000,000.

To obtain the number of entries in the Directory Information Tree, use the following command:

sqlplus ods@oiddb
select count(*) from ct_dn;
 
oidctl connect=oiddb status -diag

The following example shows the oidctl connect=oiddb status -diag command output: 

  +--------------------------------------------------------------------------+
  | Process      |  PID   |   InstName    |  CompName   |Inst#| Port | Sport |
  +--------------------------------------------------------------------------+
  | oidmon       |   8192 |         inst1 |        oid1 |    0|      |       |
  +--------------------------------------------------------------------------+
  | oidldapd disp|   8201 |         inst1 |        oid1 |    1| 5678 |     0 |
  | oidldapd serv|   8205 |         inst1 |        oid1 |    1| 5678 |     0 |
  | oidldapd serv|   8209 |         inst1 |        oid1 |    1| 5678 |     0 |
  | oidldapd serv|   8213 |         inst1 |        oid1 |    1| 5678 |     0 |
  | oidldapd serv|   8217 |         inst1 |        oid1 |    1| 5678 |     0 |
  | Config   DN  | cn=oid1,cn=osdldapd,cn=subconfigsubentry                  |
  +--------------------------------------------------------------------------+
 
 
  +--------------------------------------------------------------------------+
  |Printing LDAP Operation in progress status ...                          |
  +--------------------------------------------------------------------------+
  +--------------------------------------------------------------------------+
    OIDLDAPD_PID: 8205 WorkerID: 8 DBSID: 168 DBPID: 8245 ==> IDLE
  +--------------------------------------------------------------------------+
    OIDLDAPD_PID: 8205 WorkerID: 9 DBSID: 170 DBPID: 8253 ==> IDLE
  +--------------------------------------------------------------------------+
    OIDLDAPD_PID: 8205 WorkerID: 10 DBSID: 180 DBPID: 8261 ==> IDLE
  +--------------------------------------------------------------------------+
    OIDLDAPD_PID: 8205 WorkerID: 11 DBSID: 189 DBPID: 8269 ==> IDLE
  +--------------------------------------------------------------------------+
    OIDLDAPD_PID: 8209 WorkerID: 13 DBSID: 171 DBPID: 8249 ==> IDLE
  +--------------------------------------------------------------------------+
    OIDLDAPD_PID: 8209 WorkerID: 9 DBSID: 181 DBPID: 8257 ==> IDLE
  +--------------------------------------------------------------------------+
    OIDLDAPD_PID: 8209 WorkerID: 12 DBSID: 193 DBPID: 8267 ==> IDLE
  +--------------------------------------------------------------------------+
    OIDLDAPD_PID: 8209 WorkerID: 10 DBSID: 199 DBPID: 8225 ==> IDLE
  +--------------------------------------------------------------------------+
    OIDLDAPD_PID: 8209 WorkerID: 11 DBSID: 190 DBPID: 8227 ==> IDLE
  +--------------------------------------------------------------------------+
    OIDLDAPD_PID: 8205 WorkerID: 13 DBSID: 197 DBPID: 8223 ==> IDLE
  +--------------------------------------------------------------------------+
    OIDLDAPD_PID: 8205 WorkerID: 12 DBSID: 182 DBPID: 8229 ==> IDLE
  +--------------------------------------------------------------------------+
 
          Cache Max Size                       : 1000000512
          Max Entries configured             : 1000000
          Max Entries cached                  : 100000
          Num Entries in Cache               : 100000
          Num Entries in GC                   : 0
          Page size                                  : 976556
          Entry cache Hit count                : 6172127
          Entry cache Mis count               : 99999
          Hash Area bytes used               : 24497696
          Hash Area blocks used             : 37
          ResultSet cache bytes used       : 6799604
          Resultset cache blocks used      : 300000
          Entry cache bytes used             : 404047820
          Entry cache blocks used           : 5900293
          Cache memory used                 : 435345120

To configure the attributes, see "Attributes of the Instance-Specific Configuration Entry" in the Administering Oracle Internet Directory and "Setting System Configuration Attributes by Using ldapmodify" in the Administering Oracle Internet Directory.

Parent topic: Server Entry Cache

Result Set Cache

Result set cache allows complete result sets to be stored in memory. If an SQL query is executed and its result set is in the cache, then almost the entire overhead of the SQL execution is avoided. This includes parse time, logical reads, physical reads, and any cache contention overhead (for example, latches) that might normally be incurred. Configuring the result cache can improve performance since most LDAP applications typically look up user entries such as mail=john.doe@example.com or uid=john.doe from a user tree. Such queries are repeated by the application every time a user logs in or uses the application. The result set may be a single entry. Performance may be affected as OID makes a trip to the database for the entry each time the query is run.

Parent topic: Advanced Tuning Considerations

When to Use Result Set Cache

Consider using Result Set Cache only under the following conditions:

  • Filter matches one or few entries.

  • SQL statement causes multiple reads from disk or buffer (expensive)

Parent topic: Result Set Cache

Benefits of Using Result Set Cache

Benefits of using the entry cache include:

  • OID evaluates the filter without making a trip to the database and therefore reduces the load on the database.

    Note that the result set cache database parameter can be configured on the client side or server side. When the server side cache is enabled, the result set cache can consume a significant amount of database memory and OID performance may be impacted.

  • Performance improved by 3 to 5 times when compared to performance when result set cache is not used.

Parent topic: Result Set Cache

Configuring Result Set Cache

The OrclRSCacheAttr attribute is used to configure the result set cache for OID. OrclRSCacheAttr is a multi-valued attribute that includes cn, mail, uid, and orclguid. Typically these attributes are not modified for the life of the entry.

To enable result set cache, set orclecacheenabled=2. Result set cache can be turned off by setting orclecacheenabled=1 or orclecacheenabled=0.

Any change to these configuration attributes requires a restart of OID server (all the instances).

Parent topic: Result Set Cache

Values for Configuring Result Set Cache

Note that any change to the following configuration attributes requires a restart of OID server (all the instances).

Table 11-6 Result Set Cache Attributes to Tune

Attribute Default Recommended Value Notes

OrclRSCacheAttr

cn, mail, uid, orclguid

Multi valued attribute, Value contains the name of the Attribute. Typically these attributes are not modified for the life of the entry.

ResultSetMaxEntries

4

Maximum number of entries for a given search that can be cached.

ResultSetMaxCacheSize

10 MB

Maximum memory that can be allocated in the shared memory for the result set cache.

ResultSetMaxTime

8 hours

Time to live for the result set cache when the cache is full.

Parent topic: Result Set Cache

Tuning Security Event Tracking

The instance-specific configuration entry attributes orcloptrackmaxtotalsize and orcloptracknumelemcontainers control how much memory is used for security event tracking.

The attribute orcloptrackmaxtotalsize specifies the maximum number of bytes of RAM that security events tracking can use for each type of operation. If the Directory Server exceeds this limit for information collected for an operation, the server stops collecting new information and records appropriate messages in server log files. For the compare operation, the Directory Server uses twice the value of the attribute, which is the combined amount of information about users performing compare operation and users whose passwords are being compared. The default value of orcloptrackmaxtotalsize is 100000000 Bytes, which should be sufficient for most deployments. It can be increased to 200MB. For information about modifying orcloptrackmaxtotalsize, see the instance-specific configuration attribute examples in "Setting System Configuration Attributes by Using ldapmodify" in the Administering Oracle Internet Directory.

The attribute orcloptracknumelemcontainers allows you to choose the number of in-memory cache containers to be allocated for security event tracking in the Oracle Internet Directory server. There are two subtypes for this attribute. They are 1stlevel and 2ndlevel. The 1stlevel subtype is for setting the number of in-memory cache containers for storing information about users performing operations. The 2ndlevel subtype, which is applicable only to compare operation, sets the number of in-memory cache containers for information about the users whose user password is compared and tracked when detailed compare operation statistics is programmed.The default value of both subtypes is 256. The appropriate values for these subtypes depend on the number of users in your environment and the number of applications used to access the directory, as follows:

  • In a deployment where several applications perform operations on behalf of a large number of end users, set 1stlevel proportional to the number of applications, plus a few hundred more for end users directly accessing the directory. Then set 2ndlevel proportional to the number of end users.

  • In a deployment where end users themselves perform the operations, set 1stlevel proportional to the number of end users, then set 2ndlevel to a small value, such as 25.

  • A typical proportional value is one fifth. Proportions between one tenth and one half are reasonable in most environments.

If your deployment requires it, set the values for orcloptracknumelemcontainers only when security events collection is turned on.

Parent topic: Advanced Tuning Considerations

Optimizing Searches

This section contains these topics:

Parent topic: Advanced Tuning Considerations

Optimizing Searches for Large Group Entries

Searches for group entries with several thousand attribute values for either the member or uniquemember attribute can have high latency. If you find the latency unacceptably high, there are steps you can take to reduce it.

The simplest step is to reduce the number of attributes you are searching for. If you do not need to retrieve all the attributes of the group entry, specify required attributes in the search request to optimize the latency.

Entry Cache Enabled Configuration

If you still see unacceptable latency, even with required attributes specified, then you can try to cache the large group entry in the entry cache. To do this, increase the value of the orclEcacheMaxEntSize attribute in the instance-specific configuration entry: 

cn=componentname,cn=osdldapd,cn=subconfigsubentry

This attribute controls the maximum size of a cache entry.

Note:

If you expect frequent updates to large groups, then do not use this tuning methodology. Use the Entry Cache Disabled Configuration.

Entry Cache Disabled Configuration.

No action is required. This configuration is enabled by default.

Optimizing Searches for Skewed Attributes

To service a typical search request, the Directory Server sends a SQL statement to the Oracle Database. If a given attribute has very different response times depending on its value, then the attribute is said to be skewed. For example, if searches for my_attribute=value1 and my_attribute=value2 have very different response times, then my_attribute is said to be a skewed.

You can uniform the response times for searches for such an attribute by adding it as a value of the orclskewedattribute attribute, which is in the DSA configuration entry. The DN of the DSA configuration entry is 

cn=dsaconfig,cn=configsets,cn=oracle internet directory

By default, the objectclass attribute is listed as a value in the orclskewedattribute attribute.

You can change the value of orclskewedattribute by using or ldapmodify. See "Attributes of the Instance-Specific Configuration Entry" in the Administering Oracle Internet Directory and "Setting System Configuration Attributes by Using ldapmodify" in the Administering Oracle Internet Directory.

Parent topic: Optimizing Searches

Optimizing Performance of Complex Search Filters

When Oracle Internet Directory receives an LDAP search filter from a client application, it sends the filter to the Oracle Database as an SQL query. Sometimes client applications send filters that include terms that match a large number of entries in the directory. For example, consider the following filter:

(&(uid=msmith)(objectclass=inetorgperson)(orclisenabled=TRUE))

The terms (objectclass=inetorgperson) and (orclisenabled=TRUE) in that filter match nearly all entries. It would be very resource-intensive to execute that entire filter in the Oracle Database. To improve performance, you can specify that Oracle Internet Directory execute a portion of that filter in its own memory, rather than in the database. To do that, you use orclinmemfiltprocess, an attribute in the DSA configuration entry: 

cn=dsaconfig,cn=configsets,cn=oracle internet directory

When orclinmemfiltprocess is configured, the following events occur each time Oracle Internet Directory receives an LDAP search:

  1. Oracle Internet Directory removes all the terms that are configured in the orclinmemfiltprocess before forming the SQL query.
  2. Oracle Internet Directory sends the SQL query to Oracle Database.
  3. Oracle Database sends the entries resulting from the SQL query to Oracle Internet Directory.
  4. Oracle Internet Directory applies the original filter sent by the client (the terms in orclinmemfiltprocess) to those entries in memory.
  5. Oracle Internet Directory sends the entries that match that filter to the client.

For example, suppose orclinmemfiltprocess is set to (objectclass=inetorgperson)(orclisenabled=TRUE). When Oracle Internet Directory receives the search (&(uid=msmith)(objectclass=inetorgperson)(orclisenabled=TRUE)), it sends a filter containing only the parameter (uid=msmith) to the database. After Oracle Internet Directory receives entries back from the database, Oracle Internet Directory itself applies the filter (objectclass=inetorgperson) (orclisenabled=TRUE) to those entries.

By default, orclinmemfiltprocess is set to the following values:

(objectclass=inetorgperson)

(objectclass=oblixorgperson)

(|(!(obuseraccountcontrol=*))(obuseraccountcontrol=activated))

(|(obuseraccountcontrol=activated)(!(obuseraccountcontrol=*)))

(objectclass=*)

(objectclass=oblixworkflowstepinstance)

(objectclass=oblixworkflowinstance)

(objectclass=orcljaznpermission)

(obapp=groupservcenter)(!(obdynamicparticipantsset=*))

(objectclass=orclfeduserinfo)

You can change the value of orclinmemfiltprocess by using or ldapmodify. See "Attributes of the Instance-Specific Configuration Entry" in the Administering Oracle Internet Directory and "Setting System Configuration Attributes by Using ldapmodify" in the Administering Oracle Internet Directory.

Under some conditions, Oracle Internet Directory ignores orclinmemfiltprocess and sends the entire filter to the database. It does this if the filter it receives meets the following conditions:

  • It contains only one parameter, that is, one attribute-value pair.

  • It contains no filter condition other than those in orclinmemfiltprocess

  • It contains an OR condition applied to the terms that are in orclinmemfiltprocess

  • It contains the same terms as in orclinmemfiltprocess, but in a different order

The following cases illustrate those conditions. In all of the following cases, orclinmemfiltprocess is set to (objectclass=inetorgperson)(employeetype=Contract).

Examples

Case A

(&(manager=cn=john doe)(objectclass=inetorgperson) (employeetype=Contract))

Oracle Internet Directory sends the filter (&(manager=cn=john doe)) to the database.

Case B

(&(uid=rmsmith)((objectclass=inetorgperson)(employeetype=Contract)))

Oracle Internet Directory sends only (&(uid=rmsmith)) to the database, then applies the filter (&(objectclass=inetorgperson)(employeetype=Contract)) to the entries that are returned from the database.

Case C

(|(uid=rmsmith)(objectclass=inetorgperson) (employeetype=Contract))

In this filter, the terms that match orclinmemfiltprocess are part of an OR condition. Oracle Internet Directory sends the filter, as is, to the database.

Case D

(&(uid=rmsmith)(employeetype=Contract) (objectclass=inetorgperson))

Even though some of the terms in this filter match orclinmemfiltprocess, they are in a different order, so Oracle Internet Directory sends the whole filter to the database. You could add (employeetype=Contract)(objectclass=inetorgperson) to orclinmemfiltprocess if you do not want Oracle Internet Directory to send this filter to the database.

Case E

(|(&(uid=rmsmith)(sn=smith)(objectclass=inetorgperson)(employeetype=Contract))

In this filter, the terms that match orclinmemfiltprocess are part of an OR condition. Oracle Internet Directory sends the filter, as is, to the database.

Case F

(&(|(uid=rmsmith)(sn=smith))(objectclass=inetorgperson)(employeetype=Contract)))

Even though this filter contains an OR operator, it is not applied to the terms that match orclinmemfiltprocess. Oracle Internet Directory sends (&(|(uid=rmsmith)(sn=smith))) to the directory and applies the filter (&(manager=cn=john doe)(&(objectclass=inetorgperson) (employeetype=Contract)) to the entries that are returned from the database.

Configuring Multiple Filters

If the application is sending multiple filters, and the terms in one filter are a superset of the terms in the other, you must configure orclinmemfiltprocess for both values.For example, suppose the application is sending the following two filters:

(&(uid=rmsmith)(objectclass=inetorgperson)(employeetype=Contract))

(&(uid=rmsmith)(objectclass=inetorgperson)(employeetype=Contract)(departmentNumber=627))

where (departmentNumber=627) matches a lot of entries. You must configure orclinmemfiltprocess as follows:

(objectclass=inetorgperson)(employeetype=Contract)

(departmentNumber=627)

Optimizing Performance for Search baseDN

In the DIT, if all the users are under one baseDN, such as cn=users,dc=acme,dc=com, and all the LDAP search clients send base as cn=users,dc=acme,dc=com, then the configuration of the orclinmemfilter will significantly reduce database processing time. See the following example: 

orclinmemfiltprocess;dn: cn=users,dc=acme,dc=com

Parent topic: Optimizing Searches

Specific Use Cases That Require Additional Tuning

This section describes some specific use cases that require additional tuning, in addition to Basic Tuning Considerations.

Parent topic: Oracle Internet Directory Performance Tuning

Bulk Load Operations

If you are planning a large bulkload operation, make the following changes:

  • Set the database initialization parameter pga_aggregate_target to 1-4GB for the duration of the operation, if sufficient RAM is available.

  • Increase the database temporary tablespace before loading a large number entries. You need about 1G of temporary tablespace per million entries being loaded. You can free up the tablespace after the operation.

Parent topic: Specific Use Cases That Require Additional Tuning

Bulk Delete Operations

If you are planning a large bulkdelete operation, perform the following tasks:

  • Ensure that the database initialization parameter sga_target are tuned as described in Database Parameters.

  • Set the database initialization parameter log_buffer to 10M. This can provide additional performance benefit.

  • Ensure that you have at least three database redo log files with at least 100MB.

  • Ensure that the undo tablespace is at least 1 GB in total size.

  • Follow the recommendations about redo logs and undo tablespace in the next section, High LDAP Write Operations Load.

Parent topic: Specific Use Cases That Require Additional Tuning

High LDAP Write Operations Load

If you have a high LDAP write operations load, or if you perform many bulkdelete operations, consider tuning the following values:

  • Increase the size or number of the database redo log files so that the total size is 1000-1500 MB. Other considerations affect the total size of redo logs.

  • Depending on how the disks are configured, it might be beneficial to isolate the redo log files to a dedicated set of disks.

  • Increase the undo tablespace size by adding data files to this tablespace. For most deployments, 2-4 GB should suffice.

  • Do not use the Oracle Internet Directory server entry cache. See Server Entry Cache.

  • If neither Oracle Internet Directory replication nor DIP is deployed, disable change log generation. See Replication or Oracle Directory Integration Platform.

Table 11-7 summarizes the redo log and undo tablespace recommendations provided in this section.

Table 11-7 Redo Log and Undo Tablespace Values

Attribute Value Notes

Redo Log

3 logs, 100MB each

Many bulkdelete operations.

Redo Log

Total size 1000-15000MB

Large number of write operations.

Undo Tablespace

At least 1GB total

Many bulkdelete operations.

Undo Tablespace

2-4 GB

Large number of write operations.

Parent topic: Specific Use Cases That Require Additional Tuning