Oracle® Fusion Middleware Performance and Tuning Guide 11g Release 1 (11.1.1) E10108-01 |
|
![]() Previous |
![]() Next |
This chapter provides guidelines for tuning and sizing an Oracle Internet Directory installation. It contains these topics:
Section 17.2, "Introduction to Tuning Oracle Internet Directory"
Section 17.8, "Evaluating Performance on UNIX and Windows Systems"
Section 17.9, "Obtaining Recommendations by Using the Tuning and Sizing Wizard"
Section 17.10, "Updating Database Statistics by Using oidstats.sql"
Section 17.11, "Setting Performance-Related Replication Configuration Attributes"
Section 17.12, "Modifying Performance-Related System Configuration Attributes"
Section 17.13, "Setting Garbage Collection Configuration Attributes"
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, multi-process, 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 out of box configuration is not optimal for most production or test deployments. You must follow at least the steps listed in Section 17.3, "Basic Tuning Recommendations" to achieve optimal performance and availability. |
See Also:
|
Many of the recommendations in this chapter require changes to Oracle Internet Directory system configuration attributes and replication configuration attributes.
See Also:
for more information about Oracle Internet Directory configuration attributes. |
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.
Some good minimum values for Oracle Database instance parameters are given here:
Table 17-1 Minimum Values for Oracle Database Instance Parameters
See the Oracle Database Performance Tuning Guide for information on setting Oracle Database instance parameters.
The recommendations in this section are summarized in Table 17-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 17-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 has 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 Oracle Fusion Middleware Administrator's Guide for 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 17-2 LDAP Server Attributes to Tune
Attribute | Default | Recommended Value | Notes |
---|---|---|---|
2 |
10 |
Server restart required. |
|
1 |
Number of CPU sockets on Oracle Internet Directory node |
||
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. |
|
1 |
0 |
Disable change log generation only if you do not deploy either replication or Oracle Directory Integration Platform. |
|
0 (no timeout) |
Varies, 60 is reasonable |
Users configured for statistics tracking do not time out. |
|
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 Section 17.12.1, "Modifying Instance-Specific Attributes by Using Fusion Middleware Control."
For information about configuring orclskiprefinsql
or orclmatchdnenabled
with Oracle Enterprise Manager Fusion Middleware Control, see Section 17.12.2, "Modifying Shared Attributes by Using Fusion Middleware Control."
For information about configuring these attributes, as well as orclgeneratechangelog
, from the command line, see Section 17.12.3, "Modifying Attributes by Using ldapmodify."
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 Section 17.10, "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 Oracle Internet Directory installation. 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.
See Also: Oracle Database Performance Tuning Guide for information about SQL tuning. |
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.
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.
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.
Create an additional server instance, as described in the chapter "Managing Oracle Internet Directory Instances" in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.
Set orclmaxcc
to 10 and orclserverprocs
to 1 in the new instance configuration.
Restart the server, as described in the chapter "Managing Oracle Internet Directory Instances" in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.
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 Section 17.12.1, "Modifying Instance-Specific Attributes by Using Fusion Middleware Control" and Section 17.12.3, "Modifying Attributes by Using ldapmodify."
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. |
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 17-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 17-3 summarizes these recommendations.
Table 17-3 Replication Attributes
Attribute | Default | Recommended Value | Notes |
---|---|---|---|
transport=1 apply=5 |
Set transport threads to 1 and apply threads to 10 or greater |
Most useful if the supplier is the bottleneck. |
|
10 |
4 |
Provides more resources to changelogs but might increase HIQ. |
|
60 seconds |
0 |
Causes changelogs to be processed immediately |
|
600 seconds |
21600 seconds |
Provides more resources to process new changes. |
|
1 |
0 |
Change only if you are deploying a single master with read-only replica consumers. |
See Section 17.11, "Setting Performance-Related Replication Configuration Attributes" for information on setting these replication attributes.
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 17-4.
Table 17-4 Garbage Collection Configuration Parameters
Parameter | Value | Notes and References |
---|---|---|
Less than 10days (240 hours) |
Only if there is no requirement to retain change logs |
|
6–12 hours |
You can modify these attributes by using ldapmodify
or Oracle Directory Services Manager. See Section 17.13, "Setting Garbage Collection Configuration Attributes."
As described in Section 17.4.2, "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
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:
|
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. |
Consider using Oracle Internet Directory Server Entry Cache only under the following conditions:
The total number of entries in Oracle Internet Directory can be fully or mostly cached. This is usually the case for deployments with fewer than 500K entries in Oracle Internet Directory on a 32-bit system
The number of concurrent clients is low, typically less than 100
You are not using a cluster configuration
You do not require the LDAP server instance to be multiprocess.
You expect a very low update rate, especially on group entries.
You are not using a second, dedicated LDAP server instance for replication or Oracle Directory Integration Platform
Very few applications are using Oracle Internet Directory
You have no large binary values or large group entries, and updates on binary and group entries are infrequent.
Benefits of using the entry cache include:
LDAP search operations with subtree and one-level scope are about twice as fast.
LDAP search operations with base scope are about five times as fast.
These benefits apply only when all or most entries can be cached. A cache miss is more expensive than disabling the entry cache.
You can configure and optimize the server entry cache by setting the values shown in Table 17-5.
Table 17-5 Server Entry Cache Configuration
Attribute | Default | Recommended Value | Notes |
---|---|---|---|
2 |
Total number of processor cores on the node |
Restart the server after changing this attribute. |
|
1 |
1 |
For values greater than 1, entry cache is automatically disabled. Restart the server after changing this attribute. |
|
1 |
1 |
||
200000000 Bytes |
Total size of the directory, in bytes |
Estimate three times the size of the entries in LDIF format |
|
100000 |
Total number of entries in the DIT |
||
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 DIT is 300K and total size of 300K entries in LDIF format is 500M, you would set orclecacheenabled to 1, orclecachemaxsize to 1500000000, and orclecachemaxentries to 300000. If the size of the largest group entry or entry with binary value is 10M, you would set orclecachemaxentsize to 10000000.
To configure the attributes, see Section 17.12.1, "Modifying Instance-Specific Attributes by Using Fusion Middleware Control" and Section 17.12.3, "Modifying Attributes by Using ldapmodify."
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 Section 17.12.3, "Modifying Attributes by Using ldapmodify."
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 userpassword 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.
This section describes attributes that can sometimes improve performance, but are considered low-priority.
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 Section 17.12.3, "Modifying Attributes by Using ldapmodify."
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 Section 17.12.3, "Modifying Attributes by Using ldapmodify."
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 Section 17.12.1, "Modifying Instance-Specific Attributes by Using Fusion Middleware Control."
This section describes some specific use cases that require additional tuning, in addition to Section 17.3, "Basic Tuning Recommendations"
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.
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 Section 17.3.1, "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, Section 17.6.3, "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 Section 17.4.6, "Server Entry Cache."
If neither Oracle Internet Directory replication nor DIP is deployed, disable change log generation. See Section 17.4.1, "Replication or Oracle Directory Integration Platform."
Table 17-6 summarizes the redo log and undo tablespace recommendations provided in this section.
Table 17-6 Redo Log and Undo Tablespace Values
Attribute | Value | Notes |
---|---|---|
Redo Log |
3 logs, 100MB each |
Many |
Redo Log |
Total size 1000-15000MB |
Large number of write operations. |
Undo Tablespace |
At least 1GB total |
Many |
Undo Tablespace |
2-4 GB |
Large number of write operations. |
This section contains these topics:
Section 17.7.1, "Optimizing Searches for Large Group Entries"
Section 17.7.3, "Optimizing Performance of Complex Search Filters"
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.
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. The default value is 1M. If the size of the large group entry is greater than the value of orclEcacheMaxEntSize
, change it to a large enough value to ensure that the large group entry is cached.
Note: If you expect frequent updates to large groups, then do not use this tuning methodology. Use the Entry Cache Disabled Configuration. |
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 Section 17.12.1, "Modifying Instance-Specific Attributes by Using Fusion Middleware Control" and Section 17.12.3, "Modifying Attributes by Using ldapmodify".
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:
Oracle Internet Directory removes all the terms that are configured in the orclinmemfiltprocess
before forming the SQL query.
Oracle Internet Directory sends the SQL query to Oracle Database.
Oracle Database sends the entries resulting from the SQL query to Oracle Internet Directory.
Oracle Internet Directory applies the original filter sent by the client (the terms in orclinmemfiltprocess
) to those entries in memory.
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 Section 17.12.1, "Modifying Instance-Specific Attributes by Using Fusion Middleware Control" and Section 17.12.3, "Modifying Attributes by Using ldapmodify".
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)
Knowledge of the following tools is recommended for Linux, Solaris, and other UNIX-like operating systems:
Knowledge of the following tools is recommended for Microsoft Windows:
Knowledge of the following tools is recommended for the Oracle Database:
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 Section 17.10, "Updating Database Statistics by Using oidstats.sql".
Oracle Enterprise Manager Fusion Middleware Control provides a convenient tool for tuning and sizing Oracle Internet Directory.
Use the wizard to obtain tuning and sizing recommendations for your system. You can select Tuning, Sizing, or Both. If you select Sizing or Both, you can select Basic or Advanced
Tuning
From the Oracle Internet Directory menu, select Administration, then Tuning and Sizing.
Click the Create icon to invoke the wizard.
On the Type Selection page, change the report name, then select Tuning.
The wizard presents the following pages: Hardware, Features, Load, Data Characteristics, and Garbage Collection.
On each page, specify values for the text fields (or use defaults) and Select Yes or No for each question. Some choices might be greyed out, depending upon your previous choices. Most fields have tool tips that appear when you move the cursor over the field.
Click Next to go to the next page or Back to return to the previous page. Click Cancel to close the wizard.
On the Review page, review the data you entered. Click Back to change your specifications or click Finish to view the report.
The report appears on the bottom right section of the page.
To download the report, click Download Report. To delete the report, click Delete.
Sizing
From the Oracle Internet Directory menu, change the report name, then select Administration, then Tuning and Sizing.
Click the Create icon to invoke the wizard.
On the Type Selection page, select Sizing.
Select Basic or Advanced.
On the Sizing page, specify values for the text fields (or use defaults) and Select Yes or No for each question. Some choices might be greyed out, depending upon your previous choices.
Click Next.
On the Review page, review the data you entered. Click Back to change your specifications or click Finish to view the report.
The report appears on the bottom right section of the page.
To download the report, click Download Report. To delete the report, click Delete.
Both
From the Oracle Internet Directory menu, change the report name, then select Administration, then Tuning and Sizing.
Click the Create icon to invoke the wizard.
On the Type Selection page, select Both.
Select Basic or Advanced.
Click Next.
The wizard presents the following pages: Sizing, Hardware, Features, Load, Data Characteristics, and Garbage Collection.
On each page, specify values for the text fields (or use defaults) and Select Yes or No for each question. Some choices might be greyed out, depending upon your previous choices.
Click Next to go to the next page or Back to return to the previous page. Click Cancel to close the wizard.
On the Review page, review the data you entered. Click Back to change your specifications or click Finish to view the report.
The report appears on the bottom right section of the page.
To download the report, click Download Report. To delete the report, click Delete.
To update database statistics, execute the Oracle Internet Directory Database Statistics Collection tool, as follows:
ORACLE_HOME/ldap/admin/oidstats.sql
You do not need to run oidstats.sq
l if you use the bulkload
tool to add entries to the database. The bulkload
command automatically updates the database statistics.
If you load data into the directory by any means other than the bulk load tool (bulkload
), then you must run oidstats.sql
after loading. Statistics collection is essential for the Oracle Optimizer to choose an optimal plan in executing the queries corresponding to the LDAP operations. You can run Oracle Internet Directory Database Statistics Collection tool at any time, without shutting down any of the Oracle Internet Directory daemons.
Note: If you do not use the bulkload utility to populate the directory, then you must run theoidstats.sql tool to avoid performance impacts. |
See Also: Theoidstats.sql command-line tool reference in Oracle Fusion Middleware User Reference for Oracle Identity Management |
To set the replication attributes, you can use either the Replication Wizard in Oracle Enterprise Manager Fusion Middleware Controlor 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:
|
You can set most performance-related system configuration attributes from Oracle Enterprise Manager Fusion Middleware Control or from the command line. This section describes how to do that.
You can also use the Data Browser in Oracle Directory Services Manager to modify system configuration attributes.
See Also: "Managing System Configuration Attributes by Using Oracle Directory Services Manager Data Browser" in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory |
This section contains the following topics:
Section 17.12.1, "Modifying Instance-Specific Attributes by Using Fusion Middleware Control"
Section 17.12.2, "Modifying Shared Attributes by Using Fusion Middleware Control"
You can configure performance attributes in the instance-specific configuration entry by using the Server Properties page of Oracle Enterprise Manager Fusion Middleware Control. Select Administration, then Server Properties from the Oracle Internet Directory menu, then select the Performance tab.
Table 17-7 shows the relationship between fields on the page and configuration attributes.
Table 17-7 Configuration Attributes on Server Properties Page, Performance Tab
Restart the server after changing orclserverprocs
, orclmaxcc
, orcldispthreads
, or orclpluginworkers
.
You configure the performance-related shared attributes in the DSA configuration entry by using the General tab of the Oracle Internet Directory Shared Properties page of Oracle Enterprise Manager Fusion Middleware Control. Select Administration, then Shared Properties from the Oracle Internet Directory menu.
Table 17-8 shows the relationship between fields on the page and the performance-related configuration attributes.
See Also: "Configuring Shared Properties" in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory for information about other fields on the Shared Properties page. |
Table 17-8 Performance-Related Attributes on Shared Properties Page, General Tab
Field or Heading | Configuration Attribute |
---|---|
Skip referral for search |
|
Skewed attributes |
|
Match DN |
|
Restart the server after changing orclskiprefinsql
or orclskewedattribute
.
Most attributes can be modified by using the LDAP command ldapmodify
.
You use a command line such as:
ldapmodify -D cn=orcladmin -q -p portNum -h hostname -f ldifFile
where ldifFile is an LDIF file.
Here are some examples of LDIF files for modifying instance-specific configuration entry attributes.
orclgeneratechangelog
dn: cn=componentname,cn=osdldapd,cn=subconfigsubentry
changetype: modify
modify: orclgeneratechangelog
orclgeneratechangelog: 0
orclsizelimit
dn: cn=componentname,cn=osdldapd,cn=subconfigsubentry
changetype: modify
modify: orclsizelimit
orclsizelimit: 10000
orclenablegroupcache
dn: cn=componentname,cn=osdldapd,cn=subconfigsubentry
changetype: modify
modify: orclenablegroupcache
orclenablegroupcache: 0
Here are some examples of LDIF files for modifying DSA configuration entry attributes.
orclskiprefinsql
dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory changetype: modify replace: orclskiprefinsql orclskiprefinsql: 1
orclinmemfiltprocess: One Filter is a Superset of Another
dn: cn=dsaconfig, cn=configsets, cn=oracle internet directory changetype: modify add: orclinmemfiltprocess orclinmemfiltprocess: (objectclass=inetorgperson)(orclisenabled=TRUE)
orclskewedattribute
dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory changetype: modify add: orclskewedattribute orclskewedattribute: my_attribute !
Restart the server after changing orclskiprefinsql
or orclskewedattribute
.
The attributes orclpurgetargetage
and orclpurgeinterval
reside in the changelog purging configuration entry. You can change them with ldapmodify
or Oracle Directory Services Manager.
The following example is an LDIF file used to configure change log purging.
See Also: "Change Log Purging" in Oracle Fusion Middleware Administrator's Guide for 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 Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory. |
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:
On the Data Browser tab, click Advanced.
Expand Garbage Collection in the left pane, then select changelog purgeconfig. The Garbage Collector Window appears in the right pane.
In the right pane, enter the changes you want to make to the Purge Target Age and Purge Interval.
Choose Apply.