Backwards Compatibility And Migration - Red Hat DIRECTORY SERVER 8.0 - ADMINISTRATION Administration Manual

Chapter 10. Managing Indexes
The problems addressed by the All IDs Threshold are no longer present because of the efficiency of
entry insertion, modification, and deletion in the Berkeley DB design. The All IDs Threshold is removed
for database write operations, and every ID list is now maintained accurately.
Since loading a long ID list from the database can significantly reduce search performance, the
configuration parameter, nsslapd-idlistscanlimit, sets a limit on the number of IDs that are
read before a key is considered to match the entire primary index. nsslapd-idlistscanlimit is
analogous to the All IDs Threshold, but it only applies to the behavior of the server's search code, not
the content of the database.
When the server uses indexes in the processing of a search operation, it is possible that
one index key matches a large number of entries. For example, consider a search for
objectclass=inetorgperson in a directory that contained one million inetorgperson entries.
When the server reads the inetorgperson index key in the objectclass index, it finds one million
matching entries. In cases like this, it is more efficient simply to conclude in the index lookup phase
of the search operation processing that all the entries in the database match the query. This causes
subsequent search processing to scan the entire database content, checking each entry as to whether
it matches the search filter. The time required to fetch the index keys is not worthwhile; the search
operation is likely to be processed more efficiently by omitting the index lookup.
In Directory Server, when examining an index, if more than a certain number of entries are found, the
server stops reading the index and marks the search as unindexed for that particular index.
The threshold number of entries is called the idlistscanlimit and is configured with the
nsslapd-idlistscanlimit configuration attribute. The default value is 4000, which is designed to
give good performance for a common range of database sizes and access patterns. Typically, it is not
necessary to change this value. However, in rare circumstances it may be possible to improve search
performance with a different value. For example, lowering the value will improve performance for
searches that will otherwise eventually hit the default limit of 4000. This might reduce performance for
other searches that benefit from indexing. Conversely, increasing the limit could improve performance
for searches that were previously hitting the limit. With a higher limit, these searches could benefit
from indexing where previously they did not.
Section 10.1.3, "Overview of the
For more information on search limits for the server, refer to
Searching Algorithm".

10.4.3. Backwards Compatibility and Migration

While current versions of Directory Server can support the old database design, only the new design is
supported for this and later releases of Directory Server.
Upon startup, the server will read the database version from the DBVERSION file, which contains the
text Netscape-ldbm/6.2 (old database version), Netscape-ldbm/7.1 (new database format),
or bdb/4.2/libback-ldbm (new database format). If the file indicates that the old format is used,
then the old code is selected for the database. Because the DBVERSION file stores everything per-
backend, it is possible to have different database formats for different individual backends, but the old
database format is not recommended.
All databases must be migrated to Directory Server 8.0 when the system is upgraded. Migration
is supported for Directory Server 6.x versions, and for releases earlier than version 6.x, dump the
databases be dumped, and install Directory Server fresh. Migrating databases is covered in the
Directory Server Installation Guide.
338