Dans mes deux derniers messages, j'ai discuté des moyens de réduire la quantité de journaux de transactions générés et de garantir que le journal des transactions peut toujours être effacé correctement. Dans cet article, je souhaite continuer avec le thème des performances du journal des transactions et discuter de certains problèmes de configuration du journal des transactions qui peuvent causer des problèmes.
Trop de VLF
Le journal des transactions est divisé en blocs appelés fichiers journaux virtuels (VLF) afin que le système de gestion des journaux puisse facilement suivre les parties du journal des transactions qui sont disponibles pour être réutilisées. Il existe une formule pour déterminer le nombre de VLF que vous obtenez lorsque vous créez votre journal de transactions, que vous le développez manuellement ou qu'il se développe automatiquement :
| Jusqu'à 1 Mo | 2 VLF, chacun environ 1/2 de la taille totale |
|---|---|
| 1 Mo à 64 Mo | 4 VLF, chacun représentant environ 1/4 de la taille totale |
| 64 Mo à 1 Go | 8 VLF, chacun représentant environ 1/8 de la taille totale |
| Plus de 1 Go | 16 VLF, chacun représentant environ 1/16 de la taille totale |
Par exemple, si vous créez un journal des transactions de 8 Go, vous obtiendrez 16 VLF d'environ 512 Mo chacun. Si vous augmentez ensuite le journal de 4 Go supplémentaires, vous obtiendrez 16 VLF supplémentaires, chacune faisant environ 256 Mo, pour un total de 32 VLF.
Remarque :cet algorithme a légèrement changé pour SQL Server 2014 afin d'atténuer les problèmes de fragmentation VLF - voir ce billet de blog pour plus de détails
Une bonne pratique générale consiste à définir la croissance automatique du journal sur autre chose que la valeur par défaut de 10 %, afin que vous puissiez contrôler la pause requise lors de l'initialisation à zéro du nouvel espace du journal des transactions. Supposons que vous créiez un journal des transactions de 256 Mo et que vous définissiez la croissance automatique sur 32 Mo, puis que le journal atteigne une taille stable de 16 Go. Compte tenu de la formule ci-dessus, votre journal des transactions aura plus de 2 000 VLF.
Ces nombreux VLF entraîneront probablement des problèmes de performances pour les opérations qui traitent le journal des transactions (par exemple, la récupération sur incident, l'effacement du journal, les sauvegardes du journal, la réplication transactionnelle, les restaurations de base de données). Cette situation est appelée fragmentation VLF. En règle générale, tout nombre de VLF supérieur à un millier environ va poser problème et doit être résolu (le plus dont j'ai jamais entendu parler est de 1,54 million de VLF dans un journal des transactions d'une taille supérieure à 1 To !).
La façon de savoir combien de VLF vous avez est d'utiliser le DBCC LOGINFO non documenté (et complètement sûr) commande. Le nombre de lignes de sortie correspond au nombre de VLF dans votre journal des transactions. Si vous pensez en avoir trop, voici comment les réduire :
- Autoriser l'effacement du journal
- Réduire manuellement le journal
- Répétez les étapes 1 et 2 jusqu'à ce que le journal atteigne une petite taille (ce qui peut être délicat sur un système de production chargé)
- Développez manuellement le journal jusqu'à la taille qu'il devrait avoir, par étapes allant jusqu'à 8 Go, de sorte que chaque VLF ne dépasse pas 0,5 Go environ
Vous pouvez en savoir plus sur les problèmes de fragmentation VLF et le processus pour les résoudre sur :
- Article Microsoft KB qui conseille de réduire les nombres VLF
- La croissance des fichiers journaux peut-elle affecter DML ?
- 8 étapes pour améliorer le débit du journal des transactions
Tempdb
Tempdb doit avoir son journal des transactions configuré comme n'importe quelle autre base de données, et il peut se développer comme n'importe quelle autre base de données. Mais il a également un comportement insidieux qui peut vous causer des problèmes.
Lorsqu'une instance de SQL Server redémarre pour une raison quelconque, les données et les fichiers journaux de tempdb reviendront à la taille à laquelle ils ont été définis le plus récemment. Ceci est différent de toutes les autres bases de données, qui conservent leur taille actuelle après le redémarrage d'une instance.
Ce comportement signifie que si le journal des transactions tempdb a augmenté pour s'adapter à la charge de travail normale, vous devez effectuer une ALTER DATABASE pour définir la taille du fichier journal, sinon sa taille diminuera après le redémarrage d'une instance et il devra à nouveau augmenter. Chaque fois qu'un fichier journal s'agrandit ou s'agrandit automatiquement, le nouvel espace doit être initialisé à zéro et l'activité de journalisation s'interrompt pendant cette opération. Ainsi, si vous ne gérez pas correctement la taille de votre fichier journal tempdb, vous paierez une pénalité de performance à mesure qu'elle augmente après chaque redémarrage de l'instance.
Réduction régulière du fichier journal
Très souvent, j'entends des gens dire qu'ils réduisent généralement le journal des transactions d'une base de données après qu'il se soit développé à partir d'une opération régulière (par exemple, une importation de données hebdomadaire). Ce n'est pas une bonne chose à faire.
Comme je l'ai expliqué ci-dessus, chaque fois que le journal des transactions augmente ou augmente automatiquement, il y a une pause pendant que la nouvelle partie du fichier journal est initialisée à zéro. Si vous réduisez régulièrement le journal des transactions parce qu'il atteint la taille X, cela signifie que vous rencontrez régulièrement des problèmes de performances car le journal des transactions revient automatiquement à la taille X.
Si votre journal des transactions continue de croître jusqu'à la taille X, laissez-le tranquille ! Réglez-le de manière proactive sur la taille X, en gérant vos VLF comme je l'ai expliqué ci-dessus, et acceptez la taille X comme la taille requise pour votre charge de travail normale. Un journal des transactions plus volumineux n'est pas un problème.
Plusieurs fichiers journaux
Il n'y a aucun gain de performances lié à la création de plusieurs fichiers journaux pour une base de données. Cependant, l'ajout d'un deuxième fichier journal peut être nécessaire si le fichier journal existant manque d'espace et que vous ne souhaitez pas forcer l'effacement du journal des transactions en passant au modèle de récupération simple et en effectuant un point de contrôle (car cela interrompt la sauvegarde du journal chaîne).
On me demande souvent s'il existe une raison pressante de supprimer le deuxième fichier journal ou s'il est acceptable de le laisser en place. La réponse est que vous devez le supprimer dès que possible.
Bien que le deuxième fichier journal ne cause pas de problèmes de performances pour votre charge de travail, il affecte la reprise après sinistre. Si votre base de données est détruite pour une raison quelconque, vous devrez la restaurer à partir de zéro. La première phase de toute séquence de restauration consiste à créer les données et les fichiers journaux s'ils n'existent pas.
Vous pouvez rendre la création du fichier de données presque instantanée en activant l'initialisation instantanée du fichier qui ignore l'initialisation à zéro mais qui ne s'applique pas aux fichiers journaux. Cela signifie que la restauration doit créer tous les fichiers journaux qui existaient au moment de la sauvegarde complète (ou qui sont créés pendant la période couverte par une sauvegarde du journal des transactions) et les initialiser à zéro. Si vous avez créé un deuxième fichier journal et oublié de le supprimer à nouveau, l'initialisation à zéro lors d'une opération de récupération après sinistre va augmenter le temps d'arrêt total. Il ne s'agit pas d'un problème de performances de charge de travail, mais cela affecte la disponibilité du serveur dans son ensemble.
Revenir à partir d'un instantané de base de données
Le dernier problème de ma liste est en fait un bogue dans SQL Server. Si vous utilisez un instantané de base de données comme moyen de récupérer rapidement à un moment connu sans avoir à restaurer les sauvegardes (appelé retour à partir de l'instantané), vous pouvez gagner beaucoup de temps. Cependant, il y a un gros inconvénient.
Lorsque la base de données revient à partir de l'instantané de la base de données, le journal des transactions est recréé avec deux VLF de 0,25 Mo. Cela signifie que vous devrez redonner à votre journal des transactions sa taille et son nombre optimaux de VLF (ou il se développera automatiquement), avec toutes les pauses d'initialisation zéro et de charge de travail dont j'ai parlé précédemment. Clairement pas le comportement souhaité.
Résumé
Comme vous pouvez le voir dans cet article et dans mes deux articles précédents, de nombreux facteurs peuvent entraîner de mauvaises performances du journal des transactions, ce qui a ensuite un effet d'entraînement sur les performances de votre charge de travail globale.
Si vous pouvez vous occuper de toutes ces choses, vous aurez des journaux de transactions sains. Mais cela ne s'arrête pas là, car vous devez vous assurer que vous surveillez vos journaux de transactions afin d'être alerté de choses telles que la croissance automatique et les latences excessives d'E/S en lecture et en écriture. Je vous expliquerai comment procéder dans un prochain article.
