dbcc inputbuffer (spid) liefert RPC Event 0 / sp_executesql;1

[Peter Schoch]

Hallo Zusammen,

wir setzen den SQL Server 2000 mit SP4 ein. Unsere Hauptapplikation ist ein C# Programm. Nun haben wir seit einiger Zeit immer wieder Locks auf der Datenbank. Wenn ich nun mit den Befehl dbcc inputbuffer nachschauen will, welches SQL-Statement den Lock verursacht bekomme ich folgedes Ergebnis:

EventType = RPC Event
Parameters = 0
EventInfo = sp_executesql;1

Hätte nun 2 Fragen:

1) Wieso bekomme ich nicht das letzte SQL-Statement zu sehen?
Dies ist mir nicht klar. Wenn jemand per Query Analyser einen Lock verursacht, dann sehe ich das SQL-Statement doch auch.

2) Wie komme ich zu dem SQL-Statement?

[Andreas Kosch]

Hallo,
ein alternativer Weg führt über <i>sysprocesses</i> und das SQL-Handle. Wenn dieses vorliegt, liefert <b>::fn_get_sql</b> die komplette SQL-Anweisung zurück (während der Aufruf von DBCC INPUTBUFFER nur die ersten 255 Zeichen der SQL-Anweisung bekanntgibt).

DECLARE @Handle binary(20)
SELECT @Handle = sql_handle FROM sysprocesses WHERE spid = <spid-Wert>
SELECT * FROM ::fn_get_sql(@Handle)

Ich glaube aber nicht, das dort mehr sichtbar wird. Während der SQL Server 2005 über den Profiler den Deadlock-Zustand visualisieren kann, ist beim SQL Server 2000 noch Handarbeit notwendig. Im Dialog <i>SQL Server Startup Parameter</i> müssen die Werte <i>-T1204</i> und <i>-T3605</i> übergeben werden, damit die Daten gesammelt und im SQL Server-Log eingetragen werden. Nach dem Neustart des SQL Server-Dienstes (erst dann werden die neuen Startup-Parameter wirksam) kann im Deadlock-Fall der <i>KEY:</i>-Wert über die Abfrage <i>select * from sysobjects where id = <KEY:Wert></i> in das vom Deadlock betroffene Datenbankobjekt (Tabelle, Index) eingetauscht werden.

[Peter Schoch]

Hallo Herr Kosch,

ich habe mir die Startup Parameter -T1204 und -T3605 mal genau angeschaut.
So wie ich das verstehe funktionieren die Parameter nur bei Deadlock's.
Wir haben keine Probleme mit Deadlock's. Unser Problem sind ganz "normale" Lock's.
Also sprich Sql-Statements (Langläufer), welche für ein Paar Minuten wichtige Tabellen sperren.

Nun suche ich eine Möglichkeit im Falle eines solchen Locks das verursachende SQL-Statement zu sehen