Ein SQL-Plan kann sich nach neuen Statistiken, einem Release Update, veränderten Datenmengen oder einer Parameteränderung verändern. Das Ergebnis ist oft nicht sofort ein Fehler, sondern eine schleichende Verschlechterung der Antwortzeit. SQL-Plan-Management (SPM) bietet dafür einen kontrollierten Mechanismus: Der Optimizer darf nur bekannte oder geprüfte Pläne verwenden.
1. Plan-Historie und Baselines trennen
Die Plan-Historie beschreibt, welche Ausführungspläne für ein SQL beobachtet wurden. Eine SQL-Plan-Baseline enthält dagegen die Pläne, die der Optimizer verwenden darf. Ein neuer Plan kann also zunächst bekannt, aber noch nicht akzeptiert sein.
Diese Trennung ist für die Governance wichtig. Nach einer Änderung sollten DBAs nicht blind den ersten neuen Plan freigeben, sondern Laufzeit, Ressourcenverbrauch, Bind-Varianten und fachliche Tests vergleichen. Erst danach wird ein Plan weiterentwickelt und als akzeptierter Kandidat übernommen.
2. Regressionen schneller erkennen
Oracle AI Database 26ai verbessert Automatic SQL Plan Management: Planänderungen werden bereits beim Parse erkannt; nach der ersten Ausführung kann die Performance mit früheren Plänen verglichen werden. Wird eine Verschlechterung festgestellt, kann ein geeigneter bekannter Plan wieder erzwungen werden.
Damit diese Automatik zuverlässig arbeitet, braucht sie aussagekräftige Vergleichsdaten. Überwachen Sie nicht nur die durchschnittliche Laufzeit, sondern auch Buffer Gets, CPU, I/O, Ausführungsfrequenz und Fehler. Ein schneller Einzelaufruf kann bei hoher Frequenz trotzdem die falsche Wahl sein.
3. Real-Time-Schutz und Hintergrundprüfung
SPM kann Regressionen in Echtzeit während der Ausführung bewerten oder über Hintergrundaufgaben historische Workload-Daten analysieren. Der Echtzeitweg reduziert die Zeit bis zu einer Reaktion; die Hintergrundprüfung kann zusätzliche Alternativpläne und längerfristige Trends einbeziehen.
Beide Ansätze brauchen klare Grenzen. Für besonders kritische SQLs sollten bekannte Baselines, ein fachlicher Smoke-Test und eine nachvollziehbare Freigabe existieren. Automatische Reparatur ist besonders hilfreich als Sicherheitsnetz, sollte aber nicht dazu führen, dass schlechte Pläne oder unklare Abhängigkeiten dauerhaft unsichtbar bleiben.
4. SPM in Release- und Patch-Prozesse integrieren
Ein Datenbank-Upgrade oder ein Release Update ist ein guter Anlass, die wichtigsten SQLs vorab zu erfassen und nach der Änderung erneut zu bewerten. Vergleichen Sie Planänderungen mit der Performance-Baseline und markieren Sie bewusst akzeptierte Verbesserungen. Nicht jede Planänderung ist eine Regression.
Auch Indexänderungen, Partitionierung und geänderte Applikationsversionen gehören in den Kontext. Eine Baseline kann einen stabilen Plan sichern, aber sie kann nicht helfen, wenn ein benötigter Index gelöscht oder ein Objekt grundlegend verändert wurde.
5. Praktische DBA-Checkliste
- Top-SQL und Service-Level als Performance-Baseline dokumentieren.
- Plan-Historie, akzeptierte Baselines und nicht akzeptierte Kandidaten unterscheiden.
- CPU, I/O, Buffer Gets, Laufzeit und Ausführungsfrequenz gemeinsam bewerten.
- SPM-Verhalten in Test, Patch- und Upgrade-Fenstern kontrolliert prüfen.
- Automatische Reparaturen, Freigaben und Ausnahmen im Change-Prozess protokollieren.
- Baselines regelmäßig auf veraltete Pläne, fehlende Objekte und unnötige Bindung prüfen.
Fazit
SQL-Plan-Management in Oracle AI Database 26ai verbindet schnelle Regressionserkennung mit der bewährten Idee geprüfter Plan-Baselines. DBAs gewinnen dadurch Zeit und Stabilität, wenn sie die Automatik mit Performance-Baselines, Tests und sauberer Governance begleiten. So bleibt der Optimizer anpassungsfähig, ohne kritische Workloads jedem Planwechsel schutzlos auszuliefern.
Weiterführend: Oracles Überblick zu SQL Plan Management, die Verwaltung von SQL-Plan-Baselines und die Neuerungen in Oracle AI Database 26ai.