Datenbankentwicklung mit dem Microsoft SQL Server 2005

Holger Schmeling Datenbankentwicklung mit dem Microsoft SQL Server 2005 ISBN-10: 3-446-22532-3 ISBN-13: 978-3-446-22532-9 Inhaltsverzeichnis Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-22532-9 sowie im Buchhandel

Inhalt 1 Einleitung... 1 1.1 Was vermittelt dieses Buch?... 1 1.2 Für wen ist dieses Buch?... 2 1.3 Wo finde ich was?... 3 1.4 Welche Voraussetzungen werden benötigt?... 5 1.5 Danksagung... 6 2 SQL Server 2005-Architektur... 9 2.1 SQL Server 2005-Komponenten... 9 2.1.1 Das SQL Server-Datenbankmodul... 10 2.1.2 SQL Server Replication Services... 12 2.1.3 SQL Server Notification Services... 12 2.1.4 SQL Server Reporting Services... 12 2.1.5 SQL Server Analysis Services... 13 2.1.6 SQL Server Integration Services... 13 2.1.7 Verwaltungswerkzeuge... 14 2.1.8 Entwicklungswerkzeuge... 14 2.1.9 Der SQL Server Agent... 14 2.2 SQL Server-Editionen... 15 2.3 Systemdatenbanken...16 2.3.1 Die master-datenbank... 16 2.3.2 Die model-datenbank... 16 2.3.3 Die msdb-datenbank... 17 2.3.4 Die tempdb-datenbank... 17 2.3.5 Weitere Datenbanken... 17 2.4 Die Struktur einer SQL Server-Datenbank... 18 2.4.1 Datenbanken... 19 2.4.2 Datenbankobjekte... 19 2.5 Zusammenfassung...21 VII

Inhalt 3 SQL Server-Verwaltungswerkzeuge... 23 3.1 SQL Server-Konfigurations-Manager...24 3.2 SQL Server-Oberflächenkonfiguration...25 3.3 SQL Server Management Studio...27 3.3.1 Start und Anmeldung...27 3.3.2 Bereiche des Hauptfensters...30 3.3.3 Datenbankprojekte erstellen...47 3.4 Business Intelligence Development Studio...51 3.5 SQL Server Profiler...52 3.6 Datenbankmodul-Optimierungsratgeber...58 3.7 Sqlcmd...61 3.8 SQL Server-Onlinedokumentation...63 3.9 Zusammenfassung...64 4 Transact SQL-Grundlagen... 65 4.1 Das Relationenmodell...66 4.2 SQL mit System...67 4.3 T-SQL-Stapel (Batches)...69 4.4 SQL-Datentypen...71 4.5 T-SQL-Ausdrücke und -Operatoren...76 4.6 Datenbanken verwalten...79 4.6.1 Datenbank erzeugen...79 4.6.2 Datenbank ändern...82 4.6.3 Datenbank löschen...84 4.7 Schemas verwenden...84 4.7.1 Namensauflösung...87 4.7.2 Synonyme...89 4.8 Tabellen entwerfen...90 4.8.1 Tabellen anlegen...90 4.8.2 Tabellen ändern...93 4.8.3 Identität/Primärschlüssel...95 4.8.4 Weitere Einschränkungen...98 4.8.5 Berechnete Spalten...102 4.8.6 Ein Wiedersehen mit CREATE TABLE...103 4.8.7 Beziehungen festlegen...104 4.8.8 Zusammenfassung zu Einschränkungen...107 4.8.9 Tabellen löschen...107 4.8.10 Datenbankdiagramme...108 4.8.11 Temporäre Tabellen...109 4.9 INSERT Daten einfügen...110 4.10 SELECT Daten abfragen...111 4.10.1 Filtern: Projektion und Selektion...115 4.11 Informationen ausgeben mit PRINT...122 4.12 Ausführen von gespeicherten Prozeduren...122 4.13 UPDATE Daten ändern...123 4.14 DELETE Daten löschen...125 VIII

Inhalt 4.15 SQL-Funktionen... 126 4.15.1 Systemfunktionen... 127 4.15.2 Konfigurationsfunktionen... 129 4.15.3 Metadatenfunktionen... 130 4.15.4 Numerische Funktionen... 132 4.15.5 Funktionen zur Zeichenkettenbearbeitung... 136 4.15.6 Konvertierungsfunktionen... 142 4.15.7 Datums- und Zeitfunktionen... 144 4.15.8 Sonstige Funktionen und Operatoren... 149 4.16 Die Beispieldatenbank AdventureWorks... 153 4.17 Sichten... 154 4.17.1 Ändern von Sichten... 156 4.17.2 Aktualisierung von Daten... 156 4.18 Daten einfügen mit SELECT... 158 4.18.1 INSERT und SELECT... 158 4.18.2 SELECT INTO... 158 4.19 Null... 159 4.19.1 Dreiwertige Logik... 160 4.19.2 Arithmetische Operationen... 163 4.19.3 Operationen mit Zeichenketten... 164 4.19.4 Hinweise für die Verwendung von NULL... 166 4.19.5 Spezielle Funktionen für NULL-Werte... 167 4.20 Fehlerbehandlung in T-SQL... 169 4.21 Komplexe Abfragen mit SELECT... 170 4.21.1 Mengenoperationen mit SQL... 170 4.21.2 Abfragen über mehrere Tabellen... 172 4.21.3 Aggregatfunktionen und GROUP BY... 179 4.21.4 Rangfolgefunktionen... 186 4.21.5 Korrelierende Unterabfragen... 191 4.21.6 Abgeleitete Tabellen... 192 4.21.7 Allgemeine Tabellenausdrücke... 193 4.21.8 PIVOT und UNPIVOT... 198 4.21.9 OUTPUT... 202 4.21.10 APPLY... 203 4.22 Zusammenfassung... 205 5 Transaktionen und Sperren... 207 5.1 Eigenschaften von Transaktionen... 207 5.2 Start und Ende einer Transaktion... 210 5.2.1 Transaktionsmodi des SQL Servers... 211 5.3 Sperren... 213 5.3.1 Sperrbare Ressourcen... 214 5.3.2 5.3.3 Sperrtypen... 217 Deadlocks... 219 5.4 Isolationsstufen... 224 5.4.1 READ UNCOMMITTED... 224 IX

Inhalt 5.4.2 READ COMMITTED...225 5.4.3 REPEATABLE READ...226 5.4.4 SNAPSHOT...227 5.4.5 SERIALIZABLE...228 5.4.6 Abschließende Betrachtungen zu Isolationsstufen...228 5.5 Sperren explizit anfordern Sperrhinweise...229 5.6 Das Transaktionsprotokoll...232 5.6.1 Abschneiden des Protokolls...233 5.6.2 Verhalten im Fehlerfall...234 5.7 Hinweise zur Verwendung von Transaktionen...234 5.8 Zusammenfassung...236 6 Administration für Datenbankentwickler... 237 6.1 Datensicherung und -wiederherstellung...237 6.1.1 6.1.2 Wiederherstellungsmodelle...240 Prüfen der Konsistenz einer Datenbank...242 6.1.3 Vollständige Datenbanksicherung...242 6.1.4 Sicherung des Transaktionsprotokolls...248 6.1.5 Sichern der Systemdatenbanken...251 6.2 Wiederherstellung von Datenbanken...252 6.2.1 Automatische Wiederherstellung bei Systemstart...255 6.2.2 Wiederherstellung der Systemdatenbanken...255 6.3 Zugriffskontrolle...256 6.3.1 SQL Server-Anmeldungen...257 6.3.2 Anmeldungen hinzufügen...259 6.3.3 Anmeldungen löschen...261 6.3.4 Berechtigungen vergeben...261 6.3.5 Vordefinierte Anmeldekonten...262 6.3.6 Datenbankbenutzer...263 6.3.7 Datenbankrollen...265 6.3.8 Rechte erteilen und entziehen...266 6.4 Überwachung von SQL Server...270 6.4.1 Was kann überwacht werden?...271 6.4.2 Überwachung mit dem SQL Server Management Studio...272 6.4.3 Überwachung mit dem SQL Server Profiler...276 6.4.4 Überwachung mit dem Windows-Systemmonitor...276 6.4.5 Verwendung von T-SQL zur Überwachung...277 6.5 Zusammenfassung...286 7 T-SQL-Programmierung... 287 7.1 Variablen...287 7.1.1 Deklaration von Variablen...287 7.1.2 Wertzuweisung an Variablen...288 7.1.3 Besondere Variablentypen...290 7.2 Dynamisches SQL...292 7.3 Ablaufsteuerung...293 X

Inhalt 7.3.1 Anweisungsblöcke... 293 7.3.2 Bedingte Ausführung von Anweisungen... 293 7.3.3 Wiederholte Ausführung von Anweisungen... 294 7.4 Cursor... 297 7.4.1 Cursor erzeugen... 297 7.4.2 Einen Cursor durchlaufen Daten abrufen... 300 7.4.3 Daten aktualisieren... 305 7.4.4 Hinweise zur Verwendung von Cursorn... 306 7.5 Gespeicherte Prozeduren... 306 7.5.1 Warum gespeicherte Prozeduren?... 307 7.5.2 Erstellung von gespeicherten Prozeduren... 307 7.5.3 Verwenden von Parametern... 311 7.5.4 Der Rückgabewert einer gespeicherten Prozedur... 314 7.5.5 Die gespeicherte Systemprozedur sp_procoption... 314 7.5.6 EXECUTE und INSERT... 316 7.5.7 Erweitertes Beispiel: PDF-Dateien einlesen... 317 7.6 Benutzerdefinierte Funktionen... 320 7.6.1 Skalarwertfunktionen... 320 7.6.2 Tabellenwertfunktionen... 323 7.7 Trigger... 325 7.7.1 DML-Trigger... 326 7.7.2 Hinweise zur Verwendung von Triggern... 332 7.7.3 DDL-Trigger... 333 7.8 Zusammenfassung... 338 8 XML-Integration... 339 8.1 Tabellen im XML-Format darstellen: FOR XML... 339 8.1.1 FOR XML RAW... 341 8.1.2 FOR XML AUTO... 342 8.1.3 FOR XML EXPLICIT... 344 8.1.4 FOR XML PATH... 352 8.1.5 FOR XML-Optionen... 355 8.1.6 Noch einmal FOR XML PATH... 358 8.2 XML-Daten in Tabellenform abbilden: OPENXML... 367 8.3 Der XML-Datentyp... 372 8.3.1 Ungetypte XML-Daten... 375 8.3.2 Getypte XML-Daten... 376 8.3.3 query... 379 8.3.4 exist... 382 8.3.5 value... 383 8.3.6 nodes... 384 8.3.7 modify... 388 8.4 8.3.8 XML-Indizes... 391 Zusammenfassung... 395 XI

Inhalt 9 SQL Server Service Broker... 397 9.1 Architektur...397 9.1.1 Service Oriented Architecture (SOA)...398 9.1.2 Service Broker-Kommunikation...399 9.1.3 Service Broker-Komponenten...401 9.2 Erstellung von Anwendungen...402 9.2.1 T-SQL-Kommandos für eine Service Broker-Kommunikation...402 9.2.2 Eine Service Broker-Beispielanwendung...403 9.2.3 Service Broker-Aktivierung...417 9.3 Überwachung von Server- und Datenbankobjekten...418 9.4 Zusammenfassung...421 10 Datenbankentwicklung mit.net... 423 10.1 SQL Server und die.net CLR...423 10.2 Sicherheitsaspekte...425 10.3 Assemblys...426 10.4 Der Namensraum Microsoft.SqlServer.Server...430 10.5 Datentypen der Namensraum System.Data.SqlTypes...431 10.6 Datenbankprojekte mit Visual Studio 2005 erstellen...431 10.6.1 Erstellen eines Datenbankprojektes...432 10.6.2 Erstellen von gespeicherten Prozeduren...434 10.6.3 Erstellen von benutzerdefinierten Funktionen...442 10.6.4 Erstellen benutzerdefinierter Typen...445 10.6.5 Erstellen von benutzerdefinierten Aggregaten...457 10.6.6 Erstellen von Triggern...460 10.6.7 Debuggen von CLR-Objekten...462 10.7 Noch einmal: Sicherheit...463 10.8 T-SQL oder.net?...467 10.9 Zusammenfassung...468 11 Web Services mit dem SQL Server... 469 11.1 Was sind Web Services?...469 11.2 SOAP-Endpunkte...470 11.2.1 Syntax zur Erstellung eines HTTP-Endpunktes...471 11.3 Reservierung von HTTP-Namensräumen...473 11.3.1 Implizite Reservierung...474 11.3.2 Explizite Reservierung...475 11.3.3 Löschen einer expliziten Reservierung...475 11.4 Aufbau der URL für einen Endpunkt...476 11.5 Einen Web Service erstellen und verwenden...476 11.5.1 Den AdWrksServicePoint-Endpunkt erzeugen...477 11.5.2 Sicherheitsaspekte...478 11.5.3 Den Web Service verwenden...481 11.6 Zusammenfassung...486 XII

Inhalt 12 Optimierung von Abfragen... 487 12.1 Die Speicherverwaltung von SQL Server... 488 12.2 Ausführung von Abfragen durch SQL Server... 489 12.3 Erstellen einer Testdatenbank... 490 12.4 Verwenden von Indizes... 491 12.4.1 Tabellen ohne Index Heap... 491 12.4.2 Gruppierte Indizes... 492 12.4.3 Nicht gruppierter Index auf einem Heap... 494 12.4.4 Nicht gruppierter Index auf einem gruppierten Index... 495 12.4.5 Erzeugen von Indizes... 497 12.4.6 Löschen von Indizes... 501 12.5 Messen der Leistung... 501 12.5.1 Messen mit der Stoppuhr... 502 12.5.2 Statistische Werte... 503 12.5.3 Ausführungspläne... 505 12.5.4 Der SQL Server Profiler... 511 12.5.5 Windows-Systemmonitor... 517 12.5.6 Verbindung von Ablaufverfolgung und Logfile... 518 12.6 Beispiele für die Optimierung... 521 12.7 Weitere Hinweise für Indizes... 528 12.7.1 Index-Selektivität... 528 12.7.2 Index-Fragmentierung... 529 12.7.3 Fehlende Indizes... 529 12.7.4 Nicht verwendete Indizes... 531 12.8 Der Datenbankmodul Optimierungsratgeber... 532 12.9 Tipps zur Abfrageoptimierung... 535 12.10 Zusammenfassung... 538 13 Anwendungen mit den Notification Services erstellen... 539 13.1 Einführung in SQL Server Notification Services... 539 13.2 Architektur... 540 13.3 Erstellen von Notification Services-Anwendungen... 543 13.4 Eine Notification Services-Beispielanwendung... 544 13.4.1 Instance Configuration File (ICF)... 544 13.4.2 Application Definition File (ADF)... 547 13.4.3 Erzeugen und Ausführen der NS-Anwendung... 554 13.4.4 Überprüfen der erzeugten NS-Datenbanken und -Objekte... 558 13.4.5 Erzeugen von Abonnements und Ereignissen... 559 13.5 Zusammenfassung... 572 Literatur... 573 Register... 575 XIII

Holger Schmeling Datenbankentwicklung mit dem Microsoft SQL Server 2005 ISBN-10: 3-446-22532-3 ISBN-13: 978-3-446-22532-9 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-22532-9 sowie im Buchhandel

12 Optimierung von Abfragen Mit den präsentierten Daten ergibt sich diese Zusammenfassung: Totale Abfragekosten: 0,008 Logische E-/A-Operationen: 8 Insgesamt wurden die Kosten für diese Abfrage also gegenüber der ursprünglichen Version um den Faktor 8500 gesenkt. Die erforderlichen Leseoperationen sind in der Endversion ca. 11500 Mal kleiner. 12.7 Weitere Hinweise für Indizes Im vorangegangenen Abschnitt haben Sie gesehen, wie immens wichtig Indizes für performante Abfragen sind. An dieser Stelle sollen einige weitere Aspekte, Indizes betreffend, untersucht werden. Zunächst einmal enthalten Indizes redundante Information, die für eine logische Funktionalität der Datenbank nicht erforderlich ist. Alle Abfragen funktionieren im Prinzip auch ohne Indizes, können dann aber eben erheblich langsamer sein. Mit der Speicherung redundanter Information sind stets Probleme verbunden. Indizes bilden hier keine Ausnahme. Zunächst einmal benötigen Indizes auch Speicherplatz auf der Festplatte. Wenn Spalten verändert werden, die in Indizes enthalten sind, so müssen außer den eigentlichen Tabellendaten auch die entsprechenden Indizes verändert werden. Für Aktualisierungsoperationen sind Indizes also in der Regel eher hinderlich. Es gibt Ausnahmen, nämlich dann, wenn ein Index verwendet werden kann, um für eine Aktualisierungs- oder Löschoperation die Suche der Zeilen zu unterstützen. Dies kann zum Beispiel der Fall sein, wenn Sie eine Abfrage der Form: update BestellKopf set Nr = '0815' where Nr = '4711' mit einem existierenden Index auf der Spalte Nr ausführen. Das Aktualisieren von Index-Spalten kann letztlich dazu führen, dass der Indexbaum nicht mehr ausbalanciert ist, also für unterschiedliche Suchpfade sehr unterschiedliche Tiefen aufweist. Dies kann sogar so weit gehen, dass der Index vom Optimierer nicht mehr verwendet wird. 12.7.1 Index-Selektivität Die Selektivität eines Index ist ein Kriterium, das der Optimierer für die Verwendung eines Index in Erwägung zieht. Nehmen Sie als Beispiel unsere Tabelle BestellPos und den Index auf der Spalte LiefNr. In unserem ersten Beispiel des vorigen Abschnitts haben wir für diese Spalte einen Index erzeugt, der in der Beispielabfrage dann auch verwendet wurde. Der Index wurde deswegen hergenommen, weil der Optimierer entschieden hat, dass die Abfrage hiervon profitiert. Wenn die Filterbedingung in der WHERE-Klausel so formuliert wird, dass sehr viele Zeilen zurückgegeben werden, dann kann ein Tabellen- 528

12.7 Weitere Hinweise für Indizes Scan unter Umständen performanter sein als die Suche über den Indexbaum mit einem anschließenden Lookup. Schauen Sie sich hierzu diese Abfrage an: select ProduktId from BestellPos where LiefNr > '2' Die Abfrage gibt insgesamt über 53000 Zeilen zurück. Obwohl ein Index für die Spalte LiefNr existiert, wird dieser nicht verwendet. Stattdessen wird ein Tabellen-Scan durchgeführt, wie Sie sich durch die Betrachtung des Ausführungsplanes überzeugen können. Ein Durchsuchen des Indexbaumes mit anschließendem Lookup wäre in diesem Fall einfach teurer gewesen als der Tabellen-Scan. Das gerade für die Index-Selektivität Gesagte gilt übrigens auch generell für die Anzahl von Zeilen in einer Tabelle. Stellen Sie sich diesen Extremfall vor: eine kleine Tabelle, die insgesamt in eine Datenseite passt. Diese Datenseite muss in jedem Fall gelesen werden, wenn Zeilen bzw. Spalten zurückgegeben werden sollen. Hier hilft ein Index also überhaupt nicht. Egal, was für einen Index Sie für diese Tabelle auch erzeugen, er wird in SELECT-Anweisungen immer ignoriert. Für Aktualisierungsoperationen allerdings gilt dies nicht! Der Index muss natürlich immer mit den Tabellendaten übereinstimmen. Also ist der Index nicht nur nutzlos, sondern sogar hinderlich. 12.7.2 Index-Fragmentierung Mit der Zeit kann ein Indexbaum entarten, wie bereits etwas weiter oben erläutert. Möglich ist auch, dass der Index im Laufe der Zeit fragmentiert wird, also auf der Festplatte nicht mehr zusammenhängend gespeichert wird. Dies kann natürlich immer dann, wenn die Indexdaten von der Festplatte gelesen werden, erheblichen Einfluss auf die Performanz haben. Daher sollten Sie Ihre Indizes in periodischen Abständen reorganisieren. Der Grad der Index-Fragmentierung kann durch die dynamische Verwaltungsfunktion sys.dm_db_index_physical_stats abgefragt werden. Diese Funktion haben wir bereits etwas weiter oben in diesem Kapitel verwendet, um die Anzahl der Stufen in einem Index abzufragen. Die Funktion gibt auch eine Spalte zurück, die den Grad der Fragmentierung eines Index anzeigt: avg_fragmentation_in_percent. Ist dieser Wert zu hoch, dann sollten Sie den Index reorganisieren. Es ist eine gute Idee, eine solche Reorganisation von Zeit zu Zeit durchzuführen. Hierzu existiert die Anweisung ALTER INDEX.. REORGANIZE, die so verwendet wird: alter index ix_bk_nr on BestellKopf reorganize 12.7.3 Fehlende Indizes Eine interessante Frage ist, wie man mitbekommt, dass durch Indizes eine Verbesserung der Abfrageleistung erzielt werden kann. In unseren obigen Beispielen haben wir dies manuell durch die Untersuchung von Ausführungsplänen erledigt. 529

12 Optimierung von Abfragen Der Abfrageoptimierer von SQL Server verfügt für diesen Zweck über ein fantastisches Feature: Er informiert im Ausführungsplan über fehlende Indizes und sogar über die erwartete Verbesserung der Abfrageleistung bei Verwendung eines entsprechenden Index. Wir wollen uns dies an einem Beispiel ansehen. Zunächst einmal sollen dafür die existierenden Indizes auf allen Tabellen der Datenbank AWPerformance gelöscht werden. Dies wird durch das folgende Skript erledigt: use AWPerformance declare @cmd varchar(max) select @cmd=isnull(@cmd + ';','') + 'drop index '+name + ' on ' + object_name(object_id) from sys.indexes where name like 'ix%' and object_name(object_id) in ('BestellPos','BestellKopf') exec (@cmd) Anschließend soll nun der XML-Ausführungsplan für eine Abfrage erzeugt werden. Die Informationen über fehlende Indizes sind nur im XML-Ausführungsplan enthalten. Im bislang meist verwendeten grafischen Ausführungsplan finden Sie diese Informationen nicht. Hier ist das Skript für dieses Experiment: set showplan_xml on go select Preis * Menge from BestellPos where LiefNr = '8E3A-4564-99' go set showplan_xml off go Der erzeugte Ausführungsplan enthält tatsächlich eine Sektion <MissingIndexes>, wie das folgende Listing zeigt: <MissingIndexes> <MissingIndexGroup Impact="99.9521"> <MissingIndex Database="[AWPerformance]" Schema="[dbo]" Table="[BestellPos]"> <ColumnGroup Usage="EQUALITY"> <Column Name="[LiefNr]" ColumnId="3" /> </ColumnGroup> <ColumnGroup Usage="INCLUDE"> <Column Name="[Preis]" ColumnId="5" /> <Column Name="[Menge]" ColumnId="6" /> </ColumnGroup> </MissingIndex> </MissingIndexGroup> </MissingIndexes> Die in dieser Sektion enthaltenen Informationen können leicht verwendet werden, um zu entscheiden, ob ein entsprechender Index erstellt werden sollte. Im präsentierten Beispiel kann diese Frage sicherlich mit einem klaren Ja beantwortet werden, da eine Verbesserung der Abfrageleistung um über 99% prognostiziert wird. Das entsprechende CREATE INDEX-Kommando sieht dann so aus: create nonclustered index IX_BP_LiefNr on BestellPos(LiefNr) include Preis,Menge Da SQL Server eine Ablaufhistorie über dynamische Verwaltungssichten bzw. -funktionen zur Verfügung stellt, sind Sie nicht einmal darauf angewiesen, für interessierende Abfra- 530

12.7 Weitere Hinweise für Indizes gen den XML-Ausführungsplan anzuzeigen, so wie oben geschehen. Es ist tatsächlich möglich, auch im Nachhinein abzufragen, in welchen Fällen der Optimierer Indizes vermisst hat. Dadurch können Sie periodisch überprüfen, ob sich das Hinzufügen von Indizes lohnen würde. Dies kann zum Beispiel durch die dynamische Verwaltungssicht sys.dm_db_missing_index_details geschehen, die detaillierte Informationen über fehlende Indizes zurückgibt: select * from sys.dm_db_missing_index_details Das Ergebnis sieht zum Beispiel so aus: Weiter oben haben wir bereits gespeicherte Ausführungspläne verwendet, die im Prozedurcache gespeichert sind. Diese Pläne können über die dynamischen Verwaltungssicht sys.dm_exec_cached_plans abgefragt werden. Selbstverständlich enthalten diese Pläne auch die Informationen über fehlende Indizes, also entsprechende <MissingIndexes>- Sektionen. Mit den in Kapitel 8 erworbenen Kenntnissen über XQuery können wir die folgende Abfrage formulieren, um Abfragepläne zu erhalten, in denen fehlende Indizes beanstandet werden: with MI_Plan(XmlPlan) as ( select p.query_plan from sys.dm_exec_cached_plans cross apply sys.dm_exec_query_plan(plan_handle) as p where p.query_plan.exist( 'declare namespace mi="http://schemas.microsoft.com/sqlserver/2004/07/showplan"; //mi:missingindexes')=1 ) select c.query('.') as MissingIndexInfo from MI_Plan cross apply XmlPlan.nodes( 'declare namespace mi="http://schemas.microsoft.com/sqlserver/2004/07/showplan"; //mi:missingindex') as mi(c) Diese Abfrage gibt als Ergebnis die <MissingIndex>-Sektionen zurück, enthält also Informationen über alle vom Optimierer vermissten Indizes. 12.7.4 Nicht verwendete Indizes Zum Schluss unserer Betrachtungen zur Optimierung durch Indizes soll nun noch eine weitere dynamische Verwaltungssicht erwähnt werden: sys.dm_db_index_usage_stats. Diese Sicht gibt Auskunft über die Verwendung von Indizes im Rahmen von Such- und Aktualisierungsoperationen. Insbesondere können Sie diese Sicht verwenden, um herauszufinden, ob Indizes überhaupt verwendet werden. Nicht oder nur für Aktualisierungen verwendete Indizes sind natürlich nicht von Nutzen. Die folgende Abfrage liefert Daten zu allen Indizes der Datenbank AWPerformance, die seit dem letzten Start von SQL Server nicht verwendet wurden: 531

12 Optimierung von Abfragen select object_name(object_id) as Tabelle,i.name as [Index] from sys.indexes i where i.index_id not in (select s.index_id from sys.dm_db_index_usage_stats s where s.object_id = i.object_id and i.index_id=s.index_id and database_id=db_id('awperformance')) order by object_name(object_id) Seien Sie aber bitte vorsichtig bei der Auswertung des Ergebnisses. Immerhin ist es möglich, dass Indizes zurückgegeben werden, die sehr wohl Verwendung finden, die eben nur nicht seit dem letzten SQL Server-Start benötigt wurden. Außerdem filtert die obige Abfrage nicht diejenigen Indizes heraus, die lediglich für Aktualisierungen verwendet wurden. Auch diese sind ja nicht erforderlich. Probieren Sie es doch einmal aus, auch diese Indizes durch die Abfrage zurückzugeben. Hierzu müssen Sie die Spalte update der Sicht sys.dm_db_index_usage_stats berücksichtigen. tras/datenbankmodul-optimierungsratgeber des Management Studios. 532

12.9 Tipps zur Abfrageoptimierung Abbildung 12.26 Ergebnis der Analyse 12.9 Tipps zur Abfrageoptimierung Zum Abschluss folgen noch einmal eine Zusammenfassung und Ergänzung der Ratschläge für eine Verbesserung der Leistung Ihrer Abfragen. SQL Server bietet mittlerweile großartige Unterstützung für die Abfrageoptimierung an. Verwenden Sie die vorhandenen Möglichkeiten und Werkzeuge unbedingt, aber verstehen Sie sie als Unterstützung für eine Entscheidungsfindung. Denken Sie bitte daran, dass das menschliche Gehirn durch Software unterstützt, aber nicht ersetzt werden kann. Ansonsten würde ich dieses Buch nicht schreiben, und Sie bräuchten es nicht zu lesen. Geben Sie in einer SELECT-Anweisung nur die benötigten Spalten zurück Die Verwendung von * zur Rückgabe aller Spalten ist eine bequeme Möglichkeit, die den Vorteil hat, dass bei Änderungen der Tabellenstruktur die Ausgabe automatisch angepasst wird. Sie erkaufen diesen Vorteil allerdings mit erheblichen Nachteilen: Die Benutzung von abdeckenden Indizes ist nicht möglich. Dadurch ist in der Regel immer ein zusätzlicher Lookup erforderlich, der unter Umständen eine entscheidende Verschlechterung des Laufzeitverhaltens zur Folge hat. 535

12 Optimierung von Abfragen Zur Laufzeit der Abfrage muss zunächst auch eine Abfrage der Metadaten erfolgen, welche die Spalten der Tabellen bzw. Sichten ermittelt. Dadurch wird die Leistung der Abfrage natürlich negativ beeinträchtigt. Dir Rückgabe nicht benötigter Daten kann die Netzwerklast enorm erhöhen. Nehmen Sie nur einmal an, dass die folgende Anweisung innerhalb einer gespeicherten Prozedur ausgeführt wird: select * from Rechnung where RgNr = @nr Wenn Sie der Tabelle Rechnung nun eine Spalte vom Typ VARCHAR(MAX) hinzufügen, in der jede Rechnung nochmals im PDF-Format abgelegt wird, so kann die obige Abfrage ganz automatisch um Größenordnungen langsamer sein. Probieren Sie verschiedene Varianten aus Experimentieren Sie! Bei komplexen Abfragen gibt es immer unterschiedliche Möglichkeiten, zum Ziel zu kommen. Probieren Sie verschiedene Möglichkeiten aus, und benutzen Sie hierzu auch die Ihnen zur Verfügung stehenden Ressourcen, wie zum Beispiel Ihre Kollegen oder News Groups. Sie haben in diesem Kapitel gesehen, wie Sie die Leistung von Abfragen messen können, und sind dadurch in der Lage, die unterschiedlichen Varianten einer Bewertung zu unterziehen. Nutzen Sie diese Möglichkeit zum Vergleich der gefundenen Lösungsvarianten. Dadurch werden Sie im Laufe der Zeit auch ein Gefühl dafür bekommen, wie der Abfrageoptimierer arbeitet, und werden dadurch in der Lage sein, kompakte und performante Abfragen zu entwerfen. Vermeiden Sie Hinweise zur Abfrageausführung Arbeiten Sie nicht gegen den Optimierer, sondern versuchen Sie, ihn zu verstehen und zu benutzen. Abfragehinweise sind in der Regel nicht erforderlich. Wenn Sie wissen, wie der Optimierer arbeitet, müssen Sie ihn nicht austricksen, sondern können Ihre Abfragen entsprechend gestalten. Verwenden Sie geeignete Indizes Überprüfen Sie Ihre Indizes dahingehend, ob sie tatsächlich auch verwendet werden, also ob sie erforderlich sind. Nicht benötigte Indizes belasten den Server bei Datenaktualisierungen. Indizes sind für folgende Spalten nützlich: Prädikate in einer WHERE-Klausel. Wie Sie gesehen haben, gilt dies allerdings nur, wenn der Index auch selektiv genug ist. Fremdschlüssel (FOREIGN KEY). Für Fremdschlüsselbeziehungen sollten Sie in der Regel einen Index erzeugen. Auch dies gilt allerdings nur dann, wenn dieser Index über eine ausreichende Selektivität verfügt. Abdeckende Indizes. Prüfen Sie, ob abdeckende Indizes Vorteile bringen. Hierbei leistet der DTA Hilfe. 536

12.9 Tipps zur Abfrageoptimierung Kurze Indizes. Verwenden Sie lieber viele Indizes auf wenige Spalten statt weniger Indizes mit vielen Spalten. Der Optimierer hat dadurch mehr Möglichkeiten. Verwenden Sie aktuelle Statistiken Gerade bei gespeicherten Prozeduren ist es nicht ausgeschlossen, dass der Plan für eine Prozedur auf veralteten Daten basiert, dass also die Statistiken nicht mehr aktuell sind. Aktuelle Statistiken sind essentiell für eine korrekte Arbeitsweise des Optimierers. Reorganisieren Sie von Zeit zu Zeit Ihre Indexstrukturen, oder verwenden Sie die Anweisung UPDATE STATISTICS bzw. die gespeicherte Systemprozedur sp_updatestats zur periodischen Aktualisierung der Statistiken. Überprüfen Sie Ihr System regelmäßig Versuchen Sie, eine Performance Baseline zu erstellen, und testen Sie dann in regelmäßigen Abständen, wie der derzeitige Zustand von dieser Basis abweicht. Hierzu benötigen Sie eventuell spezielle T-SQL-Skripte oder auch Ablaufverfolgungen, die Sie von Zeit zu Zeit einfach messen. Für diese Art Messung ist eine Stoppuhr geeignet. Optimieren Sie die Datenbankstruktur Der beste Index nützt nichts, wenn Ihre Datenbank so aufgebaut ist, dass relevante Daten jeweils nur durch einen JOIN über acht bis zehn Tabellen zurückgegeben werden können. Sie benötigen also eine entsprechende Tabellenstruktur, damit Abfragen optimal erstellt werden können. Hierzu ist in der Regel ein ausgewogenes Verhältnis zwischen Normalisierung und Denormalisierung einer Datenbank erforderlich. Sie werden also nicht umhinkommen, sich auch mit der Thematik Datenbank-Design auseinanderzusetzen, die nicht Gegenstand dieses Buches ist. Verwenden Sie passende Datentypen in Tabellen Denken Sie daran, dass SQL Server Daten seitenweise liest. Je mehr Tabellenzeilen Sie in eine Daten- oder Indexseite aufnehmen können, umso schneller werden Ihre Abfragen sein, da weniger Lesevorgänge benötigt werden. Verwenden Sie also nach Möglichkeit immer den kleinsten passenden Datentyp, und seien Sie vorsichtig mit Zeichenketten fester Länge, also zum Beispiel NCHAR. Vermeiden Sie temporäre Datenbankobjekte Temporäre Tabellen oder Cursor verwenden alle die Systemdatenbank tempdb. Diese Datenbank müssen sich alle zu einer SQL Server-Instanz existierenden Verbindungen teilen. In der tempdb werden auch SQL Server-Objekte abgelegt, die zum Beispiel während einer Abfrage zwischengespeichert werden müssen. Benutzen Sie die tempdb so wenig wie möglich. 537

12 Optimierung von Abfragen Vermeiden Sie Cursor Dieser Tipp wurde bereits in Kapitel 7 genannt. Cursor benötigen eine Menge SQL Server- Ressourcen und sind daher oftmals eine wesentliche Ursache für ein mangelhaftes Laufzeitverhalten. Wenn Sie mit der Optimierung beginnen, konzentrieren Sie sich bitte zunächst auf die Optimierung von Abfragen. Hier ist immer am meisten herauszuholen. Ich erlebe es häufig, dass ein Optimierungsansatz bei der Hardware, also beim Server beginnt. In der Regel ist ein solcher Ansatz aber lange nicht so vielversprechend wie die eigentliche Abfrageoptimierung. Dies sollte wirklich Ihr Hauptansatzpunkt sein. 538