2.1 FLAIM Database

A checkpoint brings the on-disk version of the database to the same coherent state as the in-memory (cached) database. FLAIM can perform a checkpoint during the minimal update activity on the database. It runs every second and writes the dirty blocks (dirty cache) to the disk. Blocks that are modified in the cache but not yet written to the disk are called “dirty blocks”. FLAIM acquires a lock on the database and performs the maximum amount of possible work until either the checkpoint completes or another thread is waiting to update the database. To prevent the on-disk database from becoming too far out of sync, there are conditions under which a checkpoint is forced even if threads are waiting to update the database:

An index is a set of keys arranged in a way that significantly speeds up the task of finding any particular key within the index. Index keys are constructed by extracting the contents of one or more fields (attributes) from the entries. Indexes are maintained in the block cache. Any changes to the indexed attributes requires changes in the index blocks.

eDirectory defines a default set of indexes for system attributes (fields). System attributes such as parentID and ancestorID are used for one-level and subtree searches. These indexes cannot be suspended or deleted. The directory internally uses them. Default indexes are defined for attributes such as CN, Surname, Given Name, and so on. Indexes can be of type presence, value, and substring indexes. These indexes can be suspended. On deletion they are automatically re-created.

You can use iManager or the ndsindex Lightweight Directory Access Protocol (LDAP) utility to create indexes. Indexes are server-specific.

By enabling the Storage Manager (StrMan) tag in DSTrace (ndstrace), you can view the index chosen for the search queries.

The following example is for a DSTrace log for a subtree search using "cn=admin", CN.

3019918240 StrMan: Iter #b239c18 query ((Flags&1)==1) && ((CN$217A$.Flags&8=="admin") && (AncestorID==32821))

3019918240 StrMan: Iter #b239c18 index = CN$IX$220

The following example is for an DSTrace log for a subtree search using "Description= This is for testing", AncestorID.

2902035360 StrMan: Iter #83075b0 query ((Flags&1)==1) && ((Description$225A$.Flags&8=="This is for testing") && (AncestorID==32821))

2902035360 StrMan: Iter #83075b0 index = AncestorID_IX

To improve the search performance with the server side sort, use the -a option to prefix the AncestorID attribute to the list of attributes passed while creating a new index.

The below table explains the trend of increasing DIB size while creating simple/compound indexes for a certain number of objects. We recommend you to refer to this test data while creating simple/compound indexes:

FLAIM logs operations for each update transaction in a roll-forward log (RFL) file. An RFL is used to recover transactions from a system failure or when restoring from a backup. The RFL file is truncated after every checkpoint is completed unless it is turned on (rflkeepfiles) by using a hot continuous backup.

To ensure optimal utilization of the entry cache and enhanced performance of attribute search operations, FLAIM stores attributes with larger values or higher number of values in a separate location namely, Attribute Container. By default the attributes will be moved to the container automatically when the attribute:

To disable the automatic containerization of attributes, add disablemovetoattrcontainer =1 in the _ndsdb.ini file and restart eDirectory.

eDirectory provides you the flexibility of scheduling the attribute movement. You first view the attributes that are ready to be moved and then schedule their movement as per your convenience.

To view the number of attributes ready for movement to attribute containers, run the ndscheck command. To view the details of attributes, use iMonitor dsContainerReadyAttrs attribute on the Pseudo server objects in the Agent Configuration. User can also find those attributes which are marked for indexing in the Agent Health.

You can start the attribute containerization by using the single object repair option of ndsrepair for the Pseudo server object. To containerize an attribute, issue the ndsrepair command with the new advance switch -am followed by the name of the attribute as below:

ndsrepair –J <Pseudo server object ID> –Ad –AM/–am <attribute name>

After moving an attribute to the Attribute Container, eDirectory creates a system index with the name of the attribute. When an attribute is containerized, you cannot move it back to the original container.