Architektur von Extensible Storage Engine

Letztes Änderungsdatum des Themas: 2006-01-16

Wie bereits weiter oben in diesem Abschnitt erwähnt, setzt der Exchange-Informationsspeicher auf einer ESE-Datenbank (Extensible Storage Engine) auf. Bei ESE handelt es sich um eine ISAM-Tabellenverwaltung (Indexed Sequential Access Method) für mehrere gleichzeitig angemeldete Benutzer mit vollständigen Funktionen für DML (Data Manipulation Language) und DDL (Data Definition Language). Mit ESE können Datensätze von Anwendungen gespeichert sowie Indizes für verschiedenste Zugriffe auf diese Datensätze erstellt werden.

Derzeit liegen drei Versionen von ESE vor:

• ESE97   Das Datenbankmodul in Exchange Server 5.5.
• ESENT   Das Datenbankmodul für Active Directory und zahlreiche andere Microsoft Windows-Komponenten. Im Gegensatz zu anderen Versionen von ESE (mit 5-MB-Protokolldateien und 4-KB-Seitengrößen) werden bei der ESENT-Implementierung für Active Directory Protokolldateien mit einer Größe von 10 MB und Seiten mit einer Größe von 8 KB verwendet.
• ESE98   Das Datenbankmodul in Exchange 2000 Server und Exchange Server 2003.

Anmerkung:
ESE wurde früher als JET Blue (Joint Engine Technology) bezeichnet. Bei JET Blue handelt es sich nicht um die in Access verwendete JET-Version (die als JET Red bezeichnet wird).

Transaktionen

ESE ist ein hochentwickeltes transaktionsbasiertes Datenbankmodul. Bei einer Transaktion handelt es sich um eine Folge von Operationen, die als unteilbare Einheit gelten. Entweder sind alle Operationen in einer Transaktion abgeschlossen und dauerhaft gespeichert oder keine einzige Operation wird durchgeführt. Betrachten Sie beispielsweise die Operationen beim Verschieben einer Nachricht vom Ordner Posteingang in den Ordner Gelöschte Objekte. Die Nachricht wird in einem Ordner gelöscht und in einem anderen Ordner eingefügt. Die Ordnereigenschaften werden aktualisiert. Beim Auftreten eines Fehlers sollen nicht versehentlich zwei Kopien der Nachricht, keine Kopie oder Ordnereigenschaftenwerte (z. B. Objektzahl) vorliegen, die mit dem tatsächlichen Inhalt des Ordners nicht übereinstimmen.

Zur Vermeidung dieser Probleme werden durch ESE alle Operationen in einer Transaktion gebündelt. Damit wird sichergestellt, dass alle Operationen erst dauerhaft angewendet werden, wenn die Transaktion an die Datenbankdatei übergeben wurde. Mit Übergabe der Transaktion an die Datenbankdatei werden alle Operationen dauerhaft angewendet.

Bei einem Systemabsturz wird die automatische Wiederherstellung beim Start über ESE verwaltet. Alle nicht übergebenen Transaktionen werden zurückgesetzt. Wenn vor der Übergabe einer Transaktion Fehler in ESE auftreten, wird die gesamte Transaktion zurückgesetzt, als wäre sie nie ausgeführt worden. Wenn nach der Übergabe einer Transaktion Fehler in ESE auftreten, wird die gesamte Transaktion beibehalten. Die Änderungen werden auf den Clients angezeigt.

ACID-Transaktionen

Zuverlässige Transaktionen werden im Allgemeinen als ACID-Transaktionen bezeichnet. ACID-Transaktionen können anhand der folgenden Eigenschaften identifiziert werden:

• Unteilbar   Mit diesem Begriff wird angegeben, dass die Änderung des Transaktionsstatus entweder vollständig ausgeführt oder überhaupt nicht ausgeführt wird. Zu den unteilbaren Statusänderungen zählen Änderungen der Datenbank sowie Nachrichten und Vorgänge in Wandlern.
• Konsistent   Mit diesem Begriff wird angegeben, dass eine Transaktion die korrekte Transformation des Status darstellt. Mit den als Gruppe durchgeführten Vorgängen wird keine der dem Status zugeordneten Integritätsanforderungen verletzt. Dazu muss die Transaktion ein fehlerfreies Programm sein.
• Isoliert   Mit diesem Begriff wird angegeben, dass Transaktionen zwar gleichzeitig ausgeführt werden, sie dabei aber entweder vor oder nach, jedoch nicht vor und nach einer Transaktion ausgeführt werden.
• Dauerhaft   Mit diesem Begriff wird angegeben, dass nach dem erfolgreichen Abschluss (der Übergabe) einer Transaktion der Status so geändert wird, dass er auch bei Fehlern beibehalten wird.

Der Versionsspeicher

ESE kann über den Versionsspeicher aktuelle Transaktionen protokollieren und verwalten. Daher können die Themen Isolation und Konsistenz des ACID-Tests als gegeben angesehen werden. Mit dem Versionsspeicher wird eine Liste der an der Datenbank vorgenommenen Änderungen im Arbeitsspeicher verwaltet.

Der Versionsspeicher wird in folgenden Fällen verwendet:

• Rollback   Wenn eine Transaktion zurückgesetzt werden muss, wird der Versionsspeicher überprüft und eine Liste der ausgeführten Operationen abgerufen. Durch die inverse Ausführung aller Operationen kann die Transaktion zurückgesetzt werden.
• Schreibkonflikterkennung   Wenn in zwei verschiedenen Sitzungen der gleiche Datensatz geändert werden soll, wird die zweite Änderung im Versionsspeicher erkannt und abgelehnt.
• Wiederholbare Lesevorgänge   Beim Start einer Transaktion in einer Sitzung wird immer die gleiche Ansicht der Datenbank angezeigt, auch wenn die angezeigten Datensätze in anderen Sitzungen geändert werden. Beim Lesen eines Datensatzes in einer Sitzung wird der Versionsspeicher zum Festlegen der Version des anzuzeigenden Datensatzes verwendet. Wiederholbare Lesevorgänge verfügen über eine Isolationsstufe, in der nach dem Start einer Transaktion über einen Client der Status der Datenbank zum Zeitpunkt des Transaktionsstarts angezeigt wird, unabhängig von den durch andere Clients oder in anderen Sitzungen vorgenommenen Änderungen. Wiederholbare Lesevorgänge werden durch Verwendung des Versionsspeichers implementiert. Mit einer Liste der an der Datenbank vorgenommenen Änderungen im Arbeitsspeicher kann festgelegt werden, welche Ansicht eines Datensatzes in bestimmten Sitzungen jeweils angezeigt wird.
• Verzögerung vor der Abbildprotokollierung   Hierbei handelt es sich um ein komplexes Optimierungsverfahren, mit dem über ESE weniger Daten als mit anderen vergleichbaren Datenbankmodulen protokolliert werden können.

Snapshot-Isolation

Nach dem Starten einer Transaktion wird von ESE gewährleistet, dass in der Sitzung ein einzelnes konsistentes Abbild der Datenbank zum Zeitpunkt des Starts der entsprechenden Transaktion sowie daran vorgenommene Änderungen angezeigt werden. Da die Daten auch in anderen Sitzungen geändert und die zugehörigen Transaktionen übergeben werden können, werden Änderungen in Transaktionen nicht angezeigt, die vor der Übergabe gestartet wurden. Benutzer können Datensätze nur ändern, wenn die jeweils aktuellste Version angezeigt wird. Andernfalls schlägt die Aktualisierung mit JET_errWriteConflict fehl. Die zeitlich vor der letzten Transaktion liegenden Versionen werden automatisch verworfen.

ESE verfügt über eine Transaktionsisolationsstufe mit der Bezeichnung Snapshot-Isolation. Über die Snapshot-Isolationsstufe können Benutzer in einer übergangsweise konsistenten Ansicht der Datenbank auf die letzte übergebene Zeile zugreifen. Bei der Snapshot-Isolation handelt es sich um einen Steuerungsalgorithmus mit vollständiger Parallelität, der zuerst in A Critique of ANSI SQL Isolation Levels beschrieben wurde. Die Snapshot-Isolation wird mit ESE durch Verwendung von wiederholbaren Lesevorgängen implementiert.

ESE-Datenbankstruktur

Alle Daten in der Rich-Text-Datenbankdatei werden in B-Strukturen gespeichert. Das „B“ in B-Struktur steht für „ausgeglichen“ (Englisch: balanced). „Struktur“ bezieht sich auf eine Anordnung, die der einer Ordnerstruktur in einem Dateisystem entspricht, bei der ein Stamm den Objekten (Datenbankseiten) übergeordnet ist, die wiederum anderen Objekten übergeordnet sind. B-Strukturen sind so entworfen, dass schnell auf Daten auf der Festplatte zugegriffen werden kann. Da Lese- und Schreibvorgänge auf einer Festplatte mehr Zeit in Anspruch nehmen als im Arbeitsspeicher, ist eine B-Struktur in 4-KB-Seiten unterteilt, sodass die erforderlichen Daten über ESE mit der Mindestanzahl von E/A-Vorgängen auf der Festplatte abgerufen werden können. Eine ESE-Datenbank kann bis zu 232 Seiten oder 16 Terabyte enthalten. Tatsächlich wird die Datenbankgröße nur durch die Funktionen zum Sichern, Wiederherstellen oder Ausführen anderer Verwaltungsoperationen in der Datenbank (z. B. Offlinedefragmentierung, Datenbankreparaturen) in einer angemessenen Zeit begrenzt.

Datenbankseiten

Die Seitengröße in ESE wird in der Anwendung definiert, in der sie verwendet wird. In ESE97 (Exchange Server 5.5) und ESE98 (Exchange 2000 Server und Exchange Server 2003) werden beispielsweise 4-KB-Seiten verwendet, in ESENT (Active Directory) dagegen 8-KB-Seiten. Jede dieser 4-KB- oder 8-KB-Seiten enthält Verweise auf andere Seiten oder auf die tatsächlichen in der B-Struktur gespeicherten Daten. Der Verweis und die Datenseiten sind zusammen in der Datei vorhanden.

Zur Optimierung der Systemleistung werden die Seiten möglichst lange in einem Puffer im Arbeitsspeicher zwischengespeichert, sodass sie nicht auf der Festplatte gespeichert werden müssen. Jede Seite beginnt mit einer Kopfzeile mit einer Größe von 40 Byte, in der folgende Werte aufgeführt sind:

• pgnoThis   Mit diesem Wert wird die Seitenzahl der Seite angegeben.
• DbtimeDirtied   Mit diesem Wert wird der Zeitpunkt angegeben, an dem die Seite zuletzt geändert wurde.
• pgnoPrev   Mit diesem Wert wird die Seitenzahl der angrenzenden linken Seite auf dem Endknoten angegeben.
• pgnoNext   Mit diesem Wert wird die Seitenzahl der angrenzenden rechten Seite auf dem Endknoten angegeben.
• ObjidFDP   Mit diesem Wert wird die Objekt-ID einer speziellen Seite in der Datenbank angegeben, die als Vater der Datenbankseite (FDP, Father of the Data Page) bezeichnet wird. Dadurch ist festgelegt, welcher B-Struktur die Seite zugeordnet ist. Die FDP-Seite wird bei der Reparatur verwendet.
• cbFree   Mit diesem Wert wird die Größe der in der Seite verfügbaren Byte angegeben.
• cbUncommittedFree   Mit diesem Wert wird die Größe der verfügbaren, nicht übergebenen Byte (freigegebene Byte, die beim Zurücksetzen verwendet werden können) in der Seite angegeben.
• ibMicFree   Mit diesem Wert wird der Seitenoffset für die nächsten verfügbaren Byte oben in der Seite angegeben.

ECC-Prüfsumme

Exchange Server 2003 Service Pack 1 (SP1) verfügt über eine neue Funktion, die so genannte ECC-Prüfsumme (Error Correcting Code). Die ECC-Prüfsumme ist ein neues Prüfsummenformat, über das Einzelbit-Fehler in Datenbankseiten (in der EDB-Datei, STM-Datei und den Transaktionsprotokolldateien) korrigiert werden können. In diesem neuen Prüfsummenformat werden 64 Bit verwendet, in älteren Prüfsummenformaten dagegen nur 32 Bit. Der neue Code kann in Datenbanken mit älteren Formaten verwendet werden, ältere ESE-Versionen jedoch nicht in Datenbanken im aktuellen Format. Nach der Aktualisierung des Datenbankmoduls haben alle in die Datenbank geschriebenen Seiten das neue Prüfsummenformat. Bei Seiten, die gelesen und nicht geändert werden, wird das Prüfsummenformat nicht aktualisiert.

Anmerkung:

Nach der Bereitstellung der neuen Datei ESE.dll wird das Prüfsummenformat aller Seiten in der Datenbank bei jeder Offlinedefragmentierung aktualisiert. Dadurch verlängert sich die Dauer der Defragmentierung einer Datenbank möglicherweise erheblich. Aus diesem Grund wird diese Vorgehensweise nicht empfohlen. Ebenso wird von der Ausführung von esetuil mit dem Parameter /k abgeraten, da hierbei ebenfalls die Prüfsumme aller Seiten in der Datenbank erstellt wird.

Bei Datenbankseiten mit dem älteren Prüfsummenformat wird zuerst eine 4-Byte-Prüfsumme und anschließend eine 4-Byte-Seitenzahl erstellt, mit der überprüft wird, ob die angeforderte Seite tatsächlich von der Festplatte gelesen wurde.

Beim neuen Prüfsummenformat wird die 4-Byte-Seitenzahl durch eine 8-Byte-Seitenzahl ersetzt. Bei der Berechnung der Prüfsumme wird die Seitenzahl als Eingabeparameter verwendet. Wenn die falsche Seite von der Festplatte gelesen wurde, führt dies zu einer Nichtübereinstimmung der Prüfsumme.

Das aktuelle Prüfsummenformat setzt sich aus zwei 32-Bit-Prüfsummen zusammen. Bei der ersten handelt es sich um eine XOR-Prüfsumme, die in fast identischer Weise wie die Prüfsumme im älteren Format berechnet wird. Dabei wird die Seitenzahl als Ausgangswert zur Berechnung der Prüfsumme verwendet. Die zweite 32-Bit-Prüfsumme ist eine ECC-Prüfsumme, mit der die Einzelbit-Fehler in der Seite korrigiert werden können.

Datenbankkonsistenz und -1018-Fehler

• Beim Lesen einer Seite wird von ESE ein Kennzeichen überprüft. Dadurch wird festgestellt, ob die Seite das aktuelle Prüfsummenformat aufweist. Anschließend wird die entsprechende Prüfsumme (mit dem aktuellen oder älteren Format) berechnet. Bei einer Nichtübereinstimmung der Prüfsumme mit der Prüfsumme im aktuellen Format versucht ESE, den Fehler zu korrigieren. Wenn der Fehler nicht automatisch behoben werden kann, wird in Exchange eine -1018-Fehlermeldung ausgegeben.

Möglicherweise wird ein -1018-Fehler durch den Exchange-Informationsspeicher erzeugt, wenn im Exchange-Informationsspeicher folgende Vorgänge durchgeführt werden:

• Erstellen einer Seite mit der falschen Prüfsumme
• Ordnungsgemäßes Erstellen einer Seite, jedoch Anweisung an das Betriebssystem zum Schreiben der Seite in den falschen Speicherort

Wenn ein Systemadministrator einen -1018-Fehler erkennt oder Diagnosehardwaretests auf dem Server ausführt und dabei keine Fehler ausgegeben werden, zieht er möglicherweise den Schluss, dass ein interner Fehler in Exchange Server aufgetreten ist, da die Analyse der Hardware positiv ausgefallen ist.

In vielen Fällen wurden durch weitere Untersuchungen durch Microsoft oder Hardwarehersteller schwerwiegende Fehler in der Hardware, Firmware oder in Gerätetreibern festgestellt, aufgrund derer die Datenbankdatei beschädigt wurde.

Aus verschiedenen Gründen werden in gewöhnlichen Diagnosetests unter Umständen nicht alle möglichen Fehler ermittelt. Probleme in der Firmware oder Treibersoftware werden möglicherweise mit den Funktionen von Diagnoseprogrammen nicht gefunden. Mit Diagnosetests können die langen Laufzeiten oder komplexen Ladevorgänge eventuell nicht entsprechend simuliert werden. Darüber hinaus wird das System durch die Diagnoseüberwachung oder die Debugprotokollierung unter Umständen so geändert, dass die Fehler nicht erneut auftreten.

Durch die Einfachheit und Stabilität der Exchange Server-Mechanismen zum Erstellen von Prüfsummen und Schreiben von Seiten in die Datenbankdatei wird ein -1018-Fehler in aller Regel nicht durch Exchange Server selbst hervorgerufen. Die Prüfsummenüberprüfung und die Erkennung falscher Seiten sind einfach und zuverlässig und wurden seit der ersten Exchange-Version nahezu unverändert beibehalten, mit Ausnahme von geringfügigen Änderungen zur Anpassung an Datenbankseitenformate von einzelnen Datenbankversionen.

Eine Prüfsumme wird für eine auf Festplatte zu schreibende Seite erstellt, nach dem alle anderen Daten sowie die Seitenzahl in die Seite geschrieben wurden. Nach dem Hinzufügen der Prüfsumme zur Seite weist Exchange Server das Microsoft Windows Server-Betriebssystem an, die Seite über standardisierte und veröffentlichte Windows Server-APIs auf Festplatte zu schreiben.

Unter Umständen wird die Prüfsumme für eine Seite richtig erstellt, die Seite jedoch an einen falschen Speicherort auf die Festplatte geschrieben. Dies kann durch einen temporären Speicherfehler hervorgerufen werden, z. B. durch einen „Bit Flip“-Fehler. In Exchange wird beispielsweise eine neue Version von Seite 70 erstellt. Die Seite selbst enthält keine Fehler, die Kopie der Seitenzahl im Festplattencontroller oder im Betriebssystem wurde jedoch willkürlich verändert. Dieses Problem kann auftreten, wenn 70 (binär 1000110) in einer instabilen Speicherzelle in 6 (binär 000110) geändert wurde. Die Prüfsumme der Seite ist weiterhin richtig, der Speicherort der Seite in der Datenbank nun jedoch falsch. In Exchange Server wird ein -1018-Fehler für die Seite ausgegeben, wenn die logische Seitenzahl nicht mit dem physischen Speicherort der Seite übereinstimmt.

Ein anderer (in Exchange Server verursachter) Fehler kann bei der Seitennummerierung auftreten, wenn in Exchange Server die falsche Seitenzahl in die Seite selbst geschrieben wird. Hierdurch treten jedoch andere Fehler, nicht der -1018-Fehler auf. Wenn von Exchange Server 71 in Seite 70 geschrieben und anschließend die Prüfsumme der Seite berechnet wird, wird die Seite nach erfolgreichem Seitenzahlen- sowie Prüfsummentest in Speicherort 71 geschrieben.

In der Regel wird eine Exchange Server-Datenbank durch einen einzelnen ausgegebenen -1018-Fehler nicht beendet, sondern lediglich der -1018-Fehler selbst protokolliert. Die Seite befindet sich unter Umständen in einem Ordner, der selten aufgerufen wird (z. B. der Ordner Gesendet oder Gelöschte Objekte), oder in einer Anlage, die nicht oft geöffnet wird oder gar leer ist.

Obwohl durch einen einzelnen -1018-Fehler wahrscheinlich kein großer Datenverlust entsteht, sollten diese Fehler dennoch berücksichtigt werden, da sie darauf hindeuten, dass Daten im Speichersystem mindestens einmal nicht zuverlässig gespeichert oder wiederhergestellt wurden. Obwohl es sich bei einem -1018-Fehler um ein vorübergehendes Problem handeln kann, das nie wieder auftritt, ist es wahrscheinlicher, dass dieser Fehler eine frühzeitige Warnung für ein Problem ist, das zunehmend schwerwiegender wird. Auch wenn der erste -1018-Fehler bei einer leeren Seite in der Datenbank auftritt, können Sie nicht wissen, welche Seite möglicherweise demnächst beschädigt wird. Wenn eine wichtige globale Tabelle beschädigt ist, kann die Datenbank möglicherweise nicht gestartet und eine Reparatur nur teilweise erfolgreich oder überhaupt nicht durchgeführt werden.

Nach der Protokollierung eines -1018-Fehlers sollten Sie alle Möglichkeiten für drohende Fehler oder einer weiteren Beschädigung in der Datenbank überprüfen, bis die Ursache für den Fehler gefunden und behoben wurde.

Datenbankstrukturausgleich

Eine der Hauptfunktionen von ESE besteht darin, dass die Datenbankstruktur permanent ausgeglichen wird. Der Vorgang zum Ausgleichen der Struktur wird durchgeführt, wenn alle Seiten geteilt oder zusammengeführt sind. Wie in der folgenden Abbildung dargestellt, stimmt die Anzahl der Knoten im Stamm der Struktur immer mit den Knoten in den Endknoten der Struktur überein. Daher ist die Struktur ausgeglichen.

Anmerkung:

Obwohl die Strukturen in einer ESE-Datenbank im Allgemeinen als B-Strukturen bezeichnet werden, handelt es sich in Wirklichkeit um B+-Strukturen. B+-Strukturen weisen die gleichen Merkmale wie B-Strukturen auf, jede Datenseite in einer B+-Struktur verfügt jedoch zusätzlich über Seitenverweise zur vorherigen und nächsten angrenzenden Seite im Endknoten. Obwohl die Aktualisierung dieser Verweise beim Einfügen oder bei Teilungs- bzw. Zusammenführungsvorgängen einen zusätzlichen Aufwand darstellt, kann über die Verweise eine schnellere sequentielle Suche durch die Daten in der B+-Struktur durchgeführt werden.

In ESE handelt es sich bei einer Datenbanktabelle um eine Sammlung von B-Strukturen. Jede Tabelle umfasst eine B-Struktur, die die Daten enthält, obwohl mehrere B-Strukturen für sekundäre Indizes zum Bereitstellen verschiedener Ansichten der Daten vorliegen können. Wenn eine Spalte oder ein Feld in einer Tabelle zu groß werden, um in der B-Struktur gespeichert werden zu können, werden sie auf eine gesonderte B-Struktur aufgeteilt, die so genannte Langwertstruktur.

Die Definition der Tabellen und der zugeordneten B-Strukturen wird in einer anderen B-Struktur gespeichert, dem so genannten Systemkatalog. Der Verlust des Systemkatalogs führt zu schwerwiegenden Problemen. Aus diesem Grund sind in ESE zwei identische Kopien dieser B-Struktur in jeder Datenbank gespeichert, wobei eine auf Seite 4 beginnt und die andere auf Seite 24.

Teilung

Wenn eine Seite fast gefüllt ist, wird etwa die Hälfte der Daten in eine sekundäre Seite verschoben und in der übergeordneten Seite der sekundären Seite ein zusätzlicher Schlüssel gespeichert. Dieser Vorgang wird nur durchgeführt, wenn die übergeordnete Seite nicht voll ist. In diesem Fall wird die übergeordnete Seite geteilt und der dieser Seite übergeordneten Seite ein Verweis hinzugefügt. Letzten Endes muss möglicherweise jede Verweisseite bis zum Stammblock geteilt werden. Wenn der Stammblock geteilt werden muss, wird eine zusätzliche Seitenebene in die Struktur eingefügt. In einem übertragenen Sinne nimmt die Struktur an Höhe zu.

Zusammenführung

Wenn eine Seite fast leer ist, wird sie mit einer angrenzenden Seite zusammengeführt. Die Verweise in der übergeordneten Seite werden aktualisiert, und gegebenenfalls wird die Seite wiederum mit einer anderen Seite zusammengeführt. Wenn jede Verweisseite bis zum Stammblock mit einer anderen Seite zusammengeführt werden muss, verringert sich die Höhe der Struktur. Zum Abrufen eines Endknotens (Daten) sucht ESE beginnend beim Stammknoten und dann entsprechend den Seitenverweisen, bis der gewünschte Endknoten abgerufen wird.

Auffächerung

Die Baumstruktur einer B-Struktur in ESE kann sehr weit aufgefächert werden. Dies bedeutet, dass in ESE alle Daten in einer 50-GB-Tabelle mit höchstens vier Lesevorgängen auf der Festplatte (drei Verweisseiten und die Datenseite) abgerufen werden können. In ESE werden über 200 Seitenverweise pro 4-KB-Seite gespeichert, sodass Strukturen mit einer sehr geringen Anzahl von übergeordneten und untergeordneten Ebenen (auch als flache Strukturen bezeichnet) verwendet werden können. In ESE wird darüber hinaus ein Schlüssel der aktuellen Struktur gespeichert, sodass diese auf schnelle Weise durchsucht werden kann. In der Abbildung weiter oben ist eine Struktur mit drei über- und untergeordneten Ebenen dargestellt. In einer Struktur mit vier über- und untergeordneten Ebenen können mehrere Gigabyte Daten gespeichert werden.

Indizes

Eine herkömmliche B-Struktur wird nur auf eine bestimmte Weise indiziert. Dazu wird ein Schlüssel verwendet. Die Daten müssen über diesen Schlüssel abgerufen werden. Die Datensätze in der Nachrichtentabelle werden beispielsweise mittels einer eindeutigen ID der Nachricht indiziert, der so genannten MTS-ID (Nachrichtenübertragungsdienst). Benutzer möchten die Daten in den Nachrichtentabellen jedoch möglicherweise in einem benutzerfreundlicheren Format anzeigen.

Die Daten werden über Indizes, oder genauer gesagt über sekundäre Indizes abgerufen. Jeder sekundäre Index ist eine andere B-Struktur, in der der ausgewählte sekundäre Schlüssel dem primären Schlüssel zugeordnet wird. Daher sind B-Strukturen im Verhältnis zu den indizierten Daten relativ klein.

Die Verwendung von sekundären Indizes kann anhand der Vorgänge verstanden werden, die durchgeführt werden, wenn ein Benutzer die Darstellung von Nachrichten in einem Messagingordner ändert. Wenn Sie die Ordneransicht in Outlook so ändern, dass sie nach dem Betreff und nicht nach der Empfangszeit angeordnet ist, wird im Informationsspeicher und in ESE ein neuer sekundärer Index in der Nachrichtenordnertabelle erstellt.

Bei der ersten Änderung der Ansicht eines großen Ordners tritt eine zeitliche Verzögerung auf. Beim Überprüfen des Servers kann eine kleine Spitze in der Festplattenaktivität festgestellt werden. Beim erneuten Wechsel zu dieser Ansicht ist der Index bereits erstellt, und die Reaktion erfolgt viel schneller.

Im Microsoft Exchange-Informationsspeicherdienst werden B-Strukturen für sekundäre Indizes acht Tage gespeichert. Wenn sie nicht verwendet werden, werden sie vom Microsoft Exchange-Informationsspeicherdienst im Hintergrund gelöscht.

Langwerte

In ESE kann sich eine Spalte oder ein Datensatz nicht über mehrere Seiten in der B-Struktur erstrecken. Bei bestimmten Werten (z. B. PR_BODY, der Nachrichtentext einer Nachricht) kann jedoch die 4-KB-Begrenzung einer Seite überschritten werden. Diese werden als Langwerte bezeichnet (LV). In der B-Struktur für Langwerte einer Tabelle werden diese langen Werte gespeichert.

Wenn Daten in eine ESE-Tabelle eingefügt werden und zu groß für die B-Struktur sind, werden sie in 4-KB-Seiten aufgeteilt und in der gesonderten B-Struktur für Langwerte dieser Tabelle gespeichert. Der Datensatz in der B-Struktur für Daten enthält einen Verweis auf den Langwert. Der Verweis wird als Langwert-ID (LID) bezeichnet. Dies bedeutet, dass der Datensatz über einen Verweis auf LID 256 verfügt.

Datensatzformat

Eine Sammlung von B-Strukturen ergibt eine Tabelle. Eine Tabelle besteht wiederum aus einer Reihe von Zeilen. Eine Zeile wird auch als Datensatz bezeichnet. Ein Datensatz setzt sich aus mehreren Spalten zusammen. Die maximale Größe eines Datensatzes und daher die maximale Anzahl der in einem Datensatz angezeigten Spalten wird durch die Größe der Datenbankseite abzüglich der Größe der Kopfzeile festgelegt. ESE-Datenbankseiten haben eine Größe von 4 KB. Daraus ergibt sich eine maximale Datensatzgröße von ca. 4050 Byte (4096 Byte minus Größe der Seitenkopfzeile).

Spaltendatentypen

In jeder Spaltendefinition muss der in der Spalte gespeicherte Datentyp angegeben sein. In ESE werden die in der folgenden Tabelle beschriebenen Datentypen unterstützt.

Spaltendatentypen in ESE (Extensible Storage Engine)

Die Spaltendatentypen sind in zwei Kategorien unterteilt. Die erste Kategorie enthält feste und variable Spalten. Die zweite Kategorie enthält markierte Spalten. Jede Spalte ist als 16-Byte-FIELD-Struktur definiert, zusätzlich zur Größe des Spaltennamens.

Beim Erstellen einer Tabelle in einer ESE-Datenbank wird diese durch ein Array von FIELD-Strukturen definiert. Mit dem Array werden die einzelnen Spalten in der Tabelle festgelegt. In diesem Array wird jede Spalte durch einen Indexwert dargestellt, der als Spalten-ID bezeichnet wird. Dies entspricht in etwa einem normalen Array, in dem mit einer ID auf Arraymitglieder verwiesen werden kann, z. B. Array[0], Array[1]. Über eine ID kann auf Spalten schnell zugegriffen werden, für eine Suche nach Spaltenname muss jedoch eine lineare Suche im Array der FIELD-Strukturen durchgeführt werden.

Feste und variable Spalten

Feste Spalten weisen eine festgelegte Datenlänge auf. Jeder Datensatz belegt eine festdefinierte Größe an Speicherplatz, selbst wenn kein Wert definiert ist. Die Datentyp-IDs 1 bis 10 können als feste Spalten definiert werden. In jeder Tabelle können bis zu 126 feste Spalten (Spalten-ID 1 bis 127) festgelegt werden.

Variable Spalten können Daten mit einer Größe bis zu 256 Byte enthalten. Ein Offsetarray wird im Datensatz mit dem größten Satz von variablen Spalten gespeichert. Für jede Spalte sind 2 Byte erforderlich. Die Datentyp-IDs 10 und 11 können als variable Spalten definiert werden. In jeder Tabelle können bis zu 127 variable Spalten (Spalten-ID 128 bis 256) festgelegt werden.

Markierte Spalten

In ESE werden Spalten, die selten oder mehrfach in einem Datensatz auftreten, als markierte Spalten definiert. Eine nicht definierte markierte Spalte belegt keinen zusätzlichen Speicherplatz. Eine markierte Spalte kann im gleichen Datensatz mehrfach vorhanden sein. Wenn eine markierte Spalte in einem sekundären Index vorhanden ist, wird über den Index auf jedes einzelne Vorkommen der Spalte verwiesen.

Markierte Spalten können eine variable und unbegrenzte Datenlänge aufweisen. Die Spalten-ID und die Länge werden mit den Daten gespeichert. Alle Datentypen können als markierte Spalten definiert werden. In jeder Tabelle können bis zu 64.993 markierte Spalten festgelegt werden.