Dans la deuxième partie de cette série, j'ai décrit la hiérarchie structurelle du journal des transactions. Comme cet article concerne principalement les fichiers journaux virtuels (VLF) que j'ai décrits, je vous recommande de lire la deuxième partie avant de continuer.
Lorsque tout va bien, le journal des transactions bouclera sans fin, réutilisant les VLF existants. Ce comportement est ce que j'appelle la nature circulaire du journal . Parfois, cependant, quelque chose se produit pour empêcher cela, et le journal des transactions grandit et grandit, ajoutant de plus en plus de VLF. Dans cet article, je vais vous expliquer comment tout cela fonctionne, ou parfois non.
VLF et troncature des journaux
Tous les VLF ont une structure d'en-tête contenant des métadonnées sur le VLF. L'un des champs les plus importants de la structure est le statut du VLF, et les valeurs qui nous intéressent sont zéro, ce qui signifie que le VLF est inactif , et deux, ce qui signifie que le VLF est actif . C'est important car un VLF inactif peut être réutilisé, mais pas un actif. Notez qu'un VLF est totalement actif ou totalement inactif.
Un VLF restera actif tant que les enregistrements de journal requis s'y trouvent, il ne peut donc pas être réutilisé et écrasé (je couvrirai les enregistrements de journal eux-mêmes la prochaine fois). Voici des exemples de raisons pour lesquelles des enregistrements de journal peuvent être requis :
- Les enregistrements du journal font partie d'une transaction de longue durée, ils ne peuvent donc pas être publiés tant que la transaction n'a pas été validée ou n'a pas fini de revenir en arrière
- Une sauvegarde de journal n'a pas encore sauvegardé ces enregistrements de journal
- Cette partie du journal n'a pas encore été traitée par l'agent de lecture du journal pour la réplication transactionnelle ou la capture de données modifiées
- Cette partie du journal n'a pas encore été envoyée à un miroir de base de données asynchrone ou à un réplica de groupe de disponibilité
Il est important de noter que s'il n'y a aucune raison pour qu'un VLF reste actif, il ne redeviendra pas inactif jusqu'à ce qu'un processus appelé troncature de journal se produit - plus à ce sujet ci-dessous.
En utilisant un journal de transactions hypothétique simple avec seulement cinq VLF et des numéros de séquence VLF commençant à 1 (rappelez-vous de la dernière fois qu'en réalité, ils ne le font jamais), lorsque le journal de transactions est créé, VFL 1 est immédiatement marqué comme actif, car il a toujours être au moins un VLF actif dans le journal des transactions - le VLF dans lequel les blocs de journal sont actuellement écrits. Notre exemple de scénario est illustré à la figure 1 ci-dessous.
Figure 1 :Journal des transactions hypothétique et flambant neuf avec 5 VLF, numéros de séquence 1 à 5.
Au fur et à mesure que davantage d'enregistrements de journal sont créés et que davantage de blocs de journal sont écrits dans le journal des transactions, VLF 1 se remplit, de sorte que VLF 2 doit devenir actif pour que davantage de blocs de journal soient écrits, comme illustré à la figure 2 ci-dessous.
Figure 2 :L'activité se déplace dans le journal des transactions.
SQL Server suit le début de la plus ancienne transaction non validée (active) et ce LSN est conservé sur le disque chaque fois qu'une opération de point de contrôle se produit. Le LSN de l'enregistrement de journal le plus récent écrit dans le journal des transactions est également suivi, mais il n'est suivi que dans la mémoire car il n'y a aucun moyen de le conserver sur le disque sans se heurter à diverses conditions de concurrence. Cela n'a pas d'importance car il n'est utilisé que lors de la récupération sur incident, et SQL Server peut déterminer le LSN de la "fin" du journal des transactions lors de la récupération sur incident. Les points de contrôle et la récupération après un crash sont des sujets pour les prochains articles de la série.
Finalement, VLF 2 se remplira et VLF 3 deviendra actif, et ainsi de suite. Le point crucial de la nature circulaire du journal des transactions est que les VLF antérieurs du journal des transactions deviennent inactifs afin de pouvoir être réutilisés. Ceci est fait par un processus appelé troncature de journal , également communément appelé nettoyage des journaux . Malheureusement, ces deux termes sont de terribles abus de langage, car rien n'est réellement tronqué ou effacé.
La troncation du journal consiste simplement à examiner toutes les VLF du journal des transactions et à déterminer quelles VLF actives peuvent à nouveau être marquées comme inactives, car aucun de leurs contenus n'est encore requis par SQL Server. Lorsque la troncature du journal est effectuée, il n'y a aucune garantie que les VLF actifs puissent être rendus inactifs - cela dépend entièrement de ce qui se passe avec la base de données.
Il existe deux idées fausses courantes concernant la troncation des journaux :
- Le journal des transactions devient plus petit (l'idée fausse de "troncature"). Non, ce n'est pas le cas - il n'y a pas de changement de taille à partir de la troncature du journal. La seule chose capable de réduire la taille du journal des transactions est un DBCC SHRINKFILE explicite.
- Les VLF inactifs sont mis à zéro d'une manière ou d'une autre (l'idée fausse de "nettoyage"). Non - rien n'est écrit dans le VLF lorsqu'il est rendu inactif, à l'exception de quelques champs dans l'en-tête VLF.
La figure 3 ci-dessous montre notre journal des transactions où les VLF 3 et 4 sont actifs, et la troncation du journal a pu marquer les VLF 1 et 2 comme inactifs.
Figure 3 :la troncation du journal marque les VLF antérieures comme inactives.
Le moment où la troncature du journal se produit dépend du modèle de récupération utilisé pour la base de données :
- Modèle simple :la troncature du journal se produit lorsqu'une opération de point de contrôle se termine
- Modèle complet ou modèle avec journalisation en bloc :la troncature du journal se produit lorsqu'une sauvegarde du journal est terminée (tant qu'il n'y a pas de sauvegarde complète ou différentielle simultanée en cours d'exécution, auquel cas la troncation du journal est différée jusqu'à la fin de la sauvegarde des données)
Il n'y a aucune exception à cela.
Nature circulaire du journal
Pour éviter que le journal des transactions ne grossisse, la troncature du journal doit pouvoir marquer les VLF comme inactives. Le premier VLF physique du journal doit être inactif pour que le journal des transactions ait sa nature circulaire.
Considérez la figure 4 ci-dessous, qui montre que les VLF 4 et 5 sont en cours d'utilisation et que la troncation du journal a marqué les VLF 1 à 3 comme inactives. Plus d'enregistrements de journal sont générés, plus de blocs de journal sont écrits dans VLF 5, et finalement, il se remplit.
Figure 4 :L'activité remplit le VLF physique le plus élevé dans le journal des transactions.
À ce stade, le gestionnaire de journaux de la base de données examine l'état du premier VLF physique dans le journal des transactions, qui dans notre exemple est VLF 1, avec le numéro de séquence 1. VLF 1 est inactif, de sorte que le journal des transactions peut boucler et recommencer le remplissage depuis le début. Le gestionnaire de journaux change le premier VLF en actif et augmente son numéro de séquence pour qu'il soit supérieur d'un numéro au numéro de séquence VLF actuel le plus élevé. Il devient donc VLF 6 et la journalisation continue avec l'écriture du bloc de journal dans ce VLF. C'est la nature circulaire du journal, comme illustré ci-dessous dans la figure 5.
Figure 5 :La nature circulaire du journal des transactions et la réutilisation de VLF.
Quand quelque chose tourne mal
Lorsque le premier VLF physique dans le journal des transactions n'est pas inactif, le journal des transactions ne peut pas boucler, donc il grandira (tant qu'il est configuré pour le faire et qu'il y a suffisamment d'espace disque). Cela se produit souvent parce qu'il y a quelque chose qui empêche la troncation du journal de désactiver les VLF. Si vous constatez que le journal des transactions d'une base de données augmente, vous pouvez interroger SQL Server pour savoir s'il existe un problème de troncation du journal à l'aide du code ci-dessous :
SELECT
[log_reuse_wait_desc]
FROM [master].[sys].[databases]
WHERE [name] = N'MyDatabase'; Si la troncation du journal a pu désactiver un ou plusieurs VLF, le résultat sera RIEN. Sinon , vous recevrez une raison pour laquelle la troncation du journal n'a pas pu désactiver les VLF. Il existe une longue liste de raisons possibles décrites ici dans la section Facteurs pouvant retarder la troncature du journal.
Il est important de comprendre la sémantique du résultat :c'est la raison pour laquelle la troncature du journal n'a rien pu faire la dernière fois qu'elle a essayé de s'exécuter . Par exemple, le résultat pourrait être ACTIVE_BACKUP_OR_RESTORE, mais vous savez que cette sauvegarde complète de longue durée est terminée. Cela signifie simplement que la dernière fois que la troncature du journal a été tentée, la sauvegarde était toujours en cours d'exécution.
D'après mon expérience, la raison la plus courante pour laquelle la troncation des journaux est empêchée est LOG_BACKUP; c'est-à-dire, allez effectuer une sauvegarde du journal ! Mais il y a aussi un comportement étrange et intéressant avec LOG_BACKUP . Si vous voyez continuellement le résultat LOG_BACKUP mais vous savez que les sauvegardes de journaux se déroulent avec succès, c'est parce qu'il y a très peu d'activité dans la base de données et que le VLF actuel est le même que la dernière fois qu'une sauvegarde de journal a été effectuée. Donc, LOG_BACKUP signifie "aller effectuer une sauvegarde du journal" ou "tous les enregistrements du journal sauvegardés proviennent du VLF actuel, il n'a donc pas pu être désactivé". Lorsque ce dernier se produit, cela peut prêter à confusion.
Tourner en rond…
Le maintien de la nature circulaire du journal des transactions est très important pour éviter des croissances coûteuses du journal et la nécessité de prendre des mesures correctives. Habituellement, cela signifie s'assurer que les sauvegardes des journaux sont effectuées régulièrement pour faciliter la troncature des journaux et dimensionner le journal des transactions pour pouvoir contenir toutes les opérations longues et volumineuses telles que les reconstructions d'index ou les opérations ETL sans que la croissance des journaux ne se produise.
Dans la prochaine partie de la série, je couvrirai les enregistrements de journaux, leur fonctionnement et quelques exemples intéressants.
