Partage via

MSSQLSERVER_1204

  • Article

S’applique à : SQL ServerAzure SQL Database Azure SQL Managed Instance

Détails

Attribut Valeur
Nom du produit SQL Server
ID de l’événement 1204
Source de l’événement MSSQLSERVER
Composant SQLEngine
Nom symbolique LK_OUTOF
Texte du message L'instance du moteur de base de données SQL Server ne peut pas obtenir une ressource LOCK en ce moment. Réexécutez votre instruction lorsque le nombre d'utilisateurs actifs est moindre. Demandez à l'administrateur de base de données de vérifier la configuration du verrou et de la mémoire pour cette instance, ou de vérifier les longues transactions.

Explication

Pendant l’exécution, les requêtes acquièrent et libèrent fréquemment des verrous sur les ressources auxquelles elles accèdent. L’acquisition d’un verrou consomme les structures de verrou à partir d’un pool de structures de verrou disponibles. Lorsque de nouveaux verrous ne peuvent pas être acquis parce qu’il n’y a plus de structures de verrou disponibles dans le pool, le message d’erreur 1204 est renvoyé. Ce problème peut être dû à l’une des raisons suivantes :

  • SQL Server ne peut pas allouer plus de mémoire, soit parce que d’autres processus l’utilisent, soit parce que SQL Server a utilisé toute sa mémoire et atteint la valeur configurée à l’aide de la mémoire max du serveur de l’option de configuration.

  • Le gestionnaire de verrous ne peut pas utiliser plus de 60 % de la mémoire disponible pour SQL Server, et le seuil a déjà été atteint.

  • Vous configurez les verrous d’option de configuration de la procédure stockée système sp_configure (Transact-SQL) sur une valeur non dynamique non dynamique par défaut.

  • Vous avez activé les indicateurs de trace 1211, 1224 ou les deux sur votre serveur SQL Server pour contrôler le comportement d’escalade des verrous et vous exécutez des requêtes qui nécessitent de nombreux verrous.

Action utilisateur

  • Si vous pensez que SQL Server ne peut pas allouer suffisamment de mémoire, essayez les options suivantes :

    • Identifiez si un autre commis de mémoire à l’intérieur de SQL Server a utilisé une grande partie de la mémoire configurée par SQL Server, à l’aide d’une requête comme celle-ci :

      SELECT pages_kb, type, name, virtual_memory_committed_kb, awe_allocated_kb
FROM sys.dm_os_memory_clerks
ORDER BY pages_kb DESC;

      Ensuite, réduisez la consommation de mémoire de ce commis de mémoire pour permettre à la mémoire de verrou d’utiliser davantage de ressources. Pour plus d’informations, consultez Résoudre les problèmes de mémoire insuffisante ou de mémoire insuffisante dans SQL Server.

    • Si des applications autres que SQL Server consomment des ressources, essayez d'arrêter ces applications ou envisagez de les exécuter sur un serveur distinct. Cela libère de la mémoire à partir d’autres processus pour SQL Server.

    • Si vous avez configuré la mémoire maximale du serveur, augmentez le paramètre max server memory .

  • Si vous pensez que le gestionnaire de verrous a utilisé la quantité maximale de mémoire disponible, identifiez la transaction qui contient le plus de verrous et la terminez. Le script suivant identifie la transaction qui a le plus de verrous :

    SELECT request_session_id, COUNT (*) num_locks
FROM sys.dm_tran_locks
GROUP BY request_session_id
ORDER BY count (*) DESC;

    Prenez l’ID de session le plus élevé et terminez-le à l’aide de la commande KILL .

  • Si vous utilisez une valeur non par défaut pour locks, utilisez sp_configure cette option pour modifier la valeur de son paramètre par défaut à l’aide de locks l’instruction suivante :

    EXEC sp_configure 'locks', 0;

  • Si vous avez rencontré le message d’erreur ci-dessus lors de l’utilisation des indicateurs de trace SQL Server 1211, 1224 ou les deux, examinez leur utilisation et désactivez-les lors de l’exécution de requêtes nécessitant un grand nombre de verrous. Pour plus d’informations, consultez DBCC TRACEON - Indicateurs de trace (Transact-SQL) et résolvez les problèmes de blocage causés par l’escalade de verrous dans SQL Server.