Autonomic Database Tuning im Microsoft SQL Server 2005

Autonomic Database Tuning im Microsoft SQL Server 2005
Blockseminar Autonomic Database Tuning
Stephan Arenswald
Lehrstuhl für Datenbanken und Informationssysteme
Institut für Informatik
Friedrich-Schiller-Universität Jena
Ernst-Abbe-Platz 2
07743 Jena
[email protected]
Abstract: Diese Ausarbeitung beschäftigt sich mit den Autonomic Database Tuning
Features im Microsoft SQL Server 2005. Es gibt einen allgemeinen Überblick über die
vorhandenen Techniken und mitgelieferten Werkzeuge. Des weiteren werden
Statistiken gezeigt, welche die Qualität der Fähigkeiten darlegen.
1 Einleitung
Der Microsoft SQL Server gilt neben IBMs DB2 UDB (aktuell Version 9) und Oracles
Oracle Database 10g als eines der meistgenutzten Datenbankmanagementsysteme weltweit.
Die aktuelle Version ist Microsoft SQL Server 2005 (Service Pack 1).
Mit Erscheinen der Version 2005 wurden einige neue Funktionen bezüglich des Autonomic
Database Tuning eingeführt. Microsoft stellte sich dazu eigene Anforderungen welche im
Produkt umgesetzt werden sollen.
 Integrierte Auswahl von physischen Design-Features: Bisher gab es für
verschiedene Tuningaufgaben verschiedene Advisor, also Programme, welche
Vorschläge für den physischen Datenbankentwurf erstellten. Diese arbeiteten
jedoch nicht zusammen, so dass verschiedene Advisors Vorschläge liefern konnten,
welche im Einzelnen zweckvoll sind, aber zusammen die Performance senken. Um
dem entgegenzuwirken, setzt Microsoft voraus, dass es nur ein Werkzeug gibt,
welches einen Vorschlag für alle physischen Datenbankfeatures in Abhängigkeit
voneinander liefert [BC07].
 Handhabbarkeit (Manageability): Trotz guter Performance eines Autonomic
Computing Toolkits, sollte dabei die Handhabbarkeit nicht verloren gehen. Es ist
also wichtig das die Features zugänglich sind und auch genauso leicht verwendet
werden können. Aber nicht nur die Werkzeuge selbst, sondern auch deren
Ergebnisse sollen zur besseren Manageability beitragen. Zum Beispiel wird
horizontale Partitionierung von Tabellen oft dazu verwendet leichteres Backup,
Insert oder Delete von Daten zu gewährleisten. Sind nun alle Tabellen und Indexe
gleich partitioniert trägt dies zur besseren Administration bei.
1
 Skalierbarkeit: Ein Advisor muss in der Lage sein, Vorschläge in akzeptabler Zeit
auch für sehr große Datenbanken zu erstellen.
 Fähigkeit mit sehr geringem Overhead einen Produktionsserver zu tunen: Um
einen Server performant zu tunen, ist es intuitiv, die Daten auf einen Testserver zu
kopieren, auf welchem das Tuning stattfindet. Je nach Größe der Daten kann das
Kopieren aber die Performance stark senken. Zusätzlich kann währenddessen auf
dem Produktionsserver eine ganz neue Situation eintreten, welche neue Probleme
mit sich bringt. Diese können auf dem Testserver nicht berücksichtigt werden. Auch
unterschiedliche Hardware und Software spielt eine wichtige Rolle. Somit kann ein
System nur auf dem Produktionsserver autonom optimiert werden. Entsprechend
sollte der dadurch entstehende Overhead gering gehalten werden.
 Scriptability: Wegen der gewachsenen Fülle an Funktionen und der Größe der
Tuningaktionen ist es wichtig, die Möglichkeit von Skripten zu bieten. Diese helfen
nicht nur einen Tuningauftrag übersichtlicher zu gestalten, sondern dienen auch der
Wiederverwendbarkeit. 
 Anpassung (Customization): Die Entwicklung eines Werkzeuges zum autonomen
Tuning von Datenbanken ist nicht trivial. Zum Einen soll dieses Programm
automatisch Vorschläge erstellen und das Design umsetzen und zum Anderen soll
der Administrator die Möglichkeit besitzen den gesamten Prozess zu überwachen
und an jeder beliebigen Stelle einzugreifen.
Der Database Tuning Advisor (DTA) [AC04] ist die Antwort auf diese Anforderungen.
Dieses Tool wird seit Version 2005 mitgeliefert. Es beherrscht das integrierte Tuning von
Indexen, von Materialized Views und durch horizontale Partitionierung. Tabelle 1 zeigt einen
Vergleich des SQL Server 2005 mit der Vorgängerversion einschließlich der Editionen
bezüglich des Vorhandenseins des DTA. Der sogenannte Index Tuning Wizard (ITW) des
SQL Server 2000 [ACN99] ist ausschließlich auf Indexe spezialisiert.
Version
SQL Server 2000
ITW
SQL Server 2005
DTA
Edition
Alle außer MSDE
Autonomic Tuning
Express
Workgroup
Standard
Enterprise
Tabelle 1: Vergleich der SQL Server Versionen in Bezug auf Vorhandensein von ITW und DTA
Kapitel 3 geht näher auf den DTA ein. Es erläutert den Aufbau und das zugrunde liegende
Kostenmodell und beschreibt das Tuning in einem Produktions-/Testserversystem. Zuvor
beschäftigt sich Kapitel 2 jedoch mit Selbst-Management-Funktionen des SQL Servers.
Microsoft konzentriert sich im Bereich Forschung hauptsächlich auf Selbst-Tuning und
Selbst-Administrierung von Datenbanksystemen. Das als „
A
u
t
o
A
d
m
i
n
“
g
e
t
a
u
f
t
e
P
r
o
j
e
k
t
bietet bereits eine Reihe von Veröffentlichungen1 zu diesen Themen.
1
http://research.microsoft.com/dmx/autoadmin/
2
2 Selbst-Management
Autonomes Datenbank-Tuning bedeutet, das sich ein System selbst managt. Das heißt, es
kann sich selbst konfigurieren, wenn es nötig ist. Genauso gut kann es sich optimieren.
Im folgenden Abschnitt 2.1 wird auf die Selbst-Konfiguration im Microsoft SQL Server 2005
näher eingegangen. Dabei werden sowohl Konfigurationsparameter als auch
Speichermanagement behandelt. Unterkapitel 2.2 geht im Anschluss näher auf selbst
optimierende Features ein. Der Focus wird dabei auf Histogrammen liegen. Darauf folgen in
Abschnitt 2.3 Selbstoptimierungsfeatures des Query Prozessors. Im letzten Abschnitt 2.4
wird dann noch die Storage Engine kurz behandelt.
2.1 Selbst-Konfiguration des Datenbankmanagementsystems
In den großen Datenbankmanagementsystemen gibt es sehr viele Einstellmöglichkeiten. Dazu
zählen vor allem viele Konfigurationsparameter. Der SQL Server besitzt in Version 2005
circa 66 solcher sogenannter Optionen2.
Damit sich ein System selbst konfigurieren kann, muss es unter anderem
Konfigurationsparameter anpassen können. Das Problem dabei ist nicht die Änderung,
sondern, dass ein Datenbankmanagementsystem in manchen Fällen nach der Anpassung neu
gestartet werden musste. In Anwendungen, wo die Daten stets zur Verfügung stehen müssen,
sind die Ausfallzeiten dadurch aber zu hoch. Deshalb bemühen sich die Hersteller
zunehmend die Parameter Online-konfigurierbar zu implementieren.
Von den genannten 66 Parametern erfordern nur 14 einen Neustart, entweder der Instanz oder
des gesamten Systems. Wiederum 6 von der Gesamtanzahl sind selbst konfigurierend.
Tabelle 2 gibt einen Überblick über diese Parameter (RR = Neustart des Systems
erforderlich, SC = Selbstkonfigurierende Option).
Parameter (Option)
Minimalwert
Maximalwert
Defaultwert
index create memory (SC)
704
2147483647
0
locks (RR, SC)
5000
2147483647
0
max server memory (SC)
16
2147483647
2147483647
min server memory (SC)
0
2147483647
8
recovery interval (SC)
0
32767
0
user connections (RR, SC)
0
32767
0
Tabelle 2: Selbstkonfigurierbare Parameter
2
http://msdn2.microsoft.com/de-de/library/ms189631.aspx
3
Zwei der angegebenen Parameter sind selbstkonfigurierbar und benötigen einen Neustart. Der
Administrator legt in diesem Fall einen Maximalwert fest wodurch das Intervall für die
automatische Anpassung eingeschränkt wird. Auf den ersten Blick erscheint dieses Vorgehen
unverständlich. Es macht jedoch Sinn, wenn man daran denkt, dass ein Computer durch die
verwendete Hardware gewisse Grenzen besitzt. Ein Datenbankadministrator kann zum
Beispiel bestimmen, wieviel Speicher dem System mindestens und dem
Datenbankmanagementsystem maximal (max server memory) zur Verfügung stehen soll.
Innerhalb dieser Grenze kann der SQL Server den Speicher autonom allokieren und wieder
frei geben.
Der folgende Abschnitt geht auf das bereits angesprochene dynamische Speichermanagement
genauer ein.
2.2 Dynamisches Speichermanagement in der Relationalen Engine
Zur Selbst-Konfiguration gehören nicht nur Parameter. Auch autonomes
Speichermanagement spielt eine wichtige Rolle. Damit einem System immer wieder Speicher
zur Verfügung steht muss dieser nach fertigen Aktionen freigegeben werden.
Der SQL Server allokiert in der Grundeinstellung soviel Speicher wie er für sich benötigt.
Einschränkungen dabei ergeben Konfigurationsparameter wie zum Beispiel max server
memory oder das Betriebssystem. Der vorhandene Speicher wird zum Beispiel für Buffer
Pools verwendet. Sie sind unter anderem dafür verantwortlich teure Festplattenzugriffe zu
vermeiden und werden ausschließlich von SQL Server internen Objekten verwendet. Objekte
außerhalb des Serverprozesses machen keinen Gebrauch von den Buffer Pools.
Startet nun der SQL Server reserviert er sich genau den Speicher, den er insgesamt benötigt,
schafft sich davon, wie bereits erwähnt, nur soviel an, wie er gerade braucht. Während seiner
Laufzeit passt er die allokierte Menge immer wieder an, je nach Bedarf. Wie bereits erwähnt
wird immer darauf geachtet, dass das Betriebssystem in keine Engpässe gerät. Startet also ein
Anwendungsprogramm wird Speicher freigegeben und Daten werden auf Festplatte
ausgelagert. Beendet sich dieses Programm kann der SQL Server den schnelleren
Hauptspeicher bei Bedarf wieder verwenden um ausgelagerte Elemente zurück zu holen.
Eine Neuerung in Version 2005 ist, das Buffer Pools ihren Speicher durch die Adress
Windowing Extension (AWE) erweitern können. Dies ist eine Technik der 32-Bit
Serverbetriebssysteme (Microsoft Windows 2003, Longhorn Server) womit es möglich ist die
theoretisch maximale Grenze von 4 GB für Hauptspeicher zu überwinden.
4
64 GByte
2-3 GByte
AWE Window
AWE Memory
Mapping
Abbildung 1: Funktion der Adress Windowing Extension (AWE)
Abbildung 1 zeigt das Prinzip dieser Erweiterung. In einem 32-Bit Windowssystem stehen
von den maximal 4 GB Hauptspeicher den Anwendungen 2 GB (3 GB wenn das
Betriebssystem mit der Option /3GB geladen wird) zur Verfügung. Den Rest reserviert sich
das System. Durch AWE ist es nun möglich diesen Speicher auf maximal 64 GB zu mappen,
was Anwendungen wie dem SQL Server zu Gute kommt. Buffer Pools können nun,
abgesehen von den anderen Objekten, die Speicher benötigen, bis zu 64 GByte für sich
beanspruchen und dynamisch verwalten.
2.3 Selbst-Optimierung des Query Prozessors
Der Query Prozessor bearbeitet Anfragen und optimiert diese um die Ausführungszeit zu
minimieren. Dies kann durch Statistiken unterstützt werden.
Viele Datenbankmanagementsysteme verwenden Histogramme zur Anfrageoptimierung. Ein
Histogramm stellt die Häufigkeitsverteilung von Messwerten dar. Abbildung 2 enthält ein
Beispiel. In diesem wird eine SFW-Anfrage mit verschiedenen Bedingungen und deren
Ergebnisse aufgetragen. Es ist dabei nicht wichtig, dass der gesamte Wertebereich abgedeckt
wird.
5
Gehalt von Mitarbeitern einer Firma
60
50
40
30
SELECT count(*) FROM
A
n
g
e
s
t
W
H
E
R
E
G
e
h
a
l
t
…
20
10
0
< 1000
> 1500
< 2000
> 2010
< 2050
> 3000
Abbildung 2: Beispiel für ein Histogramm
Aus dem Histogramm ist erkennbar, dass es zum Beispiel eine Anfrage über die Anzahl der
Gehälter größer 3000 gab. Sollte diese Anfrage noch einmal kommen hat der Optimizer
bereits einen quantitativen Anhaltspunkt über das Ergebnis. Dies kann zum Beispiel für die
Größe des Sperrgranulates von Bedeutung sein. Wenn die Angest-Tabelle 115 Tupel
beinhaltet, so könnte der Optimizer entscheiden die ganze Tabelle zu sperren. Bei mehreren
tausend Einträgen jedoch würde es ausreichen einzelne Seiten zu sperren.
Kommerzielle Datenbankprodukte verwenden, wie bereits erwähnt, für Statistiken und zur
Query Optimierung unter anderem Histogramme. Sie bringen allerdings ein
Performanceproblem wegen zu aufwendiger Algorithmen und dem damit verbundenen
Zeitaufwand mit sich. Da sich eindimensionale Histogramme nur auf ein Attribut einer
Relation beziehen, müssten für aussagekräftigere Statistiken mehrdimensionale Histogramme
verwendet werden. Dadurch können mehrere Attribute einer Relation zusammen und in
Abhängigkeit voneinader eingebracht werden. Wegen der zu großen Performanceprobleme
gibt es aber kaum einen Datenbankadministrator welcher diese trotz Implementierung
verwendet. Um diesem Problem entgegen zu wirken gibt es im SQL Server 2005 eine neue
Art Histogramme. Die sogenannten Self-Tuning Histogramme (ST-Histogramme) [AC99]
sind selbst für den mehrdimensionalen Fall in Erstellung und Wartung schnell genug. Es gibt
drei Operationen, welche immer wieder anfallen und entsprechend schnell bearbeitet werden
müssen. (1) Die Erstellung des Histogramms, (2) Verfeinern der Messwerte (refining of
frequencies) und (3) Restrukturierung der Messwertintervalle. Im folgenden werden diese
jeweils für eindimensionale und mehrdimensionale ST-Histogramme erläutert.
6
Eindimensionaler Fall: Eine Dimension bedeutet das Histogramm wird auf einem Attribut
(Spalte einer Tabelle) erstellt. Zum Erstellen wird die Anzahl der Tupel T, ein geschätztes
Intervall [min,max] für den Wertebereich und die Größe der Buckets B (ein Bucket ist ein
Intervall aus dem [min,max] Bereich) benötigt. Um falsche Schätzungen zu vermeiden, kann
der Wertebereich des Datentyps verwendet werden. Bei Integer zum Beispiel
[0,4.294.967.295]. Die Bucketgröße wird gleichmäßig zwischen min und max aufgeteilt und
die Messwerte werden auf T/B als Startwert gesetzt.
Merge
Split
Messwerte /
Tupelanzahl
10
13
17
14
70
20
Buckets
1
2
3
4
5
6
35 35
20
Messwerte /
Tupelanzahl
23
17
14
Buckets
1
2
3
4
5
6
Abbildung 3: Rekonstruierung eines eindimensionalen ST-Histogramms
Während die Verfeinerung der Messwerte durch eine einfache Fehlerabschätzung
funktioniert, dass heißt es wird der absolute Fehler bestimmt um die Buckets danach
anzupassen, werden bei der Restrukturierung zusätzliche Werte benötigt. Zum einen wird
eine Kennzahl für den Abstand zweier benachbarter Messwerte benötigt. Diese ergibt sich
aus einem frei gewählten Prozentsatz m (
m
e
i
s
t
≤
1
%
)
u
n
d
d
e
r
A
n
z
a
h
l
d
e
r
T
u
p
e
l
T insgesamt.
Dann werden die benachbarten Buckets gesucht deren Messwerte ≤
m
*
T
sind. Abbildung 3
zeigt ein solches Beispiel. Für dieses wurde der Wert m * T = 3 gewählt. Daraus ergeben sich
nur die Buckets 1 und 2. Alle so entstandenen Mengen werden zusammengenommen.
Die Anzahl der Buckets vor und nach der Aktualisierung muss gleich sein. Daraus folgt, das
einige geteilt werden müssen. Die Anzahl derer wird über eine Kennzahl bestimmt. Für das
Beispiel sei diese k = 1. Die k größten Buckets werden zueinander ins Verhältnis gesetzt.
𝑥
𝑦
𝑙
=𝑠
;
𝑙
=𝑠
; …
𝑥
𝑦
𝑥
+𝑦
+⋯ 𝑦
+𝑥
+⋯
 𝑥
,𝑦
,…
sind die Messwerte der k größten Buckets
 𝑙
ist die Anzahl der durch den Mergeschritt fehlenden Buckets
 𝑠
,𝑠
,…
sind die Verhältnisse für die Aufteilung (Bucket mit Messwert x muss in
𝑥
𝑦
𝑠
+ 1 Buckets aufgeteilt werden)
𝑥
Im Beispiel gibt es nur einen Splitbucket wodurch 𝑠
= 1 ist. Das heißt er wird geteilt.
𝑥
7
Mehrdimensionaler Fall: Die existierenden eindimensionalen Histogramme können als
Ausgangspunkt gewählt werden. Sie werden nun in einer n-dimensionalen Tabelle
angeordnet, wie in Abbildung 4 für n=2 zu sehen. Die Anpassung der Werte geschieht wie
bei dem eindimensionalen Fall anhand von Fehlerabschätzungen, mit dem Unterschied, dass
die Buckets nun mehrdimensionale Intervalle abdecken.
Σ
200
Σ 50
Σ 60
65 –
10 = 55
14 –
10 = 4
65
Farbskala mit Bereich
von kleinstem zum
größten Wert der
oberen Tabelle
0
Abbildung 4: Rekonstruierung eines mehrdimensionalen ST-Histogramms
Bei der Restrukturierung werden wieder Kennzahlen für den Merge- und den Splitschritt
angegeben. Für erstere wird der größte Abstand zwischen zwei benachbarten Zeilen, auch
Partitionen genannt, bestimmt. Liegt das Ergebnis unter der Mergekennzahl, so werden die
beiden Partitionen zusammen gerechnet. Für das Splitten wird die Summe aller Messwerte
einer Partition bestimmt. Diejenige mit dem größten Ergebnis wird geteilt.
Abbildung 4 veranschaulicht ein Beispiel. Für eine Mergekennzahl der Größe 5 gibt es nur
eine Kombination von Spalten deren größte Differenz darunter liegt (2 und 3). Diese beiden
werden zusammen gerechnet. Die erste Partition ist diejenige mit der größten Summe der
einzelnen Messwerte. Bei einer Splitkennzahl der Größe 1 wird nur diese geteilt. Das
Ergebnis der Restrukturierung zeigt die untere Tabelle. Man kann sehen, dass die
Werteverteilung harmonischer ist.
Verwendung im SQL Server 2005: Die Verwendung von ST-Histogrammen im SQL
Server 2005 zeigt Abbildung 5. Es gibt zwei Wege über welche der Query Optimizer diese
Statistiken nutzen kann.
 Online: Nachdem von der Query Engine ein optimierter Zugriffspfad erstellt wurde
wird die SFW-Anfrage ausgeführt. Das Ergebnis ist die Anzahl der Tupel für das
Intervall, welches durch die WHERE-Klausel begrenzt wurde. Das ST-Histogramm
bekommt dadurch kostenlose Messwerte. Dieser werden während der Laufzeit
eingearbeitet, so dass der Optimizer auf ein aktuelles Histogramm zurückgreifen
kann.
8
Abbildung 5: Tuning mit Hilfe von ST-Histogrammen
 Offline: In diesem Fall werden die Messwerte nicht sofort an das ST-Histogramm
übergeben. In einer Workload-Datenbank werden sowohl die Anfragen als auch
deren Ergebnisse gespeichert. Zu einem vom Administrator festgelegten Zeitpunkt
werden diese abgearbeitet wodurch der laufende Betrieb bei einem günstigen
Zeitpunkt weniger behindert wird. Dadurch ist auch möglich das System zu tunen,
wenn das Datenbankmanagementsystem selbst offline ist.
2.4 Selbst-Tuning der Storage Engine
Die Storage Engine ist unter anderem für Nebenläufigkeit, Buffering, Recovery und Memory
Management zuständig. Während auf letzeres bereits Abschnitt 2.2 näher eingegangen ist,
behandelt der folgende Text Ressourcen-Optimierungsstrategien.
Ressourcen sind zum Beispiel vom System zur Verfügung gestellter Hauptspeicher und
Festplattenspeicher. Bevor sie genutzt werden, kann die Storage Engine in Bezug auf SelbstTuning zuerst auf die zugehörige Operation und die Verfügbarkeit der Ressource schauen,
um einen optimierten Speicherplan bereit zu stellen. Dazu gehört zum Beispiel die
automatische Bestimmung des Lockgranulats.
3 Database Tuning Advisor
Der DTA ist ein, im SQL Server 2005, neu hinzu gekommenes Werkzeug für das Tuning
eines Datenbankmanagementssystems. Wie bereits in Kapitel 1 beschrieben dient er zur
integrierten Erstellung von physischen Datenbankdesigns. Im Laufe dieses Abschnitts wird
die Architektur näher erläutert und Statistiken werden die Verbesserung gegenüber dem
Vorgänger (ITW) darstellen.
9
Databases
Workload
Storage, Time,
Managability
DB-Admin
Tools,
Applications
XML-Input
Column Group
Restriction
Candidate
Selection
Microsoft SQL Server
2005
Query
Optimizer
Merging
Enumeration
Physical
XML-Output
Design
Recommend
ation
Abbildung 6: Architektur des Database Tunging Advisors
Abbildung 6 gibt einen Überblick über die Architektur und deren Zusammenarbeit mit dem
Query Optimizer des SQL Servers. Der Kreislauf bringt das sogenannte Iterative Tuning mit
sich. Das gleiche Prinzip wurde bereits bei ST-Histogrammen verwendet. Die Tuningaktion
erzeugt ein Ergebnis, welches für einen erneuten Durchlauf zur Optimierung verwendet
werden kann. Bei diesem Kreislauf gibt es keine Beschränkung auf ein physisches
Designfeature. Er ist also sehr leicht erweiterbar, da sich verschiedenste physische
Designfeatures auf die vier Teile abbilden lassen.
Bevor auf die einzelnen Schritte genauer eingegangen wird, muss das Kostenmodell erläutert
werden. Das heißt wonach entscheidet der DTA welcher Entwurf kostengünstig ist, denn für
einen optimalen Wert sollten mehrere Vorschläge vorliegen aus welchem der beste gewählt
w
i
r
d
.
D
a
s
K
o
s
t
e
n
m
o
d
e
l
l
b
a
s
i
e
r
t
a
u
f
d
e
r
„
w
h
a
t
-i
f
“
-Analyse [CN98]. Das heisst, was passiert
wenn genau ein Parameter um einen bestimmten Wert verändert wird. Damit ist es möglich
horizontale Partitionierung, Indexe und materialisierte Sichten zu simulieren. Also werden
verschiedene Konfigurationen getestet und die billigste wird ausgewählt.
Beispiel: Gegeben sind eine Query Q und zwei Konfiguration C1 und C2. Q wird auf sowohl
auf C1 als auch auf C2 simuliert. Gilt nun 𝑡
(𝐶
𝑡
(𝐶
1) ≤
2 ) (t ist Ausführungszeit), so
wird die Konfiguration C1 gewählt.
Im folgenden werden die einzelnen Schritte des Iterative Tuning erklärt.
10
 Column Group Restriction: Eine Reduzierung auf relevante Spaltengruppen ist
wichtig, weil die Erstellung von horizontal partitionierten Tabellen, Idexen und
materialisierten Sichten selbst als Performancekritisch anzusehen ist. Durch die
Reduzierung werden ausschließlich die Spalten gewählt, welche für den Workload
relevant sind.
 Candidate Selection: A
u
s
d
e
r
M
e
n
g
e
d
e
r
„
i
n
t
e
r
e
s
s
a
n
t
e
n
“
S
p
a
l
t
e
n
d
e
s
V
o
r
s
c
h
r
i
t
t
e
s
werden nun Kandidaten anhand des beschriebenen Kostenmodells gewählt. In
diesem Schritt simuliert der DTA also zusammen mit dem Query Optimizer
verschiedene Konfigurationen und wählt die Kandidaten, also diejenigen, die in
einer bestimmten Zeit liegen aus.
 Merging: Die bisher gewählten Kandidaten beruhen auf jeweils einer Query aus
dem Workload. Nun werden diese Kandidaten zusammen geführt, sodass sie für die
gesamten Eingabedaten eine optimale Konfiguration ergeben (wobei nicht
ausgeschlossen wird, dass es mehrere sehr gute Konfigurationen gibt).
 Enumeration: Der letzte Schritt zählt alle Kandidaten in einer Liste auf. Sowohl
diejenigen aus dem Candidate Selection-Schritt als auch aus dem Merging-Schritt.
Trotzdem bleibt nun die Frage nach der Performance. Die ganzen Kostenberechnungen und
Simulationen benötigen ebenfalls Zeit und beanspruchen den Datenbankserver durch die
Zusammenarbeit mit dem Query Optimizer. Um diesem Problem aus dem Weg zu gehen
können die Daten auf einen zweiten Server überspielt werden auf welchem dann der DTA
arbeitet. Das kopieren der gesamten Datenbank ist jedoch selbst sehr Performancekritisch.
Vor allem wenn diese sehr groß4 ist.
Production Server
Test Server
Import metadata
and statistics
Create statistics
Perform Tuning
DTA
DTA recommendations
Abbildung 7: Verbesserung der Skalierbarkeit durch Verwendung eines Testservers
4
Unter http://www.wintercorp.com/vldb/2003_TopTen_Survey/TopTenWinners.asp kann die Liste der größten
Datenbanken angezeigt werden
11
Zur besseren Skalierbarkeit bietet der SQL Server eine weitere Möglichkeit. Anstatt alle
Daten zu nehmen, werden ausschließlich Metadaten kopiert. Dazu gehören zum Beispiel das
Datenbankschema, Trigger und Stored Procedures, aber auch Statistiken. Diese
Informationen reichen aus, um auf dem Testserver die Konfigurationen zu testen. Dadurch
wird der Produktionsserver entlastet und der DTA kann arbeiten ohne die Performance stark
zu beeinflussen. Abbildung 7 gibt einen Überblick über die Skalierung durch Verwendung
eines Produktions- und eines Testservers mit der beschriebenen Methode. Zur besseren
Kompatibilität ist es ebenfalls möglich Hardware des Produktionsservers zu simulieren.
4 Statistiken und Performancemessungen
Erwartete Verbesserung
für den Workload
Gegenüber dem aus den Vorgängerversionen bekannte ITW liefert der DTA qualitativ höhere
Erwartungswerte für einen Performanceanstieg. Abbildung 8 zeigt den Vergleich beider
Werkzeuge und deren erwarte Verbesserung für den Workload. Als Benchmarks wurden im
einzelnen (1) TCPH225, die ersten 22 Querys des TPC-H Benchmarks, (2) PSOFT, eine
Customerdatenbank mit ungefähr 6000 inserts, deletes und updates, und (3) SYNT1, eine
synthetische Datenbank, welche mit dem SetQuery Benchmarkschema übereinstimmt. Bei
allen liegt der DTA erkennbar vor dem ITW.
100%
95%
90%
85%
80%
75%
TPCH22
PSOFT
SYNT1
Workload
DTA Quality
SS2K ITW Quality
Abbildung 8: Erwartete prozentuale Verbesserung des DTA im Vergleich zum ITW
Abbildung 9 zeigt die Einsparung der Laufzeit bei den Benchmarks des DTA gegenüber dem
ITW. Auch hier ist zu erkennen, dass der DTA teilweise sehr deutlich vorne liegt, das heißt,
dass die physischen Designentscheidungen performanter sind.
5
http://www.tpc.org/tpch/
12
Reduction in running time
100%
80%
60%
40%
20%
0%
TPCH22
PSOFT
SYNT1
Workload
Reduction in running time
Abbildung 9: Verbesserung der Laufzeit durch Tuning mit dem DTA gegenüber dem ITW
5 Fazit
Auch Microsoft beschäftigt sich mit dem Thema Autonomic Computing. Es gibt bereits
einige Implementierungen die bereits seit Version 7.0 implementiert sind und bis zur
aktuellen Version erweitert und verbessert wurden. Die Forschungen beschränken sich vor
allem auf das physische Datenbankdesign. Das dazugehörige Vorzweigewerkzeug ist der
DTA, welcher mit Version 2005 eingeführt wurde. Aufgrund der positiven
Benchmarkergebnisse wird in dieser Richtung wohl auch in Zukunft weiter geforscht.
Literaturverzeichnis
[AC99]
Aboulnaga, A. and Chaudhuri, S., Self-Tuning Histograms: Building Histograms Without
Looking at Data. Proceedings of ACM SIGMOD, Philadelphia, 1999.
[ACN99] Agrawal S., Chaudhuri S., Kollar L., and Narasayya V. Index Tuning Wizard for Microsoft
SQL Server 2000.
[AC04] Agrawal S., Chaudhuri S., Kollar L., Marathe A., Narasayya V., and Syamala M., Database
Tuning Advisor for Microsoft SQL Server 2005. Proceedings of the 30th International
Conference on Very Large Databases (VLDB04), Toronto, Canada, 2004.
[BC07] Bruno N. and Chaudhuri S. , An Online Approach to Physical Design Tuning. Proceedings of
the 2007 ICDE Conference.
[CC99] Surajit Chaudhuri, Eric Christensen, Goetz Graefe, Vivek Narasayya, and Michael Zwilling,
Self Tuning Technology in Microsoft SQL Server. Data Engineering Vol. 22 No. 2, 1999
[CN98] Chaudhuri, S. and Narasayya V., AutoAdmin "What-If" Index Analysis Utility. Proceedings
of ACM SIGMOD, Seattle, 1998.
13