wake-up-neo.net

Was bedeutet "exec sp_reset_connection" in SQL Server Profiler?

Ich versuche zu verstehen, was SQL Profiler bedeutet, indem ich "sp_reset_connection" sende.

Ich habe die folgende Zeile "exec sp_reset_connection" gefolgt von BatchStarting und Completed,

RPC:Completed       exec sp_reset_connection
SQL:BatchStarting   SELECT [c].[TestID] AS [TestID], [c].[Description] AS [Description] FROM [dbo].[Test] AS [c]
SQL:BatchCompleted  SELECT [c].[TestID] AS [TestID], [c].[Description] AS [Description] FROM [dbo].[Test] AS [c]    

Bedeutet die erste Zeile "exec sp_reset_connection", dass der gesamte Prozess (meine Verbindung wurde geöffnet, der ausgewählte Status wird ausgeführt, dann wird die Verbindung geschlossen und zurück in den Pool freigegeben) gerade stattgefunden hat? Oder meine Verbindung ist noch offen.

Und warum wird die sp_reset_connection vor meiner eigenen select-Anweisung ausgeführt, sollte sie nicht nach dem sql des Benutzers zurückgesetzt werden?

Ich versuche zu wissen, ob es eine Möglichkeit gibt, genauer zu wissen, wann eine Verbindung geöffnet und geschlossen wird.

Bedeutet dies, dass meine Verbindung geschlossen ist, wenn "exec sp_reset_connection" angezeigt wird?

165
Ray

Wie die anderen Antworten sagten, sp_reset_connection gibt an, dass der Verbindungspool wiederverwendet wird. Seien Sie sich einer besonderen Konsequenz bewusst!

Jimmy Mays 'MSDN Blog sagte:

sp_reset_connection setzt die Transaktionsisolationsstufe NICHT auf den Serverstandard der vorherigen Verbindungseinstellung zurück.

[~ # ~] Update [~ # ~] : Ab SQL 2014 gelten für Client-Treiber mit TDS Version 7.3 oder höher die Transaktionsisolationsstufen auf den Standard zurückgesetzt werden.

ref: SQL Server: Isolationslevel tritt bei Poolverbindungen auf

Hier einige zusätzliche Informationen:

Was macht sp_reset_connection?

Datenzugriffs-APIs wie ODBC, OLE-DB und System.Data.SqlClient rufen alle die (interne) gespeicherte Prozedur sp_reset_connection auf, wenn eine Verbindung aus einem Verbindungspool erneut verwendet wird. Auf diese Weise wird der Status der Verbindung zurückgesetzt, bevor sie erneut verwendet wird. Es wird jedoch nirgends dokumentiert, welche Dinge zurückgesetzt werden. Dieser Artikel versucht, die Teile der Verbindung zu dokumentieren, die zurückgesetzt werden.

sp_reset_connection setzt die folgenden Aspekte einer Verbindung zurück:

  • Alle Fehlerzustände und -nummern (wie @@ Fehler)

  • Stoppt alle ECs (Ausführungskontexte), die untergeordnete Threads eines übergeordneten ECs sind und eine parallele Abfrage ausführen

  • Wartet auf ausstehende E/A-Vorgänge

  • Gibt alle gehaltenen Puffer auf dem Server durch die Verbindung frei

  • Entsperrt alle Pufferressourcen, die von der Verbindung verwendet werden

  • Gibt den gesamten zugewiesenen Speicher frei, der der Verbindung gehört

  • Löscht alle von der Verbindung erstellten Arbeits- oder temporären Tabellen

  • Tötet alle globalen Cursor, die der Verbindung gehören

  • Schließt alle offenen SQL-XML-Handles

  • Löscht alle offenen SQL-XML-bezogenen Arbeitstabellen

  • Schließt alle Systemtabellen

  • Schließt alle Benutzertabellen

  • Löscht alle temporären Objekte

  • Bricht offene Transaktionen ab

  • Fehler aus einer verteilten Transaktion, wenn sie eingetragen werden

  • Verringert die Referenzanzahl für Benutzer in der aktuellen Datenbank, wodurch freigegebene Datenbanksperren freigegeben werden

  • Gibt erworbene Sperren frei

  • Gibt alle erworbenen Handles frei

  • Setzt alle SET-Optionen auf die Standardwerte zurück

  • Setzt den Wert von @@ rowcount zurück

  • Setzt den @@ Identitätswert zurück

  • Setzt alle Trace-Optionen auf Sitzungsebene mit dbcc traceon () zurück.

  • Setzt CONTEXT_INFO in SQL Server 2005 und höher auf NULL zurück [nicht Teil des Originalartikels]

sp_reset_connection wird NICHT zurückgesetzt:

  • Sicherheitskontext. Aus diesem Grund werden beim Verbindungspooling Verbindungen basierend auf der genauen Verbindungszeichenfolge abgeglichen

  • Anwendungsrollen, die mit sp_setapprole eingegeben wurden, da Anwendungsrollen nicht zurückgesetzt werden können

Hinweis: Ich füge die Liste hier hinzu, da ich nicht möchte, dass sie im vorübergehenden Web verloren geht.

189
ram

Dies ist ein Hinweis darauf, dass das Verbindungspooling verwendet wird (was eine gute Sache ist).

21
Mitch Wheat

Beachten Sie jedoch:

Wenn Sie SET TRANSACTION ISOLATION LEVEL in einer gespeicherten Prozedur oder einem Trigger ausgeben, wird die Isolationsstufe auf die Ebene zurückgesetzt, die beim Aufrufen des Objekts gültig war, wenn das Objekt die Steuerung zurückgibt. Wenn Sie beispielsweise REPEATABLE READ in einem Stapel festlegen und der Stapel dann eine gespeicherte Prozedur aufruft, mit der die Isolationsstufe auf SERIALIZABLE festgelegt wird, wird die Isolationsstufe auf REPEATABLE READ zurückgesetzt, wenn die gespeicherte Prozedur die Steuerung an den Stapel zurückgibt.

http://msdn.Microsoft.com/en-us/library/ms173763.aspx

9
SAO