Symptômes
Supposez que vous utilisez Microsoft SQL Server 2016 et 2017. Si vous activez l’événement xml_deadlock_report pour collecter des données pour les interblocages, de nombreux événements de xml_deadlock_report sont signalés pour une seule occurrence de blocage intra-requête.
Solution de contournement
Pour contourner ce problème, vous pouvez recueillir les error_reported XEvent en utilisant un filtre ERROR_NUMBER = 1205 au lieu de xml_deadlock_report, comme illustré dans l’exemple suivant :
CRÉER une SESSION d’événements [Deadlock_Collection] sur le serveur
Ajoutez SqlServer.error_reported d’événements (
OÙ ([error_number] = (1205)))
Ajoutez TARGET package0. histogramme (définissez filtering_event_name = N’sqlserver.lock_acquired', source = N’sqlserver.query_hash')
AVEC (MAX_MEMORY = 4096 KO EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS MAX_DISPATCH_LATENCY = 30 SECONDES MAX_EVENT_SIZE = 0 KO MEMORY_PARTITION_MODE = AUCUNE TRACK_CAUSALITY = ACTIVÉ STARTUP_STATE = DÉSACTIVÉ)
NAVIGU
Résolution
Ce problème a été résolu dans les mises à jour cumulatives de SQL Server suivantes :
Mise à jour cumulative 10 pour SQL Server 2017
Mise à jour cumulative 2 pour SQL Server 2016 SP2
Remarque :Dans le cadre de ce correctif, aucun événement xml_deadlock_report n’est signalé pour le blocage intra-requête lorsque le blocage peut être résolu sans tuer un thread.
Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs et les correctifs de sécurité inclus dans la mise à jour cumulative précédente. Consultez les dernières mises à jour cumulatives pour SQL Server :
Statut
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft figurant dans la liste des produits concernés par cet article.
Références
Apprenez-en davantage sur la terminologieutilisée par Microsoft pour décrire les mises à jour logicielles.
