Eine Abfrage ist langsam – aber warum? Ein Explain Plan beschreibt einen möglichen Ablauf, nicht den tatsächlichen Verlauf einer bestimmten Ausführung. Real-Time SQL Monitoring ergänzt diese Sicht: Der Bericht verfolgt eine einzelne SQL- oder PL/SQL-Ausführung und zeigt unter anderem Laufzeit, CPU, Ein-/Ausgabe sowie Statistiken je Ausführungsschritt. Das ist besonders hilfreich bei langen Statements, parallelen Abfragen und schwer reproduzierbaren Lastspitzen.
Die richtige Ausführung auswählen
SQL Monitor erfasst geeignete Statements automatisch, wenn sie beispielsweise mindestens fünf Sekunden CPU- oder I/O-Zeit benötigen oder parallel ausgeführt werden. Deshalb reicht die SQL-ID allein nicht immer aus: Dasselbe Statement kann mehrfach laufen. Für die Untersuchung muss die konkrete Ausführung identifiziert werden – anhand von SQL-ID, Startzeit und Ausführungs-ID. So landet man nicht versehentlich beim Bericht eines anderen Laufs.
Im Monitoring-Bericht lässt sich anschließend der Ablauf pro Planoperation untersuchen. Vergleichen Sie verstrichene Zeit und CPU-Zeit mit den gelesenen Zeilen, Pufferzugriffen, physischen Lesevorgängen und Warteanteilen. Ein Schritt mit viel verstrichener Zeit, aber wenig CPU kann auf I/O oder eine andere Warteursache hindeuten. Hohe Zeilenzahlen oder stark abweichende tatsächliche Mengen an einer Planoperation lenken den Blick auf Datenverteilung, Filter und Kardinalitätsschätzungen.
Vom Bericht zur Diagnose
Ein brauchbarer Ablauf im Betrieb sieht so aus:
- SQL-ID und Startzeit des auffälligen Laufs festhalten; bei Parallelität auch die Ausführungs-ID berücksichtigen.
- Den SQL-Monitor-Bericht genau für diese Ausführung erzeugen.
- Im Plan den Schritt mit dem größten Zeit- oder Ressourcenanteil lokalisieren.
- Ist-Werte mit erwarteten Zeilenmengen vergleichen und anschließend gezielt Daten, Prädikate, Statistiken oder Zugriffspfade prüfen.
- Änderungen mit derselben repräsentativen Last erneut messen.
Der Bericht liefert Hinweise, aber keine automatische Erklärung. Beispielsweise beweist ein hoher I/O-Anteil noch nicht, dass ein neuer Index sinnvoll ist. Erst Datenverteilung, Selektivität, parallele Last und Schreibkosten vervollständigen die Diagnose. Für eine breitere, historische Sicht auf viele Sessions und Statements sind andere Workload-Werkzeuge zuständig; SQL Monitor ist vor allem die Lupe für eine konkrete Ausführung.
Lizenz vor Nutzung prüfen
Wichtig für den produktiven Einsatz: Real-Time SQL Monitoring und die zugehörigen Ansichten beziehungsweise APIs gehören zum Oracle Tuning Pack. Prüfen Sie daher vor Aktivierung und Verwendung die Lizenzbedingungen Ihrer Edition und Umgebung. Auch ein /*+ MONITOR */-Hinweis ist kein lizenzfreier Umweg; er fordert die Überwachung gezielt an und setzt die passende Konfiguration und Berechtigung voraus. Die Funktion sollte nicht ohne vorherige Lizenzprüfung in ein Runbook oder Skript aufgenommen werden.
Fazit
SQL Monitor verbindet den Plan mit Messwerten einer realen Ausführung. Wer die Ausführung eindeutig auswählt, den dominanten Plan-Schritt anhand von Laufzeit und Ressourcen eingrenzt und jede Änderung unter vergleichbarer Last misst, kommt von „SQL ist langsam“ zu einer belastbaren Diagnose. Der erste Schritt bleibt dabei die Lizenzprüfung.
Weiterführend: Oracles Hinweise zum Monitoring von Datenbankoperationen, die DBMS_SQLTUNE-Dokumentation und die Lizenzinformationen zur Datenbank.