Les pools de connexions sont réinitialisés avec l'erreur: 18056, gravité: 20, état: 46. & Les compteurs Perfmon ne s'affichent pas

Nous utilisons l'authentification SQL (pour réduire le nombre de pools de connexions) et les chaînes de connexion .NET 4.0 pour se connecter à SQL Server Enterprise Edition 2012 SP1 sur un serveur d'entreprise Windows 2008 R2:

Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64)
19 octobre 2012 13:38:57
Copyright (c) Microsoft Corporation
Enterprise Edition (64 bits) sur Windows NT 6.1 (Build 7601: Service Pack 1)

Nous utilisons environ 50 serveurs répartis en 8 groupes différents, différentes parties d'un site Web.

Notre site Web utilise ce serveur SQL pour enregistrer les données de suivi des visites. Au cours des derniers jours, il a craché les messages suivants concernant la réinitialisation des pools de connexions:

Le client n'a pas pu réutiliser une session avec SPID 1327, qui avait été réinitialisé pour le regroupement de connexions. L'ID d'échec est 46. Cette erreur peut être due à l'échec d'une opération antérieure. Vérifiez les journaux d'erreurs pour les opérations ayant échoué immédiatement avant ce message d'erreur.

Le journal des erreurs indique:

Erreur: 18056, gravité: 20, état: 46.
Le client n'a pas pu réutiliser une session avec SPID 959, qui avait été réinitialisée pour le regroupement de connexions. L'ID d'échec est 46. Cette erreur peut être due à l'échec d'une opération antérieure. Vérifiez les journaux d'erreurs pour les opérations ayant échoué immédiatement avant ce message d'erreur.
La connexion a échoué pour l'utilisateur «xxxx». Motif: Échec de l'ouverture de la base de données 'xxxxxxxx' configurée dans l'objet de connexion lors de la revalidation de la connexion sur la connexion. [CLIENT: 10.xx.xx.xxx]

Après quelques recherches, j'ai trouvé ce document sur le blog CSS: Comment ça marche: Erreur 18056 - Le client n'a pas pu réutiliser une session avec SPID ##, qui avait été réinitialisée pour le regroupement de connexions et celle-ci par Aaron Bertrand: Dépannage de l'erreur 18456 . Je sais que le numéro d'erreur est différent mais l'ID d'échec est le même avec un certain nombre de messages identiques).

L'ID d'échec 46 suggère que la connexion ne disposait pas d'autorisations. Nos connexions par défaut à la base de données master et le nom de la base de données est spécifié dans la chaîne de connexion.

Je voulais vérifier le nombre de pools de chaînes de connexion, etc. et vérifié tous les compteurs de Perfmon .Net Data Provider for SqlServer. Cela ne m'a donné que l'option defaultdomain9675pour l'instance, j'ai donc choisi cela en supposant qu'il s'agit d'un nom d'identification généré par le système pour notre réseau Datacentre. Malheureusement, tous les compteurs lisent zéro. Sur l'un de nos autres serveurs principaux, les pools de connexions tournent autour de 10, ce que je m'attendais à voir sur un serveur sain avec ce type de charge.

Ma question est triple

1. Quelqu'un peut-il suggérer pourquoi le serveur Windows 2008 R2 n'est pas affiché .Net Data Provider for SqlServer?

2. Quelqu'un a-t-il vécu cela, car je pense que la connexion sans autorisations est un hareng rouge?

3. Si différents groupes de serveurs Web ont la même syntaxe de chaîne de connexion mais avec des espaces blancs légèrement différents, cela pourrait-il amener le serveur à utiliser un autre pool de connexions?

Les paramètres de mémoire minimum et maximum sont respectivement de 20 Go et 58 Go. Le serveur est un serveur de base de données dédié avec 64 Go de RAM. Je ne pense pas que la mémoire soit le problème car la boîte semble avoir une espérance décente de page lfe. La fermeture automatique n'est pas activée. Le serveur est toujours opérationnel: il s'agit d'un site Internet 24h / 24, 7j / 7 avec une utilisation intensive.

1 - je ne peux pas dire avec certitude, je devrais aller trouver un serveur pour creuser en moi-même.

2 - oui, je vois cela périodiquement dans mon environnement bien que nous ne soyons pas encore sur sql 2012 sur les systèmes à partir desquels nous voyons cela. Vous pouvez également vérifier http://blogs.msdn.com/b/psssql/archive/2013/02/13/breaking-down-18065.aspx bien que l'état 46 semble lié à la présence d'une base de données spécifique = xxx dans la chaîne de connexion, cette base de données existe-t-elle toujours?

La façon dont mon réseau est configuré, je suppose que c'est la fermeture automatique du réseau des sessions TCP après avoir été inactif pendant 5 minutes, c'est le problème - ni la base de données ni le client ne ferme la session, donc le pool de connexions pense toujours que la connexion est ouverte et essaie d'utiliser il suffit de constater qu'il n'est plus vraiment ouvert. Vous ne mentionnez pas comment le réseau entre vos serveurs Web et db est configuré, votre cas est peut-être similaire.

Une autre possibilité peut être le problème (ancien, pas sûr s'il a vraiment été résolu, voir http://support.microsoft.com/kb/942861 ) concernant les paramètres de déchargement TCP Chimney.

3 - Ma compréhension est que la mise en commun nécessite des correspondances de chaînes exactes, donc les espaces et l'ordre différent des paramètres entraîneraient des mises en commun différentes. (Si je me trompe, faites-le moi savoir.)

_{Réponse au wiki de la communauté initialement laissée comme commentaire par l'auteur de la question}

Dans mon cas, il s'est avéré être une table de journalisation galopante que quelqu'un avait commuté en verbeux pour résoudre un problème, mais avait oublié de l'éteindre. Il a fini par enregistrer jusqu'à 1000 enregistrements par seconde.

Un autre travail tentait de supprimer les anciens enregistrements de la table. a fini par se mettre en nœuds comme le faisait le verrouillage lors de la tentative de suppression, bloquant toutes les insertions qu'il manquait de ressources du pool de connexions.

Dès que j'ai trouvé le travail, j'ai giflé la personne qui a abusé de ses droits sur ce serveur et j'ai arrêté le travail, tous les messages d'erreur pour les pools de connexions se sont arrêtés.