Attributes on an object can be indexed to improve the performance of queries. When an attribute is indexed, the index applies to each object to which the attribute is associated. You cannot place an index on an attribute and have it apply to only one class of object. To specify the index for an attribute, you must modify the searchFlags property for the attribute in the schema.
The searchFlags property is part of the definition for a schema attribute and is composed of bit values. These bit values determine how an attribute is handled by Active Directory. The first three bits control how an attribute is indexed. By setting the first bit of the property to one, a database-wide index is created for the attribute. Setting the second bit to one creates an index on each container that holds an object that uses the attribute. This kind of index helps one-level searches, and Windows XP defines the supported sort orders for one-level VLV searches.
If the third bit is set, then the attribute is included in the filter expansion of ANR searches of the ANR attribute set only if the attribute is already normally indexed by setting the first bit to one. In the Windows Server 2003 family, if the sixth bit is set, then a substring index is created on the attribute, allowing efficient medial substring queries to be performed. Note that a substring index is significantly more expensive to create and maintain, so update speeds will be affected.
Ambiguous name resolution (ANR) helps find a user object when a unique identifying value is not known. For example, if you know that the name of a person is Sam but are not sure whether Sam is a first name, last name, e-mail alias, or an abbreviation, you can use the filter, (anr=sam) to perform a search for every object where any of the attributes are part of the ANR index and begin with sam. Although ANR was designed for use with user objects, it can be used on any type of object. Therefore, you may need to indicate the class in the search as well. For example, use (&(objectClass=user)(anr=sam)).
Indexing attributes is useful when you search for objects that have the attribute name in a filter. Indexing can reduce the number of objects that must be visited when you evaluate the filter. However, this reduces the performance of write operations because the index must be updated when the corresponding attribute is modified or added. It also increases the size of the directory database. You can use logging to find the expensive and inefficient queries. Once you’ve identified them, you can index some attributes that are used in the corresponding queries to improve the search performance.
When the searchFlags property is modified, a background task starts to create the index. This task may take a while to complete depending on which attribute is indexed and how many objects are using the attribute. To be certain that the index has been created, look at the event log for the following message:
An index on the attribute <index ID> (index name) was successfully created.
When one of the bit values is set to zero to turn off the index, a background task is started for removing the index. To be certain that the index has been removed, look at the event log for the following message:
Deleted unneeded index <index name> (Internal ID <index ID>).
You can improve search behavior by indexing the attributes that are most likely to be searched. The searchFlags attribute of an attributeSchema object indicates whether the attribute is indexed and the nature of the indexing.
The searchFlags attribute is an integer value whose least significant bits indicate whether the attribute is indexed and in what way. Use the OR operator to combine the bit values to achieve the appropriate indexing behavior.
Values in the searchFlags attribute have the following effects:
© 2020 Digcode.com. All rights reserved.