[ORACLE] UNDO Management Vorteile / Nachteile

[moo_kuh]

Hallo Kollegen,

ich beschäftige mich gerade intensiver mit den Thema Oracle Datenbanken (notgedrungen) und habe gerade viele Artikel über das UNDO Management gelesen.

Da ich mit Oracle 9i angefangen habe und dort bisher auch nur das AUTOMATIC UNDO Management verwendet habe, wollte ich mal wissen was für Vorteile das manuelle Management mit sich bringt (Rollbacksegemente).

Aber ich konnte eigentlich bisher keinen Vorteil der "manuellen" Methode entdecken. Es ist nur mehr Aufwand die Größen und Anzahl der Rollbacksegmente zu pflegen.

Den einzigen Vorteil, den ich mir im Moment vorstellen könnte ist, das ich einer Transaktion ein bestimmtes Rollback Segment zuweisen kann, und ich für verschiedene Anwendungsbereiche verschieden große Rollbacksegemente habe bzw. gebe.

Aber sonst?

Vielleicht könnt ihr mich mal aufklären und wieder ein bischen schlauer machen :confused:

Grüße

die moo_kuh

[Amstelchen]

ich vertrete hier das KISS-prinzip: so einfach und überschaubar wie möglich. UNDO so gross, wie für die grösste kapazität an UPDATES notwendig ist. sollte auf heutigen systemen auch vom speicherplatz kein hindernis mehr sein. auch kenne ich keinen DBA, der freiwillig auf MANUAL UNDO fährt; das jonglieren mit rollbacksegmenten und deren extents ist doch mühsam - und um das ganze auch etwas im auge zu behalten, aus v$rollstat wird halt v$undostat. wobei da nicht viel zu pflegen ist, ausser vielleicht die undo_retention. ausserdem, wer 9i einsetzt und von DBMS_FLASHBACK gebrauch macht (oftmals täglich!), benötigt sowieso automatisches UNDO.

gründe genug, zumindest aus meiner sicht.

s'Amstel

[sayso]

Hi,

wenn wir schon beim Thema sind.

Wie werden eigentlich Transaktionen gehandelt, die mit "Rollback" zurückgerollt wurden. Gilt für diese Änderungen/Transaktionen auch die undo_redention oder fliegen diese sofort aus dem UNDO Tablespace?

Gruß

sayso

[moo_kuh]

Wenn wir gerade den Thread erweitern, hätte ich auch noch ne Frage:

Allokieren die Schattenprozesse direkt Undo-Segmente?

Damit meine ich z.B. wie temp-segmente im Temporary Tablespace.

Oder funktioniert das über den DBWR oder über einen anderen Oracle Prozess?

Vielen Dank

[Jasper]

Allokieren die Schattenprozesse direkt Undo-Segmente?

Damit meine ich z.B. wie temp-segmente im Temporary Tablespace.

nein, undo-datenblöcke werden wie normale datenblöcke behandelt. das 'concepts'-buch in der oracle doku beschreibt es recht gut.

-j

[Jasper]

Wie werden eigentlich Transaktionen gehandelt, die mit "Rollback" zurückgerollt wurden. Gilt für diese Änderungen/Transaktionen auch die undo_redention oder fliegen diese sofort aus dem UNDO Tablespace?

es fliegt eigentlich nichts aus dem undo-tablespace, wäre zu aufwändig. die blöcke werden einfach überschrieben. uncommitted undo blocks gehören nicht mehr zu aktiven transaktionen, werden daher nicht mehr benötigt und zum überschreiben freigegeben.

undo_retention bezieht sich nur auf committed undo data.

-j

[moo_kuh]

nein, undo-datenblöcke werden wie normale datenblöcke behandelt. das 'concepts'-buch in der oracle doku beschreibt es recht gut.

-j

Oha... das ist ja ziemlich "übel".

Gut für die Performance mag es nicht schlecht sein aber nach meinen Verständnis passiert doch folgendes:

Der SMON Prozess allokiert ja beim Start der DB X Undo-Segmente (abhängig von den Sessions Parametern). Er verwaltet ja auch während der Laufzeit die Segmente (setzt online, offline, allokiert neue für jede Transkation etc...).. soweit so gut...

Ich kopiere mal aus der Doku:

the strategy with Automatic Undo is to have no more than one transaction per undo segment if possible, therefore, Oracle keeps creating new ones if there is space in the undo tablespace.

Und nun meine "Theorie":

Wenn die Undo-Segmente genauso gehandhabt werden wie normale Datenblöcke, werden sie ja zuerst in der SGA (Buffer Cache) editiert/geupdatet und dann nach einen CKP-Event in die Datenfiles geschrieben. Nebenbei werden alle Statements ja auch im Redolog mitprotokolliert.

Das heisst die DML Statements im UNDO Tablespace selbst benötigen keinen Commit oder werden gleich commited, da im Falle eines Recovers die Einträge im UNDO Tablespace ja nicht commited wären und somit evtl. nichts zurückgerollt werden könnte. (für nicht commitete transaktionen!)

Beim Recovery werden ja erst die Redologs (bzw. Archivelogs) applied und dann die nicht commiteten Transkationen mit Hilfe des UNDO Tablespaces zurückgerollt... wenn die Daten aber im UNDO Tablespace noch nicht durch ein CKP-Event geschrieben wurden, müssen diese ja auch aus den Redologs applied und commited werden..

Benötigen Daten im UNDO Tablespace also keinen Commit oder wie funzt das?

Danke :uli

[Jasper]

Oha... das ist ja ziemlich "übel".

eigentlich nicht, ist ziemlich clever.

Wenn die Undo-Segmente genauso gehandhabt werden wie normale Datenblöcke, werden sie ja zuerst in der SGA (Buffer Cache) editiert/geupdatet und dann nach einen CKP-Event in die Datenfiles geschrieben. Nebenbei werden alle Statements ja auch im Redolog mitprotokolliert.

stimmt, bis auf Undo-Segmente == Datenblöcke.

Beim Recovery werden ja erst die Redologs (bzw. Archivelogs) applied und dann die nicht commiteten Transkationen mit Hilfe des UNDO Tablespaces zurückgerollt... wenn die Daten aber im UNDO Tablespace noch nicht durch ein CKP-Event geschrieben wurden, müssen diese ja auch aus den Redologs applied und commited werden..

genauso ist es. alle daten, also auch undo-daten werden durch die redo-informationen in der rollforward-phase ab dem letzten checkpoint wiederhergestellt. die anschliessende rollback-phase verwendet die wiederhergestellten undo-daten für das zurückrollen aller nicht committeten transaktionen.

Benötigen Daten im UNDO Tablespace also keinen Commit oder wie funzt das?

oracle kennt autonome transaktionen, also transaktionen innerhalb einer transaktion. rekursive sql-statements werden damit committet ohne die umgebende transaktion zu committen.

das elegante an der sache ist, dass einzig und allein die redologs für ein recovery wichtig sind. angenommen, mir geht der undo-tablespace verloren, wie sollte der wiederhergestellt werden, wenn die daten direkt in den undo-tablespace (wie temp-tablespace) geschrieben werden? undo-daten sind aktive daten und müssen vor ausfall geschützt werden, dass wird perfekt durch die absicherung mit redo erledigt.

-j

[moo_kuh]

das elegante an der sache ist, dass einzig und allein die redologs für ein recovery wichtig sind. angenommen, mir geht der undo-tablespace verloren, wie sollte der wiederhergestellt werden, wenn die daten direkt in den undo-tablespace (wie temp-tablespace) geschrieben werden? undo-daten sind aktive daten und müssen vor ausfall geschützt werden, dass wird perfekt durch die absicherung mit redo erledigt.

Ahhh! Wenn das so ist, dann ist es natürlich ziemlich clever

Ich denke mal, das war früher aber mit den Rollbacksegmenten das selbe, wenn sie "verloren" gegangen sind/wären (habe bisher eben nur mit dem Automatic Undo gearbeitet)

Naja nu is ja alles klar...

Vielen Dank Jasper :nett:

[Jasper]

Ich denke mal, das war früher aber mit den Rollbacksegmenten das selbe, wenn sie "verloren" gegangen sind/wären (habe bisher eben nur mit dem Automatic Undo gearbeitet)

ja, das prinzip hat sich nicht geändert. der unterschied zwischen MUM und AUM liegt nur in der verwaltung der segmente.

-j

[moo_kuh]

Hallo Jungs,

ich habe noch eine ergänzende Frage zu den UNDO Segmenten mit Automatic Undo Management...

und zwar folgendes:

Nach welchen Regeln gehen die Segmente Online bzw. Offline?

Solange die Transaktion noch nicht commited ist bleibt das Segment mit den "Snapshot des alten Wertes" auf jedenfall online, aber danach?

Geht es sofort offline nachdem die Transaktion commited wurde, oder bleibt es noch die undo_retention online?

Oder bleibt das Segment sogar noch länger online, wenn ein "SELECT STATEMENT" noch den alten Snapshot benötigt?

Danke

Bei Automatic Undo Managment gibt es doch nur die 2 Statis? (ONLINE und OFFLINE)

Gruß

die moo_kuh

[Jasper]

Nach welchen Regeln gehen die Segmente Online bzw. Offline?

AFAIK bleiben in AUM die segmente während der laufzeit der instanz immer online. ansonsten funktioniert flashback nicht.

-j