Dans mon article précédent sur la rationalisation des opérations du journal des transactions, j'ai abordé deux des causes les plus courantes de génération d'enregistrements de journal supplémentaires :le poids mort des index non clusterisés inutilisés et les opérations de fractionnement de page (qui provoquent la fragmentation de l'index). En supposant que vous ayez lu cet article, j'ai mentionné qu'il existe des problèmes plus subtils qui peuvent nuire aux performances du journal des transactions, et je vais les aborder ici.
Beaucoup, beaucoup de petites transactions
De temps à autre, SQL Server vide une partie du journal des transactions sur le disque. Un vidage du journal se produit lorsque :
- Un enregistrement de journal de validation des transactions est généré.
- Un enregistrement de journal d'abandon de transaction est généré à la fin d'une annulation de transaction.
- 60 Ko d'enregistrements de journal ont été générés depuis le dernier vidage de journal.
Le plus petit vidage de journal possible est un seul bloc de journal de 512 octets. Si toutes les transactions d'une charge de travail sont très petites (par exemple, insertion d'une seule petite ligne de table), de nombreux vidages de journal de taille minimale se produiront. Les vidages de journal sont effectués de manière asynchrone, pour permettre un débit correct du journal des transactions, mais il existe une limite fixe de 32 E/S de vidage de journal simultanées à tout moment (portée à 112 sur SQL Server 2012).
Cela peut avoir deux effets :
- Sur un sous-système d'E/S aux performances lentes, le volume d'écritures minuscules dans le journal des transactions peut submerger le sous-système d'E/S, entraînant des écritures à latence élevée et une dégradation ultérieure du débit du journal des transactions. Cette situation peut être identifiée par des latences d'écriture élevées pour le fichier journal des transactions dans la sortie de sys.dm_io_virtual_file_stats (voir les liens de démonstration en haut de l'article précédent)
- Sur un sous-système d'E/S hautes performances, les écritures peuvent se terminer extrêmement rapidement, mais la limite de 32 E/S de vidage de journal simultanées crée un goulot d'étranglement lors de la tentative de pérennisation des enregistrements de journal sur le disque. Cette situation peut être identifiée par de faibles latences d'écriture et un nombre quasi constant d'écritures de journaux de transactions en attente proches de 32 dans la sortie agrégée de sys.dm_io_pending_io_requests (voir les mêmes liens de démonstration).
Dans les deux cas, allonger les transactions (ce qui est très contre-intuitif !) peut réduire la fréquence des vidages du journal des transactions et augmenter les performances. De plus, dans le cas n°1, le passage à un sous-système d'E/S plus performant peut être utile, mais peut conduire au cas n°2. Dans le cas n° 2, si les transactions ne peuvent pas être effectuées plus longtemps, la seule alternative consiste à répartir la charge de travail sur plusieurs bases de données pour contourner la limite fixe de 32 E/S de vidage de journal simultanées ou à effectuer une mise à niveau vers SQL Server 2012 ou une version supérieure.
Croissance automatique du journal des transactions
Chaque fois qu'un nouvel espace est ajouté au journal des transactions, il doit être initialisé à zéro (écrire des zéros pour écraser l'utilisation précédente de cette partie du disque), que la fonction d'initialisation instantanée du fichier soit activée ou non. Cela s'applique à la création, à la croissance manuelle et à la croissance automatique du journal des transactions. Pendant que l'initialisation zéro a lieu, les enregistrements de journal ne peuvent pas être vidés dans le journal, de sorte que la croissance automatique pendant une charge de travail qui modifie les données peut entraîner une baisse notable du débit, en particulier si la taille de croissance automatique est définie sur grande ( disons gigaoctets, ou laissé à la valeur par défaut de 10 %).
La croissance automatique doit donc être évitée, si possible, en autorisant l'effacement du journal des transactions afin qu'il y ait toujours de l'espace libre pouvant être réutilisé pour de nouveaux enregistrements de journal. L'effacement du journal des transactions (également connu sous le nom de troncature du journal des transactions, à ne pas confondre avec la réduction du journal des transactions) est effectué par des sauvegardes du journal des transactions lors de l'utilisation des modes de récupération complet ou en bloc, et par des points de contrôle lors de l'utilisation du mode de récupération simple.
L'effacement du journal ne peut se produire que si rien ne nécessite l'effacement des enregistrements du journal dans la section du journal des transactions. Un problème courant qui empêche l'effacement des journaux est d'avoir des transactions de longue durée. Jusqu'à ce qu'une transaction soit validée ou annulée, tous les enregistrements de journal depuis le début de la transaction sont requis en cas d'annulation de la transaction, y compris tous les enregistrements de journal d'autres transactions qui sont intercalés avec ceux de la transaction de longue durée. Les transactions de longue durée peuvent être dues à une mauvaise conception, à un code qui attend une intervention humaine ou à une mauvaise utilisation des transactions imbriquées, par exemple. Tous ces éléments peuvent être évités une fois qu'ils sont identifiés comme un problème.
Vous pouvez en savoir plus à ce sujet ici et ici.
Fonctionnalités de haute disponibilité
Certaines fonctionnalités de haute disponibilité peuvent également retarder l'effacement du journal des transactions :
- La mise en miroir de bases de données et les groupes de disponibilité lors d'une exécution asynchrone peuvent créer une file d'attente d'enregistrements de journaux qui n'ont pas encore été envoyés à la copie de base de données redondante. Ces enregistrements de journal doivent être conservés jusqu'à leur envoi, ce qui retarde la suppression du journal des transactions.
- La réplication transactionnelle (ainsi que Change Data Capture) s'appuie sur une tâche d'agent de lecture du journal pour analyser périodiquement le journal des transactions à la recherche de transactions qui modifient une table contenue dans une publication de réplication. Si l'Agent de lecture du journal prend du retard pour une raison quelconque ou s'il est délibérément conçu pour s'exécuter rarement, tous les enregistrements du journal qui n'ont pas été analysés par la tâche doivent être conservés, ce qui retarde l'effacement du journal des transactions.
Lors de l'exécution en mode synchrone, la mise en miroir de bases de données et les groupes de disponibilité peuvent entraîner d'autres problèmes avec le mécanisme de journalisation. En utilisant la mise en miroir de base de données synchrone comme exemple, toute transaction validée sur le principal ne peut pas réellement revenir à l'utilisateur ou à l'application tant que tous les enregistrements de journal qu'elle a générés n'ont pas été envoyés avec succès au serveur miroir, ce qui ajoute un délai de validation sur le principal. Si la taille moyenne des transactions est longue et que le délai est court, cela peut ne pas être perceptible, mais si la transaction moyenne est très courte et que le délai est assez long, cela peut avoir un effet notable sur le débit de la charge de travail. Dans ce cas, soit les objectifs de performances de la charge de travail doivent être modifiés, soit la technologie de haute disponibilité doit passer en mode asynchrone, soit la bande passante et la vitesse du réseau entre les bases de données principales et redondantes doivent être augmentées.
Incidemment, le même type de problème peut se produire si le sous-système d'E/S lui-même est mis en miroir de manière synchrone, avec un retard potentiel pour toutes les écritures effectuées par SQL Server.
Résumé
Comme vous pouvez le constater, les performances du journal des transactions ne se limitent pas à la génération d'enregistrements supplémentaires du journal des transactions. De nombreux facteurs environnementaux peuvent également avoir un effet profond.
L'essentiel est que la santé et les performances du journal des transactions sont d'une importance primordiale pour maintenir les performances globales de la charge de travail. Dans ces deux articles, j'ai détaillé les principales causes des problèmes de performances du journal des transactions. J'espère donc que vous serez en mesure d'identifier et de remédier à tout ce que vous rencontrez.
Si vous souhaitez en savoir plus sur les opérations du journal des transactions et le réglage des performances, je vous recommande de consulter mon cours de formation en ligne de 7,5 heures sur la journalisation, la récupération et le journal des transactions, disponible via Pluralsight.
