Oracle Database · · 3 Min.

Automatic In-Memory in 26ai

Wie der Column Store häufig genutzte Daten erkennt und DBAs Speichergrenzen kontrollieren.

Der In-Memory Column Store hält Daten zusätzlich zum Row Store in einer spaltenorientierten Struktur. Das kann analytische Abfragen beschleunigen, kostet aber reservierten Speicher und muss zur tatsächlichen Workload passen. Oracle AI Database 26ai erweitert Automatic In-Memory, sodass die Datenbank den Arbeitsdatensatz dynamischer verwalten und bestimmte Performance-Funktionen selbst bewerten kann.

Einordnung: Automatic In-Memory ist eine workload-basierte Optimierung. Die Datenbank entscheidet, welche Segmente und Spalten populiert oder verdrängt werden; Speicher, PDB-Grenzen und fachliche Erwartungen bleiben trotzdem DBA-Verantwortung.

1. Hot Data statt pauschaler Vollbelegung

Bei INMEMORY_AUTOMATIC_LEVEL werden Zugriffsstatistiken und interne Spalteninformationen verwendet, um häufig genutzte Segmente als Arbeitsdatensatz zu erkennen. Kühle Bereiche können verdrängt oder stärker komprimiert werden, während häufig abgefragte Daten im Column Store bleiben.

Das ist besonders nützlich bei wechselnden Workloads: Monatsabschlüsse, saisonale Abfragen oder neue Reporting-Strecken können den Hot Data-Bestand verändern. Prüfen Sie dennoch, ob der erkannte Arbeitsdatensatz zum Service-Level passt. Ein selten ausgeführter, aber kritischer Monatsreport darf nicht allein wegen geringer Frequenz aus der Planung fallen.

2. Die Automatisierungsstufe bewusst wählen

Automatic In-Memory kann mit unterschiedlichen Stufen betrieben werden. Bei HIGH entscheidet Oracle weitgehend selbst über Population, Eviction und bestimmte Kompressionsentscheidungen. Niedrigere Stufen lassen mehr Vorgaben des DBAs bestehen. Der Standard ist zunächst deaktiviert, deshalb gehört die Aktivierung in einen geplanten Change.

Beginnen Sie mit einer Baseline: Antwortzeiten, CPU, I/O, In-Memory-Nutzung, Populate-Dauer und relevante SQLs. Aktivieren Sie die Automatik zunächst in Test oder auf einer weniger kritischen Umgebung und vergleichen Sie die Ergebnisse über einen repräsentativen Zeitraum statt nur über einen einzelnen Lauf.

3. Speicher und PDBs begrenzen

INMEMORY_SIZE zählt zur SGA-Planung und kann in einer Multitenant-Umgebung auch pro PDB gesetzt werden. Ohne eigene PDB-Grenze kann eine PDB den geerbten CDB-Wert nutzen. Das macht eine klare Quoten- und Kapazitätsplanung wichtig, besonders wenn mehrere PDBs konkurrierende Analyse-Workloads haben.

In 26ai kann Automatic In-Memory Sizing die In-Memory Area abhängig vom Nutzen des Column Stores dynamisch anpassen, sofern die Voraussetzungen der konkreten Plattform erfüllt sind. Das reduziert manuelle Arbeit, ersetzt aber nicht die Prüfung von SGA, PDB-Verbrauch, Ausweichverhalten und möglichen Auswirkungen auf andere Speicherbereiche.

4. Neustart und Populate-Zeit einplanen

Die In-Memory-Kopie liegt im Speicher und wird nach einem Neustart wieder aufgebaut. Während dieser Populate-Phase kann ein Teil der Daten bereits aus dem Column Store und ein anderer Teil aus dem Row Store gelesen werden. Für Wartungsfenster und SLAs sollte trotzdem dokumentiert sein, wann die gewünschte analytische Leistung wieder erreicht wird.

Monitoring sollte daher nicht nur die konfigurierte Größe anzeigen, sondern auch Population, Eviction, belegte Kapazität, Hotness und die Ausführung der betroffenen SQLs. Ein voller Column Store ist nicht automatisch ein Fehler; problematisch wird es, wenn wichtige Workloads dauerhaft ausweichen oder Populate-Zyklen mit Produktionslast kollidieren.

5. Praktische DBA-Checkliste

  1. Analytische Ziel-SQLs, Baseline und erwartete Datenfrische dokumentieren.
  2. INMEMORY_AUTOMATIC_LEVEL, INMEMORY_SIZE und CDB-/PDB-Grenzen prüfen.
  3. Automatic In-Memory zunächst in einer repräsentativen Test- oder Pilotumgebung beobachten.
  4. Populate, Eviction, SGA, CPU, I/O und SQL-Laufzeiten gemeinsam überwachen.
  5. Neustarts, Patchfenster und Wiederaufbau des Column Stores in das Runbook aufnehmen.
  6. Nach Änderungen am Workload regelmäßig prüfen, ob der erkannte Arbeitsdatensatz noch fachlich passt.
Praxisregel: Automatische Auswahl bedeutet nicht automatische Priorisierung. Kritische Reports brauchen weiterhin eine explizite Baseline und einen Test, der die fachliche Verfügbarkeit nach Neustart oder Speicherknappheit bestätigt.

Fazit

Automatic In-Memory in Oracle AI Database 26ai kann den Column Store besser an wechselnde Workloads anpassen und DBAs von manueller Pflege entlasten. Der sichere Betrieb entsteht durch abgestufte Aktivierung, PDB-Limits, Speicher-Monitoring und realistische Tests rund um Neustart und Populate-Zeit.

Weiterführend: Oracles Dokumentation zur Automatic-In-Memory-Verwaltung, die Referenz zu INMEMORY_SIZE und die Neuerungen in Oracle AI Database 26ai.