Tablespace voll: erst Luft schaffen, dann suchen
ORA-01653 mitten im Nachtlauf ist kein Grund zum Raten, denn drei Abfragen zeigen dir, welcher Tablespace wirklich am Limit steht und welches Segment ihn gefüllt hat.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Fehler meldet sich nachts, entstanden ist er vor Wochen
Der Ablauf ist fast immer derselbe: Um halb drei bricht der Ladelauf mit ORA-01653 ab, unable to extend table, und am Morgen steht die Frage im Raum, wer schnell Platz macht. Der Reflex, einfach die Datei zu vergrößern, ist nicht falsch, er beendet aber nur das Symptom. Wenn dieselbe Datei zum dritten Mal im Quartal wächst, hat niemand mehr im Blick, wie viel Speicher die Datenbank eigentlich braucht.
Teuer wird die Sache an zwei Stellen. Erstens läuft eine abgebrochene Transaktion zurück, und ein Rollback über mehrere Millionen Zeilen dauert länger als das Einfügen selbst, während die Anwendung wartet. Zweitens greifen viele Teams zu AUTOEXTEND ON MAXSIZE UNLIMITED, und dann füllt die Datenbank irgendwann das Dateisystem, in dem auch die Archive-Logs liegen. Ab diesem Moment steht nicht mehr ein Ladelauf, sondern die ganze Instanz.
Die Ursachen sind dabei zählbar. Entweder wächst ein Segment planmäßig und niemand hat es fortgeschrieben, oder ein Job hat mehr geschrieben als sonst, oder es war überhaupt kein Nutzdaten-Tablespace, sondern Undo oder Temp. Die drei Fälle unterscheiden sich schon an der Fehlernummer, und danach brauchst du keine zehn Abfragen mehr, sondern zwei.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Symptom, Ursache, Lösung
Symptom
Der nächtliche Ladelauf bricht mit ORA-01653 ab, am Morgen zeigt der Tablespace aber 30 Prozent frei.
Ursache
Der Platz war zum Zeitpunkt des Abbruchs weg und ist danach wieder freigeworden. Das passiert, wenn der Ladelauf mit direktem Pfad geschrieben oder unterwegs ein Index aufgebaut hat: Diese Extents liegen oberhalb der Hochwassermarke oder in einem temporären Segment und gehen beim Zurückrollen an den Tablespace zurück. Ein gewöhnliches INSERT verhält sich anders, dort bleibt der belegte Platz dem Segment zugeordnet. Gemeinsam ist beiden Fällen, dass ein Ladelauf kurzzeitig deutlich mehr Platz braucht als sein Endergebnis.
Lösung
Die Belegung nicht am Morgen ablesen, sondern regelmäßig wegschreiben. Für den Ladelauf selbst gilt: Ein Neuaufbau eines Index braucht während der Laufzeit die alte und die neue Struktur gleichzeitig, dieser Spitzenbedarf gehört in die Planung.
Symptom
MAXSIZE steht auf UNLIMITED, im Dateisystem sind 200 GB frei, die Datei wächst trotzdem nicht weiter.
Ursache
Die Datendatei hat die Blockgrenze einer klassischen Datei erreicht, bei 8 KB Blockgröße also etwa 32 GB. UNLIMITED bedeutet nur, dass Oracle keine eigene Obergrenze setzt, nicht dass es keine gibt.
Lösung
Mit ALTER TABLESPACE ... ADD DATAFILE eine zweite Datei anhängen, Oracle verteilt neue Extents über alle Dateien des Tablespace. Wächst dieser Bereich dauerhaft stark, ist mittelfristig ein Bigfile-Tablespace die ruhigere Lösung.
Symptom
Der Tablespace füllt sich weiter, obwohl in den letzten Wochen mehr gelöscht als eingefügt wurde.
Ursache
Mit DROP entfernte Tabellen liegen im Papierkorb und belegen ihren Platz unverändert weiter. Gelöschte Zeilen wiederum geben ihre Blöcke nur innerhalb des Segments frei, die High-Water-Mark bleibt stehen.
Lösung
DBA_RECYCLEBIN prüfen und gezielt purgen. Für die betroffenen Tabellen ALTER TABLE ... ENABLE ROW MOVEMENT setzen und anschließend SHRINK SPACE ausführen, danach die Indizes zusammenführen oder neu aufbauen.
Symptom
Ein Auswertungslauf meldet ORA-01652, die Anwendung läuft weiter und der Datentablespace ist halb leer.
Ursache
Nicht die Nutzdaten, sondern der Temp-Tablespace ist voll. Eine einzelne Anweisung sortiert oder verbindet mehr Daten, als in den Arbeitsspeicher passt, und lagert den Rest nach Temp aus.
Lösung
In V$TEMPSEG_USAGE die Sitzung und die SQL-ID ermitteln und den Ausführungsplan ansehen. Meist steckt eine fehlende Einschränkung oder eine falsch geschätzte Verbindung dahinter, eine größere Tempfile behebt nur das Symptom.
Symptom
Ein Löschlauf über viele Millionen Zeilen scheitert mit ORA-30036 im Undo-Tablespace.
Ursache
Die Transaktion hält ihren gesamten Undo bis zum Commit. Steht der Undo-Tablespace zusätzlich auf RETENTION GUARANTEE, darf Oracle noch nicht abgelaufene Undo-Daten nicht überschreiben und lässt lieber die laufende Transaktion scheitern.
Lösung
Den Löschlauf in Portionen mit zwischenzeitlichem Commit zerlegen. Geht es um einen sehr großen Anteil der Tabelle, ist es günstiger, die verbleibenden Zeilen in eine neue Tabelle zu kopieren und zu tauschen. Erst danach über mehr Undo nachdenken.
Fünf Fragen in fester Reihenfolge
- 01 Die Fehlernummer sagt dir, ob Nutzdaten, Temp oder Undo betroffen sind.
- 02 DBA_TABLESPACE_USAGE_METRICS zeigt die Belegung samt möglicher Ausdehnung.
- 03 Ist Autoextend aus oder MAXSIZE erreicht, hilft RESIZE oder eine zweite Datei.
- 04 DBA_SEGMENTS nennt das Segment, das den Zuwachs verursacht hat.
- 05 Papierkorb und alte Partitionen geben oft mehr frei als jede Vergrößerung.
Was du nach dieser Seite in zwanzig Minuten erledigst
Alle Abfragen laufen lesend gegen Data-Dictionary-Views und brauchen kein Wartungsfenster. Die Reihenfolge ist bewusst gewählt: erst die Zahl, die die Wahrheit sagt, dann die Sofortmaßnahme, dann die Frage, wer den Platz belegt.
Die belastbare Belegungszahl
DBA_FREE_SPACE zeigt nur den freien Platz in den bereits angelegten Dateien und ignoriert, dass Autoextend noch Luft nach oben hat. DBA_TABLESPACE_USAGE_METRICS rechnet die mögliche Ausdehnung mit ein und liefert den Prozentwert, auf den du dein Monitoring stellst.
Die drei Fehlernummern auseinanderhalten
ORA-01653 und ORA-01654 betreffen Tabelle und Index in einem normalen Tablespace, ORA-01652 meldet ein Temp-Segment und ORA-30036 den Undo-Tablespace. Die Nummer entscheidet, wo du überhaupt suchst.
Platz schaffen ohne Ausfall
ALTER DATABASE DATAFILE ... RESIZE vergrößert eine vorhandene Datei im laufenden Betrieb, ALTER TABLESPACE ... ADD DATAFILE hängt eine zweite an. Beides geht online, solange das Dateisystem mitspielt.
Die Obergrenze bewusst setzen
AUTOEXTEND ON NEXT 512M MAXSIZE 30G nimmt dir den nächtlichen Anruf ab, ohne das Dateisystem preiszugeben. MAXSIZE UNLIMITED tut genau Letzteres, und zwar irgendwann auf Kosten der Archive-Logs.
Die größten Segmente sichtbar machen
Eine Abfrage auf DBA_SEGMENTS, gruppiert nach Segmentname und absteigend nach Bytes sortiert, beantwortet in Sekunden, ob eine Tabelle, ein Index oder ein LOB gewachsen ist.
Gelöschtes ist nicht weg
Eine mit DROP entfernte Tabelle liegt im Papierkorb und belegt ihren Platz unverändert weiter. DBA_RECYCLEBIN zeigt sie, PURGE gibt den Platz frei, und danach sieht die Belegungszahl oft ganz anders aus.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Welche Zahl du liest, entscheidet über die Diagnose
DBA_FREE_SPACE summiert die freien Extents in den Dateien, die schon existieren. Ein Tablespace mit einer 8-GB-Datei, die zu 95 Prozent gefüllt ist, aber auf 32 GB wachsen darf, sieht dort dramatisch aus und ist es nicht. Umgekehrt wirkt ein Tablespace harmlos, dessen Datei bereits auf MAXSIZE steht, solange noch ein paar hundert Megabyte frei sind.
DBA_TABLESPACE_USAGE_METRICS löst das, weil die View die zulässige Ausdehnung in TABLESPACE_SIZE einrechnet und USED_PERCENT als Wert liefert, auf den du eine Schwelle legen kannst. Für die Sofortdiagnose reicht der Blick in diese eine View, für die Frage nach dem Warum brauchst du zusätzlich DBA_DATA_FILES mit den Spalten AUTOEXTENSIBLE, BYTES und MAXBYTES.
Bei Temp gilt eine eigene Logik. Temp-Segmente werden nach der Sortierung nicht an das Betriebssystem zurückgegeben, sondern intern als frei markiert und wiederverwendet. Eine Tempfile, die dauerhaft als voll erscheint, ist deshalb erst dann ein Problem, wenn tatsächlich ORA-01652 auftritt. V$TEMPSEG_USAGE zeigt, welche Sitzung und welche Anweisung den Platz gerade halten.
Die 32-Gigabyte-Wand, gegen die viele laufen
Eine klassische Datendatei nimmt typischerweise gut vier Millionen Blöcke auf. Bei der üblichen Blockgröße von 8 KB ergibt das rund 32 GB, und zwar unabhängig davon, ob du MAXSIZE UNLIMITED geschrieben hast. Die Datei hört einfach auf zu wachsen, und der nächste Ladelauf bricht ab, obwohl im Dateisystem reichlich Platz frei ist.
Dagegen gibt es zwei Wege. Der schnelle ist eine zweite Datendatei im selben Tablespace, denn Oracle verteilt neue Extents über alle Dateien. Der langfristige ist ein Bigfile-Tablespace, der genau eine, dafür sehr große Datei besitzt und die Dateiverwaltung erspart. Bigfile passt gut zu ASM oder zu einem Speichersystem, das Redundanz selbst erledigt, und schlecht dorthin, wo du Dateien einzeln über Speicherklassen verteilen willst.
Prüf vor jedem Vergrößern beides: wie viel die Datei noch darf und wie viel das Dateisystem noch hat. Ein RESIZE auf einen Wert, den das Dateisystem nicht hergibt, scheitert sofort. Ein erfolgreiches RESIZE, das die letzte Reserve des Volumes verbraucht, trifft dich später an einer unangenehmeren Stelle, nämlich beim Schreiben der Archive-Logs.
Undo und Temp folgen anderen Regeln als Nutzdaten
ORA-30036 im Undo-Tablespace heißt nicht zwangsläufig, dass der Bereich zu klein bemessen ist. Zwei Ursachen kommen zusammen: Entweder darf die Datei nicht weiter wachsen, weil Autoextend aus ist oder MAXSIZE erreicht wurde, oder Oracle darf noch nicht abgelaufene Undo-Blöcke nicht überschreiben. Steht der Tablespace auf RETENTION GUARANTEE, hat die Einhaltung von UNDO_RETENTION Vorrang vor der laufenden Transaktion, und die Transaktion scheitert, obwohl Platz vorhanden wäre. Diese Einstellung ist sinnvoll, wenn Flashback-Abfragen zugesichert sind, sie verlangt aber einen entsprechend großen Undo-Tablespace.
Der zweite häufige Fall ist eine einzelne sehr lange Transaktion. Ein Löschlauf über zwanzig Millionen Zeilen in einem einzigen Commit hält seinen kompletten Undo bis zum Schluss. Zerlegst du solche Läufe in Blöcke und committest zwischendurch, sinkt der Bedarf sofort. Bei Temp ist der Auslöser dagegen meist eine einzige Anweisung mit einer ungünstigen Verbindungsreihenfolge, die eine Hash-Verbindung nach Temp auslagert.
Merk dir die Richtung: Bei Nutzdaten fragst du, welches Segment gewachsen ist. Bei Undo und Temp fragst du, welche Sitzung gerade läuft. V$TEMPSEG_USAGE und V$TRANSACTION beantworten die zweite Frage, DBA_SEGMENTS die erste.
Wer hat den Platz belegt, und war es überhaupt geplant
Sortier DBA_SEGMENTS absteigend nach BYTES und sieh dir die ersten zwanzig Zeilen an. Drei Muster tauchen dabei immer wieder auf. Erstens ein LOB-Segment, das größer ist als die Tabelle, zu der es gehört; DBA_LOBS verbindet Tabellenname und Segmentname, sonst steht dort nur ein kryptisches SYS_LOB-Kürzel. Zweitens ein Index, der größer ist als seine Tabelle, oft nach Massenlöschungen. Drittens eine Partition, die nie ausgelagert wurde, weil das Archivierungskonzept nie umgesetzt worden ist.
Freigewordener Platz innerhalb eines Segments kommt nicht von selbst zurück. Nach einem großen DELETE bleibt die High-Water-Mark stehen, die Blöcke sind leer und trotzdem dem Segment zugeordnet. ALTER TABLE ... SHRINK SPACE gibt sie frei, setzt aber ENABLE ROW MOVEMENT voraus und funktioniert nur bei automatischer Segmentverwaltung. Bei Indizes wirkt ein COALESCE oder ein Neuaufbau, wobei der Neuaufbau während der Laufzeit zusätzlichen Platz braucht.
Wenn nichts davon greift, ist die ehrliche Antwort oft, dass die Datenbank schlicht gewachsen ist. Dann gehört eine Zahl in die Kapazitätsplanung: Wie viele Gigabyte kommen pro Monat dazu, und wann ist die aktuelle Grenze erreicht. Diese Zahl bekommst du nur, wenn die Belegung wöchentlich protokolliert wird, statt im Moment des Fehlers einmal abgelesen zu werden.
Dazu passende Kurse
Genau diese Handgriffe, vom Vergrößern der Datendatei bis zur Undo-Einstellung, üben die Oracle-Kurse für den täglichen Datenbankbetrieb am laufenden System.
Das Muster wiederholt sich bei anderen Systemen, deshalb lohnt ein Blick auf Datenbankkurse, die den laufenden Betrieb abdecken auch dann, wenn bei dir nicht nur Oracle läuft.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Super Schulung, in der der Trainer auch auf eigene Fragestellungen eingegangen ist.
Super Grundlagenschulung mit allen wichtigen Punkten und hilfreichen Tipps!
Schön, sich 5 Tage ungestört mit Postgres beschäftigen zu können.
Häufige Fragen
Kann ich eine Datendatei im laufenden Betrieb vergrößern?
Warum zeigt der Temp-Tablespace dauerhaft fast hundert Prozent Belegung?
Ist AUTOEXTEND ON eine gute Voreinstellung?
Bringt ein Bigfile-Tablespace Nachteile?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Datenbanken-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Speicherfehler, die man kommen sieht
Belegung, Autoextend und Undo so einzustellen, dass die Datenbank nicht nachts anruft, gehört bei cmt zum festen Teil der Oracle-Administration.