Einleitung

Performance ist eine zentrale Kenngröße für Datenbanken. Es wird erwartet, dass moderne ausgereifte SQL Datenbanksysteme den größten Arbeitslasten standhalten können und trotzdem gute und gleichbleibende Performance abliefern. Der interne Code des Datenbanksystems ist in der Regel hochoptimiert und getuned, doch vielfach ist dies leider nicht der Fall für die Datenbanken, die mit einem solchen System verwaltet werden. Eine schlecht entworfene und/oder entwickelte Datenbank kann problemlos auch das schnellste Datenbankmanagementsystem in die Knie zwingen. Aus diesem Grund ist es äußerst wichtig, dass Datenbanken von Leuten entworfen und implementiert werden, die ihre Sache verstehen. Aber selbst mit solchen Leuten in der Verantwortung besteht fast immer noch ein Spielraum für Optimierungen. Doch leider ist die Optimierung von Abfragen und der allgemeinen Arbeitslast eine langwierige und zeitaufwändige Aufgabe. Dies nun ist der Zeitpunkt, an dem Qure von DBSophic die Bühne betritt.

Qure

Qure ist ein Arbeitslast-Optimierungs Tool das speziell für SQL Server Applikationen entwickelt wurde. Es verwendet eine besondere Methode, um die Arbeitslast einer Datenbank zu analysieren, indem diese Analyse unter Zuhilfenahme einer Kopie der Produktions-Datenbank auf einem Nicht-Produktionsserver durchgeführt wird. Dabei sind die Hautpinformationsquellen für Qure SQL Server Trace Dateien. Im Folgenden werfen wir einen Blick auf die Installation von Qure und nehmen die zentralen Features genauer unter die Lupe.

Arbeitslast

Der Begriff "Arbeitslast" ist mittlerweile des Öfteren gefallen, aber was genau ist damit eigentlich gemeint? Hier ist die Definition aus dem Arbeitslast-Optimierungs Whitepaper auf der DBSophic.com Website:

Workload Tuning introduces a completely new approach to Database Performance Management, complementing Query Tuning as a means of diagnosing and repairing production problems.
The newness is summarized in two adjectives: holistic and large scale. First, “holistic”.
Workload Tuning is to Query Tuning what holistic medicine is to traditional medicine. If a man complains of a back ache, traditional medicine commonly addresses the precise location of the pain by prescribing muscle relaxants and physical therapy to stretch and strengthen the muscles. Relief can be obtained in this way, but the pain may return if the root cause of the back problem has not been addressed. Holistic medicine looks for the root cause. The holistic therapist may notice that the man’s gait is uneven, and determine that there is a problem with the left foot that is transferring to the back. By additionally treating the foot problem, the back problem is cured for the long term.
The second new characteristic is “large scale”.
Workload Tuning is to Query Tuning what production auto manufacturing is to custom car manufacturing. After years of doing all work piecemeal, and through diligent study of the process of manufacture, an automated approach was invented that can achieve a consistently high level of quality in each of thousands of units. A new expertise arose: that of designing and supporting the large-scale operation.

Soweit, so gut, aber was genau bedeutet dies nun mit Hinblick auf Datenbank Performance-Optimierung? Nun, nichts anderes als das Qure als Arbeitstier für den DBA agiert, indem es all diejenigen langwierigen, zeitaufwändigen und, wenn man mal ehrlich ist, teilweise auch weniger interessanten Aufgaben übernimmt, Trace-Dateien und/oder die DMV's zu analysieren, um mehr über die Arbeitslast einer Datenbank in Erfahrung zu bringen. Es erspart damit dem DBA einen Großteil seiner Zeit, die er nun effektiver in Aufgaben investieren kann, die tatsächlich einen Mehrwert für seine Kunden bringt. Er braucht sich nur noch Qure's Empfehlung ansehen und diejenigen heraussuchen, die den größten Vorteil für die Benutzer bringen.

So zumindest die Verheißung. Nun installieren wir Qure und schauen mal, wie sich dieses Versprechen in der Realität bewährt.

Installation, Systemanforderungen und unterstützte SQL Server Versionen

Die nachfolgenden Installationsvoraussetzungen stammen aus der Qure Hilfe-Datei:

• Qure Installation Hardware Anforderungen:

• 50 MB freier Festplattenplatz für Programm- und Logdateien.

• Ca. 2 GB freier Festplattenplatz pro Datenbank Analyse Datei, Maximalgröße ist 4 GB pro Datei.

• 1 GB RAM Minimum, 2 GB RAM empfohlen.

• 2 GHz CPU, Dual core empfohlen.

• Qure Installation Software Anforderungen:

• Windows XP/Vista/Server 2003/Server 2003 R2/Server 2008, 32 oder 64-bit.

• Microsoft .Net Framework 3.5 SP1.

• Microsoft SQL Server 2005/2008 Client Tools, 32 oder 64-bit.

• Windows Installer 3.1 oder höher (Version 4.5 wird empfohlen).

Die Kopie der zu analysierenden Datenbank sollte auf einem Server wiederhergestellt werden, der die folgenden Minimalanforderungen erfüllt:

• Datenbank Server Hardware Anforderungen:

• Freier Festplattenspeicher mindestens 3x die Größe der zu analysierenden Datenbank inklusive Log-Datei(en).

• 1 GB RAM Minimum, 2 GB RAM empfohlen.

• 2 GHz CPU, Dual core empfohlen.

• Um größtmögliche Genauigkeit der Analyseresultate sicherzustellen, sollten sowohl der Client-Computer als auch der Server keinen anderen gleichzeitigen Zugriffen ausgesetzt sein. Ein dedizierter (nicht-virtueller) Server wird empfohlen.

• Datenbank Server Software Anforderungen:

• Windows Server 2003/Server 2003 R2/Server 2008, 32 oder 64-bit.

• Microsoft SQL Server 2005/2008/2008R2, 32 oder 64-bit.

Dem aufmerksamen Leser wird nicht entgangen sein, dass nur SQL Server beginnend mit 2005 und höher unterstützt werden. Qure kann nicht mit SQL Server 2000 betrieben werden.

Eine Trial-Version von Qure kann nach einer kurzen Registrierung kostenlos und der DBSophic Produkt-Homepage unter http://www.dbsophic.com/download heruntergeladen werden. Die aktuelle Version ist die Version 2.0. Der Download ist ca. 17,8 MB groß und kommt in Form einer MSI Datei. Ein Wizard führt den Anwender durch den einfachen Installationsvorgang und bereits ein paar Minuten später ist Qure bereit für den Einsatz.

Qure verwenden

Weiter oben wurde bereits erwähnt, dass SQL Server Trace Dateien die Hauptinformationsquelle für Qure sind. Wahlweise können bereits gespeicherte Traces verwendet werden, oder - und das ist wahrscheinlich gerade am Anfang leichter - man verwendet die mit Qure ausgelieferten Trace Vorlagen. Diese bieten den Vorteil, dass alle wichtigen Ereignisse und Spalten, die ein optimales Analyseergebnis bieten, bereits vorselektiert sind. Weitere Informationen, wie man effiziente Trace Datei für Qure erstellt, kann man aus diesem Dokument erhalten: http://www.dbsophic.com/assets/files/PrepareTrace.pdf

Startet man Qure zum ersten Mal, erscheint der oben abgebildete Wizard und es ist vielleicht eine gute Idee, zumindest einmal durch diesen Wizard durchzuklicken, bis man mit dem Tool und seiner Arbeitsweise vertraut ist. Zu jeder Zeit kann man den Wizard aber unterbrechen, indem man auf den "Start Using Qure" Button klickt. Man kann selbstverständlich auch dauerhaft den Wizard ausschalten. Dazu entfernt man einfach den Haken aus dem "Show this at next startup" Feld in der linken unteren Ecke.

Der Wizard macht einen mit der Arbeitsweise von Qure und den zugrundeliegenden Konzepten vertraut, wie man aus dem obigen Screenshot erkennen kann. Für dieses Review unterbrechen wir den Wizard hier an dieser Stelle und gehen direkt in medias res.

Der obige Bildschirm ist Qure's Haupteinstiegspunkt. Von hier aus kann man entweder neue Analysen erstellen oder bereits bestehende öffnen. Da dies nun aber unsere erste Verwendung ist, erstellen wir eine neue Analyse.

An dieser Stelle ist es angebracht, einen wichtigen Punkt zu erwähnen, der momentan vielleicht nicht so klar auf Qure's Website herausgestellt wird, wie es möglich wäre. Die netten Leute bei DBSophic haben versprochen, die Website zu überarbeiten und eindeutiger zu gestalten.

Die Trial-Version von Qure und die begleitenden Trial-Analyse kann mit jeder Datenbank und jeder Arbeitslast verwendet werden. Nicht nur mit der AdventureWorks Beispieldatenbank. Hier ist eine Gegenüberstellung der Unterschiede zwischen der Vollversion und der Trial-Version:

Vollversion	Trial-Version
gültige Lizenz erforderlich	Frei - Keine Lizenz erforderlich
Datenanalyse vollständig oder stichprobenweise	Datenanalyse nur stichprobenweise
Unlimitierte Anzahl Trace-Datei pro Analyse	Maximal 10 Trace-Datei pro Analyse
Unlimitierte Anzahl an Batches pro Analyse	Maximal 50.000 Batches pro Analyse
Maximal 3 Datenbanken pro Analyse	Maximal 2 Datenbanken pro Analyse
Alle Empfehlungen verfügbar	Empfehlungen nur für 5 Batches

Obwohl man mit der Trial-Version von Qure jede eigene Datenbank analysieren kann, werden wir für diesen Review die AdventureWorks Beispieldatenbank verwenden. Der Grund dafür ist einfach: Die Ergebnisse und Qure's Empfehlungen in diesem Review sind entweder identisch oder zumindest sehr ähnlich zu denen, die der Leser erhält, wenn er die Beispielanalyse gegen die AdventureWorks Datenbank auf einer seiner Maschinen erhält. Natürlich hätte ich eine meiner (wesentlich größeren und stärker belasteten) Datenbanken verwenden können, aber das hätte diesen Review nur abstrakter und vielleicht auch weniger realistisch gestaltet.

Nachdem dies geklärt ist, besteht der nächste Schritt darin, die Analyse Datei zu erstellen in welcher Qure alle Informationen speichert. In unserem Fall benennen wir diese Datei "MyAnalysis".

Direkt danach wird der Server ausgewählt, der die zu analysierende Datenbank hostet. Wie man gut aus dem obigen Screenshot erkennen kann, wirf Qure eine Warnung aus, wenn es feststellt, dass diese Datenbank auf derselben Instanz gehostet wie die Produktions-Instanz. In unserem Fall wird die AdventureWorks Datenbank auf der einzige Instanz auf dem Laptop gehostet. Somit ist die Warnung gerechtfertigt, aber wir ignorieren sie geflissentlich. Im reellen Betrieb würde man natürlich die Analyse von einer Client-Maschine gegen den Analyse Datenbank-Server laufen lassen. In größeren Unternehmen ist es gängige Praxis getrennte Umgebungen für Produktion und Entwicklung zu haben. Vielfach kommt auch noch eine separate Testumgebung hinzu, die nahezu identisch zu der Produktion ist. Solch eine Umgebung ist der ideale Kandidat für den Analyse-Server.

Nachdem der Server ausgewählt wurde, ist es nun Zeit, die zu analysierende Datenbank festzulegen.

Bereits mehrfach erwähnt wurde, dass für Qure SQL Server Trace Datei die Hauptinformationsquelle sind und nun ist es an der Zeit, diese Traces auszuwählen, die in die Analyse einfließen sollen. Hiermit sollte man beachten, dass das Qure Demo-Kit in zwei verschiedenen Varianten verfügbar ist. Diese beiden Varianten unterscheiden sich stark in den Analyse-Empfehlungen:

• Die erste Variante beinhaltet einen Trace mit der simulierten Arbeitslast der AdventureWorks Datenbank. Dieser Trace erlaubt es, den gesamten Analyse-Prozess zu durchlaufen. Allerdings werden aber nur für 5 Batches Empfehlungen angezeigt.
• Die zweite Variante beinhaltet eine bereits fertig aufbereitete Analyse Datei. Die Analyse unterliegt keinerlei Restriktionen und enthält alle Empfehlungen für den Workload der AdventureWorks Datenbank.

Für diesen Review verwenden wir eine Mischung aus beiden Varianten. Um den Analyse-Prozess zu demonstrieren, werden wir den Beispiel-Trace analysieren lassen. Später dann werden auf die präparierte Analyse Datei wechseln, um uns einige von Qure's Empfehlungen eingehender zu untersuchen. Doch dazu später mehr.

In den Einstellungen für die Analyse kann man entscheiden, ob Qure Empfehlungen zu den derzeit existieren Indexen treffen soll oder nicht. Das bedeutet, dass sämtliche Indexe erhalten bleiben, mit Ausnahme von doppelten, deaktivierten oder hypothetischen Indexen, die immer in die Analyse mit einfließen.

Wenn man System Trace Ereignisse wie Replikations-Ereignisse in die Analyse aufnimmt, kann unter Umständen die Performance der Analyse erhöht werden.

Nachdem diese Vorarbeiten abgeschlossen sind, kann Qure nun an die Arbeit gehen und seinen Zauber vollbringen. Dieser Analyse-Prozess kann bezüglich der Laufzeit stark schwanken, je nach Größe und Komplexität der Datenbank, die gerade analysiert wird.

Der erste Schritt in der Analyse ist die Schema-Analyse. Während dieses Schrittes werden die vorhandenen Datenbank-Objekte wie Tabellen, Indexe, Sichten, Gespeicherte Prozeduren, Funktionen, usw... untersucht. Da dieser Schritt fast ausschließlich die Metadaten der Datenbank analysiert, ist er schnell und benötigt nicht viele Ressourcen.

Der nächste Schritt ist die Analyse der Trace Datei(en). Es wird nicht überraschen, dass dieser Schritt eine lange Zeit in Anspruch nehmen kann. Dies hängt von der Größe der Datei(en) ab, der Anzahl der Ereignisse, die im Trace mitgeschnitten wurden und natürlich auch von der Komplexität der mitgeschnittenen Batches. Während dieser Zeit werden hauptsächlich Ressourcen auf der Maschine verwendet, auf der Qure installiert wurde

Parallel zu der Analyse der Trace Datei(en) wird die statistische Analyse der Daten in den Tabellen der Datenbank durchgeführt. Wie zu erwarten ist, verbraucht dieser Schritt die meisten Ressourcen auf dem Datenbank-Server, der die Datenbank hostet und kann ebenfalls eine lange Zeit in Anspruch nehmen, wenn die Datenbank dementsprechend groß ist.

Sobald die Analyse abgeschlossen ist, erstellt Qure seine Empfehlungen auf der Basis der gewonnenen Erkenntnisse.

Basierend auf diesen Empfehlungen fährt Qure mit einem Benchmark-Test fort, bei dem diese Empfehlungen gegen die im Trace aufgelisteten Batches getestet werden. Da nun aber die im Trace gespeicherten Angaben zu Dauer und IO vom Produktions-Server stammen, kann es natürlich sein, dass diese Angaben von denen abweichen, die auf dem Analyse-Server gelten würden. Aus diesem Grund besteht der erste Schritt in dem Benchmark-Prozess darin, dass Qure eine Baseline generiert, indem die Batches auf dem Analyse-Server erneut ausgeführt werden.

Nachdem diese Baseline erstellt wurde, wendet Qure seine Empfehlungen auf die Datenbank an, führt die Batches erneut aus und vergleicht sie mit der Baseline. Die Ergebnisse daraus werden in der Analyse-Datei gespeichert und der finale Report daraus generiert.

Dieser Report kann nun auf verschiedenste Weise betrachtet werden. Dazu gleich mehr, denn bis zu diesem Punkt haben wir den Demo Trace analysieren lassen. Nun aber ist es an der Zeit auf die vorbereitete vollständige Analyse zu wechseln, um tiefere Einblicke in Qure's Empfehlungen zu erhalten.

Zu diesem Zweck starten wir Qure erneut und klicken auf "Open Previous Analysis".

Anschließend wählen wir die zuvor heruntergeladen Analyse-Datei aus und können nun Qure's Potential vollständig begutachten.

Betrachten wir zunächst einmal den obigen Screenshot. Aus dem "Summary" Tab erhält man einen allgemeinen Überblick über die Ergebnisse der Analyse und eine Auflistung aller optimieren Batches zusammen mit Zahlen zur individuellen Performance-Verbesserung. Zu den einzelnen Empfehlungen gelangt man entweder über einen Klick auf die assoziierte Analyse ID im oberen Grid oder durch einen Klick auf einer der Analyse-Kategorien in dem unteren "Recommendation Summary".

Betrachten wir einmal beispielsweise "Batch-276". Sobald man auf diesen Batch im Summary Tab klickt, wird man auf den "Batch" Tab weitergeleitet und dort sieht man dann sämtliche Analyse-Ergebnisse zu dem Batch. Der obige Screenshot zeigt eine Verbesserung von 65% bei der Laufzeit mit einer Verringerung der physikalischen Lesevorgänge um 82% und eine Verringerung der logischen Lesevorgänge um beeindruckende 99%. Nur, was ist eigentlich "Batch-276"?

Bevor wir dieser Frage nachgehen, lenken wir kurz die Aufmerksamkeit auf den unteren rot eingekreisten Bereich. Dort liest man: "Difference detected in batch result set between original analysis DB and optimized DB." Was bedeutet das? Qure führt automatisch zusätzliche Checks zu der Ergebnismenge eines Batches durch, um sicherzustellen, dass diese Ergebnismenge vor und nach Optimierung identisch ist. Genauer gesagt bedeutet dies, dass Qure eine Checksummen Validierung der Ergebnismenge durchführt. In der Mehrzahl der Fälle, bei denen die obige Meldung erscheint, liegt die Ursache darin, dass eine Änderung im Ausführungsplan vollzogen wurde, die eine Änderung in der Reihenfolge in welcher die Zeilen zurückgegeben werden nach sich zieht. Ein weiterer möglicher Grund ist die Verwendung von Nicht-Deterministischen Funktionen wie NEWID(), GETDATE() oder RAND(). Natürlich gilt dies auch dann, wenn der Batch kein ORDER BY enthält, welches die Sortierung der Ergebnismenge garantieren würde. Verschiedene Ausführungspläne können zu unterschiedlichen Ausgaben in der Sortierung der Ergebnismenge führen und dieser Umstand wird von Qure erfasst. Von daher ist dieses Feature ein zusätzliches Sicherheitsnetz und beeinträchtigt keinesfalls die Qualität der Empfehlungen, wie man vielleicht denken mag, wenn man diese Warnung zum ersten Mal sieht.

Zurück zu Batch-276. Um herauszufinden, was hinter diesem Batch steckt, muss man einfach nur auf den "Script" Tab klicken

Auf dem "Recommendation" Tab schließlich findet man Qure's Empfehlungen, die zu der Performance-Steigerung führen können, die wir vorhin gesehen haben.

Mit einem Klick auf "All (3 Recommendations)" gelangt man folgerichtig auf den "Recommendation" Tab, wo man jede einzelne Empfehlung unter die Lupe nehmen kann. Wie man aus dem obigen Screenshot entnehmen kann, erzielt man die größte Performance-Steigerung durch den Einsatz eines auf diesen Batch zugeschnittenen Index. Indexe sind häufig der Punkt in einer Datenbank, ducrh den man am meisten gewinnen kann bei einem üblicherweise vernünftigen Verhältnis von Aufwand und Nutzen.

Schließlich kann man auf dem "Script Preview" Tab einen Blick auf das Skript werfen, so wie es von Qure generiert wurde und auf die Zieldatenbank angewendet werden würde. Aber es lohnt sich auch durchaus, einen Blick auf den rot markierten Bereich zu werfen. Qure generiert nicht nur ein Change-Skript, sondern auch gleich das dazu passende Rollback-Skript noch dazu, mit welchem der Change rückgängig gemacht werden kann, falls dies notwendig werden sollte.

Wie gerade erwähnt, kommt häufig der größte Performance-Gewinn aus der Erstellung geeigneter Indexe welche die Abfragen an die Datenbank optimal unterstützen. Aber Qure kann nicht nur in diesen Fällen helfen, sondern kann auch bei dem Einsatz von "Best Practices" helfen. Beispielsweise kann man in obigen Screenshot gut erkennen, dass Qure eine Warnung erzeugt, wenn ein "SELECT *" Konstrukt gefunden wird. Ein solches SELECT * Statement mag zwar auf den ersten Blick bequem erscheinen, da man sich nicht mehr um entfernte oder hinzugefügte Spalten kümmern muss. Tatsächlich aber kann ein SELECT * mehr Nachteile als Vorteile mit sich bringen. In den seltensten Fällen muss man tatsächlich sämtliche Spalten einer Abfrage an den Client zurückgeben und selbst wenn man vielleicht nicht unbedingt einen Performance-Boost auf der Serverseite bemerkt durch das Entfernen eines SELECT *, hilft es zweifelsohne, die Daten schneller zum Client zu bringen, da weniger Bytes über das Netzwerk transportiert werden müssen.

Ein weiteres Beispiel ist die Verwendung von IN Klauseln. Diese sind für Langsamkeit und beschränktem Nutzen bekannt.

Hier kann man sehen, das Qure in so einem Fall ein wesentlich "besseres" Konstrukt vorschlägt.

Die letzten beiden Beispiele sind im obigen Screenshot dargestellt. Durch die Analyse der in der Datenbank gespeicherten Daten erlangt Qure tiefergehende Einblicke, die sich in "Potential Unused Column" Empfehlungen ausdrückt. In diesem Fall hat Qure festgestellt, dass in einer Spalte stets ein identischer Wert gespeichert wird. Dies gibt Anlass zu der Vermutung, dass es nicht notwendig ist, den Wert überhaupt in der Datenbank zu speichern, sondern vielmehr entweder den Wert zur Laufzeit der Abfrage in der Datenbank oder in der Client-Applikation zu generieren.

Die "Potentially missing NOT NULL constraint on column..." Empfehlung ist ebenfalls etwas, was Qure durch die Analyse der Daten ermöglicht. Sofern es keinen NULL Wert in der Spalte einer Tabelle gibt, mag es angebracht erscheinen eine NOT NULL Einschränkung für diese Spalte zu erstellen. Solch eine Empfehlung ist nicht zwangsläufig eine Empfehlung die in bessere Performance mündet, sondern viel eher die Datenqualität erhöht. Auf der anderen Seite jedoch kann eine solche Einschränkung helfen, die Komplexität der Abfragen zu verringern, da man sich durch die Existenz einer solchen Einschränkung sicher sein kann, dass kein NULL Wert in dieser Spalte befinden kann. Daher braucht man auch nicht in den Abfragen die spezielle SQL Three-Value Logik in Betracht ziehen. Die solchermaßen vereinfachten Abfragen wiederum können in eine bessere Nutzung von Indexen münden, was dann zu einem Performance-Gewinn führen kann. Des weiteren kann aber auch eine solche NOT NULL Einschränkung dem SQL Server Query Optimizer helfen, bessere Annahmen über die Nützlichkeit von Indexen zu treffen, was wiederum zu einem besseren Ausführungsplan führen kann.

Qure kann nicht nur fehlende Indexe finden, sondern auch suboptimale Indexe, die durch Umordnung der Spalten und/oder Hinzufügen oder Entfernen von Spalten die Performance verbessern können. Dies ist ein bemerkenswertes Feature, da eine der am häufigsten verwendeten Waffen im Tuning Arsenal das Hinzufügen von Indexen ist. Leider ist aber das blinde Hinzufügen von zusätzlichen Indexen nicht zwangsläufig das Beste, was man machen kann, da jeder zusätzlicher Index auch bei jeder Datenänderung in der zugrundeliegenden Tabellen gepflegt werden muss und dies bei einer Tabelle mit relativ hoher Anzahl an Modifizierungen durchaus dazu führen kann, dass die Performance unter zusätzlichen Indexen leidet. Aus diesem Grund ist ein Tool, welches diesen Umstand in Betracht ziehen kann und Vorschläge zur Umstrukturierung der existierenden Indexe vornimmt, um eine ausgewogene Balance zu erzielen, seinen Preis in Gold wert.

Bevor wir unseren Blick auf Qure's Empfehlungen beenden, sollen noch ganz kurz zwei weitere Erwähnung finden.

OR Klauseln: Solche Konstrukte wie SELECT ... FROM Tabelle WHERE Spalte A = ? OR Spalte B = ? werden häufig verwendet, um flexible Suchabfragen von Client-Applikationen zu unterstützen. Es ist keineswegs falsch, solche Funktionalitäten in Applikationen einzubauen, aber anstelle von OR Klauseln können Abfragen vielfach wie folgt umgeschrieben werden und liefern bessere Performance.

Der obige Screenshot zeigt, wie Qure solche Abfragen umschreiben würde.

Und hier sieht man den Effekt der umgeschriebenen Abfrage. Am ehesten fällt die Reduktion in logischen Lesevorgängen auf. Aber vermutlich wird der Leser jetzt eher auf den Anstieg in Prozessorzeit schauen, der die Reduktion in der allgemeinen Laufzeit ausgleicht. Halt! Bevor man sich hier aufregt, sollten wir einen Blick darauf werfen, wie die umgeschrieben Abfrage den Ausführungsplan beeinflusst.

Ja, man kann sich den originalen und den umgeschriebenen Ausführungsplan aus Qure heraus anzeigen lassen. Dafür braucht man bloß auf den "Execution Plan" zu klicken.

Der Original-Ausführungsplan auf der linken Seite verwendet einen Clustered Index Scan, was durchaus den Erwartungen entspricht. Der Ausführungsplan der umgeschriebenen Abfrage hingegen verwendet einen Index Seek und ist damit so effektiv wie es möglich ist. Von daher ist das Umschreiben der Abfrage durchaus den Anstieg in Prozessorzeit wert. Gerade dann, wenn die Tabelle wächst und der ursprüngliche Index Scan immer mehr und mehr Daten abarbeiten müsste.

Zum Abschluss wollen wir eine weitere Optimierungsmethode in Qure erwähnen, die recht bemerkenswert für ein Automatisierungstool ist: Das Umschreiben von Funktionsaufrufen für Spalten. Was ist damit gemeint? Nun, man stelle sich vor, dass man alle Bestellungen finden möchten, die zwischen dem 02.02.2004 und dem 06.02.2004 eingegangen sind. SQL ist zwar eine deklarative Sprache, bei der man nur angibt, was man haben will und es der Datenbank-Engine überlässt, die Anfrage auf die bestmögliche Art auszuführen. Dennoch findet man leider nur allzu häufig, dass solche Abfragen in der Form SELECT ... FROM Tabelle WHERE YEAR(OrderDate) = ? AND MONTH(OrderDate) = ? AND DAY(OrderDate) BETWEEN 2 AND 5. Zweifelsohne gibt diese Abfrage ein korrektes Ergebnis zurück. Aber als optimal kann sie wohl kaum bezeichnet werden. Nicht nur werden durch die Funktionsaufrufe YEAR(), MONTH() oder DAY() die Verwendung von Indexen ausgeschlossen. Es ist auch eine eher unnatürlich Art und Weise, diesen Request auszudrücken.

Qure kann einem auch in solchen Fällen helfen, wie der obige Screenshot zeigt. Nicht nur ist dies ein wesentlich natürlicher Weg, die Abfrage auszudrücken. Vielmehr kann dieses Umschreiben auch zu einem dramatisch "besseren" Ausführungsplan führen, sofern ein Index auf OrderDate vorhanden ist. Im obigen Fall jedoch ist der Nettoeffekt 0 da die Abfrage eine SELECT * Abfrage ist, die alle Spalten anfordert, um damit keine andere Möglichkeit bleibt, die Abfragen auszuführen, als einen Clustered Index Scan durchzuführen.

Aber gerade dieses letzte Beispiel verdeutlicht sehr gut Qure's integrativen Optimierungsansatz. Für diesen Batch sind 3 Empfehlungen verfügbar.

• Optimierung des Objektes selbst
• SELECT * Verwendung
• Funktionsaufruf über eine Spalte im Suchprädikat.

An dieser Stelle nun haben wir genug von Qure's Empfehlungen gesehen. Wir überlassen es dem Leser, herauszufinden, wie er von Qure in seiner eigenen Umgebung profitieren kann. Und es gibt da tatsächlich noch einige weitere Features zu entdecken, die an dieser Stelle keine Erwähnung finden konnten. Zum Beispiel, Smart Filtering oder das Optimize Feature, welcher der Part von Qure ist, der das Change und das Rollback Skript vorbereitet.

Last, but not least soll erwähnt werden, dass Qure es erlaubt, eine Analyse als Excel Datei zu exportieren. Dies erlaubt damit die Verwendung von Excel und der gesamten Office Familie, um qualitativ hochwertige Präsentationen zu erstellen, wie Datenbank-Performance durch Qure optimiert werden kann.

Schlussfolgerung

Datenbank-Performance Optimierung ist weder Schwarze Magie noch esoterische Grenzwissenschaft. Dennoch erfordert es jemanden, der sich mit der Materie auskennt und nicht jede Firma beschäftigt solch einen Spezialisten oder kann es sich erlauben, einen externen Berater für viel Geld einzukaufen. Letzteres bietet übrigens auch keine Garantie für Erfolg. Aber es braucht sowieso etwas "mehr", um eine Datenbank vollständig zu tunen. Es braucht vertiefte Kenntnisse zu Zweck der Datenbank, ihren Platz im Gesamtsystem, und letztendlich auch Kenntnisse der darin gespeicherten Daten. Aus diesem Grund sind Tools wie Qure eine ausgezeichnete Alternative, die einem bei einem ganzheitlichen Tuning-Ansatz, helfen können. Selbst für Leuten, die sich mit Performance-Tuning und Optimierung auskennen können von Qure profitieren, da es häufig kleine Details sind, die übersehen werden und vielfach fehlt einfach die Zeit, um eine eigene vollständige Analyse zu erstellen. Daher kommt ein Tool welches einem gerade diese Arbeit abnimmt, gerade recht. Aber Qure führt diesen Ansatz noch einen Schritt weiter und hilft bei der Durchsetzung von allgemein anerkannten Best Practices. Dies macht Qure zu einen hilfreichen Tool, welches man definitiv ausprobieren sollte.