Was sind die möglichen Ursachen dafür, dass die Ausführung von sp_reset_connection lange dauert?

Warum sp_reset_connectiondauert die Ausführung der gespeicherten Systemprozedur aus Sicht von SQL Server Profiler länger als einige Millisekunden?

Ich habe mit SQL Server Profiler einen einfachen Trace von einem Produktionssystem genommen und ihn dann mit SqlNexus analysiert. SqlNexus gibt an, dass sp_reset_connection die höchste kumulative Dauer hat - 33% der gesamten Ablaufverfolgung. Die beobachtete Dauer reicht von 0 bis 7 Sekunden (12 bis 6.833.270 Mikrosekunden), liegt jedoch im Durchschnitt bei 0,956 Sekunden.

Ich verstehe, dass sp_reset_connection aufgerufen wird, wenn eine gepoolte Verbindung wiederverwendet wird. Ich habe einen Vorschlag gesehen, dass dies aufgrund von Fremdspuren geschehen kann , aber das scheint nicht der Fall zu sein.

Ich habe gelesen, was der Server tut, wenn der Sproc aufgerufen wird, aber ich glaube nicht, dass einer von diesen in diesem Fall problematisch wäre - der Code hinterlässt keine offenen Transaktionen oder riesigen temporären Tabellen, die bereinigt werden müssten.

Ich habe mir auch /server/199974/sp-reset-connection-taking-a-long-time-to-run angesehen, aber es war nicht hilfreich.

BEARBEITEN (23.12.2013): In allen Fällen sind Lese- und Schreibvorgänge 0 und die CPU fast immer 0 (nur zwei Instanzen einer CPU ungleich Null, beide bei 16 ms).

sql-server sql-server-2008

— Ganzheitlicher Entwickler
quelle

Welche Werte sehen Sie in diesem Fall für Lese- und Schreibvorgänge?

— Martin Smith

Können Sie weitere Informationen darüber bereitstellen, welche Art von Abfragen Sie ausführen? Speziell interessante Details wie lange oder komplexe Transaktionen, XML-Verarbeitung, temporäre Tabellen?

— Edward Dortland

@ Martin Lese- und Schreibvorgänge sind 0. Die Frage wurde aktualisiert. (Hatte über das Wochenende keinen Zugriff auf die Daten.)

— Holistic Developer

@EdwardDortland Die meisten Abfragen sind relativ einfache Auswahlen und Aktualisierungen ohne explizite Transaktionen oder Verwendung von temporären Tabellen. Tatsächlich sind die tatsächlichen Abfragen, die auf diesen Verbindungen ausgeführt werden, normalerweise ziemlich schnell - nur wenige ms.

— Ganzheitlicher Entwickler

@HolisticDeveloper - Ich habe mit dem Verlassen einer offenen Transaktion experimentiert und konnte dort Lese- und Schreibvorgänge ungleich Null sehen. Stimmen Sie also zu, dass es dann nicht so aussieht. Ist diese Situation mehr oder weniger dauerhaft? wenn ja ich eine erweiterte Ereignisse Spur Capturing laufen würde RPC:Starting, RPC:Completedund Typen warten für eine kurze Zeit dann die Daten durchsehen , um zu sehen , welche Arten warten die spids während dieser Zeit begegnen.

— Martin Smith

Antworten:

Endlich etwas Zeit, um eine detailliertere Antwort zu schreiben.

Es gibt normalerweise drei Hauptgründe, warum die Ausführung eines einfachen Verfahrens sp_reset_connectionlange dauert.

Sie warten auf CPU-Ressourcen
Sie sind irgendwo an einer Sperre blockiert (möglicherweise aufgrund von DML oder einer konkurrierenden Transaktion).
Ihr Netzwerk ist langsam und es dauert lange, bis das Ergebnis an den Client zurückgegeben wird

Anzeige 1) Wenn Sie auf CPU-Ressourcen warten, sollte dies als Signalwartezeit angezeigt werden. Bitte lesen Sie meinen Kommentar zu Ihrer Frage, wie Sie diagnostizieren können, ob dies das Problem ist

Anzeige 2) Wenn Sie auf eine Sperre warten, wird dies am besten durch Vergleichen von zwei Schnappschüssen von diagnostiziert sys.dm_os_wait_stats. In diesem Artikel erfahren Sie, wie das geht:

http://www.sqlsoldier.com/wp/sqlserver/sqludbaweekbeanefficientdba

Wenn Sie lange auf LCK_ [Something] warten, fragen Sie sys.dm_tran_locksab, welche Objekte gesperrt werden. In Ihrem Fall würde ich erwarten, dass irgendeine Form von SCH- [Something]> -Sperren Sie blockiert.

Anzeige 3) Der einfachste Weg, Netzwerkprobleme zu diagnostizieren, um zuerst nach OLEDB und ASYNC_NETWORK_IO zu suchen, wartet in Schritt 2 (wenn Sie lange auf das Netzwerk warten, wird eines davon angezeigt). Wenn diese Wartezeiten hoch sind, verwenden Sie xperf -on latencyein Netzwerküberwachungsprogramm wie Netmon oder Wireshark, um Ihre Latenzen zu überprüfen. Wenn das Netzwerk langsam aussieht, kann dies auch daran liegen, dass der aufrufende Anwendungsserver nicht schnell genug auf die wiederverwertete Verbindung reagiert.

— Thomas Kejser
quelle

Ich habe das Problem noch nicht wiederholt gesehen, daher kann ich die bereitgestellte Antwort an dieser Stelle nicht zur weiteren Diagnose verwenden. Ich akzeptiere die Antwort jedoch aufgrund Ihres Rufs als SQL Server-Leistungsexperte.

— Ganzheitlicher Entwickler

Ich bin gerade auf einen KB-Artikel gestoßen, der einen Fehler enthält, der möglicherweise mit diesem Problem zusammenhängt. In FIX: Leistungsprobleme treten auf, wenn die Aktivität der Datenbanksperre in SQL Server (KB 2926217) zunimmt. Eines der beschriebenen Symptome ist, dass der Abschluss sp_reset_connectionmöglicherweise lange dauert . Der Hotfix ist in den folgenden Updates enthalten:

Kumulatives Update 17 für SQL Server 2008 SP3
Kumulatives Update 13 für SQL Server 2008 R2 SP2
Kumulatives Update 9 für SQL Server 2012 SP1
Kumulatives Update 1 für SQL Server 2014

Auf dem Server, auf dem ich dieses Verhalten beobachtet habe, wurde SQL Server 2008 SP3 mit Cumulative Update 5 ausgeführt. Daher ist dieser Fehler möglicherweise aufgetreten. Ich habe das kumulative Update noch nicht ausprobiert (das Problem tritt nicht immer wieder auf), daher kann ich nicht überprüfen, ob es das Problem beheben würde oder nicht. Ich wollte jedoch die Informationen bereitstellen, falls jemand die gleichen Symptome hatte.

— Ganzheitlicher Entwickler
quelle