Was läuft auf dem Server?

Bestimmt hast du dich schon öfters gefragt, warum dein SQL Server wieder einmal so schlecht performt. In solch einem Fall wäre es doch wünschenswert zu wissen, welche SQL Kommandos so eben ausgeführt wurden; und das natürlich ad hoc ohne erst gross den Profiler oder andere Monitoring Tools starten zu müssen. Hierfür hat uns Microsoft mit dem SP3 für den SQL Server 2000 die Funktion fn_get_sql geliefert. Diese Funktion liefert unter anderem das letzte T-SQL Kommando für einen spezifischen Server Prozess (SPID). Im Gegensatz zu DBCC INPUTBUFFER kriegen wir damit aber nicht nur die ersten 255 Zeichen des Kommandos, sondern gleich das vollständige.

Mit folgendem T-SQL Script erfährst du im nu, was so auf deinem Server läuft:

SELECT sp.spid [SPID], sp.last_batch [Executed at], st.text [SQL]
FROM sys.sysprocesses sp
  OUTER APPLY fn_get_sql(sp.sql_handle) st
WHERE st.text IS NOT NULL

Meine Lösung  basiert auf einer Idee von Eli Leiba, welche in der April 2007 Ausgabe von SQL Server Magazine erschienen ist. Die dort vorgestellte Lösung basiert auf einer temporären Tabelle und einem Cursor. Weil mir Cursor aber ein greuel sind – Cursor sind Performance Killer sonder gleichen – habe ich mir die hier vorgestellte Lösung ausgedacht. Diese Kompakte Lösung (4 Zeilen anstelle von 26) ist nur dank dem OUTER APPLY Operator möglich; dieser steht erstmals mit dem SQL Server 2005 zur Verfügung. OK, wenn mein T-SQL Script so oder so nur auf dem SQL Server 2005 läuft, dann können wir die abgekündigte Funktion fn_get_sql (Upps, erst eingeführt und schon wieder veraltet!) auch gleich durch deren Ersatzfunktion sys.dm_exec_sql_text ersetzen:

SELECT sp.spid [SPID], sp.last_batch [Executed at], st.text [SQL]
FROM sys.sysprocesses sp
  OUTER APPLY sys.dm_exec_sql_text(sp.sql_handle) st
WHERE st.text IS NOT NULL

Das Ergebniss bleibt dasselbe wie mit der ersten Version. Viel Erfolg beim suchen deiner „Problemkinder“ – Big Brother is watching you!