Database Reference
In-Depth Information
Diese Daten sind ausreichend, um die meisten typischen Performanz-Probleme zu klä-
ren. Manchmal helfen sie, das jeweilige Problem sofort zu beseitigen (beispielsweise durch
das Fixieren eines guten Ausführungsplans aus dem AWR). Das AWR enthält etwas mehr
Performanzstatistiken als das Statspack. Es geht dabei nicht nur um einen quantitativen
sondern mehr um einen qualitativen Unterschied, weil einige im Statspack fehlende Statis-
tiken sehr wichtig für Performance Tuning sind. Die Deltawerte der Performanzstatistiken
im AWR beschleunigen die Abfragen der jeweiligen Views.
Peter: „
Gibt es solche Deltawerte für alle Statistiken im AWR?
“
Leonid: „
Das wäre sehr schön, ist leider aber nicht der Fall. Diese Deltawerte existieren für
die ganz großen Statistiken: für die Cursor- und für die Segmentstatistiken. Wenn Du nichts
dagegen hast, besprechen wir gleich einige wichtige Performanzstatistiken aus dem AWR, die
im Statspack fehlen.
“
P.: „
Sehr gern. Ich glaube, dass wir mindestens eine solche Statistik bereits diskutiert ha-
ben. Ich meine die Spalte OTHER_XML im Ausführungsplan.
“
L.: „
Ganz genau, Peter. Infolgedessen fehlen viele nützliche Informationen aus dieser Spal-
te im Statspack. Beipielweise die Outlines, mit denen man den jeweiligen Ausführungsplan
fixieren kann (s. im Abschn.
18.1
). Man kann aber leicht das Statspack mit den Daten aus
OTHER_XML vervollständigen (s. im Abschn.
18.3
). Es ist nicht möglich, ein SQL-Set für
die Cursor aus dem Statspack-Repository zu generieren. Konsequenterweise kann man auch
keine SQL Plan Baselines für die Cursor aus dem Statspack erstellen. Im Unterschied zu AWR
enthält das Statspack keine Informationen zu den aktiven Sessions.
“
P.: „
Ist es so tragisch? Soweit ich mich erinnere, sind diese Informationen für die Ermitt-
lung der Cursor wichtig, die auf ein konkretes Warteereignis warteten. Kann man sich nicht
mit den Warteklassen begnügen, die für die Cursor auch im Statspack vorhanden sind?
“
L.: „
Wie würdest Du beispielsweise die blockierenden Wartezustände ohne diese Informa-
tionen untersuchen?
“
P.: „
Wenn Du die Enqueues meinst, die solche Zustände verursachen, so ist ihre Analyse
überflüssig, weil sie anwendungsbedingt sind.
“
L.: „
Peter, außer Enqueues gib es bei Oracle auch andere Sperren, z. B. Mutexes. Probleme,
die durch die Enqueues entstehen, müssen übrigens auch untersucht werden. Sie sind nicht
immer anwendungsbedingt.
“
P.: „
Wieso nicht? Könntest Du bitte ein Beispiel nennen?
“
L.: „
Gern. Ich nehme absichtlich ein ganz einfaches. Stelle Dir vor, dass viele Sessions auf
eine warten, die ein TX-Enqueue hält und dabei eine SQL-Anweisung ausführt, welche nor-
malerweise sehr schnell läuft, dieses Mal aber nicht. Das ist sehr wahrscheinlich kein Anwen-
dungsproblem. Wenn dieses Problem in der Vergangenheit liegt, gibt es nur eine direkte Me-
thode zur Analyse: Untersuchung der Historie von aktiven Sessions in der View DBA_HIST_
ACTIVE_SESS_HISTORY. Ich vermute auch, Du hast einige andere Enqueues vergessen, wie
z. B. ITL oder TM, die nur bedingt mit der Anwendung zu tun haben.
“
P.: „
Du hast mich überredet. Ist es möglich, das Statspack mit den Informationen zu den
aktiven Sessions zu vervollständigen?
“
