Symptômes
Supposons que vous utilisez une session qui appelle une procédure stockée Common Language Runtime (CLR) (une « session d’appel ») pour accéder aux données dans Microsoft SQL Server, et que cette procédure établit à son tour une connexion distincte (une « deuxième session ») au même serveur au lieu d’une connexion de contexte. Ensuite, si la session d’appel est terminée en raison d’un délai d’attente ou d’une annulation, la deuxième session peut devenir orpheline et existera dans le système jusqu’à ce qu’elle soit terminée manuellement à l’aide de la commande KILL . Si cette session orpheline contient des verrous, les autres sessions peuvent être bloquées en attendant la libération des verrous.
État
Microsoft a confirmé qu’il s’agissait d’un problème dans les produits Microsoft répertoriés dans la section « S’applique à ».
Résolution
Ce problème est résolu dans les mises à jour cumulatives suivantes pour SQL Server :
À 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
Remarque Par défaut, le correctif est désactivé en raison de la nécessité de préserver le comportement hérité du threading CLR dans SQL Server. Vous devez l’activer uniquement si votre système présente les symptômes mentionnés précédemment. Pour activer le correctif, vous devez ajouter l’indicateur de trace 6559 au serveur en utilisant les options de démarrage du service du moteur de base de données. N’oubliez pas que cet indicateur de trace ne peut être utilisé qu’avec 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.