Numéros de séquence de journal CLFS
Dans le système CLFS (Common Log File System), chaque enregistrement de journal dans un flux donné est identifié de manière unique par un numéro de séquence de journal (LSN). Lorsque vous écrivez un enregistrement dans un flux, vous obtenez un LSN qui identifie cet enregistrement pour référence ultérieure.
Les LSN créés pour un flux particulier forment une séquence strictement croissante. Autrement dit, le LSN affecté à un enregistrement de journal dans un flux donné est toujours supérieur aux LSN affectés aux enregistrements de journal précédemment écrits dans ce même flux. Les fonctions suivantes sont disponibles pour comparer les LSN des enregistrements de journal dans un flux donné.
Les constantes CLFS_LSN_NULL et CLFS_LSN_INVALID sont les limites inférieure et supérieure pour tous les LSN valides. Tout LSN valide est supérieur ou égal à CLFS_LSN_NULL. En outre, tout LSN valide est strictement inférieur à CLFS_LSN_INVALID. Notez que CLFS_LSN_NULL est un LSN valide, tandis que CLFS_LSN_INVALID n’est pas un LSN valide. Malgré cela, vous pouvez comparer CLFS_LSN_INVALID à d’autres LSN à l’aide des fonctions de la liste précédente.
Pour chaque flux, CLFS effectue le suivi de deux LSN spéciaux : le LSN de base et le dernier LSN. En outre, chaque enregistrement de journal individuel a deux LSN spéciaux (le LSN précédent et le LSN undo-next) que vous pouvez utiliser pour créer des chaînes d’enregistrements de journal associés. Les sections suivantes décrivent en détail ces LSN spéciaux.
Base LSN
Lorsqu’un client écrit le premier enregistrement dans un flux, CLFS définit le LSN de base sur le LSN de ce premier enregistrement. Le LSN de base reste inchangé jusqu’à ce qu’un client le change. Lorsque les clients du flux n’ont plus besoin des enregistrements antérieurs à un certain point du flux, ils peuvent mettre à jour le LSN de base en appelant ClfsAdvanceLogBase ou ClfsWriteRestartArea. Par exemple, si les clients n’ont plus besoin des cinq premiers enregistrements de journal, ils peuvent définir le LSN de base sur le LSN du sixième enregistrement.
Dernier NSE
Lorsque les clients écrivent des enregistrements dans un flux, CLFS ajuste le dernier LSN afin qu’il soit toujours le nom de domaine du dernier enregistrement écrit. Si les clients n’ont plus besoin des enregistrements après un certain point dans le flux, ils peuvent mettre à jour le dernier LSN en appelant ClfsSetEndOfLog. Par exemple, si les clients n’ont plus besoin d’enregistrements écrits après le dixième enregistrement, ils peuvent tronquer le flux en définissant le dernier LSN sur le LSN du dixième enregistrement.
Partie active d’un flux
La partie active d’un flux est la partie d’un flux qui commence par l’enregistrement pointé par le LSN de base et se termine par l’enregistrement pointé vers le dernier LSN. Le diagramme suivant montre comment le LSN de base et le dernier LSN délimitent la partie active d’un flux.
Note Si un flux a une queue d’archive, la partie active du flux commence à l’enregistrement pointé vers le LSN de base ou la queue d’archive, selon la plus petite des deux. Pour plus d’informations sur l’archivage, consultez Prise en charge de CLFS pour l’archivage.
LSN précédent
Supposons que deux transactions de base de données actives (transaction A et transaction B) écrivent des enregistrements dans le même flux en même temps. Chaque fois que la transaction A écrit un enregistrement, elle définit le LSN précédent de l’enregistrement sur le LSN de l’enregistrement de journal précédent écrit par la transaction A. Qui forme une chaîne d’enregistrements de journal, appartenant à la transaction A, qui peut être parcourue dans l’ordre inverse. La chaîne se termine par le premier enregistrement de journal écrit par la transaction A, dont le LSN précédent est défini sur CLFS_LSN_INVALID. De même, la transaction B crée sa propre chaîne d’enregistrements de journal en définissant le LSN précédent de chaque enregistrement de journal qu’elle écrit.
Les flèches du diagramme suivant illustrent comment le LSN précédent d’un enregistrement de journal pointe vers l’enregistrement précédent dans une chaîne qui appartient à une transaction particulière.
Annuler le LSN suivant
Supposons qu’une transaction effectue cinq mises à jour d’un objet de données en mémoire volatile, restaure les quatrième et cinquième mises à jour, puis effectue une sixième mise à jour. À mesure que la transaction effectue les mises à jour, elle écrit les enregistrements de journal 1, 2, 3, 4, 5, 5', 4' et 6. Les enregistrements de journal 1 à 5 décrivent les modifications apportées par les mises à jour 1 à 5. L’enregistrement 5' décrit les modifications apportées lors de la restauration de la mise à jour 5, et l’enregistrement 4' décrit les modifications apportées lors de la restauration de la mise à jour 4. Enfin, l’enregistrement 6 décrit les modifications apportées par la mise à jour 6. Notez que les nombres 1, 2, 3, 4, 5, 5', 4' et 6 ne sont pas les numéros LSN des enregistrements de journal ; il s’agit simplement de nombres utilisés pour nommer les enregistrements de journal aux fins de cette discussion.
Les enregistrements de journal 5' et 4', qui décrivent les restaurations, sont appelés enregistrements de journal de compensation (CLR). La transaction définit le LSN undo-next de chaque CLR sur le prédécesseur (parmi les enregistrements écrits par la transaction) de l’enregistrement de journal dont la mise à jour vient d’être restaurée (annulée). Dans cet exemple, le LSN undo-next de l’enregistrement 5' est le LSN de l’enregistrement 4, et le LSN undo-next de l’enregistrement 4' est le LSN de l’enregistrement 3.
Les enregistrements de journal ordinaires (ceux qui ne sont pas des RCR) ont leur LSN undo-next défini sur l’enregistrement de journal précédent écrit par la transaction. Autrement dit, pour un enregistrement ordinaire, le LSN undo-next et le LSN précédent sont identiques.
Supposons maintenant qu’il y ait une défaillance du système et que, lors de la récupération, l’intégralité de la transaction doit être restaurée. Le code de récupération lit l’enregistrement de journal 6. Les données de l’enregistrement 6 indiquent que l’enregistrement 6 est un enregistrement ordinaire (et non un CLR), de sorte que le code de récupération restaure la mise à jour 6. Ensuite, le code de récupération inspecte le LSN undo-next de l’enregistrement 6 et trouve qu’il pointe vers l’enregistrement 4'. Les données de l’enregistrement 4' indiquent qu’il s’agit d’un CLR, de sorte que le code de récupération ne restaure pas la mise à jour 4'. Au lieu de cela, il inspecte le LSN undo-next de l’enregistrement 4' et trouve qu’il pointe vers l’enregistrement 3. L’enregistrement 3 n’étant pas un CLR, le code de récupération restaure la mise à jour 3. les Mises à jour 5 et 4 ne sont pas restaurées pendant la récupération, car elles l’ont déjà été lors du traitement avant ordinaire. Enfin, le code de récupération restaure les mises à jour 2 et 1.
Les flèches du diagramme suivant illustrent comment le LSN undo-next fournit un mécanisme que code de récupération pouvez utiliser pour ignorer les enregistrements dont les mises à jour ont déjà été restaurées.
