Verbindungspools werden mit Fehler: 18056, Schweregrad: 20, Status: 46 zurückgesetzt. & Perfmon-Leistungsindikatoren werden nicht angezeigt

Wir verwenden die SQL-Authentifizierung (um die Anzahl der Verbindungspools zu verringern) und .NET 4.0-Verbindungszeichenfolgen, um eine Verbindung mit SQL Server Enterprise Edition 2012 SP1 auf einem Windows 2008 R2 Enterprise Server herzustellen:

Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64)
19. Oktober 2012, 13:38:57 Uhr
Copyright (c) Microsoft Corporation
Enterprise Edition (64-Bit) unter Windows NT 6.1 (Build 7601: Service Pack 1)

Wir verwenden ungefähr 50 Server, die in 8 verschiedene Gruppen verschiedener Teile einer Website aufgeteilt sind.

Unsere Website verwendet diesen SQL Server, um Besuchsverfolgungsdaten zu protokollieren. In den letzten Tagen wurden die folgenden Meldungen zum Zurücksetzen von Verbindungspools ausgegeben:

Der Client konnte eine Sitzung mit der SPID 1327 nicht wiederverwenden, die für das Verbindungspooling zurückgesetzt wurde. Die Fehler-ID lautet 46. Dieser Fehler wurde möglicherweise durch einen früheren fehlgeschlagenen Vorgang verursacht. Überprüfen Sie die Fehlerprotokolle auf fehlgeschlagene Vorgänge unmittelbar vor dieser Fehlermeldung.

Fehlerprotokoll lautet:

Fehler: 18056, Schweregrad: 20, Status: 46.
Der Client konnte eine Sitzung mit SPID 959, die für das Verbindungspooling zurückgesetzt wurde, nicht wiederverwenden. Die Fehler-ID lautet 46. Dieser Fehler wurde möglicherweise durch einen früheren fehlgeschlagenen Vorgang verursacht. Überprüfen Sie die Fehlerprotokolle auf fehlgeschlagene Vorgänge unmittelbar vor dieser Fehlermeldung.
Anmeldung für Benutzer 'xxxx' fehlgeschlagen. Grund: Fehler beim Öffnen der im Anmeldeobjekt konfigurierten Datenbank 'xxxxxxxx' beim erneuten Validieren der Anmeldung für die Verbindung. [KUNDE: 10.xx.xx.xxx]

Nach einigem Graben fand ich dieses Dokument im CSS-Blog: Funktionsweise: Fehler 18056 - Der Client konnte eine Sitzung mit SPID ## nicht wiederverwenden, die für das Verbindungspooling zurückgesetzt wurde, und diese von Aaron Bertrand: Fehlerbehebung bei Fehler 18456 . Ich weiß, dass die Fehlernummer unterschiedlich ist, aber die Fehler-ID mit einer identischen Anzahl von Nachrichten identisch ist.

Die Fehler-ID 46 weist darauf hin, dass die Anmeldung keine Berechtigungen hatte. Unsere Anmeldungen erfolgen standardmäßig in der master-Datenbank, und der Datenbankname ist in der Verbindungszeichenfolge angegeben.

Ich wollte die Anzahl der Verbindungszeichenfolgenpools usw. überprüfen und habe alle Leistungsindikatoren in Perfmon auf überprüft .Net Data Provider for SqlServer. Es gab mir nur die Option defaultdomain9675für die Instanz, daher habe ich die Annahme ausgewählt, dass es sich um einen vom System generierten ID-Namen für unser Datacenter-Netzwerk handelt. Leider lesen alle Zähler Null. Auf einem unserer anderen Hauptserver schweben die Verbindungspools um 10, was ich auf einem gesunden Server mit dieser Art von Last erwartet habe.

Meine Frage ist dreifach

1. Kann jemand vorschlagen, warum der Windows 2008 R2 Server nicht angezeigt wird .Net Data Provider for SqlServer?

2. Hat jemand dies erlebt, da ich offensichtlich glaube, dass das Login, das keine Berechtigungen hat, ein roter Hering ist?

3. Wenn verschiedene Gruppen von Webservern dieselbe Verbindungszeichenfolgensyntax, jedoch mit geringfügig unterschiedlichen Leerzeichen aufweisen, würde dies dazu führen, dass der Server einen anderen Verbindungspool verwendet?

Die minimalen und maximalen Speichereinstellungen betragen 20 GB bzw. 58 GB. Der Server ist ein dedizierter Datenbankserver mit 64 GB RAM. Ich glaube nicht, dass Speicher das Problem ist, da die Box eine anständige Lebenserwartung zu haben scheint. Das automatische Schließen ist nicht aktiviert. Der Server ist immer in Betrieb: Dies ist eine 24x7-Website mit hoher Auslastung.

Ich kann nicht sicher sagen, dass ich einen Server suchen muss, um mich selbst zu erkunden.

2 - Ja, ich sehe das regelmäßig in meiner Umgebung, obwohl wir noch nicht auf SQL 2012 sind, auf den Systemen, auf denen wir das sehen. Möglicherweise möchten Sie auch http://blogs.msdn.com/b/psssql/archive/2013/02/13/breaking-down-18065.aspx überprüfen, obwohl Status 46 mit einer bestimmten Datenbank = xxx in Verbindung zu stehen scheint Gibt es die Verbindungszeichenfolge noch?

Die Art und Weise, wie mein Netzwerk eingerichtet ist, ist vermutlich das automatische Schließen von TCP-Sitzungen durch das Netzwerk nach 5 Minuten im Leerlauf das Problem. Weder die Datenbank noch der Client schließen die Sitzung, sodass der Verbindungspool denkt, dass die Verbindung noch offen ist, und versucht, sie zu verwenden es ist nur zu finden, dass es nicht mehr wirklich offen ist. Sie erwähnen nicht, wie das Netzwerk zwischen Ihren Webservern und der Datenbank konfiguriert ist. Möglicherweise ist Ihr Fall ähnlich.

Eine andere Möglichkeit ist möglicherweise das (alte, nicht sicher, ob es jemals wirklich behoben wurde, siehe http://support.microsoft.com/kb/942861 ) Problem mit den Einstellungen für das Abladen des TCP-Chimneys.

3 - Meines Wissens nach erfordert das Poolen exakte Zeichenfolgenübereinstimmungen, sodass Leerzeichen und unterschiedliche Parameterreihenfolgen unterschiedliche Pools verursachen würden. (Wenn ich mich geirrt habe, lass es mich bitte wissen.)

_{Community Wiki Antwort ursprünglich als Kommentar des Frageautors hinterlassen}

In meinem Fall stellte sich heraus, dass es sich um eine außer Kontrolle geratene Protokollierungstabelle handelte, die jemand zur Behebung eines Problems ausführlich beschrieben hatte, aber vergessen hatte, sich auszuschalten. Am Ende wurden bis zu 1000 Datensätze pro Sekunde aufgezeichnet.

Ein anderer Job hat versucht, alte Datensätze aus der Tabelle zu löschen. Es endete damit, dass er sich in einen Knoten versetzte, als er versuchte, zu löschen, und all jene Einfügungen blockierte, denen die Ressourcen des Verbindungspools ausgegangen waren.

Sobald ich den Job gefunden, die Person, die ihre Rechte auf diesem Server missbraucht hat, auf den Kopf geschlagen und den Job abgebrochen hatte, wurden alle Fehlermeldungen für Verbindungspools gestoppt.