Database Reference
In-Depth Information
3
Die 2 wichtigsten Kennzahlen für das
Performance Tuning
Bis jetzt haben wir nicht konkretisiert, was eine schlechte Performanz bedeutet. Wenn
jemand sich über eine schlechte Datenbank-Performanz beklagt, meint er, dass die Ant-
wortzeit eines Datenbankkommandos (normalerweise einer SQL-Anweisung) oder die
Laufzeit eines Datenbankprozesses zu groß ist. Es kann sein, dass mehrere Kommandos
oder mehrere Prozesse, möglicherweise das gesamte System, solche Probleme haben. In
jedem Fall geht es hier um eine inakzeptable Laufzeit, „elapsed time“ in der Computer-
fachsprache. Diese Laufzeit unterteilt sich in die CPU-Auslastung und in die Wartezeit:
„elapsed time“ = „cpu time“ + „wait time“.
Um die problematische Laufzeit zu reduzieren, soll man entweder „cpu time“ oder „wait
time“ oder beides reduzieren. Dafür muss man die Gründe für die hohe CPU-Auslastung
oder die lange Wartezeit klären. Erst danach kann man überlegen, wie man die Performanz
verbessern kann.
Peter:
„Warum muss man eigentlich die Laufzeit in die CPU-Auslastung und in die War-
tezeit unterteilen und diese beiden Bestandteile analysieren? Warum kann man sich nicht
allein mit der Laufzeit begnügen?“
Leonid:
„Die Laufzeit reicht lediglich für eine grobe Problemfeststellung aus, aber nicht für
eine Problembehebung.“
Betrachten wir zunächst die Wartezeit. Es ist sehr wichtig zu wissen, auf welche War-
teereignisse gewartet wird. Dieses Wissen sagt uns, aus welcher Ecke das jeweilige Problem
kommt. Das ermöglicht uns eine weitere Analyse und letzten Endes die Problembehe-
bung. Nehmen wir als Bespiel das Warteereignis „log file parallel write“. Wenn das System
auf dieses Warteereignis wartet, ist das ein Indiz für eine unzureichende Performanz des
Logwriter, die man verbessern muss. In diesem Fall wäre es absolut erfolglos, nach einer
Lösung woanders zu suchen. Wenn man versucht, diese Wartezeit beispielsweise durch
die SQL-Optimierung zu reduzieren, ist es zwecklos, da dieses Warteereignis gar nichts
mit SQL-Anweisungen zu tun hat. Ein anderes Warteereignis ist zwar für die SQL-Anwei-
sungen relevant, aber die jeweilige Wartezeit ist nicht durch das SQL-Tuning zu reduzie-
ren. Ein passendes Beispiel dafür stellt das Warteereignis „enq: TX - allocate ITL entry“
