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.

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.

Beim Anlegen von Datenbankdateien (Daten, Log) werden standardmäßig die zu erstellenden Dateien beim Initialisieren mit 0 aufgefüllt, damit eventuell auf dem Datenträger zurückgebliebene Daten von vorherigen (gelöschten) Dateien überschrieben werden. Dieses Verfahren betrifft nicht nur das Erstellen neuer Datenbanken sondern auch die Wiederherstellung von Datenbanken aus einem Backup oder die stetige Vergrößerung einer Datenbank. Welchen Einfluss diese Vorgänge auf die Leistung von Microsoft SQL Server hat, beschreibt der nachfolgende Artikel.

Während der Vorbereitungen zu meinem Vortrag “DMO für die Analyse von Indexen” für die SQL Server Konferenz 2014 in Darmstadt wollte ich es mir einfach machen und eine Stored Procedure für die Ausgabe der Analyse programmieren, die in jeder Benutzerdatenbank verwendet werden kann. Dieser Prozedur wird nur noch der Name des zu analysierenden Objekts sowie die Index Id für die Ausgabe übergeben. Während der Tests gab es jedoch Schwierigkeiten, weil ein Aufruf in der Demo-Datenbank keine Daten lieferte. Die Ursache war schnell gefunden; einige Objekte in der Prozedur wurden im Kontext der master- Datenbank ausgeführt. Wie man eine Prozedur dazu veranlassen kann, dass sie trotz Speicherung in der master-Datenbank immer im Kontext der aktuellen Datenbank ausgeführt wird, zeigt dieser Artikel.

Das folgende Szenario basiert auf einer Anfrage in den Microsoftforen, in der die Frage in den Raum gestellt wurde, ob die Verwendung von FILLFACTOR für einen non clustered index, der als Optimierung für eine Fremdschlüsselbeziehung erstellt wurde, effektiv ist und Abfragen beschleunigt. Die Standardaussage: “It depends” gilt nicht, wenn der Clustered Key fortlaufend ist. Der nachfolgende Artikel verdeutlicht die Problematik im Detail.