INF: Verstehen von die Transact-SQL Befehl Works KILL

Der Befehl KILL Transact-SQL wird verwendet, um einen SQL Server-Prozess abrupt zu beenden. Jeder Prozess wird häufig eine System-Prozess-ID (Spid) bezeichnet. Die Schaltfläche SQL Enterprise Manager Kill Process unter aktuelle Aktivität sendet einen Transact-SQL KILL-Befehl lediglich an den Server, damit der serverseitigen KILL Mechanismus dem in diesem Fall ist.

Eine Spid kann sofort oder nach einer Verzögerung oder überhaupt nicht auf der KILL-Befehl reagieren. Ein verzögerter oder nicht mehr reagiert KILL-Befehl kann unter bestimmten Bedingungen normal sein. Dieser Artikel beschreibt Funktionsweise der KILL-Befehl, was diese Bedingungen verspätete oder -Antwort sind und zum identifizieren.

Jede Datenbankverbindung bildet eine Zeile in Sysprocesses, bezeichnet eine Spid oder Systemprozess-ID In SQL Server-Terminologie jede Verbindung wird auch als "Prozess" bezeichnet, aber dies impliziert nicht, einen separaten Prozesskontext im üblichen Sinne. Jeder Prozess in SQL Server 6.0 und 6.5 entspricht ungefähr und von einer separaten Betriebssystemthread bedient. Jede Datenbankverbindung besteht auch Server-Datenstrukturen, die nachverfolgen Prozessstatus, Transaktionszustand, Sperren usw. aus. Eine dieser Strukturen wird der Prozess Status Struktur (PSS) aufgerufen, der vorhanden pro Verbindung ist. Der Server überprüft die Liste der PSSs die virtuellen Tabelle Sysprocesses materialisieren. Die CPU- und Physical_io Spalten von Sysprocesses werden die entsprechenden Werte in jeder PSS abgeleitet.

Die Transact-SQL KILL Befehl Beiträge, die ein "kill selbst" an die Spid Prozess Steckplatz Struktur Nachricht. Er erscheint es als ein Bit Status, für das die Spid in regelmäßigen Abständen interrogates. Wenn die Spid einen Codepfad ausgeführt wird, der nicht das Statusfeld PSS abgefragt wird, wird die KILL nicht berücksichtigt. Einige bekannten Bedingungen, in denen diese Situation auftreten kann, werden unten angezeigt. Die meisten diese gelten erwartet und nicht als Fehler betrachtet werden.

SPID ist in einem Netzwerk-e/A warten.

Wenn der Client nicht alle Ergebniszeilen abrufen wird, werden der Server schließlich gezwungen, warten Sie, wenn an den Client schreiben. Dies wird als eine sysprocesses.waittype 0x0800 angezeigt. Beim Warten auf das Netzwerk, können keine SQL Server Code, der ausgeführt wird abgefragt, die PSS und Erkennen der KILL-Befehl. Wenn die Spid Sperren vor dem Warten auf das Netzwerk-e/A enthält, kann andere Prozesse blockiert werden.

Wenn die Netzwerkverbindung Timeout oder manuell abgebrochen wurde, der SQL-Thread wartet auf das Netzwerk, das e/a-Fehler zurückgeben dauert, daher wird freigegeben bis zu seiner PSS scannen und reagieren auf ein KILL. Sie können manuell eine named Pipes-Verbindung mit NET SESSION NET Files oder entsprechende Server-Manager-Befehl Schließen. Andere Sitzungen IPC wie z. B. TCP/IP und SPX/IPX können nicht manuell geschlossen werden, und die Option nur in diesem Fall wird anpassen das Sitzungstimeout für die bestimmten IPC einen kürzeren Wert. Weitere Informationen finden Sie unter den folgenden Artikel der Microsoft Knowledge Base:

Die SPID ist zurück parallelen (da auch "in"Ursprungsstornobetrag aufgerufen)

Wenn die Transaktion aus irgendeinem Grund abgebrochen wird, muss es zurücksetzen. Wenn es eine lange andauernde Transaktion handelt, dauert es so lange, um einen Rollback auf die Transaktion anwenden. Dies umfasst implizite Transaktionen mit langer z. B. einzelne SELECT INTO, DELETE oder UPDATE-Anweisungen. Während Sie einen Rollback ist es kann nicht gelöscht werden; andernfalls die Transaktionsänderungen würde nicht gesichert werden konsistent.

Das unkillable Rollback-Szenario kann häufig beobachten der Ausgabe Sp_who (ROLLBACK-Befehl hindeuten identifiziert werden. Auf SQL Server Version 6.5 Service Pack 2 oder höher, eine ROLLBACK-Status wurde hinzugefügt, sysprocesses.status, die auch im Sp_who Ausgabe oder den SQL Enterprise Manager "aktuelle Aktivität" erscheint Bildschirm. Allerdings ist das zuverlässigste Verfahren zum Abrufen dieser Informationen überprüfen, die DBCC PSS der blockierenden SPID in Frage, und beobachten den Wert Pstat. Beispiel:

Die erste Zeile des zurückgegebenen Informationen werden den Pstat Wert enthalten.

Beispielsweise kann etwa wie folgt sein:

Bedeutung der Bits, die Pstat:

Der Pstat-Wert oben würde eine typische Situation sein, wenn eine lang andauernde Datenänderung abgebrochen (z. B. durch Klicken auf die Abfrage Abbrechen-Schaltfläche auf einer GUI-Anwendung), und dann die SPID wurde (für einen Zeitraum) Benutzer blockieren, noch unkillable gefunden. Dies ist normal; die Transaktion muss zurückgezogen. Es kann durch die Bits identifiziert werden, wie oben erwähnt.

SPID 1 enthält einen Status 0000 (mit Wiederherstellung)

Beim Starten (oder Neustarten) SQL Server jede Datenbank muss abgeschlossen Start Wiederherstellung sein, bevor es verwendet werden kann. Dies wird als erste Spid in müssen einen Status 0000 Sp_who betrachtet. Kann nicht gelöscht werden, und Wiederherstellung sollte bis zum Abschluss ohne Neustart des Servers zugelassen werden. Nur Benutzer Spids abgebrochen werden können, nicht-System-Spids z. B. für verzögertes Schreiben, Prüfpunkt, RAS-Manager und So weiter. Sie können nicht auch eigene Spid beenden. Sie finden die Spid durch Ausführen von SELECT @@ SPID ist.

Server wurde absichtlich verzögert KILL beachtet

In einigen Situationen wird der Server absichtlich fungiert in einem KILL-Befehl oder ATTENTION-Signal (eine Abbruchanforderung Abfrage). Ein Beispiel dafür ist in einen kritischen Abschnitt. Diese Intervalle werden normalerweise kurze. Diese Situation kann als Pstat Wert von 0 x 4000 eingesehen werden.

Code-Pfad ist nicht für KILL überprüfen.

Wenn Sie jedes der oben beschriebenen Szenarios entfernt haben, ist es möglich, dass der aktuelle Codepfad einfach nicht KILL überprüft wird. Beispielsweise vor SQL Server Version 6.5 Servicepack 3, DBCC CHECKDB nicht zuverlässig auf KILL reagiert da bestimmte Pfade code nicht es überprüfen. Wenn alle der oben genannten Situationen ausgeschlossen wurden (, der Benutzerprozess wartet nicht auf e/a- und nicht in Rollback, die Datenbank ist nicht bei der Wiederherstellung und SQL Server ist absichtlich verzögert KILL) noch KILL nicht berücksichtigt wird, ist es möglicherweise den Server zu verbessern, damit die KILL funktioniert. Für diese Ermittlung muss jeweils einzeln von Ihrem Anbieter Hauptanbieter für technischen Support untersucht werden.

Weitere Informationen

Die Tatsache, die die Meldung "Prozess-Id 10 durch Hostnamen JOE abgebrochen" in das Fehlerprotokoll geschrieben wird wird nicht bestätigt die KILL tatsächlich stattgefunden hat. Diese Meldung wird unmittelbar nach die Kill-Anforderung ausführenden geschrieben, aber ist nicht signalisieren, dass die KILL berücksichtigt wurde.