Database Reference
In-Depth Information
16.3
Wo und wie fängt man beim Performance Tuning an?
Das ist die Lieblingsfrage aller Anfänger. Es gibt hier kein allgemeines Rezept, da jeder
Spezialist das Performance Tuning nach seiner eigenen Art und Weise macht. In diesem
Abschnitt teile ich mit, wo und wie ich bei Performance Tuning anfange.
Der Anfang des Performance Tuning hängt von der Situation ab. Nehmen wir zunächst
einen allgemeinen Fall. Eine Datenbank leidet an einem akuten Performanz-Problem, und
es ist nicht klar, was dieses Problem verursacht. Wenn diese Datenbank neu für mich ist,
würde ich diese Datenbank zunächst schnell kennenlernen (falls die Lage mit der Perfor-
manz nicht „lebensbedrohlich“ ist). Ich ermittle dabei die folgenden Informationen:
• welcherOracleReleaseistes,
• isteseinRAC-Systemodereine„single“Instanz,
• wiegroßistdieDatenbank,
• wievieleDatenbankprozesselaufenaufderjeweiligenDatenbankinstanz,
• isteseineOLTP-AnwendungodereinDatawarehouse,
• wiesinddieParametereinstellungen,gibtesdortirgendwelcheAuffälligkeiten,
• gibtesFehlermeldungenimAlertlog,
• sinddieRedologsordnungsgemäßkonfiguriert,
• werdenirgendwelchebesondereFeaturesvonOracleeingesetzt,
• usw.
Die meisten dieser Informationen kann man mit dem Skript dbconfig_html11.sql und mit
der Routineprüfung der Datenbankstatistiken ermitteln, die im Abschn. 4.2.1 beschrie-
ben sind. Falls ich ausreichend Zeit habe, untersuche ich die Datenbank etwas länger, um
ihre Besonderheiten besser zu verstehen. Wie das beim Performance Tuning helfen kann,
habe ich bereits an einigen Beispielen gezeigt. Weiter ermittle ich die CPU-Betriebssys-
temstatistiken, die CPU-Datenbankstatistiken und die Wartezustände der Datenbank, um
zu verstehen, in welchem Bereich das Performanz-Problem liegt. Diesen Ansatz habe ich
bereits im Abschn. 3 ausführlich beschrieben. Ich arbeite immer mit einem Tool, das die
grafische Auswertung vom AWR- oder vom Statspack-Repository ermöglicht. Die Vorteile
der grafischen Auswertungen haben wir bereits im Abschn. 12.2 besprochen. Die weitere
Vorgehensweise ist stark davon abhängig, was die Analyse der CPU-Statistiken und der
Wartezustände ergibt. Manchmal kann man gar keine Performanz-Engpässe entdecken,
da die CPU-Auslastung minimal ist und keine gravierenden Wartezustände vorliegen. In
so einem Fall sagen manche Datenbankadministratoren, dass das Performanz-Problem
außerhalb der Datenbank liegt. Das ist aber nur eine mögliche Erklärung. Es kann sein,
dass das jeweilige System so großzügig konfiguriert ist, dass man die meisten Performanz-
Probleme nicht auf der Systemebene sieht. Es ist auch möglich, dass das jeweilige Problem
sehr lokal und aus diesem Grund unauffällig ist. Normalerweise sind es reine SQL-Proble-
me, und es ist sinnvoll, nach den problematischen SQL-Anweisungen zu suchen. Manch-
mal ist es gar nicht so einfach. Ich habe eines Tages ein System untersucht, das so eigen-
artig konzipiert war, dass die Anwendungsperformanz von einer einzigen unauffälligen
