Oracle AI Database 26ai: Tablespaces sicher verkleinern

Veröffentlicht am 25.09.2026 · Verfasst von Veysi Guenay

Wenn Tabellen oder Indizes gelöscht und Daten dauerhaft bereinigt werden, wird der Platz innerhalb eines Tablespaces zwar wieder nutzbar. Das Datafile bleibt dadurch aber nicht automatisch kleiner. Oracle AI Database 26ai erweitert die Möglichkeiten für Tablespace Shrink: DBAs können belegte Segmente innerhalb eines Tablespaces reorganisieren und anschließend Speicher am Ende der Datafiles zurückgeben – für SMALLFILE- und BIGFILE-Tablespaces.

Wichtig: Tablespace Shrink ist eine Speicheroperation mit möglichen I/O- und Lock-Auswirkungen. Sie sollte nach Analyse, Wartungsfenster und Rückfallplanung erfolgen, nicht als spontane Reaktion auf eine volle Platte.

1. Interne Freigabe ist nicht gleich Datafile-Shrink

Nach dem Löschen von Objekten entstehen freie Extents. Diese können von anderen Segmenten im Tablespace wiederverwendet werden, ohne dass sich die Dateigröße im Storage verändert. Wenn Speicherplatz außerhalb der Datenbank tatsächlich zurückgewonnen werden soll, muss freier Raum am Ende des Segments beziehungsweise Datafiles erreichbar gemacht werden.

Prüfen Sie deshalb zuerst, ob das Ziel interne Wiederverwendung oder eine kleinere Datei ist. Für die Kapazitätsplanung sind beide Fälle unterschiedlich: freie Extents helfen dem Tablespace, während ein erfolgreicher Shrink zusätzlich Storage freigeben kann.

2. Analyse vor der Reorganisation

Beginnen Sie mit dem Segment- und Tablespace-Bestand. `DBA_SEGMENTS`, `DBA_EXTENTS` und `DBA_FREE_SPACE` zeigen, welche Objekte Platz belegen und wo freie Bereiche liegen. Die Analyse sollte auch Autoextend, Backup-Strategie, ASM- oder Filesystem-Grenzen und den erwarteten zukünftigen Wachstumspfad einbeziehen.

Für die eigentliche Planung stellt Oracle mit DBMS_SPACE Verfahren bereit, die ungenutzten Platz und die Position des High Water Mark untersuchen. Erst wenn klar ist, welche Segmente bewegt werden müssten und wie viel Platz realistisch frei wird, lässt sich ein sinnvolles Ziel für die Verkleinerung festlegen.

3. SMALLFILE und BIGFILE unterscheiden

Ein BIGFILE-Tablespace verwendet ein großes Datafile, ein SMALLFILE-Tablespace mehrere kleinere Dateien. In Oracle AI Database 26ai werden Datenbanken aus DBCA-Templates standardmäßig stärker auf BIGFILE-Tablespaces ausgerichtet; bestehende Datenbanken behalten jedoch ihre bisherige Tablespace-Struktur.

Das ändert die Betriebsplanung: Bei BIGFILE muss ein einzelnes großes Datafile korrekt analysiert und verkleinert werden. Bei SMALLFILE sind mehrere Dateien, deren Wachstum und die Verteilung der Segmente zu berücksichtigen. Ein automatisiertes Runbook sollte daher zuerst den Tablespace-Typ und die Datafiles ermitteln.

4. Sicheres Runbook

Belegung, freie Extents, High Water Mark und Wachstum des Tablespaces dokumentieren.
Prüfen, ob ein Backup, Snapshot oder Restore-Test für das Wartungsfenster verfügbar ist.
Auswirkungen auf I/O, laufende Sessions, Replikation und Backup-Zeit einplanen.
Shrink zunächst in einer Testumgebung mit ähnlicher Segmentverteilung durchführen.
Nach dem Lauf Dateigröße, freie Kapazität, Objektzugriff und Monitoring-Alarme kontrollieren.

Praxisregel: Niemals nur die gewünschte Endgröße raten. Ein zu aggressiver Shrink führt zu wiederholtem Wachstum und unnötiger Fragmentierung. Die Zielgröße muss aus Datenbestand, Wachstum und Reserven abgeleitet werden.

Fazit

Tablespace Shrink in Oracle AI Database 26ai ist ein praktisches Werkzeug für zurückgewinnbaren Storage, verlangt aber saubere Vorbereitung. Wer interne Freiräume, Segmentlage, Tablespace-Typ und Wachstum gemeinsam betrachtet, kann Datafiles kontrolliert verkleinern und trotzdem ausreichende Reserven für den nächsten Wachstumsschub behalten.

Weiterführend: die Oracle-Einführung zu Tablespace Shrink, der Administrator’s Guide zu Tablespaces und die Dokumentation zur Speicherfreigabe.