-
Important Critical Indexes. The Directory Server has several built-in indexes on the Local DB Backend that are critical to internal server processing and should never be removed.
aci, ds-entry-unique-id, objectClass
-
Built-in Indexes for Efficient Queries. The Directory Server has built-in indexes on the Local DB Backend. Internal processing of the server relies on the
aci
,ds-soft-delete-from-dn
,ds-soft-delete-timestamp
,entryUUID
,member
,objectClass
, anduniqueMember
indexes, which must not be removed. Themail
anduid
indexes can be removed, but these attributes are referenced from the Password Modify Extended Operation and will cause problems with components such as the Exact Match Identity Mapper. If themail
oruid
indexes are removed, additional configuration changes may be necessary to ensure that the server starts properly. Thecn
,givenName
,mail
,sn
, andtelephoneNumber
indexes can be safely removed if clients do not query on these attributes. This will reduce the size of the database both on disk and in memory. - Online Rebuilds. Whenever an online index rebuild is in progress, the data in that backend will be available and writable although the index being rebuilt will not be used; therefore, searches which attempt to use that attribute might be unindexed.
- Index Rebuild Administrative Alert. The Directory Server generates an administrative alert when the rebuild process begins and ends. It will have a degraded-alert-type of "index-rebuild-in-progress" so that a Directory Proxy Server, such as the Directory Server can avoid using that server while the rebuild is in progress.
- System Indexes Cannot be Rebuilt. The contents of the backend must be exported and re-imported in order to rebuild system indexes. See the table below for the list of system indexes.
-
Indexing Certain Attributes. You should ensure that the following recommendations
are used when setting up the indexes.
- Equality and substring indexes should not be used for attributes that contain binary data.
- Approximate indexes should be avoided for attributes containing numbers, such as telephone numbers.
-
Unindexed Searches. Unindexed attributes result in
longer search times as the database itself has to be searched instead of the database
index file. Only users with the
unindexed-search
privilege are allowed to carry out unindexed searches. In general, applications should be prevented from performing unindexed searches, so that searches that are not indexed would be rejected rather than tying up a worker thread. The ways to achieve this include:- Make sure that only the absolute minimum set of users have the
unindexed-search
privilege. This privilege can be used without any other restrictions. - To allow unindexed searches with some control, the Permit Unindexed Search
request control can be used with the
unindexed-search-with-control
privilege. With this privilege, a user will only be permitted to request an unindexed search if the search request includes the Permit Unindexed Search request control. Theunindexed-search privilege
allows a client to request an unindexed search without this control. - The Reject Unindexed Search request control can be used to explicitly indicate that a client does not want
the server to process an unindexed search request, regardless of priviledges.
See the LDAP SDK for information about these controls. These capabilities are also available
with the
ldapsearch
tool. - Make sure that
allow-unindexed-searches
property is set to false in all client connection policies, in which unindexed searches should never be necessary. If the client connection policy should allow undindexed searches, set theallow-unindexed-searches-with-control
property to true. Ifallow-unindexed-searches
is false but,allow-unindexed-searches-with-control
is true, the policy will only permit an unindexed search if the request includes the Permit Unindexed Search request control. See the LDAP SDK and theldapsearch
tool for more information. -
Set a nonzero value for the
maximum-concurrent-unindexed-searches
global configuration property to ensure that if unindexed searches are allowed, only a limited number of them will be active at any given time. Administrators can configure the maximum number of concurrent unindexed searches by setting a property under Global Configuration.To change the maximum number of concurrent unindexed searches, use the dsconfig tool to set a value for the number. A value of "0" (default) represents no limit on the number of concurrent unindexed searches.
$ bin/dsconfig set-global-configuration-prop \ --set maximum-concurrent-unindexed-searches:2
- Make sure that only the absolute minimum set of users have the
-
Index Entry Limit. The Directory Server specifies an index entry limit property. This property defines the maximum number of entries that are allowed to match a given index key before it is no longer maintained by the server. If the index keys have reached this limit (default value is 4000), then you must rebuild the indexes using the rebuild-index tool. If an index entry limit value is set for the local DB backend, it overrides the value set for the overall JE backend index entry limit configuration (i.e., 4000).
To change the default index entry limit, use the dsconfig tool as seen in the following example:
$ bin/dsconfig set-local-db-index-prop --backend-name userRoot \ --index-name cn --set index-entry-limit:5000
-
Rebuild Index vs Full Import. You can expect a limited amount of database growth due to the existence of old data when running rebuild-index versus doing a full import of your database.
Administrators should keep the following tips in mind when working with indexes: