Database Reference
In-Depth Information
zu ermitteln, die am häufigsten angefragt werden (also mit den meisten Logical oder Disk
Reads), und erst danach die SQL-Anweisungen ermitteln, wo die jeweiligen Segmente be-
teiligt sind (s. im Abschn. 17.3).
Wenn die Lage sehr ernsthaft ist, muss man möglichst schnell die Ursache des Perfor-
manz-Problems klären und, wenn möglich, beseitigen. Aus diesem Grund ermittle ich in
solchen Fällen lediglich den Oracle Release, um zu verstehen, mit welchen Oracle Features
ich es zu tun habe und welche Tuning-Methoden ich einsetzen kann. Als nächstes über-
prüfe ich, wie hoch die CPU-Auslastung im Moment ist und worauf die Sessions warten.
Sehr oft werden solche Performanz-Probleme durch die nicht performanten SQL-Anwei-
sungen verursacht. In den Abschn. 17 und 18 sind einige Methoden präsentiert, wie man
die problematischen SQL-Anweisung möglichst schnell und ohne großen Aufwand ermit-
teln und tunen kann.
Es kann sein, dass nicht die ganze Datenbankanwendung von einem Performanz-Pro-
blem betroffen ist, sondern nur ein bestimmter Prozess. In diesem Fall kann beispielswei-
se ein SQL-Tracing helfen, das Problem zu klären. Das SQL-Tracing ist im Abschn. 6.1.5
beschrieben. Man kann in diesem Fall auch einige Skripte einsetzen, die für eine Session
relevant sind.
In einigen Situationen findet der Kunde selbst die Ursache des Performanz-Problems,
kann aber diese Ursache nicht beseitigen. Oft wenden sich die Kunden mit den problema-
tischen SQL-Anweisungen, die sie nicht tunen können, an mich. In so einem Fall fange ich
direkt mit SQL-Tuning an. Wenn ich keinen Zugang zu der Datenbank habe, sind meine
Möglichkeiten beim Tuning ziemlich begrenzt. Deshalb habe ich ein so großes Interesse an
den effektiven Methoden des Remote-SQL-Tuning. Das sind die Methoden, die das SQL-
Tuning ohne Datenbankzugang ermöglichen. Einige Ansätze des Remote-Tuning sind im
Abschn. 18.5 beschrieben.
16.4
Umgehungslösungen (Workarounds)
Dieser Abschnitt ist eine Hymne auf die Workarounds. Es gibt Leute, die keine Umge-
hungslösungen ausstehen können. Sie erklären es damit, dass man mit einem Workaround
nicht das eigentliche Problem löst, sondern lediglich dessen Symptome bekämpft. Ich
möchte hier meine Argumentation für die Workarounds darstellen.
Die Workarounds im Allgemeinen und im IT-Bereich im Einzelnen sind zwangsläufig not-
wendig und nicht vermeidbar. Da es keine fehlerfreien Software-Systeme gibt, muss man diese
Tatsache in Kauf nehmen und lernen, mit den Fehlern zu leben, weil man nicht jeden Fehler be-
seitigen kann. Ohne die Umgehungslösungen ist solch eine Koexistenz einfach nicht möglich.
Es ist nur eine Frage des Blickwinkels, was man als das eigentliche Problem betrach-
tet. Wenn ein System akute Performance Probleme hat, weil beispielsweise der Optimizer
einen suboptimalen Ausführungsplan für eine SQL-Anweisung generiert, ist das eigent-
liche Problem für mich das Performanz-Problem und nicht ein Problem des Optimizer.
Oft ist ein Workaround die einzige Möglichkeit, ein bestehendes Problem zu umgehen.
