Surveillance du journal des transactions

Au cours de la dernière année, j'ai blogué plusieurs fois sur SQLPerformance.com à propos des problèmes de performances du journal des transactions (voir ici) et j'ai promis de discuter de la surveillance du journal des transactions, ce que je ferai dans cet article. Je vais présenter certaines des mesures que vous pouvez suivre, pourquoi vous devriez vous en soucier et des conseils pour traiter le problème indiqué.

DMV

Le moyen le plus simple de surveiller les latences d'E/S du journal des transactions consiste à utiliser sys.dm_io_virtual_file_stats DMV. Vous devrez effectuer des calculs pour obtenir des résultats utiles et vous pouvez obtenir un exemple de code dans le script VirtualFileStats.sql dans ce fichier zip de démonstration. Vous voulez vraiment voir des latences d'écriture inférieures à 5 ms pour le journal des transactions.

Plus tôt en novembre, j'ai publié sur un blog les résultats d'une enquête montrant les latences des journaux de transactions et des fichiers de données tempdb pour plus de 25 000 bases de données dans le monde (voir ici), avec 80 % des bases de données atteignant la barre des 5 ms ou moins pour la latence d'écriture du journal des transactions.

Si votre latence d'écriture est supérieure à 5 ms, vous pouvez :

• Travaillez pour réduire la quantité de journaux générés et/ou le nombre de vidages de journaux générés par de petites transactions, comme je l'ai décrit dans des articles précédents.
• Suivez certaines des étapes de dépannage que j'ai décrites dans l'article de blog de l'enquête ci-dessus.
• Passez à un sous-système d'E/S plus rapide, en vous rappelant que si vous décidez d'utiliser un SSD, vous devez en utiliser deux dans une configuration RAID-1.

Une autre chose que vous pouvez faire est de vous assurer que vous n'atteignez pas la limite stricte de 32 E/S d'écriture en attente pour le journal des transactions de chaque base de données en 2008 R2 et avant (porté à 2012 à partir de SQL Server 2012). Vous pouvez essayer de le faire en regardant le disque physique/moyenne. Disk Write Queue Length, mais c'est pour un volume entier, pas par fichier, donc s'il y a autre chose sur le volume en dehors du fichier journal qui vous intéresse, cela ne vous donnera pas un numéro valide. Une meilleure façon consiste à agréger les résultats des sys.dm_io_pending_io_requests DMV, qui répertorie toutes les E/S en attente. Voici un code pour le faire :

SELECT
	COUNT (*) AS [PendingIOs],
	DB_NAME ([vfs].[database_id]) AS [DBName],
	[mf].[name] AS [FileName],
	[mf].[type_desc] AS [FileType],
	SUM ([pior].[io_pending_ms_ticks]) AS [TotalStall]
FROM sys.dm_io_pending_io_requests AS [pior]
JOIN sys.dm_io_virtual_file_stats (NULL, NULL) AS [vfs]
	ON [vfs].[file_handle] = [pior].[io_handle]
JOIN sys.master_files AS [mf]
	ON [mf].[database_id] = [vfs].[database_id]
	AND [mf].[file_id] = [vfs].[file_id]
WHERE
   [pior].[io_pending] = 1
GROUP BY [vfs].[database_id], [mf].[name], [mf].[type_desc]
ORDER BY [vfs].[database_id], [mf].[name];

Vous pouvez facilement modifier cela pour n'afficher que les résultats des fichiers journaux (filtrer sur type_desc ='LOG' ) et uniquement pour l'ID de base de données qui vous intéresse.

Si vous constatez que vous atteignez la limite de 32 pour une base de données particulière, vous pouvez :

• Réduisez le nombre de vidages de journaux en réduisant le nombre de petites transactions et en surveillant les éléments tels que les fractionnements de page et les index inutilisés/dupliqués qui sont modifiés lors des opérations de modification des données. Vous pouvez en savoir plus sur l'optimisation des vidages de journaux dans cet article de blog
• Essayez d'utiliser un sous-système d'E/S plus rapide
• Mettre à niveau vers SQL Server 2012 ou version ultérieure, où la limite est de 112
• Essayez la delayed durability feature DMV qui a été ajouté dans SQL Server 2014
• En dernier recours, répartissez la charge de travail sur plusieurs bases de données ou serveurs

Si vous souhaitez voir combien de journaux de transactions sont générés par vos transactions, vous pouvez utiliser le sys.dm_tran_database_transactions DMV, dans un code similaire à celui ci-dessous :

BEGIN TRAN;
GO
 
-- Do something you want to evaluate
GO 
 
SELECT [database_transaction_log_bytes_used]
FROM sys.dm_tran_database_transactions
WHERE [database_id] = DB_ID (N'YourTestDB');
GO

Vous pourriez être très surpris de la quantité de journaux générés, en particulier dans tempdb pour le code qui utilise des objets temporaires. Et bien sûr, le journal des transactions de tempdb peut être un goulot d'étranglement, tout comme pour une base de données utilisateur.

Compteurs du moniteur de performances

Les compteurs de performance liés au journal se trouvent tous dans l'objet de performance Bases de données. Voici quelques-uns des principaux à surveiller (soit avec l'Analyseur de performances lui-même, soit en utilisant les alertes de l'Agent SQL, soit en utilisant le DMV sys.dm_os_performance_counters, ou dans votre outil de surveillance tiers préféré) :

Croissances logarithmiques

Vous ne voulez pas voir ce compteur augmenter car cela indique qu'il se passe quelque chose dans la base de données qui provoque la génération de plus de journaux de transactions qu'il n'y a d'espace actuel. Cela implique que le journal des transactions ne peut pas être effacé, vous devez donc rechercher la cause en interrogeant le champ log_reuse_wait_desc de sys.databases et prendre les mesures nécessaires (voir la rubrique de la documentation en ligne Facteurs pouvant retarder la troncature du journal pour plus de détails). Un exemple de code serait :

SELECT [log_reuse_wait_desc]
	FROM sys.databases
	WHERE [name] = N'YourDB';
GO

Chaque fois qu'une croissance du journal se produit, la partie nouvellement allouée du journal des transactions doit être mise à zéro, et d'autres fichiers journaux virtuels sont ajoutés, ce qui peut causer des problèmes, comme je l'ai mentionné précédemment.

Log Shrinks

À moins que vous ne soyez la personne effectuant l'opération de réduction pour reprendre le contrôle d'un journal de transactions hors de contrôle, vous ne voulez pas voir ce compteur augmenter. Si quelqu'un réduit simplement le journal des transactions sans raison valable, il augmentera probablement à nouveau, causant des problèmes comme j'en ai parlé précédemment sur le blog.

Pourcentage d'utilisation du journal

Vous devez surveiller ce compteur et vous inquiéter si la valeur dépasse 90 %, car cela indique qu'une croissance du journal pourrait être imminente et que le journal des transactions ne peut pas être effacé correctement, comme je l'ai expliqué ci-dessus.

Attentes de vidage du journal/s

Vous voulez que cette valeur reste la même ou diminue. S'il augmente, cela signifie que vous avez un goulot d'étranglement du sous-système d'E / S ou un goulot d'étranglement à l'intérieur du mécanisme de vidage du journal car vous videz de nombreuses petites portions de journal. Une augmentation ici peut également être corrélée avec l'atteinte des 32 E/S en attente pour le journal. Voir la discussion sur sys.dm_io_pending_io_requests ci-dessus pour plus de détails.

Octets de journal vidés/s et vidages de journaux/s

Ces deux compteurs vous permettent de déterminer la taille moyenne de la chasse d'eau en divisant le premier compteur par le second. Le résultat sera une valeur comprise entre 512 et 61440 (les tailles minimale et maximale d'un vidage de journal, respectivement). Une valeur inférieure est plus susceptible d'être corrélée à l'augmentation du nombre d'attentes de vidage de journal/s. Encore une fois, voir la discussion de sys.dm_io_pending_io_requests ci-dessus pour plus de détails.

Événements étendus

Pour les plus avancés d'entre vous, il existe des événements étendus que vous pouvez utiliser pour regarder ce qui se passe avec le journal. Je vous recommande de commencer par utiliser le modèle de suivi des E/S du fichier journal de la base de données dans SQL Server 2012 SSMS. Vous pouvez y accéder en accédant à l'Explorateur d'objets, puis à votre instance -> Gestion -> Événements étendus et en cliquant avec le bouton droit sur Sessions pour sélectionner l'assistant de nouvelle session. Dans la fenêtre qui s'affiche, saisissez un nom de session et sélectionnez le modèle de suivi dans la liste déroulante. Appuyez ensuite sur Ctrl + Maj + N et la session sera scriptée dans une fenêtre de requête. Les détails de tout ce qui s'y trouve dépassent malheureusement le cadre de cet article, mais la description du modèle est assez explicative :

Il existe également un nouvel événement étendu dans SQL Server 2012 appelé transaction_log qui peut être utilisé pour effectuer toutes sortes d'analyses intéressantes sur les enregistrements de journal générés. C'est certainement un sujet que j'aborderai dans un prochain article.

Résumé

Compte tenu de toutes les informations ci-dessus, vous devriez être en mesure de proposer un assez bon système de surveillance du journal des transactions. La santé du journal des transactions est d'une importance primordiale pour garantir que votre charge de travail fonctionne comme il se doit et j'espère que les quatre articles de cette série (ainsi que tous les autres liens) vous ont aidé à améliorer les performances globales de votre environnement SQL Server.