Applies ToSQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Web - duplicate (do not use) SQL Server 2014 Enterprise Core - duplicate (do not use) SQL Server 2014 Express - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use) SQL Server 2012 Service Pack 3 SQL Server 2012 Developer SQL Server 2012 Enterprise SQL Server 2012 Enterprise Core SQL Server 2012 Standard SQL Server 2016 Developer - duplicate (do not use) SQL Server 2016 Enterprise - duplicate (do not use) SQL Server 2016 Enterprise Core - duplicate (do not use) SQL Server 2016 Express - duplicate (do not use) SQL Server 2016 Standard - duplicate (do not use)

Symptômes

Après avoir installé SQL Server 2014 Service Pack 1 (SP1), SQL Server 2012 SP3 ou SQL Server 2016, vous observez des performances de requête lentes et une utilisation de l’UC en mode privilégié (noyau) jusqu’à ce que le serveur redémarre. Vous pouvez également constater un volume élevé de PAGELATCH_ * attend.

Résolution

Ce problème a été résolu dans les mises à jour cumulatives de SQL Server suivantes :

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. Nous vous recommandons de télécharger et d’installer les dernières mises à jour cumulatives pour SQL Server :

Cause

SQL Server utilise la logique de promotion et de rétrogradation du loquet dynamique (Super-loquet). Cela améliore les performances et l’évolutivité de SQL Server en effectuant le suivi du nombre d’acquisitions sur un loquet et de la durée nécessaire à l’acquisition d’un même loquet si aucune contention de loquet n’existait. Les loquets éligibles sont alors promus (Super-loquet) en fonction de ce modèle. Lorsque de nombreuses modifications sont apportées (insertion/mises à jour/suppressions) sur un tas ou BTree (HoBT), les loquets associés à HoBT peuvent être promus à l’État Super Latch. Toutefois, la rétrogradation ne se produit pas automatiquement. Vous pouvez en savoir plus sur le Super ou le sous-verrouillage dans cet article. Si ces HoBTs sont désallouées par la suite, le HoBT disponible repasse dans un cache global en vue d’une réutilisation. Lorsque ce HOBT est réutilisé, il réutilise le loquet précédemment promu, même s’il n’y a aucune contention sur le HoBT. Cela ajoute une surcharge de processeur. Ce comportement augmente l’utilisation de l’UC en mode privilégié (noyau) de SQL Server jusqu’au redémarrage du serveur. En règle générale, cette augmentation n’ajoute pas plus de quelques microsecondes à chaque exécution. Vous pouvez également constater un volume élevé de PAGELATCH_ * attend en raison de ces super-loquets étendus sur HoBTs. 

Statut

Microsoft a confirmé l’existence de ce problème dans les produits Microsoft répertoriés dans la section « S’applique à ».

Besoin d’aide ?

Vous voulez plus d’options ?

Explorez les avantages de l’abonnement, parcourez les cours de formation, découvrez comment sécuriser votre appareil, etc.

Les communautés vous permettent de poser des questions et d'y répondre, de donner vos commentaires et de bénéficier de l'avis d'experts aux connaissances approfondies.