Indizes können Abfragen deutlich beschleunigen, verursachen aber zusätzliche Schreibarbeit bei INSERT, UPDATE und DELETE. Automatic Indexing versucht, diesen Zielkonflikt anhand der tatsächlichen Workload zu bewerten. Oracle AI Database 26ai erweitert diese Bewertung unter anderem um den Einfluss von DML-Kosten und berücksichtigt zusätzliche Kandidaten wie Bereichsfilter und function-based indexes.
1. Erst die Ausgangslage sichtbar machen
Vor dem Aktivieren braucht es eine belastbare Baseline. Erfassen Sie Top-SQL, Ausführungszeiten, logische und physische Reads, DML-Raten sowie die wichtigsten Wartungsfenster. Tabellenstatistiken müssen aktuell sein, weil fehlende oder veraltete Statistiken die Kandidatenauswahl beeinflussen können.
Prüfen Sie außerdem vorhandene manuelle Indizes, unsichtbare Indizes, Partitionierung und SQL Plan Baselines. Ein automatisch vorgeschlagener Index kann technisch sinnvoll wirken, aber mit einer bestehenden Designentscheidung oder einem geplanten Schema-Change kollidieren.
2. Kandidaten zunächst unsichtbar bewerten
Automatic Indexing erzeugt Kandidaten zunächst als invisible indexes. Dadurch kann Oracle ihre Wirkung gegen relevante SQL-Ausführungen messen, ohne dass sie sofort den gesamten Optimizer-Pfad der Anwendung verändern. Erst wenn die Tests einen Vorteil zeigen, kann ein Index sichtbar und damit regulär nutzbar werden.
Diese Schutzstufe sollte im Change-Prozess erklärt werden: „automatisch erstellt“ bedeutet nicht automatisch „sofort produktiv“. DBAs sollten die Kandidaten, die getesteten SQLs und die gemessenen Verbesserungen nachvollziehbar dokumentieren.
3. DML-Kosten und Gesamtwirkung prüfen
Ein Index ist nicht kostenlos. Bei schreibintensiven Tabellen kann die zusätzliche Pflege den Gewinn einzelner SELECTs übersteigen. Genau hier setzt die erweiterte Bewertung in 26ai an: Die Entscheidung soll den Nutzen der Abfragen und den Pflegeaufwand der Indexstruktur gemeinsam betrachten.
In der Praxis lohnt sich ein Vergleich nach Workload-Typ. Für ein Reporting-Fenster kann ein Index hilfreich sein, während derselbe Index im OLTP-Spitzenfenster zusätzliche Latenz erzeugt. Beobachten Sie daher sowohl Query-Laufzeiten als auch DML-Durchsatz, Log-Volumen, Speicherverbrauch und Wartungsdauer.
4. Freigabe, Ausschluss und Rückfallplan
Definieren Sie vorab, welche Schemas, Tabellen oder Umgebungen einbezogen werden dürfen. Entwicklungs- und Testsysteme können als kontrollierte Beobachtungsfläche dienen; produktive Systeme brauchen engere Freigaberegeln. Bei kritischen SQLs sollte ein Plan für Regressionen vorhanden sein, etwa über Plan-Baselines, eine temporäre Unsichtbarkeit oder das kontrollierte Entfernen eines Indexes.
Zur Governance gehört auch die Aufbewahrung: Nicht genutzte automatische Indizes werden nach einer konfigurierbaren Zeit entfernt. Der Default ist dabei kein Ersatz für eine eigene Aufbewahrungs- und Dokumentationsregel. Prüfen Sie, ob ein später gelöschter Index noch Teil eines bekannten Performance-Fixes oder eines geplanten Releases war.
5. Praktische DBA-Checkliste
- Lizenzierung und unterstützte Datenbankkonfiguration vor der Aktivierung prüfen.
- Top-SQL, DML-Last, Statistiken und bestehende Indizes als Baseline sichern.
- Scope für Schemas und Wartungsfenster festlegen.
- Automatisch erzeugte Kandidaten und ihre Testresultate regelmäßig prüfen.
- Query-Gewinn gegen DML-Kosten, Speicher und Wartungsaufwand bewerten.
- Regressionen, Ausschlüsse und Freigaben im Change- oder Performance-Register dokumentieren.
Fazit
Automatic Indexing in Oracle AI Database 26ai kann DBAs bei wechselnden Workloads entlasten, wenn die Funktion mit Baselines, Monitoring und klaren Freigaberegeln betrieben wird. Der wichtigste Fortschritt liegt nicht in möglichst vielen neuen Indizes, sondern in einer besseren Gesamtbewertung aus Abfragegewinn und Schreibkosten.
Weiterführend: Oracles Dokumentation zu Automatic Indexing, die DBMS_AUTO_INDEX-Referenz und die Neuerungen in Oracle AI Database 26ai.