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.

Oracles Diagnosetools AWR und statspack speichern in ihren Repositories neben Ausführungsstatistiken auch Ausführungspläne ab. Diese werden regulär per INSERT-SELECT aus entsprechenden Data Dictionary-Views in die Repositories übertragen. Je mehr Statements sich im Shared Pool befinden, desto mehr SELECT-Statements werden ausgeführt und entsprechend Datenblöcke durch den Buffer Cache geschleust. Das verdrängt unter Umständen in großem Umfang Datenblöcke, die für die eigentliche Datenbankanwendung dort gepuffert waren und performancerelevant wären.

Zudem haben wir oft beobachtet, dass vergleichsweise große Shared Pools mit sehr vielen nicht-wiederverwendbaren Statements zu einer erhöhten Anzahl von „library cache: mutex X“ oder „library cache pin“ Wait-Events führen. Du kannst Cursor Sharing an der Anwendung vorbei datenbankweit mit dem Parameter CURSOR_SHARING=FORCE erzwingen. In diesem Fall ersetzt die Datenbank von sich aus Literale in SQL-Statements durch Bindevariablen.

Sind die Oracle Datenbanken auf mehrere Hosts verteilt und alle Oracle Datenbanken sollen per Alias von jedem Host aus erreichbar sein, wird es in der tnsnames.ora schnell unübersichtlich. Für eine übersichtlichere Gestaltung bietet sich der Parameter IFILE an. Dieser Parameter erlaubt die Referenzierung weiterer TNS-Alias-Dateien – und das in bis zu 3 Ebenen.