Erweiterbare Speicher-Engine-Dateien
Gilt für: Windows | Windows Server
Erweiterbare Speicher-Engine-Dateien
Die Erweiterbare Speicher-Engine verwendet die folgenden Dateitypen:
Diese Tabelle enthält eine Übersicht über die Datendateinamen, die von ESE verwaltet werden. Für Windows Vista und höher wirkt sich die einstellung JET_paramLegacyNames auf die verwendeten Dateinamen aus.
| Bezeichnung | Wert |
|---|---|
Transaktionsprotokolldateien
Transaktionsprotokolldateien enthalten Vorgänge für Datenbankdateien. Sie enthalten genügend Informationen, um eine Datenbank nach einer unerwarteten Prozessbeendigung oder dem Herunterfahren des Systems in einen logisch konsistenten Zustand zu versetzen.
Die Namen der Protokolldateien sind von einem dreistelligen Basisnamen abhängig, der mit JET_paramBaseName festgelegt werden kann. In den folgenden Beispielen wird der Basisname "edb" verwendet, da dies der Standardbasisname ist. Die Erweiterung für die Transaktionsprotokolldateien ist entweder .log oder .jtx, je nachdem, ob die JET_bitESE98FileNames im parameter JET_paramLegacyFileNames festgelegt ist. Weitere Informationen finden Sie unter Systemparameter der erweiterbaren Speicher-Engine.
Transaktionsprotokolldateien heißen <basis><generation-number.log>, beginnend mit 1. Die Protokollgenerierungsnummer hat ein hexadezimales Format. Beispielsweise ist edb00001.log das erste Protokoll und edb000ff.log das 255. Protokoll. Die Protokolldateien haben fünf Hexadezimalstellen im Namen der Protokolldatei, bis zur 1048576. Protokolldatei, an der die Protokolldateien in einem 11.3-Format benannt werden (z. B. edb00100000.log). <base.log> ist immer die Protokolldatei, die derzeit verwendet wird. Wenn die Datenbank-Engine nicht aktiv ist, kann die Generierung von edb.log mithilfe des folgenden Befehls identifiziert werden: esentutl.exe -ml edb.log.
Transaktionsprotokolldateien verfügen zwar über . LOG-Erweiterung, die häufig mit Textdateien verknüpft ist, Transaktionsprotokolldateien sind in einem Binärformat und sollten niemals von einem Benutzer bearbeitet werden. Datenbankvorgänge werden zuerst in das Protokoll geschrieben. Die Daten können später in die Datenbankdatei geschrieben werden. möglicherweise sofort, möglicherweise viel später. Im Falle einer unerwarteten Prozess- oder Systembeendigung sind die Vorgänge weiterhin in den Protokolldateien vorhanden, und unvollständige Transaktionen können zurückgesetzt werden. Die Wiedergabe von Transaktionsprotokolldateien wird als vorläufige Wiederherstellung bezeichnet und erfolgt automatisch, wenn JetInit oder JetInit2 aufgerufen wird. Die vorläufige Wiederherstellung kann auch manuell mit der Option "-r" des Esentutl.exe-Programms durchgeführt werden. Die Wiedergabe von Transaktionsprotokolldateien für eine Datenbank, die aus einer Sicherung wiederhergestellt wird, wird als harte Wiederherstellung bezeichnet.
Protokolldateien haben eine feste Größe und können mit JET_paramLogFileSize angepasst werden. Wenn die aktuelle Protokolldatei (d. h. edb.log) gefüllt wird, wird sie in <Base><generation-number.log> umbenannt, und im Transaktionsprotokolldatenstrom wird eine neue Transaktionsprotokolldatei benötigt.
Jeder Datenbank instance ist eine einzelne Protokolldateisequenz zugeordnet. Windows XP hat JetCreateInstance eingeführt, sodass mehrere Transaktionsprotokolldateisequenzen von einem einzelnen Prozess verwendet werden können. Mehrere Transaktionsprotokolldateisequenzen können jedoch nicht im selben Verzeichnis vorhanden sein.
Transaktionsprotokolldateien sollten fast nie manuell bearbeitet, umbenannt, verschoben oder gelöscht werden, da Daten beschädigt werden können.
Transaktionsprotokolldateien werden von der Datenbank-Engine während einer vollständigen Sicherung (siehe JetBackup, JetTruncateLog, JetTruncateLogInstance) oder während des normalen Betriebs gelöscht, wenn die Zirkelprotokollierung aktiviert ist.
Nachdem eine Transaktionsprotokolldatei aufgefüllt wurde, muss die Datenbank-Engine eine neue Protokolldatei erstellen. Die Zirkelprotokollierung ist ein Mittel, mit dem Protokolldateien automatisch von der Datenbank-Engine bereinigt werden können, wenn sie für die Absturzwiederherstellung nicht mehr benötigt werden. Dieser Prozess ist eine Alternative zum Entfernen von Protokolldateien als Nebenprodukt der Durchführung einer Sicherung. Die zirkuläre Protokollierung kann mit dem systemparameter JET_paramCircularLog gesteuert werden. Transaktionsprotokolldateien sollten nicht mit einer anderen Methode gelöscht werden.
Temporäre Transaktionsprotokolldateien
Wenn edb.log aufgefüllt wird, muss ESE eine neue Datei erstellen. Die neue Protokolltransaktionsdatei wird vor ihrer Verwendung durch ESE als temporäre Transaktionsprotokolldatei bezeichnet.
Während eine neue Protokolldatei erstellt und ihre Größe erweitert wird, wird sie als Basis>tmp.log bezeichnet<. Das Erstellen einer neuen Datei kann ein potenziell kostspieliger Vorgang sein, sodass ESE die nächste Protokolldatei proaktiv als Hintergrundaufgabe erstellt.
Da die temporäre Transaktionsprotokolldatei in Erwartung der Notwendigkeit einer neuen Transaktionsprotokolldatei erstellt wird, enthält sie keine nützlichen Informationen.
Reservierte Transaktionsprotokolldateien
Die reservierten Transaktionsprotokolldateien werden beim Starten der Engine erstellt, damit wichtige Vorgänge protokolliert werden können, um ein sauber Herunterfahren zu erhalten.
Windows Vista: In Windows Vista und höher heißen die reservierten <Transaktionsprotokolldateien basis>RESXXXXX.jrs.
Windows Server 2003: In Windows Server 2003 und früheren Versionen heißen die reservierten Transaktionsprotokolldateien res1.log und res2.log.
Wenn der Speicherplatz für die Datenbank-Engine nicht mehr verfügbar ist, kann keine neue Protokolldatei erstellt werden. Am sichersten ist das saubere Herunterfahren, aber einige Vorgänge (z. B. Rollbackvorgänge) müssen weiterhin protokolliert werden. Die meisten Datenbankvorgänge schlagen in dieser Phase fehl.
Da die reservierten Transaktionsprotokolldateien in Erwartung der Notwendigkeit von Transaktionsprotokolldateien in einem Out-of-Disk-Szenario erstellt werden, enthalten sie keine nützlichen Informationen.
Prüfpunktdateien
Die Prüfpunktdatei speichert den Prüfpunkt für eine bestimmte Transaktionsprotokolldateisequenz. Die Prüfpunktdatei hat den Namen <base.chk> oder <base.jcp>, je nachdem, ob die JET_bitESE98FileNames im parameter JET_paramLegacyFileNames festgelegt ist und ihr Speicherort durch JET_paramSystemPath angegeben wird.
Datenbankvorgänge werden zuerst in die Protokolldateien geschrieben und dann im Arbeitsspeicher zwischengespeichert. Zu einem späteren Zeitpunkt werden die Vorgänge in die Datenbankdatei geschrieben, aber aus Leistungsgründen entspricht die Reihenfolge, in der Vorgänge in die Datenbankdatei geschrieben werden, möglicherweise nicht der Reihenfolge, in der sie ursprünglich protokolliert wurden. Vorgänge, die in die Transaktionsprotokolldatei geschrieben werden, befinden sich in einem von zwei Zuständen:
In die Transaktionsprotokolldatei und die Datenbankdatei geschrieben.
In die Transaktionsprotokolldatei geschrieben und noch nicht in die Datenbankdatei geschrieben.
Viele Datenbankvorgänge können in einer einzelnen Transaktionsprotokolldatei gespeichert werden. Eine angegebene Protokolldatei kann aus den folgenden Elementen bestehen:
Alle In die Datenbankdatei geschriebenen Vorgänge.
Keine In die Datenbankdatei geschriebenen Vorgänge
Eine Mischung aus Vorgängen, die in die Datenbankdatei geschrieben wurden, und Vorgängen, die noch nicht in die Datenbankdatei geschrieben wurden.
Der Prüfpunkt bezieht sich auf den Zeitpunkt im Transaktionsprotokolldatenstrom, an dem alle Vorgänge vor dem Prüfpunkt in die Datenbankdatei geschrieben wurden. Es gibt keine Garantie für die Vorgänge, die nach dem Prüfpunkt auftreten. Einige befinden sich möglicherweise im Arbeitsspeicher, und einige werden möglicherweise in die Datenbank geschrieben.
Da alle Vorgänge in den Protokolldateien vor dem Prüfpunkt in der Datenbankdatei dargestellt werden, werden nur die Transaktionsprotokolldateien nach dem Prüfpunkt für die vorläufige Wiederherstellung benötigt, um eine bestimmte Datenbank in einen sauber Zustand zu versetzen.
Datenbankdateien
Die Datenbankdatei enthält das Schema für alle Tabellen in der Datenbank, die Datensätze für alle Tabellen in der Datenbank und die Indizes für die Tabellen. Der Speicherort wird mithilfe von JetCreateDatabase, JetCreateDatabase2, JetAttachDatabase oder JetAttachDatabase2 angegeben.
Eine Datenbank wird erst nach einem erfolgreichen Aufruf von JetTerm oder JetTerm2 sauber heruntergefahren.
Das Esentutl.exe Programm kann mit der Option "-mh" erkennen, ob eine Datenbank sauber heruntergefahren wird. Beispielsweise liest "esentutl.exe -mh sample.edb" den Datenbankheader einer Datenbank namens sample.edb und gibt den Zustand von sample.edb aus. Möglicherweise wird "State: Clean Shutdown" oder "State: Dirty Shutdown" ausgegeben.
Eine Datenbank, die nicht sauber heruntergefahren wurde, befindet sich in einem modifiziert Zustand zum Herunterfahren. Vor Windows XP wurde dieser Zustand als inkonsistent bezeichnet. Eine modifiziert (inkonsistente) Datenbank kann mit der vorläufigen Wiederherstellung in einen sauber Zustand versetzt werden. Eine beschädigte Datenbank ist nicht identisch mit einer modifiziert -Datenbank (inkonsistent).
Eine beschädigte Datenbank bezieht sich auf eine physische oder logische Beschädigung und kann nicht mit der vorläufigen Wiederherstellung behoben werden. Physische Beschädigungen können Bit-Flips sein, die häufig von den Prüfsummen auf den Datenbankseiten abgefangen werden. Eine fehlerhafte Prüfsumme in einer Datenbankdatei manifestiert sich als JET_errReadVerifyFailure Fehler.
Nur sauber heruntergefahrene Datenbanken können sicher verschoben oder umbenannt werden. Wenn eine Datenbank nicht ordnungsgemäß heruntergefahren wurde, kann sie nicht automatisch sicher verschoben oder umbenannt werden.
Mehrere Datenbanken können einer einzelnen Transaktionsprotokolldateisequenz zugeordnet werden.
Temporäre Datenbanken
Die temporäre Datenbank wird als Sicherungsspeicher für Temptables und auch beim Erstellen von Indizes verwendet.
Name und Speicherort sind mit JET_paramTempPath konfiguriert.
Temptables werden mit JetOpenTempTable, JetOpenTempTable2, JetOpenTempTable3, JetOpenTemporaryTable erstellt. Sie werden auch durch einige API-Aufrufe erstellt und verwendet, um Schemainformationen (z. B. JetGetIndexInfo) zurückzugeben.
Leeren von Zuordnungsdateien
Beginnend mit dem Windows 10 Anniversary Update (Client) und Windows Server 2016 (Server) hat ESE eine zusätzliche Schutzebene vor verlorenen Schreibvorgängen (oder verlorenen Leerungen) 1 hinzugefügt, sodass solche Ereignisse prozessübergreifend neu initialisiert2 erkannt werden können. Dieses Feature erfordert das Beibehalten von Metadaten in einer separaten Datei, die als "Zuordnungsdatei leeren" bezeichnet wird.
Für jede Datenbankdatei wird eine Entleerungszuordnungsdatei erstellt, die sich im selben Verzeichnis befindet. Die Datei wird ähnlich wie die Datenbankdatei benannt, hat jedoch eine andere Erweiterung. Wenn die Clientanwendung beispielsweise eine Datenbank mit dem vollständigen Pfad C:\MyDirectory\MyDabatase.edb erstellt, lautet die entsprechende Zuordnungsdatei C:\MyDirectory\MyDabatase.jfm.
Durch diese Erweiterung werden zwei Anforderungen für die Benennung von Datenbankdateien eingeführt:
Zwei Datenbanken im selben Verzeichnis dürfen nicht denselben Dateinamen mit unterschiedlichen Erweiterungen aufweisen. Beispiel: C:\MyDirectory\MyDabatase.db1 und C:\MyDirectory\MyDabatase.db2.
2. Eine Datenbank darf keine JFM-Erweiterung aufweisen.
Wenn Sie eine Datenbankdatei manuell kopieren oder verschieben, sollte die entsprechende Entleerungszuordnungsdatei ebenfalls kopiert bzw. in dasselbe Zielverzeichnis verschoben werden. Wenn zum Zeitpunkt einer neuen Datenbankanlage (über JetAttachDatabase) keine entleerte Zuordnungsdatei vorhanden ist, wird eine neue Datei erstellt und bei Bedarf erneut aufgefüllt, wenn Seiten aus der Datenbank eingelesen werden. Das Mischen von nicht übereinstimmenden Datenbank- und Leerenzuordnungsdateien wird von ESE verarbeitet und erzwingt, dass die nicht übereinstimmende Zuordnung gelöscht und von Grund auf neu erstellt wird.
Die Größe einer leeren Zuordnungsdatei ist direkt proportional zur zugeordneten Datenbankdatei und ungefähr gleich (alle Größen in Bytes, das Ergebnis muss auf das nächste Vielfache von 8.192 aufgerundet werden):
8,192 + ((<database file size> / <database page size>) / 4)
Beispiel: Für eine 1,5-GB-Datenbank mit einer Seitengröße von 32 KB beträgt die ungefähre Größe der Leerenzuordnung 24.576 Byte (oder 24 KB).
Die Entleerungszuordnungsdatei muss aktualisiert werden, wenn Datenbankseiten geleert werden. Wenn die Transaktionsprotokollierung aktiviert ist (z. B. JET_paramRecovery auf "on" (Standardeinstellung) festgelegt ist, wird die Leerungszuordnung aktualisiert, während die Clientanwendung Änderungen an der Datenbank vornimmt. Im Durchschnitt wird die gesamte Leerungszuordnung einmal für alle 20 % JET_paramCheckpointDepthMax Werts (in Bytes) der generierten Transaktionsprotokolle auf die nicht flüchtigen Medien geschrieben. Die Anzahl der Schreibvorgänge hängt davon ab, wie die Änderungen über die Datenbank verteilt sind. Aber es ist höchstens ungefähr (alle Größen in Bytes):
<flush map file size> / JET_paramMaxCoalesceWriteSize
Wenn die Transaktionsprotokollierung deaktiviert ist (z. B. JET_paramRecovery auf "off" festgelegt ist), wird die Leerungszuordnung nur einmal aktualisiert, wenn die Datenbank explizit sauber getrennt wird (über JetDetachDatabase, oder implizit sauber getrennt wird, indem die zugeordnete ESE-instance beendet wird (über eine der JetTerm-Funktionen, sofern JET_bitTermDirty nicht übergeben wird).
1 Ein verloren gegangener Schreibvorgang (oder verlorenes Leeren) wird als Schreibvorgang definiert, der erfolgreich vom Betriebssystem an die ESE-Datenbank-Engine zurückgibt, aber die tatsächlichen Daten werden nie in der Datenbankdatei auf dem nicht flüchtigen Medium beibehalten. Dies wird in der Regel durch einen fehlerhaften oder falsch konfigurierten Speicherstapel (Software oder Hardware) verursacht. Clientanwendungen erhalten möglicherweise einen JET_errReadLostFlushVerifyFailure Fehler von ESE-Funktionen, die das Lesen von Daten aus der Datenbank erfordern, wenn sich die Daten in einer Region befinden, in der ein Schreibfehlerereignis aufgetreten ist.
2 Die Möglichkeit, verlorene Schreibvorgänge innerhalb der Lebensdauer eines Prozesses zu erkennen, ist seit Windows 8 (Client) und Windows Server 2012 (Server) vorhanden.