Hallo Chris!
ok, das hatte ich schon mal durch … segment ist eine
oraclegröße un nicht an Datenbankfiles gebunden…?!
Ein Segment ist eine logische Einheit innerhalb der Datenbank. Unter Oracle 8i gibt es folgende Segmentarten:
INDEX PARTITION, TABLE PARTITION, TABLE, CLUSTER, INDEX, ROLLBACK, DEFERRED ROLLBACK, TEMPORARY, CACHE, LOBSEGMENT und LOBINDEX
Ein Segment liegt immer innerhalb eines bestimmten Tablespaces, aber nicht notwendigerweise innerhalb eines einzelnen Datenfiles. Es ist (mehr oder weniger) einfach nur die Summer aller Extents, die für das gegebene Objekt alloziert sind.
ok, ich glaube die angaben in dem view habe ich verstanden die
file_id gibt die id des DBF an und zusätzlich ist die angabe
dann wahrscheinlich noch in segmente unterteilt und man kann
sich den restspeicherplatz der einzelnen segmente ansehen ?
Also DBA_FREE_SPACE hat folgende Spalten:
TABLESPACE_NAME
Der Name des Tablespaces, zu dem der freie Extent (d.h. die Gruppe von hintereinanderliegenden Blocks, die Oracle als verfügbar markiert hat) gehört. (–>DBA_TABLESPACES)
FILE_ID
Die ID des DB Files (–>DBA_DATA_FILES)
BLOCK_ID
Die ID des Blocks, an dem der freie Extent beginnt (brauchst du eher nicht).
BYTES
Eh klar.
BLOCKS
Anzahl der freien Blocks.
RELATIVE_FNO
Da schweigt sich die Doku aus. Brauchst du jedenfalls nicht…
Mit Segmenten hat der View gar nichts am Hut. Wie sehr die Extents innerhalb eines Segments gefüllt sind findest du am Besten mit dem Package DBMS_SPACE heraus (aber da sind wir dann eigentlich schon ziemlich weit im Bereich von Feintuning).
DBA_Tables: Tabelle tr_tfz_zeitpunkt; next_extent 209715200
also bin ich wohl dem Trugschluß aufgelegen das die
Extentangaben beim Create Tablespace sich auf die Tabellen
übertragen…
Bei Dictionary managed tablespaces wird überhaupt nur der NEXT-Teil des Tablespaces berücksichtigt, und das auch nur, wenn beim Anlegen der Tabelle (oder später mittels ALTER TABLE) nix anderes angegeben wurde. Die Angaben in DBA_TABLESPACES sind also nur als Default-Werte zu lesen.
(SIZE 2048M REUSE AUTOEXTEND ON NEXT 50M MAXSIZE 2048M
Die Grössenangabe ist etwas eigenwillig: Er soll ein Datenfile
von 2GB Grösse anlegen (oder falls File vorhanden dieses
verwenden), das sich bei Bedarf in Schritten von 50MB
vergrössern soll, allerdings nur bis zu einer maximalen Grösse
von 2GB…
ja, das ist etwas kompliziert, die Scripte für die Instanz
kommen vom Softwarelieferant, und da stand das wahrscheinlich
auf maxsize unlimited. da hat unsere Betriebsführung aber was
gegen und dann wird das halt dementsprechend einfach im keim
erstickt…
Das würde ich eher beim Softwarelieferant urgieren, als es dann selbst zu ändern. Es kommt immer wieder vor, dass sich die SW-Hersteller bei ihren DB-Parametern etwas überlegen (obwohl mir da die Erfahrung entschieden anderes sagt…). Wenn er keine Ahnung hat, warum er das so tut, dann kann man’s immer noch ändern.
Ich persönlich werde immer ausgesprochen böse, wenn mir jemand in meiner DB herumpfuscht 
. Im Prinzip geht es da halt auch um Wartbarkeit. Wenn ich meine DB mit einem bestimmten Konzept erstelle, dann verlasse ich mich in der Regel auch bei der Fehlersuche einmal darauf, dass die DB auch wirklich so aussieht. Wenn der Kunde da etwas geändert hat, dann kommst du in die unangenehme Lage, dem Kunden erklären zu müssen, warum er trotz Wartungsvertrag eine Fehlerbehebung zahlen soll (die Zeit nämlich, die du vergammelt hast um draufzukommen, dass du von falschen Voraussetzungen ausgehst).
Hat’s geholfen?
weiß ich nicht, ich hab noch keinerlei Rückmeldung
Im Fall des Falles einfach melden…
also wenn ich das jetzt richtig verstanden habe, dann wollte
die tabelle ein extent der größe 209715200 erstellen (das
wären dann 209.715.200 = 209MB ?) und es gab für diese größe
keinen zusammenhängenden speicher mehr im Tablespace…
Das ist von mir aus gesehen der wahrscheinlichste Grund für den Fehler. Muss aber nicht sein.
so ganz verstehe ich zwar noch nicht warum dann das rollback
segment 7 vollgelaufen ist aber ich vermute jetzt mal das die
anderen schon gefüllt waren und der rettende Commit; gefehlt
hat … oder ?
Eine Transaktion verwendet immer nur EIN Rollback Segment. Aber auch dieses kann natürlich volllaufen. Da ist es dann eigentlich völlig unerheblich, ob die anderen leer sind oder nicht. Wenn die Anzahl der Transaktionen grösser ist, als die Anzahl der RBS, dann verwenden durchaus auch mal mehrere Transaktionen das gleiche Rollback Segment, was den Prozess natürlich nochmal verkürzt.
Der Commit muss nicht notwendigerweise wirklich fehlen (also vergessen worden sein). Mitunter kann ein Commit nicht sinnvoll in einem grösseren INSERT (oder DELETE/UPDATE) abgesetzt werden. Dann muss man halt dafür sorgen, dass die RBS entsprechend gross sind. Im Extremfall kann es auch angebracht sein, eigens für eine bestimmte Transaktion ein (wirklich grosses) RBS anzulegen und dieses der Transaktion dezidiert zuzuweisen.
Gruß,
Martin
