Database Reference
In-Depth Information
Leonid:
„Ich hätte den Reorganisationsprozess genau untersuchen und Schritt für Schritt
tunen müssen. Da die Wartezustände aber so auffallend und so groß waren, wollte ich es zu-
nächst mit einer allgemeinen und einfacheren Lösung probieren. Das hat sich in diesem Fall
auch gelohnt.“
Fazit
• einigeLeerlauf-Warteereignisselassensichtunen,
• beiPerformanceTuningistesmanchmalnichtausreichend,dierichtigentechni-
schen Lösungen zu finden. Man muss noch selbstbewusst genug sein, um diese Lö-
sungen durchzusetzen.
3.2.3
Einige wichtige Warteereignisse (wait events)
Was sollen Sie tun, wenn Sie es mit einem System, mit einem Server-Prozess oder mit ei-
ner SQL-Anweisung zu tun haben, die auf ein Warteereignis warten, und Sie nicht sicher
sind, was dieses Warteereignis bedeutet und wie man die Wartezeit reduzieren kann? In
so einer Situation müssen Sie die notwendigen Informationen irgendwo besorgen. Meiner
Meinung nach ist der MOS die beste Quelle dafür (in jedem Fall würde ich zunächst dort
suchen). Man kann im MOS nicht nur die Beschreibungen der Warteereignisse finden,
sondern auch einige Verbesserungsvorschläge und Verweise auf die bekannten Probleme.
Es spielt auch eine große Rolle, dass die Informationen im MOS regelmäßig aktualisiert
werden.
In diesem Abschnitt beschreibe ich nur einige Warteereignisse, die häufig Performanz-
Probleme verursachen.
3.2.3.1 db file sequential read
Bei diesem Warteereignis geht es um das Warten auf das Ende eines Lesevorganges beim
Lesen der einzelnen Datenblöcke (singe block read) über den Buffer Cache. Normalerwei-
se wird ein einziger Datenblock jeweils dabei gelesen.
Am häufigsten tritt dieses Warteereignis bei Index Scans auf (außer Fast Full Index
Scan) und bei Tabellenzugriffen über die Rowid.
Im Prinzip ist es normal, dass man die Wartezustände für „db file sequential read“ be-
obachtet. Man muss eingreifen, wenn diese Wartezeit gravierend wird. In solchen Fällen
hilft am häufigsten das SQL-Tuning. Wenn das System CPU-mäßig noch Reserven hat,
könnte man in einigen Fällen den Buffer Cache vergrößern oder die betroffenen Segmente
in einem Keep Pool verwalten. Für alle Fälle kann man zusätzlich die I/O-Performanz
überprüfen.
