Par défaut, Service Pack 1 pour SQL Server 2014 et Service Pack 3 pour SQL Server 2012 incluent ce correctif et vous n’avez pas besoin d’ajouter d’indicateurs de trace pour l’activer. Pour activer le correctif après avoir installé l’une des mises à jour cumulatives de la section Résolution, vous devez démarrer Microsoft SQL Server en ajoutant l’indicateur de trace 1236 aux paramètres de démarrage.
Symptômes
Supposons que vous exécutez une instance de Microsoft SQL Server 2014, SQL Server 2012, SQL Server 2008 ou SQL Server 2008 R2 sur un ordinateur qui contient de nombreux processeurs. Quand le nombre de verrous (type de ressource = BASE DE DONNÉES) pour une base de données spécifique dépasse un certain seuil, vous rencontrez les problèmes de performances suivants :
Des valeurs élevées se produisent pour LOCK_HASH nombre de verrouillages tournants.
Remarque : Voir la section « Plus d’informations » pour plus d’informations sur la façon de surveiller ce verrouillage tournant.
L’exécution des requêtes ou des opérations qui nécessitent des verrous de base de données est très longue. Par exemple, vous pouvez noter les retards de performances suivants :
- Connexions SQL Server
- Requêtes du serveur lié
- sp_reset_connection
- Transactions
Remarque Pour localiser la liste des verrous (type de ressource = BASE DE DONNÉES) sur une base de données donnée, consultez la section « Plus d’informations ». La valeur de seuil varie selon l’environnement.
Résolution
Informations sur les mises à jour cumulatives
Le problème a été résolu pour la première fois dans la mise à jour cumulative suivante de SQL Server.
Mise à jour cumulative 13 pour SQL Server 2008 R2 SP2 /en-us/help/2967540
Mise à jour cumulative 17 pour SQL Server 2008 SP3 /en-us/help/2958696
Mise à jour cumulative 1 pour SQL Server 2014 /en-us/help/2931693
Mise à jour cumulative 9 pour SQL Server 2012 SP1 /en-us/help/2931078
À propos des mises à jour cumulatives pour SQL Server
Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs logiciels et tous les correctifs de sécurité inclus dans la mise à jour cumulative précédente. Consultez les dernières mises à jour cumulatives pour SQL Server :
- Dernière mise à jour cumulative pour SQL Server 2008 R2 SP2
- Dernière mise à jour cumulative pour SQL Server 2008 SP3
- Dernière mise à jour cumulative pour SQL Server 2014
- Dernière mise à jour cumulative pour SQL Server 2012 SP1
Informations sur le correctif logiciel
Un correctif logiciel pris en charge est disponible auprès de Microsoft. Toutefois, il est conçu uniquement pour corriger le problème décrit dans cet article. N’appliquez ce correctif qu’aux systèmes sur lesquels vous rencontrez ce problème.
Si le correctif logiciel est disponible en téléchargement, une section « Téléchargement de correctif logiciel disponible » figure en haut du présent article de la Base de connaissances. Si cette section est absente, demandez le correctif logiciel auprès du Support technique et Service clientèle Microsoft.
Remarque Si des problèmes supplémentaires surviennent ou si des procédures de dépannage sont nécessaires, vous devrez peut-être créer une demande de service distincte. Les coûts habituels du support s’appliqueront aux autres questions et problèmes du support non directement liés au correctif logiciel en question. Pour obtenir la liste complète des numéros de téléphone des services d’assistance technique Microsoft ou pour créer une demande de service distincte, reportez-vous au site web de Microsoft à l’adresse suivante :
/contactus/ ?ws=support Remarque Le formulaire « Téléchargement de correctif logiciel disponible » affiche les langues pour lesquelles le correctif logiciel est disponible. Si votre langue n'est pas répertoriée, cela signifie qu'aucun correctif logiciel n'est disponible pour cette langue.
État
Microsoft a confirmé qu’il s’agissait d’un problème dans les produits Microsoft répertoriés dans la section « S’applique à ».
Informations supplémentaires
Lorsqu’une application établit une connexion à SQL Server, elle établit d’abord un contexte de base de données. Par défaut, la connexion tente d’obtenir un verrou DATABASE en mode SH. Le verrou SH-DATABASE est libéré lorsque la connexion est arrêtée ou que le contexte de la base de données est modifié pendant la durée de vie de la connexion. Si vous avez de nombreuses connexions actives qui utilisent le même contexte de base de données, vous pouvez avoir plusieurs verrous du type de ressource DATABASE pour cette base de données spécifique.
Sur l’ordinateur équipé de 16 processeurs ou plus, seuls les objets de la table utilisent un schéma de verrouillage partitionné. Toutefois, les verrous de base de données ne sont pas partitionnés. Par conséquent, plus le nombre de verrous de base de données est élevé, plus il faut de temps à SQL Server pour obtenir un verrou sur la base de données. La plupart des applications ne rencontrent aucun problème causé par cette conception. Mais dès que le nombre dépasse un certain seuil, un travail et un temps supplémentaires sont nécessaires pour obtenir le verrou. Bien que le coût ne soit que de quelques microsecondes pour chaque verrou supplémentaire, le temps total peut rapidement augmenter car les compartiments de hachage de verrou sont protégés par l’utilisation d’un verrou tournant. Cela entraîne des cycles processeur supplémentaires et attend que d’autres travailleurs obtiennent le verrou.
Ce correctif logiciel introduit le partitionnement de verrouillage de base de données lorsque l’indicateur de trace T1236 est activé au démarrage. Le partitionnement du verrou BASE DE DONNÉES permet de gérer la profondeur de la liste des verrous dans chaque partition locale. Ceci optimise considérablement le chemin d’accès utilisé pour obtenir un verrou DATABASE.
Pour surveiller le verrouillage tournant LOCK_HASH, vous pouvez utiliser la requête suivante. SET NOCOUNT ON
CREATE TABLE #spinlock_stats([CaptureTime] datetime,[name] nvarchar(512),[collisions] bigint,
[spins] bigint,[spins_per_collision] real,[sleep_time] bigint,[backoffs] int)
DECLARE @counter int = 1
WHILE @counter< 100
BEGIN
INSERT INTO #spinlock_stats SELECT GETDATE() as « CaptureTime » , * FROM sys.dm_os_spinlock_stats WHERE [name] = 'LOCK_HASH'
WAITFOR DELAY '00:00:05'
DÉFINIR @counter +=1
Fin
SELECT * FROM #spinlock_stats ORDER BY [CaptureTime]
DROP TABLE #spinlock_stats Pour plus d’informations sur le diagnostic et la résolution de la contention de verrouillage tournant sur SQL Server, consultez le document suivant :
Diagnostic et résolution de la contention de verrouillage tournant sur SQL Server Remarque Bien que ce document soit écrit pour SQL Server 2008 R2, les informations sont toujours applicables à SQL Server 2012.
Références
Pour plus d’informations sur les indicateurs de trace dans SQL Server 2012, reportez-vous au site web TechNet à l’adresse suivante :
Informations sur les indicateurs de trace dans SQL Server 2012
Pour plus d’informations sur la façon de trouver le nombre de verrous de base de données utilisateur par base de données, utilisez la requête suivante pour calculer cette valeur :select Resource_database_id, resource_type, request_mode, request_status,
count (*) 'LockCount' dans sys.dm_tran_locks
Regrouper par Resource_database_id, resource_type, request_mode request_status