Tablespace voll

[Urwi]

Hallo,

ich weiß, dass dies hier kein Administrator-Forum ist, aber vielleicht kann mir trotzdem wer helfen.

Im Enterprise Manager wird bei den Alerts <Tablespace voll/Tablespace ist 94 percent voll> angezeigt. Um den Tablespace bei Bedarf wachsen zu lassen, gebe ich folgenden Befehl ein:

ALTER DATABASE DATAFILE 'D:\APP\ORADATA\ECHT\USERS01.DBF' AUTOEXTEND ON NEXT 500M MAXSIZE UNLIMITED

Dies war vor ca. einer Woche. Nachdem ich heute nochmals kontrolliert habe, gibt es die Meldung noch immer und der Prozentsatz ist gewachsen.

Mache ich da etwas falsch?

Danke
Urwi

[defo]

Mache ich da etwas falsch?

Ich denke nicht.
Erstmal zur Prozentrechnung: Wenn Dein tablespace absolut 20 MB groß ist, ist bei 94 % Füllgrad wirklich nicht mehr viel Platz. Ist er 20 GB groß, sieht das schon anders aus.
Dann: Ein "voller" Tablespace ist nicht mit Daten gefüllt, sondern mit Segmenten, die für eine Tabelle reserviert sind. Diese Segmente können aber noch leer sein.
Du sagst nun mit Deinem Statement, das Datafile von USER1.DBF bitte automatisch(!) vergrößern um 500 MB, wenn nötig und zwar für immer und ewig.

Die Automatik lässt Oracle den Zeitpunkt also selbst wählen.

Sinnvoll wäre ggF. das Unlimited zu ändern bzw. das Tablespace File auf "handliche" Größe zu beschränken und lieber weitere Datafiles hinzuzufügen.
Je nach Filesystem gibt es Dateigrößenbeschränkungen, die dann vielleicht ersts beim Backup / Kopie / verschieben problematisch werden können.
Also ein Tablespace kann beliebig viele Files überschaubarer größe haben, dafür kann man individuell angeben, wie groß die sein sollen, initial, maximal, wachstum, absolut, ....usw.

Du kannst das auch einfach mal mit einem neuen Tablespace nachvollziehen, leg Dir einen kleinen an, definiere eine Tabelle dort hinein und schau, was passiert.
Sinnvoll sind hier natürlich kleine Größenangaben und Limits.

[Urwi]

Hallo defo,

Danke für Deine Ausführung!

Mein Tablespace ist ca. 35GB groß. Was mich irritiert ist die Tatsache, dass der Prozentsatz stetig wächst.

"Die Automatik lässt Oracle den Zeitpunkt also selbst wählen" Genau so sollte es auch sein, aber bei 94% werde ich schon nervös.

Im Moment möchte ich an diesem Zustand, dass er automatisch wächst, auch nichts ändern, weil im 1. Quartal wahrscheinlich ein neuer Server kommt, wo die DB auch neu aufgesetzt wird.

Gesetzt dem Fall, ich limitiere den Tablespace und füge noch einen weiteren hinzu, teilt Oracle dann dem neuen Tablespace auch automatisch Daten zu?

Danke
Urwi

[defo]

Gesetzt dem Fall, ich limitiere den Tablespace und füge noch einen weiteren hinzu, teilt Oracle dann dem neuen Tablespace auch automatisch Daten zu?

Also wenn es hier um ein Produktivsystem geht, solltest Du Dir das vielleicht mal etwas genauer anschauen.

Und warum solltest Du einen Tablespace limitieren und statt dessen einen anderen anlegen?

Als erstes musst Du unterscheiden zwischen Tablespace und Datafile.
Das eine ist Logik, das andere Physik.
Ein Tablespace hat einen Namen, unter Verwendung dieses Namens werden Tabellen angelegt; logisch, in diesem Tablespace.
Ein Tablespace besteht physikalisch aus Datafiles, vielleicht eins, vielleicht mehrere. Für den Tablespace, aber auch für jedes File einzeln kannst du administrative Angaben machen, wie es sich verhalten soll.
Z.B. könntest Du ein Datafile des User Tablespace auf einer anderen Platte oder in einem anderen Verzeichnis anlegen.

Das alles gilt erstmal für den Fall, dass klassisches Tablespace Management verwendet wird- weiß grad nicht die Bezeichnung.
Da gibt es verschiedene Möglichkeiten bei Oracle, die anderen kenne ich aber nicht aus eigener Erfahrung.

[Urwi]

Hallo Defo.

genau, es handelt sich um das Produktivsystem, deshalb lasse ich wenn möglich die Finger davon. Ich bin kein Admin und im Moment haben wir auch keinen. Deshalb schaue ich ein wenig drauf.

"Und warum solltest Du einen Tablespace limitieren und statt dessen einen anderen anlegen?" Weil Du in Deinem 1. Post geschrieben hast, ich solle es limitieren.

"Ein Tablespace besteht physikalisch aus Datafiles, vielleicht eins, vielleicht mehrere" Ok verstehe, unter dem Tablespace subsummieren sich Datafiles

Muss ein wenig im Internet recherchieren, wie sich TS und DF verwalten lassen.

Danke
Urwi

[kuemmelchen]

Hallo Urwi,

du muss Dir erst einmal keine Gedanken wegen dem steigenden Prozentsatz machen.
Der Prozentsatz wird auf 95, 96, 97,98, 99 100% steigen.

Ok, bei 100% bekommst du ein Problem. Aber du hast diesbezüglich schon Vorkehrungen getroffen, indem du die Anweisung:
ALTER DATABASE DATAFILE 'D:\APP\ORADATA\ECHT\USERS01.DBF' AUTOEXTEND ON NEXT 500M MAXSIZE UNLIMITED;
abgesetzt hast. Wenn deine Datei zu 100% gefüllt ist, wird sie automatisch um 500 MB vergrößert. Dann wird auch dein Prozentsatz wieder sinken.

Gruss kuemmelchen

[Urwi]

Hallo kuemmelchen,

das beruhigt mich. Ich hätte schon damit gerechnet, dass der Tablespace bereits früher vergrößert wird. Dein Wort in Gottes Ohr!

vg
Urwi

[defo]

das beruhigt mich. Ich hätte schon damit gerechnet, dass der Tablespace bereits früher vergrößert wird. Dein Wort in Gottes Ohr!

Wieso sollte das RDBMS eine Vergrößerung vornehmen, wenn noch Platz da ist?!
Ich würde mich aufregen, wenn es das täte!

Die unlimited clause also unbeschränkte Vergrößerung ist dann tückisch, wenn das Dateisystem am Ende ist, also trügerische Sicherheit.
Und nochmal, der freie Tablespace von 2,3,4% ist der, der keinem Tablesegment zugeordnet ist.
Tablesegmente sind Reservierungen je table, die nach dem gleichen Schema funktionieren wie beim Tablespace.

Ein Tablespace kann also 100% voll sein und trotzdem mit Daten befüllt werden, weil die Tablesegmente darin noch nicht voll sind. Das ist ganz normales Verhalten.
Das System steht erst, wenn in einem 100% gefüllten Tablespace ein neues Segment reserviert werden muss.

Es gibt also keinen Grund, ein Tablespace zu "sperren" und statt dessen einen anderen anzulegen. Im Gegenteil, alle definierten Tabellen sind entweder explizit per Create Anweisung oder implizit per Default einem Tablespace (z.B. "users") zugeordnet. Denen wäre es egal, wenn es einen neuen Tablespace gibt.
Wenn, dann willst Du ein neues Datafile für den bestehenden Tablespace. Das könntest Du, falls tatsächlich Platzprobleme auf dem Filesystem bestehen, woanders anlegen und wieder wachsen lassen.

[dimitri]

Wieso sollte das RDBMS eine Vergrößerung vornehmen, wenn noch Platz da ist?!
Ich würde mich aufregen, wenn es das täte!

Ruhig Blut Es gibt diverse Szenarien, in denen Oracle das macht - und zwar korrekterweise.
Direct Path Loads z.B. oder falls die Tabelle LOB Spalten enthält, viel DML drauf läuft und eine hohe undo_retention gewählt wurde.

Man sollte sich mal ansehen, um welches oder welche Objekt(e) es sich handelt. Je nach Anwendung kann das das normale Verhalten sein, oder auch auf einen Bug in dieser schließen lassen.

[defo]

Ruhig Blut

Mein Blut ist ganz ruhig.

Dass Oracle das tatsächlich in einigen Fällen macht, wusste ich nicht.
Dennoch kommt mir der Denkansatz, "mach schon mal im Voraus größer" etwas sagen wir ungewöhnlich vor.
Vielleicht wird dieses Verhalten über den Schwellwertparameter "Anzahl Schweißperlen auf der Stirn" gesteuert?

Also noch mal ernst, das ist ein sensibler Bereich. Besonders wenn man mit webbasierten (Oracle) Werkzeugen arbeitet und dort bei Tablespace Administration timeouts des Browsers bekommt ist das nicht sehr lustig. Dann lieber SQLPlus.
Ich persönlich mag Automatik in der EDV nur, wenn sie sich mir persönlich vorgestellt hat.

[kuemmelchen]

Es gibt einige Vorgänge, die automatische Abläufe besitzen, beispielsweise UNDO_MANAGEMENT=AUTO.

Ich bin froh, wenn ich Text/Bilder in einer Datei speichern kann und die Größe der Datei wird automatisch angepasst.

@defo

Das System steht erst, wenn in einem 100% gefüllten Tablespace ein neues Segment reserviert werden muss.

Nur zur Information: Das System steht auch, wenn ein bestehendes Segment durch ein weiteres Extent erweitert werden muss.

kuemmelchen

[defo]

Es gibt einige Vorgänge, die automatische Abläufe besitzen, beispielsweise UNDO_MANAGEMENT=AUTO.

Ich bin froh, wenn ich Text/Bilder in einer Datei speichern kann und die Größe der Datei wird automatisch angepasst.

@defo

Nur zur Information: Das System steht auch, wenn ein bestehendes Segment durch ein weiteres Extent erweitert werden muss.

kuemmelchen

Ja, dieser Gedanke mit der automatischen Vergrößerung von Dokumenten ist ein super Beispiel.
Word macht eine Menge bekloppte Sachen (automatisch), aber es beginnt nicht von allein das doc file zu vergrößern, wenn ich einen Screenshot anlege oder auf "Grafik einfügen" klicke.
naja, glaub ich zumindest.

Bei Extens waren wir noch nicht, aber Du hast natürlich Recht. Wichtig war mir die Aussage, dass ein voller Tablespace nicht Stillstand bedeutet. Ich wollte jetzt auch keinen Adminkurs halten.

[dimitri]

Hier werden jetzt aber mehrere Sachen miteinander vermischt.
Auf der einen Seite haben wir die automatische Vergrößerung des Datafiles bis zur Limitierung durch das OS/Filesystem oder den Plattenplatz. Im Normalfall wird man das Datafile mit der maximalen, geplanten Größe anlegen bzw. diese Vorgeben und fertig. Stelle ich ein stetiges Wachstum fest welches ich mir nicht erklären kann, muss ich dem auf den Grund gehen.

Dann haben wir den Punkt "es ist noch Platz frei, Oracle verwendet ihn aber nicht". Das ist etwas völlig anderes und es liegt nun mal in der Natur eines Direct Path Loads immer an eine Tabelle anzuhängen und keine freien Blöcke unterhalb der HWL zu nutzen. Gleiches bei LOBs. Stelle ich die undo_retention auf einen hohen Wert, dann muss die DB mehr Speicher verwenden um meine Vorgaben zu erfüllen. Works as designed.

UNDO_MANAGEMENT=AUTO muss wiederum nicht mit automatischer Erweiterung des UNDO-TS einhergehen. Wenn der UNDO-TS fixed sized ist, wird er auch nie größer werden. Im Zweifelsfall bekommt man den allseits beliebten ORA-01555. Da hilft auch keine UNDO_RETENTION, der wird in dem Fall ignoriert.