AWR-Report: vier Sprünge statt vierzig Seiten
Der Report ist ein Differenzbild zwischen zwei Momentaufnahmen, und wer das Zeitfenster zu groß wählt, bekommt saubere Durchschnittswerte über ein Problem, das zwölf Minuten gedauert hat.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Report ist nicht zu lang, er wird nur falsch gelesen
Der übliche Einstieg besteht darin, im Report nach etwas Auffälligem zu suchen. Auf vierzig Seiten mit mehreren hundert Kennzahlen findet man immer etwas: eine Trefferquote von 91 Prozent, ein Wartereignis mit einem unbekannten Namen, eine Anweisung mit einer sehr großen Zahl dahinter. Daraus entsteht eine Maßnahme, die nichts verbessert, weil die Kennzahl nie die Ursache war.
Die Trefferquote des Buffer Cache ist dafür das beste Beispiel. Der Wert steigt zuverlässig, wenn eine Anwendung mit einem schlechten Ausführungsplan dieselben Blöcke millionenfach aus dem Cache liest. Ein System mit 99 Prozent kann also deutlich kränker sein als eines mit 90. Wer daraufhin den Cache vergrößert, macht die schlechte Abfrage nur billiger und lässt sie im System.
Der zweite Fehler betrifft den Ausschnitt. Ein Report über acht Stunden mittelt die Nachtstunden mit dem Vormittag, und die Spitze zwischen 9:15 und 9:30 Uhr verschwindet vollständig im Durchschnitt. Der Report kann nur beantworten, was innerhalb seines Fensters passiert ist, und je größer das Fenster, desto weniger sagt er über einen konkreten Vorfall aus.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Aufbau im Detail
Der Aufbau
Report-Kopf > Load Profile > Top 10 Foreground Events > Time Model > SQL ordered by Elapsed Time > Segment Statistics - 01 Der Rahmen
Report-KopfOben stehen Instanzname, Anfang und Ende der beiden Momentaufnahmen sowie Elapsed Time und DB Time. Prüf zuerst, ob dazwischen ein Neustart lag, denn dann ist der Report unbrauchbar. Der Vergleich von Elapsed Time und DB Time entscheidet anschließend, ob sich das Weiterlesen überhaupt lohnt.
- 02 Der Charakter der Last
Load ProfileKennzahlen je Sekunde und je Transaktion, darunter Redo Size, Logical Reads, Executes, Parses und Hard Parses. Hier erkennst du, ob eine schreibende Batchlast oder eine Masse kurzer Transaktionen läuft. Ein hoher Anteil harter Parses ist ein eigener Befund und hat mit den Ausführungsplänen der einzelnen Anweisungen nichts zu tun.
- 03 Wohin die Zeit geflossen ist
Top 10 Foreground EventsDie zehn Wartereignisse der Vordergrundprozesse, sortiert nach Gesamtwartezeit, mit Anzahl, durchschnittlicher Wartezeit und Anteil an DB Time. DB CPU steht als eigene Zeile dazwischen. Genau diese Liste beantwortet, ob du ein Problem mit dem Speichersystem, mit Sperren oder mit der CPU hast.
- 04 Die Gegenprobe
Time ModelDie Zeit noch einmal aufgeteilt nach Tätigkeit statt nach Wartegrund, etwa sql execute elapsed time, parse time elapsed und PL/SQL execution elapsed time. Die Werte überlappen sich und summieren sich deshalb nicht auf hundert Prozent. Nützlich ist der Abschnitt vor allem, um zwischen Parsen und Ausführen zu unterscheiden.
- 05 Die Verursacher
SQL ordered by Elapsed TimeAnweisungen mit Gesamtlaufzeit, Anzahl der Ausführungen, Laufzeit je Ausführung und Anteil an DB Time. Rechne Anteil mal DB Time, dann weißt du, wie viel Zeit eine Behebung überhaupt einsparen kann. Steht dort eine Anweisung mit 400.000 Ausführungen zu je 8 Millisekunden, ist das ein Aufrufproblem der Anwendung und kein Planproblem.
- 06 Die Zuordnung zu Objekten
Segment StatisticsDie Abschnitte zu Segmenten nach logischen und physischen Lesevorgängen sowie nach Sperrkonflikten verbinden die Wartereignisse mit konkreten Tabellen und Indizes. Das ist der Schritt, mit dem aus einem Wartereignis eine Maßnahme wird, etwa ein fehlender Index oder eine ungünstig belegte Tabelle.
Wenn es nicht funktioniert
Das siehst du
Die Trefferquote des Buffer Cache liegt bei 99 Prozent, das System ist trotzdem langsam.
Warum
Die Quote misst nur, welcher Anteil der Blockzugriffe aus dem Cache bedient wurde. Ein schlechter Ausführungsplan, der dieselben Blöcke millionenfach anfasst, treibt sie nach oben statt nach unten.
Was hilft
Die Quote ignorieren und stattdessen die logischen Lesevorgänge je Ausführung in der Anweisungsliste betrachten. Dort steht, welche Anweisung zu viele Blöcke anfasst.
Das siehst du
Der Report umfasst acht Stunden, sämtliche Werte wirken unauffällig.
Warum
AWR bildet Differenzen zwischen zwei Momentaufnahmen und mittelt alles dazwischen. Eine Spitze von zwölf Minuten verschwindet in acht Stunden vollständig.
Was hilft
Zwei benachbarte Momentaufnahmen rund um den Vorfall wählen. Ist das Raster zu grob, lässt sich eine Momentaufnahme auch von Hand erzeugen, bevor der nächste Testlauf startet.
Das siehst du
Ein Wartereignis fällt durch Millionen Vorkommen auf, obwohl sein Zeitanteil klein ist.
Warum
Die Anzahl sagt nichts über die Wirkung. Ereignisse mit sehr kurzer Einzelwartezeit sammeln große Zahlen an, ohne relevante Zeit zu verbrauchen.
Was hilft
Ausschließlich nach Zeitanteil und Gesamtwartezeit gehen. Die Spalte mit der durchschnittlichen Wartezeit sagt zusätzlich, ob das Speichersystem oder die schiere Menge das Problem ist.
Das siehst du
Die Zahlen im Report passen nicht zu dem, was die Anwendung gemeldet hat.
Warum
Der Report gilt für die gesamte Instanz. Eine einzelne langsame Anfrage kann in der Summe aller Sitzungen komplett untergehen, und in einer RAC-Umgebung deckt ein Instanz-Report nur einen Knoten ab.
Was hilft
Für einzelne Vorgänge auf Sitzungsebene messen, also SQL-Trace oder die Abtastung aktiver Sitzungen. Bei RAC den Report je Instanz erzeugen und die Knoten vergleichen.
Das siehst du
Zwischen den beiden Momentaufnahmen liegt ein Neustart der Instanz.
Warum
Die Zähler beginnen beim Start wieder bei null, die Differenz zwischen den Momentaufnahmen ergibt dann negative oder sinnlose Werte.
Was hilft
Den Zeitraum so wählen, dass er vollständig zwischen zwei Starts liegt. Der Report weist einen Neustart im Kopfbereich aus, ein Blick dorthin spart die ganze Fehlersuche.
Die vier Sprünge, und wohin du danach schaust
- 01 DB Time gegen die Fensterlänge zeigt, wie ausgelastet die Instanz war.
- 02 Das Load Profile verrät den Charakter der Last, etwa viele harte Parses.
- 03 Die Top-10-Events sagen, worauf gewartet wurde, sortiert nach Zeitanteil.
- 04 Die Liste nach Elapsed Time nennt die Anweisungen hinter diesem Anteil.
- 05 Erst danach lohnt der Blick in Segment- und Instanzstatistiken.
Was du nach dieser Seite aus einem Report herausliest
Die Reihenfolge unten ist keine Geschmacksfrage, sondern folgt der Logik der Zahlen: erst der Charakter der Last, dann wohin die Zeit geflossen ist, dann wer sie verursacht hat. Jeder Schritt schränkt den nächsten ein.
Das Fenster passend schneiden
Nimm zwei Momentaufnahmen, die den Vorfall eng umschließen, im Zweifel dreißig oder sechzig Minuten. Für den Vergleich holst du dir denselben Ausschnitt vom Vortag, dann siehst du, was tatsächlich anders war.
DB Time gegen Elapsed Time stellen
Elapsed Time ist die verstrichene Uhrzeit, DB Time die aufsummierte Zeit aller Sitzungen in der Datenbank. 240 Minuten DB Time in einem Fenster von 60 Minuten bedeuten vier durchgehend beschäftigte Sitzungen, und erst dieses Verhältnis sagt, ob die Instanz überhaupt ausgelastet war.
Das Load Profile als Charakterbild lesen
Zeilen wie Executes, Parses, Hard Parses, Redo Size und Logical Reads je Sekunde beschreiben, welche Art von Last läuft. Viele Hard Parses bei wenigen unterschiedlichen Anweisungen verweisen auf fehlende Bindevariablen, lange bevor du eine einzelne SQL-ID ansiehst.
Wartereignisse nach Zeit gewichten
Die Top-10-Liste ist nach Gesamtwartezeit sortiert, nicht nach Anzahl. Ein Ereignis mit Millionen Vorkommen und drei Prozent Zeitanteil ist unwichtig, eines mit zweitausend Vorkommen und sechzig Prozent Anteil ist die Spur.
Die Anweisungsliste nach der richtigen Spalte sortieren
SQL ordered by Elapsed Time zeigt, wo die Wanduhrzeit geblieben ist, SQL ordered by Gets die Blockzugriffe. Steht oben eine Anweisung mit sehr kleiner Einzellaufzeit, ist die Häufigkeit das Problem und nicht der Plan.
Aussagen sauber begrenzen
Ein AWR-Report gilt für die Instanz, nicht für eine Sitzung. Ob eine einzelne Anfrage langsam war, beantwortet er nicht; dafür brauchst du ein SQL-Trace oder die Abtastung der aktiven Sitzungen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wie der Report entsteht und was das für seine Aussage bedeutet
AWR schreibt in festen Abständen Momentaufnahmen der Systemzähler in den SYSAUX-Tablespace. In der Voreinstellung passiert das einmal pro Stunde, und die Daten werden acht Tage aufbewahrt. Der Report selbst ist nichts anderes als die Differenz zwischen zwei dieser Momentaufnahmen, umgerechnet auf die dazwischenliegende Zeit.
Daraus folgt alles Weitere. Du kannst nur Fenster auswerten, für die zwei Momentaufnahmen existieren, du kannst innerhalb eines Fensters nichts feiner auflösen, und nach Ablauf der Aufbewahrung lässt sich nichts mehr rekonstruieren. Tritt ein Vorfall regelmäßig zur selben Uhrzeit auf, lohnt es sich deshalb, das Intervall vorübergehend zu verkürzen, statt hinterher zu raten.
Ein Hinweis zum Umfeld: Oracle ordnet AWR und die zugehörigen Ansichten dem Diagnostics Pack zu, das gesondert lizenziert wird. Was du davon nutzen darfst, steht in deinem Vertrag und in der Lizenzdokumentation, und das gehört einmal geklärt, bevor jemand aus Gewohnheit awrrpt.sql aufruft.
Der Weg von der Wartezeit zur Maßnahme
Ein Wartereignis benennt den Zustand, nicht die Ursache. db file sequential read heißt, dass einzelne Blöcke von der Platte geholt wurden, typischerweise über einen Index, und das ist zunächst normal. Interessant wird die durchschnittliche Wartezeit: Liegt sie im einstelligen Millisekundenbereich, arbeitet das Speichersystem ordentlich und die Menge ist das Problem. Liegt sie deutlich darüber, sieh dir das Speichersystem an.
db file scattered read verweist auf mehrblockige Lesevorgänge, also auf vollständige Tabellen- oder Indexdurchläufe. Ob das ein Problem ist, hängt vom Anwendungsfall ab; in einem Auswertungslauf ist es gewollt, in einer Einzelabfrage aus der Anwendung selten. log file sync bedeutet, dass Sitzungen auf die Bestätigung ihres Commits warten, und die häufigste Ursache dafür ist nicht ein langsames Log, sondern eine Anwendung, die je Zeile committet.
buffer busy waits und die enq-Ereignisse zeigen Konkurrenz um dieselben Blöcke oder Sperren. Hier hilft der Abschnitt zu den Segmenten weiter, weil er das Ereignis einem Objekt zuordnet. Ein klassisches Muster ist ein Index über eine fortlaufende Nummer, bei dem alle Einfügungen auf denselben rechten Rand treffen.
Vergleichen schlägt bewerten
Für die meisten Kennzahlen im Report gibt es keinen guten Zielwert. Ob 12.000 logische Lesevorgänge je Sekunde viel sind, hängt vom System ab. Deshalb ist ein zweiter Report vom Vortag aus derselben Uhrzeit das nützlichste Werkzeug: Alles, was gleich geblieben ist, scheidet aus der Ursachensuche aus.
Zwei Zeiträume lassen sich auch direkt gegenüberstellen, awrddrpt.sql erzeugt dafür einen Vergleichsbericht. Das nimmt dir das Nebeneinanderlegen ab und hebt die Abweichungen hervor. Für wiederkehrende Fragen ist außerdem awrsqrpt.sql interessant, der Bericht zu einer einzelnen SQL-ID zwischen zwei Momentaufnahmen, weil er alle Pläne zeigt, die in diesem Bereich verwendet wurden, und damit einen Planwechsel sichtbar macht.
Ein Planwechsel ist ohnehin die Ursache, die am häufigsten übersehen wird. Dieselbe Anweisung, gestern in zwei Sekunden, heute in vier Minuten, hat meist nichts an sich verändert, sondern einen anderen Ausführungsplan bekommen, etwa nach neuen Statistiken oder wegen einer anderen Belegung der Bindevariablen.
Was der Report nicht kann
Er kennt keine einzelne Anfrage. Wenn jemand meldet, dass eine Maske seit gestern langsam ist, kannst du im Report zwar nachsehen, ob die Instanz insgesamt anders arbeitet, den einzelnen Vorgang findest du dort aber nicht. Dafür gibt es ein SQL-Trace über die betroffene Sitzung.
Er kennt außerdem nichts außerhalb der Datenbank. Wartet die Anwendung auf einen Webservice, steht davon nichts im Report, die Datenbank sieht dann schlicht eine untätige Sitzung. Und in einer RAC-Umgebung beschreibt ein Instanz-Report immer nur einen Knoten, während die Last womöglich ungleich verteilt ist.
Nimm den Report deshalb als das, was er ist: die belastbarste Zusammenfassung dessen, womit eine Instanz in einem Zeitraum beschäftigt war. Die These entsteht dort, der Beweis oft woanders.
Dazu passende Kurse
Wer solche Reports regelmäßig auf den Tisch bekommt, holt aus den Oracle-Trainings zu Performance und Diagnose am meisten heraus.
Erst die Zeit zu verteilen und dann zu optimieren, funktioniert in jedem System gleich, deshalb passen Datenbankkurse rund um Laufzeiten und Abfragepläne auch zu gemischten Landschaften.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Super Schulung, in der der Trainer auch auf eigene Fragestellungen eingegangen ist.
Super Grundlagenschulung mit allen wichtigen Punkten und hilfreichen Tipps!
Schön, sich 5 Tage ungestört mit Postgres beschäftigen zu können.
Häufige Fragen
Wie groß sollte das Zeitfenster sein?
Womit fange ich an, wenn ich den Report zum ersten Mal öffne?
Was ist der Unterschied zur Abtastung aktiver Sitzungen?
Wie erzeuge ich einen Report auf der Kommandozeile?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Datenbanken-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Von der Kennzahl zur Ursache
Aus Wartereignissen und Ausführungsplänen eine belastbare These zu bauen, arbeiten die Oracle-Kurse bei cmt an echten Reports durch.