Database Reference
In-Depth Information
benutzt. Diese Statistiken können manchmal bei der Verifizierung der Hypothesen über
die möglichen Ursachen des jeweiligen Performanz-Problems helfen. Solche Hypothesen
entstehen normalerweise nach einer Voranalyse, z. B. nach der Analyse der vorliegenden
Wartezustände. Nehmen wir das Beispiel aus dem Abschn. 3.2.3.7.3. Wenn eine oder meh-
rere Sessions auf das Warteereignis „enq: TX - index contention“ warten, passiert es nor-
malerweise wegen der Spaltung der Index-Blöcke bei konkurrierenden Index-Zugriffen.
Mit den folgenden Statistiken kann man verifizieren, ob es der Fall ist:
• „branchnodesplits“,
• „leafnodesplits“,
• „leafnode90-10splits“
Die erste Statistik liefert die Anzahl der Spaltungen der inneren Blöcke („branch nodes“)
der Index-Struktur. Die zweite betrifft die End-Blöcke („leaf nodes“) der Index-Struktur.
Die Spaltung dieser beiden Blockarten erfolgt nach dem Verfahren „50-50“, i.e. die 2 neu-
en Blöcke sind halbvoll mit den Daten gefüllt. Ganz anders ist es mit der dritten Statistik.
Das Verfahren „90-10“ wird bei der Spaltung des letzten End-Blockes verwendet, wenn
der neue Index-Eintrag, der die jeweilige Spaltung verursacht, der größte ist. Bei dieser
Spaltung werden die neu entstandenen Blöcke ungleichmäßig mit den Daten gefüllt, so
dass der letzte End-Block nach der Spaltung fast leer ist. Das Verfahren „90-10“ ist bei
Oracle speziell eingeführt für den Fall der aufsteigenden (im Sinne eines Indexes) Einträge
in eine Tabelle. Wenn man ein schnelles Anwachsen der oberen Statistiken beobachtet (für
eine Session oder für das ganze System), ist die Spaltung der Index-Blöcke die Ursache der
Wartezeit für „enq: TX - index contention“, und man kann die bereits im Abschn. 3.2.3.7.3
beschriebenen Tuning-Maßnahmen ergreifen.
Nehmen wir ein weiteres Beispiel. Wenn ein System auf ein Mutex-Warteereignis war-
tet, kann es sein, dass es durch viele harte Parse Calls verursacht ist. Bevor man mit den für
die Mutexes spezifischen Tuning-Maßnahmen anfängt (s. im Abschn. 3.2.3.9), kann man
zunächst die Statistik „parse count (hard)“ überprüfen, um zu klären, ob die Mutex-War-
tezustände dadurch verursacht werden. Die genaue Vorgehensweise ist im Abschn. 12.2.2
beschrieben.
Bei den Parsing-Problemen ist auch die Statistik „parse count (total)“ nicht uninteres-
sant, die gleich ist mit der Anzahl der gesamten Parse Calls. Laut der Dokumentation von
Oracle muss man den Statistikwert von „session cursor cache hits“ aus dem obigen Statis-
tikwert subtrahieren, um die Anzahl der „echten“ Parse Calls zu bekommen. Das bedeutet,
dass Oracle die Treffer im Session Cache auch als Parse Calls betrachtet. Bis auf Oracle
Release 11.2.0.2 ist es tatsächlich so. Ein Test auf meiner kleinen Datenbank von Oracle
11.2.0.3 zeigt aber, dass die Statistik „session cursor cache hits“ nicht in der Statistik „parse
count (total)“ enthalten ist. In diesem Test habe ich einen Cursor Cache für eine Session
konfiguriert und dreimal eine einfache SQL-Anweisung ausgeführt (beim dritten Mal soll
der jeweilige Cursor im Cache landen):
