Hallo Philipp,
Ich benutze die Merge-Operation, um eine Tabelle upzudaten
bzw. zu befüllen.
Da mehrere Millionen Datensätze bei Inserts vorkommen können,
muss der Undo-Tablespace extrem groß sein.
Was verstehst Du unter „extrem groß“? Wenn ich unter „mehrere Millionen“ einmal 10 Millionen annehme und eine durchschnittliche Länge des Datensatzes mit 1k annehme (was ziemlich viel ist, das wären 46 NUMBERs), dann brauchst Du einen UNDO von rund 10 GB. Natürlich wäre noch zu beachten, dass andere Sessions evtl. auch noch Platz brauchen, aber solche Batch-Inserts macht man ja meist ohnehin zu Niedrig-Last-Zeiten. Angesichts der momentan üblichen Plattengrößen sehe ich da jedenfalls kein Problem - zumindest weniger, als bei den Zwischendruch-Commits (s.u.)
Gibt es die Möglichkeit, zwischendurch ein commit auszuführen,
z.B. alle 100.000 Sätze, damit der Tablespace immer wieder
freigegeben wird?
Ein Statement ist atomar, d.h. Du kannst nicht bei der Bearbeitung eines einzelnen Statements zwischendurch commits ausführen. Was natürlich geht ist sowas wie:
INSERT INTO myTab SELECT * FROM otherTab WHERE pk_col between 1 AND 100000;
COMMIT;
INSERT INTO myTab SELECT * FROM otherTab WHERE pk_col between 100001 AND 200000;
COMMIT;
[…]
Ich kann davon aber nur abraten: Was passiert, wenn Du beim 5. INSERT ein Problem bekommst? Wie kriegst Du die bereits eingefügten/veränderten Sätze wieder raus? Sind die Daten, die eine andere Session währenddessen liest konsistent, wenn sie teilweise geänderte und teilweise alte Sätze liest? Wie gehst Du mit dem gefürchteten „snapshot too old“ um?
Wie gesagt - ich denke die Größe des UNDO TS ist da bei weitem das kleinere Übel.
Danke für Deine Unterstützung!
Hoffe geholfen zu haben und stehe für Rückfragen gerne zur Verfügung.
Gruß
Martin