Database Reference
In-Depth Information
2.3.1
Performance Tuning mit 3 Datenbankparametern
Vor einigen Jahren musste ich bei einer Migration von Oracle 8.1.7 auf Oracle 10.2.0.2
mit Performance Tuning helfen, da die 10-er Testdatenbank eine miserable Performanz
aufwies. Als Ansprechpartner habe ich einen Entwickler bekommen, der sofort verkün-
dete, dass ich mich auf eine Zusammenarbeit von mindestens 3 Wochen einstellen müsse.
Er begründete es damit, dass das Tuning bei der vorherigen Migration von Oracle 7 auf
Oracle 8 auch etwa so lange gedauert hätte. Da ich andere Pläne hatte, versuchte ich eine
andere Methode zu finden, statt die SQL-Anweisungen eine nach der anderen zu tunen.
Meinen Ansprechpartner habe ich um einige Stunden gebeten, um mich zunächst um-
schauen zu können. In dieser Zeit untersuchte ich die Datenbank. Dabei suchte ich gezielt
nach irgendwelchen Besonderheiten, die mir beim Performance Tuning helfen konnten.
Und ich fand sie. Die meisten SQL-Anweisungen bei dieser Datenbank waren ähnlich auf-
gebaut. Man könnte fast alle SQL-Anweisungen in 3-4 Kategorien unterteilen. Es gab dort
z. B. sehr komplexe SQL-Anweisungen, die die Zehner von Operatoren UNIONs beinhal-
teten, in den Ausführungsplänen der anderen fand ich immer „ANTI JOIN“, usw. Wie
konnte man diese Tatsache beim Tuning gebrauchen? Meine Schlussfolgerung war sehr
einfach. Wenn eine Datenbank ein paar Typen der SQL-Anweisungen hat und diese SQL-
Anweisungen nicht performant sind, kann es sein, dass der jeweilige Oracle Release ge-
wisse Probleme gerade mit solchen Typen der SQL-Anweisungen hat. Ich suchte unter den
bekannten Problemen für 10.2.0.2 in MOS (My Oracle Support) und fand einige vermut-
lich passende. Am nächsten setzte ich 5 Parametereinstellungen als Workarounds für die
gefundenen Probleme ein. Alle Test-Cases von mir brachten eine deutliche Performanz-
Verbesserung. Nach den ausführlichen Performanz-Tests reduzierte der Kunde die Anzahl
der Parametereinstellungen auf 3, da die anderen 2 für einige SQL-Anweisungen sich un-
günstig erwiesen haben. Das hat aber die Tatsache nicht verändert, dass ich in einem Tag
mit ein paar Parametern die Datenbank getunt habe.
Eine der abgelehnten Parametereinstellungen war
_
optimizer
_
cost
_
based
_
transfor
-
mations
=
off
. Diese Parametereinstellung half mir die SQL-Anweisungen mit vielen UNI-
ONs zu beschleunigen. Diesen Trick habe ich nach diesem Fall mehrmals und meistens
mit Erfolg wieder verwendet. Sie können das selber probieren, wenn Sie eine SQL-Anwei-
sung mit mehreren nacheinander folgenden UNIONs zu tunen haben. Dabei ist folgendes
zu beachten:
• die Anzahl der UNIONs in der SQL-Anweisung muss gravierend sein, damit diese
Parametereinstellung hilft,
• dieParametereinstellung
_
optimizer
_
cost
_
based
_
transformations
=
off
kann sich auf
einige andere SQL-Anweisungen negativ auswirken. Aus diesem Grund ist es sinnvoll,
diese Einstellung mit dem Hint OPT_PARAM gezielt für die problematische SQL-
Anweisung einzusetzen (mehr Informationen zum Hint OPT_PARAM finden Sie im
Abschn. 13.2).
