Donnerstag, 25. April 2013

Flexible Parameterübergabe als Filterkriterien für dynamisches SQL in Stored Procedures

Während der Besprechung zu einer Projekterweiterung wurde unter anderem ein Problem besprochen, dass sehr häufig anzutreffen ist – Konkatenation eines SQL-String “am Client” und Versand und Ausführung am SQL Server, um die Daten zu ermitteln. Ich habe vorgeschlagen, die komplette Suchroutine in eine Stored Procedure auszulagern. Dieser Stored Procedure werden dann nur noch die Parameter übergeben und die Konkatenation findet dann in der Prozedur statt. Das komplette SQL-Statement wird dann innerhalb der Stored Procedure ausgeführt und die Daten an den Client zurück geliefert. Die Bedenken von SQL-Injection habe ich widerlegt, indem ich argumentiert habe, dass trotz Variabilität in der Parameterübergabe ausschließlich mit sp_executeSQL und expliziter Parameterübergabe gearbeitet wird. Die Herausforderung war nicht ganz einfach aber ich habe eine funktionierende Lösung entwickeln können, die mehrere Vorteile besitzt.

Dienstag, 23. April 2013

Verhalten von Non Clustered Indexes bei einem REBUILD eines Clustered Index

Bei der Durchsicht von Datenbank-Wartungsaufträgen in einem SQL Server 2008 R2 ist aufgefallen, dass ein täglich auszuführender Job ausschließlich den REBUILD / REORG von Clustered Indexe vornimmt. Auf die Frage, warum nur die Clustered Indexe neu organisiert / neu aufgebaut werden, wurde erwidert, dass dieser Job von einem Dienstleister mit der folgenden Aussage implementiert wurde: “Es müssen nur die Clustered Indexe überprüft und gewartet werden. Wenn ein Clustered Index neu aufgebaut wird, werden alle anderen Indexe, die von diesem Index abhängig sind (Non Clustered Indexe) ebenfalls neu aufgebaut!”. Der nachfolgende Artikel beschäftigt sich mit dieser Aussage und zeigt die Abhängigkeit von Clustered Index und Non Clustered Index. Der Artikel belegt, warum die getroffene Aussage falsch ist.

Mittwoch, 17. April 2013

Indexoptimierung = Reduktion von I/O

Während ich den vorherigen Artikel “Clustered Index vs. Non Clustered Index” geschrieben habe, habe ich ein paar interessante Beobachtungen gemacht, die es wert sind, etwas genauer unter die Lupe genommen zu werden. Vielmals höre ich aus Bemerkungen in Vorträgen oder Unterhaltungen mit Kollegen, wie wenig Beachtung bei der Indexierung der Vergleich des I/O bei der Umsetzung differenzierter Indexstrategien findet. Wenn ich mit einem Auftrag betraut werde, eine Abfrage zu optimieren, führe ich zunächst die Abfrage im Original aus und lege die daraus resultierenden I/O-Werte und den Ausführungsplan als "Baseline” fest. Anschließend beginne ich mit der Optimierung. Der nachfolgende Artikel soll deutlich machen, dass nicht immer nur der Ausführungsplan im Mittelpunkt stehen sollte sondern – und gerade – das I/O der Gratmesser für eine optimierte Indexstrategie ist.

Sonntag, 14. April 2013

Clustered Index vs. NonClustered Index

Heute habe ich mit einem sehr geschätzten Freund und Kollegen (Bernd Jungbluth) eine interessante Diskussion im Rahmen meines Vortrags zu Indexstrategien auf der SNEK II in Nürnberg geführt. Die Aufgaben-/Fragestellung war recht simpel. Es ging darum, ob ein Clustered Index auf einem Datumsattribut performanter sei als ein Clustered Index auf einem INT-Attribut und einem zusätzlichen Index auf dem besagten Datumsattribut. Allgemeine Nachteile eines Clustered Index auf einem Datumsattribut (Fragmentierung / Größe) sollen als Pro / Contra Argumente hier nicht beleuchtet werden.