Unterschied zwischen Primary Key und Clustered Index

Letzte Woche wurde ich beauftragt, die Ursachen für eine schlechte Performance innerhalb einer Datenbank zu analysieren und gegebenenfalls Hinweise zu geben, wie man die Wartezeiten im Frontend verkürzen kann. Bei der Prüfung der Ausführungspläne und Indexstrukturen ist aufgefallen, dass fast 10% der Relationen HEAPS sind und in vielen Abfragen mit anderen Relationen über JOINS verwendet wurden. Meine erste Empfehlung war demzufolge – basierend auf den Ausführungsplänen – die Implementierung und Verwendung von Clustered Indexes. Da die Anwendung nicht “in House” entwickelt worden ist, wurde sich mit der Bitte um Prüfung und Zusendung von Skripten an den Hersteller gewandt. Das nachfolgende Script soll stellvertretend für den Lösungsansatz des Herstellers dienen. Bei der im Beispiel benannten Relation handelt es sich um eine simple Relation für die Speicherung historischer Daten ohne Fremdschlüssel-Referenzen.

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.

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.

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.

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.

Inside sys.dm_db_index_physical_stats

Ich habe in dieser Woche einen Fall zu untersuchen gehabt, der ein System für mehrere Stunden (teilweise sogar Tage) komplett lahm gelegt hat. Die Analyse hat gezeigt, dass (unter anderem) regelmäßige Index- und Statistikaktualisierungen durchgeführt wurden. Was ich dann herausgefunden habe, mag man kaum glauben. In diesem konkreten Beispiel wurden wirklich ALLE Fehler gemacht, die man in Verbindung mit sys.dm_db_index_physical_stats und dessen Anwendungsspektrum überhaupt machen kann.

Clustered Primary Key – Surrogate Key vs. Natural Key

Auf die nachfolgende Problematik wurde ich auf Grund eines Threads in den Microsoft Foren zu SQL Server aufmerksam. In dem Thread ging es darum, ob es sinnvoller ist, einen Surrogatschlüssel als “clustered primary key” zu verwenden oder besser einen – aus mehreren Attributen bestehenden – Naturalschlüssel. Die Vor- und Nachteile der verschiedenen Ausprägungen sollen im nachfolgenden Artikel etwas genauer betrachtet werden.

2. SNEK in Nürnberg vom 13.04.2013–14.04.2013

Bei der SNEK (SQL Server / .NET) Entwicklerkonferenz werden Themen rund um SQL Server und .NET in in einer Veranstaltung kombiniert. Diese Strategie wird auch in 2013 mit der SNEK 2 fortgesetzt. Da mein ausgewiesenes Lieblingsthema Indexstrategien des SQL Servers sind (wer hätte das gedacht ) halte ich über dieses Thema auf der SNEK einen entsprechenden Fachvortrag.

SELECT [*] – sinnvoll oder sinnlos

Die obige Fragestellung mag provokativ sein, denoch sehe ich immer wieder in Abfragen, Views und Stored Procedures diese Konstruktion. Im deutschsprachigen Raum wurden jedoch die Vor- und/oder Nachteile noch nie wirklich von allen Facetten beleuchtet. Der nachfolgende Artikel beschäftigt sich mit diesem Thema in Bezug auf verschiedene Merkmale.

Konsolidierung von Indexes

Bei den Wartungsarbeiten an Datenbanken, die an den Wochenenden durchgeführt werden, haben wir festgestellt, dass in einer – relativ – kleinen Datenbank verhätnismäßig viel Zeit für die Reorganisation der Indexe in Anspruch genomnen wird. Bei der Analyse haben wir festgestellt, dass viele Indexe trotz unterschiedlicher Definitionen ihrer Attribute redundant angelegt worden sind. In diesem Artikel möchte ich zeigen, wie Sie die Indexverwendung analysieren können und Indexe durch “Zusammenlegung” optimieren können.