CLFS-Protokollsequenznummern
Im Common Log File System (CLFS) wird jeder Protokolldatensatz in einem bestimmten Stream eindeutig durch eine Protokollsequenznummer (Log Sequence Number, LSN) identifiziert. Wenn Sie einen Datensatz in einen Stream schreiben, erhalten Sie einen LSN zurück, der diesen Datensatz als zukünftigen Verweis identifiziert.
Die für einen bestimmten Stream erstellten LSNs bilden eine streng ansteigende Sequenz. Das heißt, der LSN, der einem Protokolldatensatz in einem bestimmten Stream zugewiesen ist, ist immer größer als die LSNs, die Protokolldatensätzen zugewiesen wurden, die zuvor in denselben Stream geschrieben wurden. Die folgenden Funktionen stehen zum Vergleichen der LSNs von Protokolldatensätzen in einem bestimmten Stream zur Verfügung.
Die Konstanten CLFS_LSN_NULL und CLFS_LSN_INVALID sind die unteren und oberen Grenzen für alle gültigen LSNs. Jeder gültige LSN ist größer als oder gleich CLFS_LSN_NULL. Außerdem ist jede gültige LSN streng kleiner als CLFS_LSN_INVALID. Beachten Sie, dass CLFS_LSN_NULL ein gültiger LSN ist, während CLFS_LSN_INVALID kein gültiger LSN ist. Dennoch können Sie CLFS_LSN_INVALID mit anderen LSNs vergleichen, indem Sie die Funktionen in der vorherigen Liste verwenden.
Für jeden Stream verfolgt CLFS zwei spezielle LSNs nach: die Basis-LSN und die letzte LSN. Außerdem verfügt jeder einzelne Protokolldatensatz über zwei spezielle LSNs (die vorherige LSN und die Rückgängig-Nächste-LSN), die Sie zum Erstellen von Ketten verwandter Protokolldatensätze verwenden können. In den folgenden Abschnitten werden diese speziellen LSNs ausführlich beschrieben.
Basis-LSN
Wenn ein Client den ersten Datensatz in einen Stream schreibt, legt CLFS den Basis-LSN auf den LSN des ersten Datensatzes fest. Der Basis-LSN bleibt unverändert, bis ein Client ihn ändert. Wenn die Clients des Streams die Datensätze vor einem bestimmten Punkt im Stream nicht mehr benötigen, können sie den Basis-LSN aktualisieren, indem sie ClfsAdvanceLogBase oder ClfsWriteRestartArea aufrufen. Wenn die Clients beispielsweise die ersten fünf Protokolleinträge nicht mehr benötigen, können sie den Basis-LSN auf den LSN des sechsten Datensatzes festlegen.
Letzte LSN
Wenn Clients Datensätze in einen Stream schreiben, passt CLFS den letzten LSN so an, dass es immer der LSN des zuletzt geschriebenen Datensatzes ist. Wenn die Clients die Datensätze nach einem bestimmten Punkt im Stream nicht mehr benötigen, können sie den letzten LSN aktualisieren, indem sie ClfsSetEndOfLog aufrufen. Wenn die Clients beispielsweise keine Datensätze mehr benötigen, die nach dem zehnten Datensatz geschrieben wurden, können sie den Stream abschneiden, indem sie den letzten LSN auf den LSN des zehnten Datensatzes festlegen.
Aktiver Teil eines Datenstroms
Der aktive Teil eines Datenstroms ist der Teil eines Datenstroms, der mit dem Datensatz beginnt, auf den der Basis-LSN verweist, und mit dem Datensatz endet, auf den der letzte LSN verweist. Das folgende Diagramm veranschaulicht, wie der Basis-LSN und der letzte LSN den aktiven Teil eines Datenstroms abgrenzen.
Hinweis Wenn ein Stream über einen Archivschwund verfügt, beginnt der aktive Teil des Datenstroms mit dem Datensatz, auf den der Basis-LSN oder der Archivschwund verweist, je nachdem, welcher Wert kleiner ist. Weitere Informationen zur Archivierung finden Sie unter CLFS-Unterstützung für die Archivierung.
Vorheriger LSN
Angenommen, zwei aktive Datenbanktransaktionen (Transaktion A und Transaktion B) schreiben Datensätze gleichzeitig in denselben Stream. Jedes Mal, wenn Transaktion A einen Datensatz schreibt, legt sie den vorherigen LSN des Datensatzes auf die LSN des vorherigen Protokolldatensatzes fest, der von Transaktion A geschrieben wurde. Dies bildet eine Kette von Protokolldatensätzen, die zu Transaktion A gehören und in umgekehrter Reihenfolge durchlaufen werden können. Die Kette endet mit dem ersten Protokolldatensatz, der von Transaktion A geschrieben wurde, dessen vorheriger LSN auf CLFS_LSN_INVALID festgelegt ist. Auf ähnliche Weise erstellt Transaktion B eine eigene Kette von Protokolldatensätzen, indem die vorherige LSN jedes protokollgeschriebenen Datensatzes festgelegt wird.
Die Pfeile im folgenden Diagramm veranschaulichen, wie der vorherige LSN eines Protokolldatensatzes auf den vorherigen Datensatz in einer Kette verweist, die zu einer bestimmten Transaktion gehört.
Nächster LSN rückgängig
Angenommen, eine Transaktion führt fünf Updates an einem Datenobjekt im flüchtigen Arbeitsspeicher durch, führt ein Rollback für die vierten und fünften Updates aus und führt dann ein sechstes Update durch. Während die Transaktion die Aktualisierungen vornimmt, werden die Protokolldatensätze 1, 2, 3, 4, 5, 5', 4' und 6 geschrieben. Die Protokolldatensätze 1 bis 5 beschreiben die Änderungen, die durch die Updates 1 bis 5 vorgenommen wurden. Datensatz 5' beschreibt die Änderungen, die während des Rollbacks von Update 5 vorgenommen wurden, und Datensatz 4' beschreibt die Änderungen, die während des Rollbacks von Update 4 vorgenommen wurden. Schließlich beschreibt Datensatz 6 die Änderungen, die mit Update 6 vorgenommen wurden. Beachten Sie, dass die Nummern 1, 2, 3, 4, 5, 5', 4' und 6 nicht die LSNs der Protokolldatensätze sind; es handelt sich nur um Zahlen, die zum Benennen der Protokolldatensätze für diese Diskussion verwendet werden.
Die Protokolldatensätze 5' und 4', die Rollbacks beschreiben, werden als Kompensationsprotokolldatensätze (CLRs) bezeichnet. Die Transaktion legt die nächste Undo-Next-LSN jeder CLR auf den Vorgänger (unter den von der Transaktion geschriebenen Datensätzen) des Protokolldatensatzes fest, dessen Aktualisierung gerade zurückgesetzt (rückgängig gemacht) wurde. In diesem Beispiel ist der undo-next-LSN von Datensatz 5' der LSN von Datensatz 4, und der rückgängig-nächste LSN von Datensatz 4' ist die LSN von Datensatz 3.
Bei den normalen Protokolldatensätzen (bei denen es sich nicht um CLRs handelt) sind die LSNs zum Rückgängigmachen auf den vorherigen Protokolldatensatz festgelegt, der von der Transaktion geschrieben wurde. Das heißt, für einen normalen Datensatz sind der Undo-Next-LSN und der vorherige LSN identisch.
Angenommen, es liegt ein Systemfehler vor, und während der Neustartwiederherstellung muss für die gesamte Transaktion ein Rollback ausgeführt werden. Der Wiederherstellungscode liest Protokolldatensatz 6. Die Daten in Datensatz 6 geben an, dass Datensatz 6 ein normaler Datensatz (nicht ein CLR) ist, sodass der Wiederherstellungscode Update 6 zurückrollt. Anschließend überprüft der Wiederherstellungscode den nächsten LSN des Datensatzes 6 und stellt fest, dass er auf Datensatz 4" verweist. Die Daten im Datensatz 4' geben an, dass es sich um eine CLR handelt, sodass der Wiederherstellungscode update 4' nicht rollbackt. Stattdessen überprüft es den undo-next-LSN von Datensatz 4' und stellt fest, dass er auf Datensatz 3 verweist. Datensatz 3 ist keine CLR, sodass der Wiederherstellungscode Update 3 zurückrollt. Updates 5 und 4 werden während der Wiederherstellung nicht zurückgesetzt, da sie bereits während der normalen Vorwärtsverarbeitung zurückgesetzt wurden. Schließlich führt die Wiederherstellungscode ein Rollback für die Updates 2 und 1 aus.
Die Pfeile im folgenden Diagramm veranschaulichen, wie der LSN zum Rückgängigmachen einen Mechanismus bereitstellt, mit dem Wiederherstellungscode Datensätze überspringen können, deren Updates bereits zurückgesetzt wurden.
