Symptômes
Supposez que vous utilisez une session qui appelle une procédure stockée CLR (Common Language Runtime) pour accéder à des données dans Microsoft SQL Server et que cette procédure à son tour établit une connexion séparée (une « deuxième session ») au même serveur plutôt qu’une connexion de contexte. Par la suite, si la session d’appel est arrêtée en raison d’un délai d’expiration ou d’une annulation, la deuxième session peut devenir orpheline et exister dans le système jusqu’à ce qu’elle soit arrêtée manuellement à l’aide de la commande Kill . Si celle-ci contient des verrous, d’autres sessions peuvent être bloquées en attendant la sortie des verrous.
Statut
Microsoft a confirmé l’existence de ce problème dans les produits Microsoft répertoriés dans la section « S’applique à ».
Résolution
Ce problème a été résolu dans les mises à jour cumulatives de SQL Server suivantes :
À propos des mises à jour cumulatives pour SQL Server :
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. Découvrez les dernières mises à jour cumulatives pour SQL Server
Remarque Par défaut, le correctif est désactivé en raison de la nécessité de préservation du comportement hérité des threads CLR dans SQL Server. Il vous suffit de l’activer si votre système présente les symptômes mentionnés plus haut. Pour activer le correctif, vous devez ajouter l’indicateur de suivi 6559 au serveur à l’aide des options de démarrage du service du moteur de base de données. Gardez à l’esprit que cet indicateur de suivi ne peut être utilisé que dans les options de démarrage de SQL Server. Elle ne peut pas être définie à l’aide de la commande DBCC TRACEON .
Références
En savoir plus à propos de la terminologie utilisée par Microsoft pour décrire les mises à jour logicielles.
