Performance-Optimierung für Datenbankanwendungen

… aufwändiger (da, um bei dem zuvor genannten Beispiel zu bleiben, bei
einem Umzug die Adresse bei jeder Person
geändert werden muss). Das letztgenannte
Problem lässt sich aber umgehen, indem
vorgefertigte Extrakte aus den Daten in
separaten Tabellen speichert werden. Ein
Beispiel wäre eine Situation, wenn auf einer
Webseite vortagesaktuelle Daten für
eine Auswertung ausreichen und diese jede
Nacht aus einem Produktivsystem abgefragt
und in einer separaten Tabelle abgelegt
werden, damit sie möglichst schnell
abgefragt werden können. Nach einem
ähnlichen Prinzip funktionieren auch Data
Warehouse-Lösungen.

Eines der wichtigsten Gebiete der Optimierung
von Datenbankanwendungen
ist die Index-Optimierung. Selbst einfache
Abfragen auf großen Tabellen werden
durch das Vorhandensein eines passenden
Indizes um das hundertfache (oder mehr)
beschleunigt. So kann es leicht vorkommen,
dass eine Abfrage, die zuvor noch
fast eine Stunde benötigte, plötzlich in
wenigen Sekunden ausgeführt wird. Allerdings
müssen Indizes stets aktualisiert
werden, so dass es auch nicht sinnvoll ist,
für jedes Feld in einer Tabelle einen Index
zu definieren. Es sollte nur gezielt für diejenigen
Felder Indizes definiert werden,
nach denen oft gesucht wird. Dazu ist es
auch ratsam, sich Gedanken zu machen,
ob eine Tabelle vorrangig gelesen oder
eher geschrieben wird.

Bei einer Wissensdatenbank, die meist
abgefragt und lediglich vereinzelt ergänzt
wird, sollten eher mehr Indizes angelegt
werden, während es sich für die Log-Datei
einer vielbesuchten Webseite, die in einer
Datenbank gespeichert wird, empfehlenswert
ist, lediglich die nötigsten Indizes
anzulegen, da hier sehr häufige Schreiboperationen
stattfinden und die Daten nur
relativ selten ausgewertet werden.

Die Rolle der Clustered Indizes

Eine Besonderheit stellen die Clustered
Indizes dar. Hier wird nämlich der Index
nicht separat gespeichert, sondern die Tabelle
selbst ist quasi nach der indizierten
Feldkombination sortiert. Das bringt es
mit sich, dass eine Reorganisation hier
noch erheblich aufwändiger ist, als bei
einem normalen (Nonclustered) Index.
Man sollte also für Clustered Indizes möglichst
nur Felder verwenden, die sich nur
selten ändern. Eine beliebte und allgemein
gute (wenn auch nicht immer die beste)
Variante ist es, ein ID-Feld für jede Tabelle
zu definieren und dieses auch als Clustered
Index zu nutzen.

Optimierung des Datenzugriffs
Die Optimierung des Datenzugriffs ist ein
äußerst weites Feld. Im Folgenden sollen
daher lediglich eine Reihe einfacher Beispiele
aufgeführt werden, um den Leser
zumindest für die Grundproblematik zu
„sensibilisieren“. Auch hier spielen Indizes
wieder eine relativ wichtige Rolle.
Durch ungünstig formulierte SQL-Abfragen
kann es vorkommen, dass vorhandene
Indizes nicht oder nur uneffektiv
genutzt werden können. Das ist insbesondere
dann der Fall, wenn die indizierten
Felder als Funktionsparameter verwendet
werden. Dazu ein einfaches Beispiel:

SELECT * FROM Adressen WHERE Ort='Frankfurt'
-- Index-Seek möglich
SELECT * FROM Adressen WHERE Ort LIKE 'Frankfurt%'
-- Index-Seek möglich
SELECT * FROM Adressen WHERE RTRIM(Ort)='Frankfurt'
-- nur Index-Scan möglich!

In vielen Situationen bietet es sich auch
an, mehrere Abfragen (die beispielsweise
über UNION verbunden sind), zu einer
zusammenzufassen. Damit können die
Daten wesentlich effektiver abgefragt
werden. In Listing 1 sehen Sie ein, zugegebenermaßen
geografisch nicht ganz korrektes, Beispiel:

SELECT *, 'Nord' as Region FROM Adressen
WHERE PLZ='50000'
-- Tabelle wird zweimal durchlaufen
SELECT *,
CASE
WHEN PLZ='50000' THEN 'Süd'
END as Region
FROM Adressen
-- Tabelle wird nur einmal durchlaufen

In den gezeigten Beispielen steckt aber
noch weiteres Optimierungspotential.
Man sollte generell vermeiden, alle Felder
über den * zu selektieren. Meist wird
lediglich ein Teil der Felder benötigt und
durch den * werden unnötig viele Daten
aus der Datenbank gelesen und zum Client
übertragen. Außerdem werden so unerwünschte
Nebeneffekte vermieden, falls
der entsprechenden Tabelle später einmal
weitere Spalten hinzugefügt werden
sollen. Um die automatische Abfrageoptimierung
zu unterstützen sollte, sofern
das möglich ist, auf die Benutzung von
SQL-Cursorn verzichtet werden. Wenn
möglich, ist eine mengenorientierte SQLOperation
(wie SELECT, INSERT, UPDATE
oder DELETE) immer die schnellere
Wahl.

Es gibt viel zu optimieren

Auch beim SQL Server 2005 spielt die Optimierung
von Datenbankanwendungen
nach wie vor eine wichtige Rolle. Insbesondere
durch die vielen möglichen Optimierungsmaßnahmen
(und besonders
bei bereits bestehenden Anwendungen)
sollte man immer erst eine Schwachstellenanalyse
betreiben und dann gezielt die
kritischsten Aspekte optimieren. In vielen
Fällen kann durch einen geringfügigen
Eingriff an der der richtigen Stelle bereits
eine entscheidende Performance-Verbesserung
erzielt werden. Natürlich konnte
dieser Artikel nur einen Überblick über
die verschiedenen Möglichkeiten der Datenbank-
Anwendungsoptimierung bieten.
Ein ausführliches Eingehen auf die
verschiedenen Ansätze würde schnell ein
ganzes Buch füllen, sodass es noch viel Material
für weitere Artikel gibt.

Der Diplom-Informatiker (FH) Robert Panther
beschäftigt sich seit vielen Jahren mit SQL-Datenbankanwendungen
und deren Optimierung.
So ist bereits im Jahre 1996 seine Diplomarbeit
zum Thema „Optimierung von Datenbankanwendungen“
entstanden. Ein weiteres Spezialgebiet
von ihm ist Anwendungsentwicklung für mobile
Geräte, zu denen er bereits zwei Bücher verfasst
hat. Für Fragen und Anregungen steht er unter
rpanther@panthercomputing.de zur Verfügung.

[1] Urban/Köller/Jungbluth: SQL Server 2005 Entwicklerbuch. Microsoft Press 2007
[2] Ruprecht Dröge/Markus Raatz: Microsoft SQL
Server 2005. Microsoft Press 2005
[3] Andreas Kosch: SQL Server 2005 Express Edition. entwickler.press 2006
[4] Offizielle Produkt-Website des Microsoft SQL
Server: www.microsoft.com/germany/sql/
[5] Newsgroup zum SQL Server:
news://msnews.microsoft.com/microsoft
.public.de.sqlserver

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.