eDirectory verwendet FLAIM als Datenbank. FLAIM (Flexible Adaptable Information Manager) wird für herkömmliche, flüchtige und komplexe Informationen verwendet. Es handelt sich um eine äußerst skalierbare Datenbank-Engine, die ein Nebenläufigkeitsmodell für mehrere Leser und einen einzelnen Schreiber unterstützt. Die Leser blockieren die Schreiber nicht, und die Schreiber blockieren nicht die Leser.
Physisch organisiert FLAIM die Daten in Blöcken. Einige Blöcke werden üblicherweise im Arbeitsspeicher behalten. Sie stellen den Block-Cache dar. Der Eintrags-Cache (manchmal Datensatz-Cache genannt) speichert logische Einträge der Datenbank im Cache. Aus den Elementen im Block-Cache werden Einträge konstruiert. FLAIM pflegt Hash-Tabellen für beide Caches. Die Größe des Hash-Bucket wird regelmäßig auf Grundlage der Elementanzahl angepasst.
Standardmäßig arbeitet eDirectory mit einer Blockgröße von 4 KB. Die Größe des Block-Cache für das Caching der gesamten DIB entspricht der DIB-Größe. Der Eintrags-Cache muss etwa zwei- bis viermal so große sein wie die DIB.
Beim Abrufen eines Eintrags sucht FLAIM zunächst im Eintrags-Cache nach dem Eintrag. Wenn der Eintrag vorhanden ist, ist kein Lesen aus dem Block-Cache erforderlich. Beim Abrufen eines Blocks von der Festplatte sucht FLAIM zuerst im Cache nach dem Block. Wenn der Block vorhanden ist, ist kein Lesevorgang auf dem Datenträger erforderlich.
Beim Hinzufügen oder Ändern eines Eintrags wird für die entsprechenden Blocks des Eintrag auf dem Datenträger nicht direkt ein Commit ausgeführt. Daher sind der Datenträger und der Arbeitsspeicher unter Umständen nicht synchronisiert. Die am Eintrag vorgenommenen Aktualisierungen werden jedoch im Rollforward-Protokoll (Einzeltransaktionsprotokoll) (RFL) protokolliert. Das RFL dient dem Wiederherstellen von Transaktionen nach einem Systemfehler.
LRU (Least Recently Used) ist der Algorithmus zum Ersetzen von Einträgen im Cache.
Anhand eines Checkpoints wird die Datenträgerversion der Datenbank auf den gleichen kohärenten Zustand wie die Datenbank des Arbeitsspeichers (im Cache gespeichert) gebracht. FLAIM kann während der minimalen Aktualisierungsaktivität an der Datenbank einen Checkpoint ausführen. Der Prozess wird jede Sekunde ausgeführt und schreibt die veränderten Blocks (dirty Cache) auf den Datenträger. Im Cache geänderte, aber noch nicht auf den Datenträger geschriebene Blocks werden als „dirty Blocks“ (veränderte Blocks) bezeichnet. FLAIM ruft eine Sperre der Datenbank ab und führt die größtmögliche Menge Arbeit aus, bis entweder der Checkpoint abgeschlossen ist oder ein anderer Thread darauf wartet, die Datenbank zu aktualisieren. Um zu verhindern, dass die Datenbank auf dem Datenträger zu stark desynchronisiert wird, wird unter bestimmten Bedingungen ein Checkpoint erzwungen, auch wenn Threads auf die Aktualisierung der Datenbank warten:
Wenn der Checkpoint-Thread einen Checkpoint nicht innerhalb eines festgelegten Zeitintervalls (standardmäßig 3 Minuten) abschließen kann, wird der Checkpoint erzwungen und der veränderte Cache (dirty Cache) wird bereinigt.
Wenn die Datei des veränderten Cache den Wert maxdirtycache übertrifft (sofern festgelegt), wird ein Checkpoint erzwungen, der die Größe des veränderten Cache auf mindirtycache (sofern festgelegt) bzw. auf null reduziert.
Ein Index ist ein Satz Schlüssel, deren Anordnung die Suche nach einem bestimmten Schlüssel im Index deutlich beschleunigt. Indexschlüssel werden erstellt, indem die Inhalte eines oder mehrerer Felder (Attribute) von den Einträgen extrahiert werden. Die Indexe werden im Block-Cache gepflegt. Änderungen an den indizierten Attributen erfordern eine Änderung der Indexblöcke.
eDirectory definiert einen standardmäßigen Indexsatz für Systemattribute (Felder). Systemattribute wie parentID oder ancestorID werden für Suchen in einer Ebene und in Teilbäumen verwendet. Diese Indexe können nicht aufgehoben oder gelöscht werden. Sie werden intern im Verzeichnis verwendet. Standardmäßige Indexe werden für Attribute wie CN, Nachname, Vorname usw. verwendet. Indexe können vom Typ „Präsenz“, „Wert“ oder „Teilzeichenkette“ sein. Diese Indexe können aufgehoben werden. Nach einem Löschen werden sie automatisch neu erstellt.
Indexe können mit iManager oder mit dem Lightweight Directory Access Protocol (LDAP)-Dienstprogramm „ndsindex“ erstellt werden. Indexe sind serverspezifisch.
Durch Aktivieren der Storage Manager (StrMan)-Kennung in DSTrace (ndstrace), können Sie den für die Suchabfragen gewählten Index anzeigen.
Folgendes Beispiel betrifft ein DSTrace-Protokoll für eine Teilbaumsuche mit “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
Folgendes Beispiel betrifft ein DSTrace-Protokoll für eine Teilbaumsuche mit “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
FLAIM protokolliert die Vorgänge für jede Aktualisierungstransaktion in einer Rollforward-Protokolldatei (Einzeltransaktionsprotokolldatei) (RFL). Ein RFL dient der Wiederherstellung von Transaktionen nach einem Systemfehler oder der Wiederherstellung von einer Sicherung. Die RFL-Datei wird nach jedem Abschließen eines Checkpoints abgeschnitten, sofern sie nicht aktiviert ist (rflkeepfiles), indem eine interaktive dauerhafte Sicherung eingesetzt wird.