Mit bestimmter Regelmäßigkeit werde ich beauftragt, vorhandene Microsoft SQL Server zu untersuchen, wenn zum Beispiel eine Performance-Analyse gemacht werden soll oder aber der Microsoft SQL Server einer generellen Untersuchung unterzogen werden soll. Das man dabei schon mal recht interessanteste Analysen vorfindet, habe ich bereits im Artikel “Berater / DBA / DEV – Dokumentation ist eine Hauptleistungspflicht!” behandelt. Mit diesem Artikel möchte ich eine Artikelreihe beginnen, in der ich ein paar meiner im Alltag verwendeten Skripte vorstelle und deren Interpretation beschreibe.

Im Gespräch mit einem Kunden haben wir uns über NON SARGable Abfragen unterhalten. Dabei ist unter anderem ausgeführt worden, dass Funktionen grundsätzlich zu Index-Scans führen, da sie immer jede Zeile überprüfen müssen. Dieses Thema habe ich im Artikel “Optimierung von Datenbankmodellen – SARGable Abfragen” bereits ausführlich behandelt. Viele Funktionen arbeiten tatsächlich nach diesem Prinzip; dennoch ist z. B. die Arbeitsweise von ISNULL als Prädikat davon abhängig, wie das Attribut in der Tabelle definiert wird.

Im Forum eines von mir sehr geschätzten MVP-Kollegen wurde eine Frage bezüglich der Verwendung von Variablen anstelle von Literalen gestellt (hier). Das Problem war, dass die Abfrage sich deutlich verlangsamte, wenn Variablen statt Literale verwendet wurden. Warum dieses Verhalten für Microsoft SQL Server jedoch korrekt ist, soll der folgende Artikel zeigen.

Erst im letzten Artikel “Warum korrekte Datentypen für WHERE-Klauseln wichtig sind” habe ich die Auswirkungen von erforderlichen Typenkonvertierungen auf das Ausführungsverhalten beschrieben. Kaum geschrieben kam dann auch ein “echter” Fall diese Woche, der zunächst unerklärlich war; ein Blick auf die Ausführungspläne hat dann aber sehr schnell gezeigt, dass ein falsch gelöster “Sortierungskonflikt” die Ursache für das sehr schlechte Ausführungsverhalten der Abfrage war.

In einer Anfrage in den Microsoft Foren (link) ging es darum, warum Microsoft SQL Server trotz einer SEEK-Operation alle Datenseiten einer Tabelle durchsucht hat. Tatsächlich kann eine SEEK-Operation die vollständige Tabelle betreffen, wenn bestimmte Voraussetzungen nicht erfüllt sind. Wie wichtig zum Beispiel die korrekte Verwendung von Datentypen bei Einschränkungen sind, zeigt der nachfolgende Artikel.