Database Reference
In-Depth Information
Fazit
• jedesProblemlässtsichanalysieren,nichtjedesaberlösen,
• ineinigenFällenistdieAusgabevontkproffürdieAnalysenichtausreichend,man
muss zusätzlich einen Blick auf die jeweilige Trace-Datei werfen
6.1.8
Event 10053
Mit diesem Event kann man nachvollziehen, wie der Optimizer die Ausführungspläne er-
mittelt. Für die eigene Session kann man das Event 10053 z. B. folgendermaßen aktivieren:
alter session set events '10053 trace name context forever, level 1';
Das Aktivieren des Event 10053 in einer anderen Session kann wie bei Event 10046 erfol-
gen (s. im Abschn. 6.1.5.2). Damit die jeweilige Trace-Datei angelegt oder eine bestehende
mit den Daten gefüllt wird, muss ein harter Parse Call der jeweiligen SQL-Anweisung aus-
geführt werden. Dies kann man mit einer Änderung des SQL-Textes erreichen (beispiels-
weise durch einen Kommentar), so dass kein anderer Cursor mit demselben SQL-Text in
der SQL-Area existiert. In der eigenen Session stellt diese Änderung kein Problem dar. In
einer anderen Session ist es nicht möglich. Aus diesem Grund würde ich empfehlen, das
Event 10053 möglichst in der eigenen Session zu benutzen.
Peter: „
Glaubst Du, dass ein Datenbankadministrator imstande ist, die mit dem Event
10053 produzierte Trace-Datei zu verstehen? Ich persönlich kann das nicht.
“
Leonid: „
Dafür ist ein gewisses Know-How notwendig, welches man nicht von einem
Datenbankadministrator verlangen kann. Wenn es aber absolut unklar ist, warum der Opti-
mizer einen suboptimalen Plan auswählt, bleibt nichts anderes übrig, als eine Trace-Datei mit
dem Event 10053 zu erzeugen und diese Datei zu analysieren. Zum Glück besteht solch eine
Notwendigkeit nicht oft, weil man das normalerweise mit einfacheren Mitteln klären kann.
“
P.: „
Wie soll mir diese Trace-Datei helfen, wenn ich sie nicht interpretieren kann?
“
L.: „
An Deiner Stelle würde ich in so einem Fall nicht sofort aufgeben. Einige gravierende
Probleme sind dort ziemlich leicht zu erkennen.
“
P.: „
Welche zum Beispiel?
“
L.: „
Wenn der Optimizer beispielsweise die Selektivität nicht richtig berechnet.
“
P.: „
Das klingt aber nach einem Bug. Könntest Du ein anderes Beispiel nennen?
“
L.: „
Es spielt eigentlich keine große Rolle, ob es ein Bug ist oder nicht, weil man das je-
weilige Performanz-Problem lösen muss. Wenn man feststellt, dass das Performanz-Problem
wegen eines Bug entstand, hilft es auch bei der Problemlösung. Du wolltest aber ein ande-
res Beispiel. Bei einem System erstellte der Optimizer einen suboptimalen Ausführungsplan
und ignorierte einen offensichtlich besseren. Es ging dabei um einen großen Join von meh-
reren Tabellen. In der Trace-Datei für das Event 10053 fand ich keine Spuren vom guten
Ausführungsplan: der Optimizer zog ihn überhaupt nicht in Betracht. Dies bekräftigte mei-
nen Verdacht bezüglich der Ursache dieses Problems: der Kunde setzte den Parameterwert
