In Tabelle 2.1 sehen Sie das Ergebnis beider Ausführungen auf meiner Maschine.

Transkript

1

2 Kapitel 2 Datenverwaltung durch SQL Server Wir wollen das obige Skript zwei Mal laufen lassen, einmal mit und einmal ohne eingeschalteten Schreibcache der Festplatte. Für eine lokale Festplatte können Sie den Schreibcache über den Gerätemanager konfigurieren. Wählen Sie die Eigenschaften für das entsprechende Laufwerk und dort die Seite Richtlinien aus (Abbildung 2.1). Abbildung 2.1: Konfiguration des Festplatten-Schreibcaches In Tabelle 2.1 sehen Sie das Ergebnis beider Ausführungen auf meiner Maschine. Zeit/s WRITELOG/s % WRITELOG Mit Schreibcache Ohne Schreibcache Tabelle 2.1: Schreiben vieler kleiner Transaktionen mit und ohne Schreibcache Wie nicht anders zu erwarten, hat der Schreibcache einen ganz erheblichen Einfluss auf die Ausführungszeit. Es ist außerdem deutlich zu erkennen, dass die Zeit, die auf das Schreiben des Protokolls gewartet wurde, so gut wie identisch mit der Zeit ist, die die Abfrage insgesamt gedauert hat. Dies war sicherlich auch nicht anders zu erwarten, denn das Schreiben des Protokolls geschieht synchron. Ein COMMIT ist also erst abgeschlossen, wenn die entsprechenden Protokolleinträge in der Protokolldatei gespeichert sind. 34

3 Daten schreiben Wir wiederholen nun das Experiment mit einem etwas geänderten Skript: if (object_id('t1') is not null) drop table T1 go -- Erzeuge eine Test-Tabelle create table T1 ( id int not null default 0,daten nchar(20) null ) go set nocount on -- Setze alle Leistungsindikatoren zurück. dbcc sqlperf('sys.dm_os_wait_stats',clear) with no_infomsgs -- Füge Zeilen in einer Transaktion hinzu begin tran int = 1 while (@i < 10000) begin insert T1(id) values(@i) if (@i % 1000) = 0 raiserror('1000 Zeilen hinzugefügt', 0, 1) with nowait + 1 end commit -- Zeige an, wie oft und wie lange auf das Schreiben -- des Transaktionsprotokolls gewartet wurde. select * from sys.dm_os_wait_stats where wait_type = 'WRITELOG' Schauen Sie auf den fett gedruckten Teil im obigen Listing. Nun werden alle INSERTs in nur einer Transaktion ausgeführt. Es wird also auch nur ein Protokolleintrag geschrieben; die Anzahl der WRITELOG-Wartezustände ist folglich 1. Die Werte für die Ausführung der Abfrage liegen nun allesamt deutlich unter einer Sekunde, wobei es egal ist, ob der Schreibcache der Festplatte aktiv ist oder nicht. Und damit haben wir schon einen Ansatzpunkt für eine Optimierung: die Transaktionsgröße oder auch die Transaktionsrate. Aus dem Ergebnis des obigen Experimentes könnten Sie schließen, dass möglichst große Transaktionen eine Verbesserung der Abfrageleistung mit sich bringen. Ganz so einfach ist es aber leider nicht. Im Experiment haben wir einen Extremfall untersucht, um zu demonstrieren, welche Auswirkungen die Transaktionsrate auf Abfrageleistung bei Datenänderungen hat. Größere, länger andauernde Transaktionen benötigen auch mehr Sperren, die länger aufrechterhalten werden. Dadurch erzeugen sie potenziell viel mehr Blockierungen, wodurch in Mehrbenutzersystemen vermehrt Wartezustände auftreten, und dadurch sinkt letztlich die Performance. 35

4 Kapitel 2 Datenverwaltung durch SQL Server Wie so oft, gilt es also auch hier, ein Optimum herauszufinden. Der Indikator WRITE- LOG ist hier für eine entsprechende Überwachung sehr gut geeignet. Falls die Wartezeit für WRITELOG in der Hitliste der gesamten gewarteten Zeit weit obenan steht, wobei Sie natürlich Ihr System über einen längeren Zeitraum überwachen sollten, dann lohnt sich sicherlich eine nähere Untersuchung. 2.4 Zusammenfassung Dieses Kapitel hat Ihnen die Grundlagen der SQL Server-Datenverwaltung aufgezeigt. Da die Minimierung von Ein-/Ausgabeoperationen bei der Optimierung von Abfragen im Vordergrund steht, ist es natürlich wichtig, dass Sie wissen, in welcher Art und Weise SQL Server Daten liest und schreibt. Insbesondere sollten Sie sich einprägen, dass die Verwaltung von Tabellen- und Protokolldaten in unterschiedlicher Art und Weise erfolgt. Tabellendaten werden in der Regel zufällig gelesen und geschrieben, wohingegen Protokolldaten hauptsächlich sequenziell geschrieben werden. SQL Server verwaltet einen Datencache, in den alle von der Festplatte gelesenen Daten übertragen werden. Der Abfrageprozessor bedient sich stets aus diesem Cache. Auch Datenänderungen werden zunächst nur im Cache gespeichert und von dort asynchron auf die Festplatte übertragen. Denken Sie bitte daran, wenn Sie meinen, Ihr System greift größtenteils schreibend auf die Datenbank(en) zu. Alle Operationen, die Daten ändern oder löschen, übertragen zunächst die entsprechenden Daten in den Datencache. Die Daten werden dann im Datencache geändert und von dort wieder auf die Festplatte geschrieben. Also: Kein Schreiben ohne Lesen! 36

5 3 Ausführung von Abfragen Nach dem in Kapitel 1 vorgestellten Optimierungsmodell nimmt die Optimierung von Abfragen einen zentralen Platz bei der Performance-Optimierung ein. Nach meiner persönlichen Erfahrung ist dieser Punkt tatsächlich der vielversprechendste Ansatzpunkt für eine erfolgreiche Optimierung. Damit Sie wissen, welche Möglichkeiten sich hier bieten, ist es zunächst einmal wichtig zu verstehen, in welchen Schritten die Verarbeitung von Abfragen durchgeführt wird, wie SQL Server also letztlich aus einer SQL Anweisung ein Abfrageergebnis ermittelt. In diesem Kapitel werden Sie die an der Verarbeitung von Abfragen beteiligten Komponenten kennenlernen, wobei der Schwerpunkt auf der Erstellung von Ausführungsplänen durch den Abfrageoptimierer liegt. Ausgangspunkt ist hierbei zunächst die logische Ausführungsreihenfolge einer Abfrage. Wir werden anschließend untersuchen, wie aus einer SQL-Anweisung in verschiedenen Schritten ein physikalischer Ausführungsplan erstellt wird, der das korrekte Abfrageergebnis auf einem möglichst kostengünstigen Weg ermittelt. 3.1 Logische Schritte der Abfrageausführung Wenn Sie eine Abfrage entwerfen und ausführen, dann haben Sie sich zuvor überlegt, wie das Ergebnis aussehen soll und welche Daten aus welchen Tabellen Sie benötigen. Bei diesen Überlegungen werden Sie auch bedenken, in welcher Weise Ihre Abfrage ausgeführt wird, wobei Sie hier die logische Reihenfolge der Abarbeitung der einzelnen Klauseln berücksichtigen. Mit anderen Worten: Sie sollten wissen, welche Schritte in welcher Reihenfolge abgearbeitet werden. Wir wollen hierzu ein Beispiel untersuchen. Betrachten Sie bitte die folgende Abfrage, die alle Produktunterkategorien mit Namen und Anzahl der in ihr enthaltenen Produkte zurückgibt, wobei nur Unterkategorien berücksichtigt werden, die im Namen die Zeichenkette bike enthalten und die mehr als fünf Produkte umfassen: -- Alle Produktkategorien, die mehr als 5 Produkte enthalten -- und deren Name die Zeichenfolge "bike" enthält. use AdventureWorks2008R2; select sc.name, count(*) as Anzahl from Production.Product as p left outer join Production.ProductSubcategory as sc on sc.productsubcategoryid = p.productsubcategoryid where sc.name like '%bike%' 37

6 Kapitel 3 Ausführung von Abfragen group by sc.name having count(*) > 5 order by Anzahl desc Die einzelnen Bereiche der Abfrage, wie zum Beispiel FROM, WHERE und ORDER BY, werden logisch in einer genau festgelegten Reihenfolge nacheinander abgearbeitet, damit das Abfrageergebnis korrekt ist. Abbildung 3.1 zeigt, in welcher Reihenfolge die einzelnen Schritte der Abfrage ausgeführt werden. FROM und JOIN WHERE GROUP BY HAVING SELECT ORDER BY Ergebnis Abbildung 3.1: Logische Abfragereihenfolge Aus Gründen der Übersichtlichkeit haben wir in unserer Abfrage einige weniger wichtige Klauseln weggelassen (zum Beispiel: DISTINCT, TOP, CUBE und ROLLUP). Es geht hier nur darum, dass Sie sich die folgenden beiden Punkte einprägen: Die logische Ausführungsreihenfolge ist deterministisch. Mit anderen Worten: Wenn Sie eine Abfrage ausführen, dann ist immer sichergestellt, dass das Ergebnis der logischen Abarbeitungsreihenfolge entspricht. Die logische Abarbeitungsreihenfolge entspricht nicht der Reihenfolge des Auftretens der Klauseln in der SELECT-Anweisung. Für SQL-Neulinge ist diese Tatsache stets gewöhnungsbedürftig. Die SELECT-Klausel zum Beispiel wird erst fast am Ende ausgewertet, obwohl sie am Beginn der Abfrage steht. Sie können sich die Verarbeitung so vorstellen, dass eine virtuelle Tabelle von Schritt zu Schritt durchgereicht wird. Jeder Verarbeitungsschritt verändert die virtuelle Tabelle, indem er Zeilen bzw. Spalten hinzufügt oder entfernt, und übergibt anschließend die modifizierte Tabelle an den nächsten Verarbeitungsschritt, bis am Ende das Ergebnis feststeht. 38