Jonathan Lewis hat zuletzt zwei Artikel zum Thema Truncate veröffentlicht, in denen er ein paar grundsätzliche Erläuterungen zu Verhalten gibt:
- Truncate: erzeugt kleine Mengen von undo und redo, da nur die Metadaten für Space-Management und Dictionary Informationen protokolliert werden müssen. Diese Aussage überprüft der Autor durch einen Test, bei dem er die Sequenz "switch logfile, truncate table, dump logfile" ablaufen lässt. Ein interessantes Detail in diesem Zusammenhang ist, dass die data_object_id eines zugehörigen Index nach dem Truncate niedriger ist als die data_object_id der Tabelle, was damit zu tun hat, dass der Index vor der Tabelle truncated wird und somit zuerst eine neue Id erhält. Vor allem aber liefert der Artikel eine Übersicht zur (vermuteten) Schrittabfolge beim Truncate mit den erforderlichen Space-Management-Operationen (für Index und Tabelle) und den Änderungen der Dictionary Objekte. Auffällig ist, dass die Zahl der commits im Rahmen des Tests höher ausfällt als erwartet, aber es sieht so aus, dass die eigentliche Truncate-Operation in einer einzigen Transaktion zusammengefasst ist, während die übrigen Transaktionen weitere Aufräumarbeiten beim Space Management enthalten.
- Truncate – 2: zeigt, dass man das implizite commit eines Truncate mit Hilfe einer autonomen Transaktion daran hindern kann, vorangehende DML-Operationen festzuschreiben (was nicht weiter überrascht).
Keine Kommentare:
Kommentar veröffentlichen