The client was unable to reuse a session with SPID xx

[dily0403]

Bonjour à tous,

Sur une instance SQL Server 2008 (build 10.0.2790) sur Windows Server 2008, j'ai régulièrement un message d'erreur qui remonte. -> Voir encadré ci-dessous.
Ce type d'erreurs étaient connues sous SQL Server 2005 et avait été corrigé via dans un SP. -> http://support.microsoft.com/kb/937745/en-us
A noter que le "failure ID" ne change pas d'une remontée à l'autres...

Avez-vous une idée de la raison de ces remontées sous 2008 ?

Merci d'avance pour votre aide...
David

Log Name: Application
Source: MSSQLSERVER
Event ID: 18056
Task Category: Server
Level: Error
Description:
The client was unable to reuse a session with SPID 53, which had been reset for connection pooling. The failure ID is 29. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message.

[SQLpro]

Il semble que ce soit en cours de corrections. Problème, le bug n'est pas reproductible chez MS (peut être un problème lié au hard !). A lire :
http://connect.microsoft.com/SQLServ...pt-connections

A +

[dily0403]

Merci Frédéric pour ta réactivité.
Attendons le passage du SP2 alors...

David

[annedeblois]

Désolée pour le UP... mais j'ai installé le SP 2 de Microsoft SQL Server 2008 et depuis une mise à jour de BizTalk (dont je suis en attente des informations exactes de la part des développeurs) faite il y a 15 jours ces erreurs spamment les journaux de Windows 2003 Server sur 4 serveurs SQL 2k8 virtuels.

EDIT - finalement il n'y a eu aucune mise à jour de BizTalk, mais puisque le problème se pose depuis 15 jours, il s'est probablement passé quelque chose.

Dans le cas de mes serveurs, l'environnement est VMWare 4.1, les serveurs virtuels ont 2 CPU virtuels et 7 Go de RAM (dont 1 Go réservé à l'instance SQL Server fautive).

Comme première piste, la version des VMWare Tools qui n'est pas à jour (version 3.5 présentement). Le responsable de la virtualisation me confirme qu'il faut mettre ces outils à jour pour avoir accès à des pilotes réseau virtuels plus récents. À part ce détail, je suis dans le brouillard total.

[SQLpro]

A lire sur la virtualisation : http://blog.developpez.com/sqlpro/p8...irtualisation/
Bref, c'est pas gagné car en cas de problème la hot line MS te demandera de reproduire le bug dans un environnement non virtualisé !

A +

[annedeblois]

Peut-être une piste:

http://msdn.microsoft.com/en-us/libr...=SQL.100).aspx

J'ai augmenté l'option avancée 'max worker threads' de 0 (valeur par défaut, qui calcule les threads selon l'architecture et le nombre de CPU) à une valeur plus élevée. Dans mon cas, la valeur calculée pour un Windows 2003 Server 64 bits à 2 processeurs est 512, mais en raison du trafic de BizTalk Server j'ai augmenté la valeur à 1024 et apparemment il n'y a pas eu de pépins depuis.

Code :

1
2
3
4
5
6
7
8
USE master;
GO
EXEC sp_configure 'show advanced option', '1';
RECONFIGURE
EXEC sp_configure 'max worker threads', 1024
RECONFIGURE WITH OVERRIDE
 
Redémarrer l'instance.

Je ne puis dire encore officiellement si ma problématique est réglée, mais au cas où ça pourrait en aider...

[SQLpro]

C'est bizarre parce que SQL Server fait du pooling de connexion. Je pense que la couche virtuelle s'emmele les pinceaux. Es tu en lightweight pooling ? (utilisation des fibres ) ???

A +

[dbaffaleuf]

Envoyé par annedeblois

Peut-être une piste:

http://msdn.microsoft.com/en-us/libr...=SQL.100).aspx

J'ai augmenté l'option avancée 'max worker threads' de 0 (valeur par défaut, qui calcule les threads selon l'architecture et le nombre de CPU) à une valeur plus élevée. Dans mon cas, la valeur calculée pour un Windows 2003 Server 64 bits à 2 processeurs est 512, mais en raison du trafic de BizTalk Server j'ai augmenté la valeur à 1024 et apparemment il n'y a pas eu de pépins depuis.

Code :

Je ne puis dire encore officiellement si ma problématique est réglée, mais au cas où ça pourrait en aider...

Il faut regarder le statut de l'erreur 18056. C'est ce qui permet de savoir d'où vient le pb. Si le statut est à 29, c'est une erreur générique qui est produite lorsqu'une requête ayant réutilisée une connexion poolée est annulée après le sp_reset_connection. (Soit annulée volontairement, soit suite à un timeout.) max worker threads n'a rien à voir avec ça.

[annedeblois]

Le statut était bien à 29, d'où ma modification. Aussi, le serveur était très fragmenté. Ce code SQL ainsi que la défragmentation ont réglé le problème, enfin presque... côté serveur seulement, il reste encore des bugs côté client, mais c'est pas mon département.