Alexander Förster

„Kannst du mal eben schauen warum das Query so langsam läuft?“ – So lautete die Frage eines Kollegen, der ein Query im Management Studio und über ein SSIS-Paket ausführte. Im Management Studio waren erste Ergebnisse bereits nach Millisekunden verfügbar. Hingegen kam das SSIS-Paket weder direkt auf dem Server, noch im „DebugModus“ zu einem Ergebnis.

Bewährtes Query für erste Analysen

Besagter Kollege schaute sich sowohl den „Estimated-“ wie auch den „Actual-Execution“-Plan an, konnte aber keinerlei „Fehlverhalten“ des SQL-Servers erkennen. Sicherlich ist es schwierig, im SSIS-Paket den aktuellen Execution Plan mit auszugeben. Ich habe in der Vergangenheit des Öfteren schon unterschiedlichste Queries eingesetzt, um mir anzuschauen, was auf dem aktuellen Server gerade läuft und wo hier eventuell Probleme auftreten können. Letztlich hat sich folgendes Query für eine erste Analyse bewährt, um dann tiefer in die genaue Analyse einzusteigen:

SELECT blocking_session_id      AS blocked_by,
t2.text,
Db_name (t1.database_id) AS [database],
t1.wait_time,
t1.wait_time / 1000 / 60 AS Minuten,
t3.login_name,
t1.session_id,
t1.wait_type,
Cast (query_plan AS XML) AS Query_Plan
FROM   sys.dm_exec_requests t1
INNER JOIN sys.dm_exec_sessions t3
ON t1.session_id = t3.session_id
CROSS apply sys.Dm_exec_sql_text (t1.sql_handle) t2
CROSS apply sys.Dm_exec_text_query_plan(t1.plan_handle,
t1.statement_start_offset,
t1.statement_end_offset)
WHERE  t1.session_id <> @@SPID
ORDER  BY t1.wait_time DESC

 

Ein beherzter Klick auf die letzte Spalte („Query Plan“) eröffnet den verwendeten QueryPlan im Management Studio in der bekannten grafischen Darstellung. Aber Vorsicht: Hat man die Option „Neues Fenster im SQLCMD-Modus öffnen“ angehakt, so kann man dies nicht direkt grafisch sehen.

Falscher Query-Plan im SQL-Server

Im beschriebenen Fall war es so, dass für dasselbe Query im SSIS ein anderer Query-Plan als im Management Studio verwendet wurde – konkret: Nested Loops statt eines HashJoins. Dabei wurde ein falscher Query-Plan im SQL-Server abgelegt, der durch Tests oder ungeschickte Quelldaten erstellt und immer wieder Verwendung fand. Dies konnten wir dann anhand der echten Ausführungspläne im Management-Studio erkennen. Über die Funktion DBCC FREEPROCCACHE [planhandle] ließ sich dieser eine „falsche Query-Plan“ schließlich löschen.

Natürlich kann man durch hinzufügen von Spalten (v.a. aus t1) mehr aus dem oberen Query an Information herausholen. Allerdings sind zumindest schon mal die wichtigsten Parameter wie Blocking-Session oder Waittypes mit Query-Plan ausgewiesen.