Mit einem ab­schlie­ßen­den DBMS_REDEFINITION.FINISH_REDEF_TABLE beendest du das Re­de­fi­ni­ti­on schließ­lich. Lediglich an diesem Punkt werden Ausgangs- und In­te­rims­ta­bel­le für einen kurzen Au­gen­blick gesperrt. In diesem Schritt über­trägt das Redefinition noch die letzten Daten. Ab­schlie­ßend werden die Namen zwischen Ausgangs- und In­te­rims­ta­bel­le sowie allen ab­hän­gi­gen Objekten automatisch ausgetauscht. Un­mit­tel­bar danach steht die in Schritt 2 erzeugte In­te­rims­ta­bel­le nun mit re­or­ga­ni­sier­ten Daten oder ver­än­der­ter Struktur unter dem Namen der ur­sprüng­li­chen Aus­gangsta­bel­le zur Verfügung. Alle An­wen­dun­gen, die bisher Zugriff auf die Aus­gangs­ta­bel­le hatten, greifen nun ohne den ge­rings­ten An­pas­sungs­auf­wand auf die re­de­fi­nier­te Tabelle zu. Die in Schritt 2 angelegte Interimstabelle kannst du nun droppen.

Das Löschen einer größeren Menge von Zeilen aus einer Tabelle führt in aller Regel dazu, dass die Datenblöcke der Tabelle stark fragmentiert werden. Das heißt es gibt dann also viele Blöcke, die nur wenige Daten enthalten. Diese Fragmentierung hat zwei wesentliche Nachteile:

• Verschwendung von Speicherplatz, wenn die Lücken nicht im Laufe der Zeit wieder durch neue Zeilen gefüllt werden. Da der Freiplatz fest von einer bestimmten Tabelle allokiert ist, steht er auch keinen anderen Objekten in der Datenbank zur Verfügung.
  
  
• Auch wenn der Platz nach und nach wiederverwendet wird, wirkt sich diese Fragmentierung bis dahin negativ auf die Performance aus. Der Buffer Cache der Datenbank, eine der wichtigsten Komponenten im Bezug auf Datenbankperformance, arbeitet rein blockbasiert. Folglich verschwenden Datenblöcke einer Tabelle Platz im Buffer Cache, wenn sie fragmentiert sind, da auch der leere Anteil im Block auf den Buffer Cache angerechnet wird. Die „Nutzdatenrate“ ist damit schlechter als bei unfragmentierten Blöcken, die Performance sinkt durch eine geringere Buffer Cache Hit Ratio.

Voraussetzung für die Nutzung der Flashback-Technologie ist ein großer Undo-Tablespace, um hinreichend viele Daten für Flashbackoperationen zur Verfügung zu stellen. Da die benötigte Größe des Undo-Tablespaces sehr stark von den Änderungen in der Datenbank abhängt, bietet sich hier das Auto Extend für den Tablespace an. Die Retention Guarantee stellt dabei sicher, dass die Undo-Daten ausreichend lange im Undo-Tablespace vorgehalten werden.