Performance-Tuning für SQL Server 2000

Mit indizierten Views, erweiterter Datensicherung und Distributed Partitioned Views lässt sich aus Microsofts Datenserver das Maximum herausholen.

Artikel erschienen in Swiss IT Magazine 2000/44

     

Nachdem der SQL Server 7.0 im Vergleich mit den Vorgängerversionen in wesentlichen Bereichen neu entwickelt wurde, sind es beim 2000er Upgrade eher eine Vielzahl kleinerer Optimierungen und Erweiterungen, die vorgenommen wurden.


Die wichtigsten Neuerungen

Im Mittelpunkt der Erweiterungen stehen zweifelsohne die indizierten Views. Diese Funktionalität kann ohne Änderungen an bestehenden Anwendungen genutzt werden. Die Grundidee ist die Definition von Indizes auf der Ebene von Views statt von Datenbanken. Wenn Abfragen auf Views erfolgen, insbesondere in Verbindung mit Aggregationen oder Joins auf mehrere Views, kann so die Performance signifikant gesteigert werden. Die Definition wird auch durch einen Assistenten, den Index Tuning Wizard, unterstützt.



Mit den Erweiterungen bei den verteilten, partitionierten Views wird eine neue Stufe der Skalierbarkeit erreicht. Microsoft wechselt hier von dem Shared-Disk-Cluster-Modell zu einem Shared-Nothing-Cluster-Modell, bei dem eine Gruppe von Servern die Anforderungen bearbeiten kann.




Verbesserungen gibt es aber auch bei den Backup-Funktionen, der auf 64 GB erweiterten Speicherunterstützung in Verbindung mit dem Windows 2000 Datacenter Server und bei der Möglichkeit, mehrere Instanzen von SQL Server auf einem System auszuführen. Dabei können eine Instanz des SQL Server 6.5 oder 7.0 und mehrere Instanzen des SQL Server 2000 parallel betrieben werden. Jede dieser Instanzen verfügt über eigene Ressourcen. Dieses Konzept ist insbesondere in Verbindung mit SMP-Systemen interessant.



Für die Skalierbarkeit ist auch die Unterstützung der Net-Library für VIA (Virtual Interface Systems) interessant. VIAs sind Schnittstellen für SANs (Storage Area Networks), über die Anwendungen Speicher direkt adressieren können. VIAs sorgen für die Virtualisierung dieses Speichers.




Die indizierten Views

Views gibt es schon seit den frühesten Versionen von Microsofts SQL Server. Dabei handelt es sich um virtuelle Tabellen, die eine Ansicht auf bestehende Tabellen darstellen. Sie werden aus mehreren Gründen verwendet. Zum einen stellen sie einen Sicherheitsmechanismus dar, über den der Zugriff von Benutzern auf eine Teilmenge der Daten in einer oder mehreren Tabellen eingeschränkt werden kann. Views erlauben auch die Beschränkung auf ausgewählte Zeilen, während die Zugriffsberechtigungen auf Tabellenebene nur über Spalten gesteuert werden.



Zum anderen bieten sich auch einige Vorteile für Anwendungsentwickler. Mit Views können logische Strukturen oberhalb der Tabellen geschaffen werden. Damit lässt sich sowohl der kombinierte Zugriff auf mehrere Tabellen einfacher gestalten als auch eine Unabhängigkeit zwischen den Tabellenstrukturen und den Anwendungen realisieren.




Diese Funktionalität wurde nun im SQL Server 2000 um indizierte Views erweitert. Das Feature steht allerdings nur in der Enterprise sowie der Developer Edition zur Verfügung. Auf Views können sowohl ein eindeutiger, geclusterter Index als auch nicht geclusterte Indizes erstellt werden. Das erweist sich insbesondere in Verbindung mit komplexen Abfragen, die regelmässig ausgeführt werden, als wertvoll und gilt vor allem für entscheidungsunterstützende Anwendungen mit ihren typischerweise komplexen Analysen von Daten. Indizierte Views werden nicht zur Laufzeit, sondern dauerhaft in der Datenbank gespeichert. Damit wird der Aufwand der Indizierung zur Laufzeit vermieden.



Der SQL Server Query Optimizer analysiert eigenständig, ob eine indizierte View für Abfragen eingesetzt werden kann. Zusätzlich gibt es für die Definition von Abfragen die Option NOEXPAND im SELECT-Statement, mit der festgelegt wird, dass die View wie eine gewöhnliche Tabelle behandelt und damit auch die Indizes - soweit es für die Abfrage Sinn macht - verwendet werden.



Indizierte Views haben eine Reihe von Bedingungen zu erfüllen. So müssen sie wie auch alle referenzierten Tabellen in der gleichen Datenbank sein und den gleichen Besitzer haben. Damit der Optimizer die Tabellen nutzen kann, ist es nicht notwendig, dass alle Tabellen, die in den Abfragen verwendet werden, auch in der View enthalten sind. Der eindeutige, geclusterte Index muss in jedem Fall vor der Erstellung anderer Indizes erzeugt werden. Ausserdem müssen eine Reihe von SET-Parametern gesetzt sein, die in einem Dokument unter http://msdn.microsoft.com/library/techart/indexedviews.htm detailliert erläutert sind. Diese können auch mit dem Index Tuning Wizard gesetzt werden.



Grundsätzlich muss bei indizierten Views ebenso wie bei der Erstellung von Indizes auf Tabellen gut überlegt werden, ob diese wirklich Sinn machen. Der Index belegt zusätzlichen Plattenplatz und muss gepflegt werden. Daher ist das Anlegen solcher Indizes nur dann von Nutzen, wenn komplexe Abfragen über mehrere Tabellen auf Basis einer View regelmässig ausgeführt werden. Im Index sollten dabei so wenig wie möglich Spalten und Bytes enthalten sein. Kleinere Indizes sind effizienter als grosse Indizes. Darüber hinaus gilt es zu überlegen, ob die Optimierungen nicht auch durch eine effizientere Gestaltung von Abfragen, durch Indizes auf die zugrundeliegenden Tabellen oder durch mehrere kleine Indizes auf Views, die dann bei einer Abfrage zusammengefasst behandelt werden, erreicht werden können.




Der Index Tuning Wizard

Beim Index Tuning Wizard handelt es sich um einen von vielen Assistenten von SQL Server 2000. Er arbeitet auf Basis von Informationen über die Last des Systems, die in einer Datei gespeichert sind. Mit Werkzeugen wie beispielsweise dem SQL Profiler können Informationen über die aktuelle Last auf dem Server gesammelt werden. Wichtig dabei ist, dass mit repräsentativen Daten gearbeitet wird, bevor der Index Tuning Wizard zur Erstellung und Optimierung von Indizes eingesetzt wird.



Der Index Tuning Wizard schlägt Indizes vor, die als besonders sinnvoll erachtet werden. Diese Empfehlungen müssen aber nicht zwingend richtig sein. Wenn die Ausführung von Abfragen mit dem SQL Query Analyzer über den Befehl Query - Show Execution Plan analysiert werden, kann es durchaus vorkommen, dass über den Index Tuning Wizard erstellte Abfragen nicht genutzt werden.




Letztlich ist der Index Tuning Wizard nur ein Werkzeug, um optimale Abfragen zu erzeugen. Er liefert aber keineswegs zwingend immer bestmögliche Ergebnisse. Abgesehen davon können auch Änderungen in Anwendungen, zusätzliche Funktionen oder eine weniger intensive Nutzung von Anwendungen dazu führen, dass zusätzliche oder andere Indizes benötigt werden. Daher sollte zum einen regelmässig die Effizienz der Index-Nutzung analysiert und zum anderen der Index Tuning Wizard auf Basis möglichst exakter Daten zum Workload regelmässig durchgeführt werden.




Cluster und Skalierbarkeit

Im Bereich der Skalierbarkeit sind insbesondere die Distributed Partitioned Views von Interesse. Auf diese können nun beim SQL Server 2000 auch Updates durchgeführt werden. Dabei werden Tabellen über den Primärschlüssel in mehrere nicht miteinander verbundene Teile getrennt, die dann jeweils auf einem getrennten Knoten des Clusters ausgeführt werden können. Mit Hilfe der Distributed Partitioned Views wird dann auf jedem Knoten eine View erstellt, welche die verschiedenen Tabellen auf den Servern wiederum als eine gesamte Tabelle darstellt. Der Zugriff erfolgt dann unabhängig von der Server-Lokation.



Die wesentliche Verbesserung liegt darin, dass der SQL Server Optimizer nun in der Lage ist, Statements mit Änderungen an Informationen genau an die Partition zu senden, die an der Transaktion teilnimmt. Voraussetzung dafür ist, dass sich diese Partitionen eindeutig aufgrund der Abfrage erkennen lassen, was typischerweise zumindest bei Änderungen, die über den Primärschlüssel erfolgen, der Fall ist. Damit wird die Performance bei Updates signifikant gesteigert. Da jeder der Knoten in diesem Cluster eigenständig arbeitet, entfällt auch die Notwendigkeit für Shared-Disk-Subsysteme, die einen potenziellen Engpass darstellen.





Selektive Datensicherung

Interessant sind auch die Optimierungen im Bereich der Datensicherung. Unterstützt werden nun differenzielle Backups, bei denen nur die geänderten Seiten in der Datenbank gesichert werden. Damit lassen sich kleine und damit auch entsprechend schnell durchzuführende Backups erzielen. Diese Backups können darüber hinaus auch während Zugriffen von Benutzern auf die Datenbank ausgeführt werden. Da es sich um eine Variante handelt, die verhältnismässig wenig Einfluss auf die Performance des Servers hat, können diese Sicherungen auch häufiger durchgeführt werden, womit auch das Risiko eines Datenverlusts sinkt.



Die bessere Alternative dazu sind aber die nun unterstützten Server-less Snapshots. Dafür wird eine Anwendung zur Datensicherung benötigt, die VDI (Virtual Device Interface) unterstützt. Diese Werkzeuge können darüber auf Enterprise-Storage-Systeme zugreifen, die entweder Split-Mirror- oder Copy-on-Write-Operationen unterstützen. Ein Beispiel sind dreifache Spiegelungen auf dem Storage-System. Das VDI-Gerät verwendet eine der Spiegelungen, so dass die beiden anderen weiterhin für den produktiven Einsatz zur Verfügung stehen. Von dort aus kann dann die eigentliche Datensicherung erfolgen. Falls die Sicherung auf ein anderes System erfolgt, ergibt sich daraus ein sofort einsetzbares Standby-System, wobei der Datenbank-Server selbst nicht belastet wird.




Interessant ist in diesem Zusammenhang auch das Log Shipping. Damit lassen sich die Transaktionslogs von zwei Systemen synchronisieren. Mit Log Shipping ist es etwa möglich, ein "Warm Standby" zu erzeugen, indem die Transaktionen von einer Datenbank kontinuierlich auf eine andere Datenbank abgebildet und dort eingelesen werden. Die Zielsysteme können dann aber auch für die Beantwortung von Abfragen und damit für die Entlastung des Quellsystems genutzt werden.




Höchstleistung erst im Verbund

Microsoft ist mit dem SQL Server 2000 konsequent dabei, die Skalierbarkeit des Systems zu erhöhen. Die erreichten Werte in verschiedenen Performance-Benchmarks zeigen, dass mit SQL Server 2000 dabei deutliche Fortschritte erzielt worden sind. In Verbindung mit dem Microsoft Application Center als Cluster für Anwendungskomponenten, dem Network Load Balancing von Windows 2000 und einer generell höheren Skalierbarkeit lassen sich sehr leistungsfähige Anwendungen auf dieser Plattform entwickeln. Die verschiedenen Problembereiche wurden konsequent adressiert, um den Anforderungen der Enterprise-IT zu genügen. Mit SQL Server 2000 ist Microsoft dabei ein gutes Stück vorangekommen.



Artikel kommentieren
Kommentare werden vor der Freischaltung durch die Redaktion geprüft.

Anti-Spam-Frage: Vor wem mussten die sieben Geisslein aufpassen?
GOLD SPONSOREN
SPONSOREN & PARTNER