Database Reference
In-Depth Information
Ziemlich schnell stellte ich fest, dass die jeweiligen Wartezustände eine deutliche Re-
gelmäßigkeit hatten. Es gab täglich 4 Spitzen für das Warteereignis „library cache: mutex
X“: zwischen 1:30 und 2:00, zwischen 11:30 und 12:00, zwischen 16:30 und 17:00, zwi-
schen 21:30 und 23:00. Da diese Wartezustände auf ein mögliches Problem mit Parsing
hindeuteten, recherchierte ich in diese Richtung. U. a. suchte ich nach einer Korrelation
zwischen den Wartezuständen für „library cache: mutex X“ und den harten Parse Calls.
Die Abb.
12.9
zeigt eine mögliche Korrelation zwischen diesen Statistiken für 3 von 4 oben
genannten Zeiträume an (zwischen 1:30 und 2:00, zwischen 11:30 und 12:00, zwischen
16:30 und 17:00).
Danach ermittelte ich das Datenbankobjekt, das am häufigsten bei den Wartezuständen
für „library cache: mutex X“ betroffen war. Dafür suchte ich zunächst in der View DBA_
HIST_ACTIVE_SESS_HISTORY nach dem Hashwert dieses Objektes. Diesen Hashwert
beinhaltet PARAMETER1 des Warteereignisses „library cache: mutex X“ (die Spalte P1
der View DBA_HIST_ACTIVE_SESS_HISTORY). Über den ermittelten Hashwert stell-
te ich das Datenbankobjekt in der View V$DB_OBJECT_CACHE fest (dieses Verfahren
ist bereits im Abschn. 3.2.3.9 beschrieben). Es war das Package SYS.STANDARD, das am
häufigsten für die 3 Zeiträume in der View DBA_HIST_ACTIVE_SESS_HISTORY bei
den Wartezuständen für „library cache: mutex X“ vorkam.
Im nächten Schritt klärte ich, was das häufige harte Parsing verursachte. Dafür suchte
ich zwischen 11:30 und 12:00 und zwischen 16:30 und 17:00 in der View V$SQL nach
den SQL-Anweisungen, die lediglich einmal ausgeführt wurden. Ich fand dort sehr viele
anonyme PL/SQL-Blöcke, welche SQL-Anweisungen mit verschiedenen Literalen bein-
halteten. Den Zeitraum zwischen 1:30 und 2:00 untersuchte der Kunde selber und kam zu
demselben Ergebnis.
Ich interpretierte diese Erkenntisse folgendermaßen. Das Package SYS.STANDARD
wird beim harten Parsing von PL/SQL-Blöcken von Oracle benutzt. Wenn das harte Par-
sing intensiv und konkurrierend ausgeführt wird, kann es zu den Mutex-Wartezuständen
für dieses Package kommen. Um diese Wartezustände zu reduzieren, musste man die Li-
terale durch die jeweiligen Bind-Variablen in den PL/SQL-Blöcken ersetzen. Leider war es
nicht möglich, das mit der Parametereinstellung
cursor_sharing = force
zu erreichen, weil
diese Parametereinstellung keine Auswirkung auf die rekursiven Cursor hat.
Fazit
Die Benutzung der Grafiken bei der Suche nach den Korrelationen zwischen den ver-
schiedenen Performanzstatistiken hilft sehr häufig, schnell und sicher die Ursache der
Performanz-Probleme festzustellen.
