Blog 
Flashback Archive zum Zweiten

Das Flashback Archiv wird mehr und mehr mein Top-Oracle-Feature, da es so einfach zu implementieren ist und einen großen Vorteil hat für allen Arten von Anwendungen sowie natürlich für die Compliance.
In meinem Blog von Januar 2014 habe ich die Idee vom Flashback Daten Archiv schon erklärt. Einige von Ihnen haben vielleicht schon Zeit gefunden, es zu testen und sich über zusätzliche Features oder Verläufe gewundert, die sie nicht erwartet hatten.

Lassen Sie uns einige zusätzliche Features besprechen:

Flashback Daten Archiv und Komprimierung

Wie Sie wahrscheinlich wissen, ist das Flashback Archive nicht länger auf die Enterprise Edition oder eine seperate Lizenz beschränkt, sondern kann in der Standard Edition sowie in der Standard Edition One genutzt werden. Aber in jedem Fall werden die Flashback Archive Tabellen jeden Tag partitioniert bzw. eine neue Partition davon angelegt! Da die Erweiterungs-Größe einer einzelnen Partition bei 8 MB liegt, können Sie nach nur einem Monat leicht bei verschwendetem Speicherplatz im Gigabyte-Bereich landen. Andererseits: Wenn Sie all Ihre DML Operationen archivieren, könnte die Größe der entsprechenden Partition schnell 8 MB überschreiten, z.B. werden, wenn Sie eine Spalte weglassen oder umbenennen, ALLE alten Werte sofort in der entsprechenden Archiv-Tabelle gespeichert.

Mit der Option OPTIMIZE DATA werden einige Komprimierungs-Stufen zum Flashback-Bereich hinzugefügt, abhängig vom Daten-Typ bzw. der Machine (Exadata). Dies sind:

  • Advanced Row Compression
  • Advanced LOB Compression
  • Segment-Level-Compression Tiering
CREATE FLASHBACK ARCHIVE fda_opt 
     TABLESPACE fda_tablespace 
	 RETENTION 2 YEAR OPTIMIZE DATA;

In diesem Fall müssen Sie sich nicht um die Komprimierungen kümmern (solange Sie die Enterprise Edition benutzen und eine gültige Lizenz für die Advanced-Compression-Option haben), denn der FBA-Prozess wird für den besten Ansatz zur Komprimierung sorgen.

Flashback Archive Application

Tabellen werden in der Regel nicht „aus Jux und Dollerei“ erstellt sondern gehören zu ein oder mehreren Anwendungen. Die Idee von Flashback Archive Application ist es, die Flashback Data Archive Einstellungen nicht für jede Tabelle separat anzuwenden sondern alle Tabellen einer Anwendung gemeinsam zu verwalten.

Zuerst müssen Sie eine Flashback Daten Archiv „Anwendung“ erstellen:

BEGIN    
   dbms_flashback_archive.register_application (
      application_name => 'CUSTOMER',
	  flashback_archive_name => 'FBA_OPT'); 
END;

Jetzt können die einzelnen Tabellen zu der Anwendung hinzugefügt werden. In diesem Beispiel werde ich alle aktuellen Tabellen des Schemas zur Anwendung hinzufügen.

BEGIN
    FOR c_tab IN (
	    SELECT table_name
		    FROM user_tables
	)
	LOOP
	   DBMS_FLASHBACK_ARCHIVE.ADD_TABLE_TO_APPLICATION (
	      application_name => 'CUSTOMER',           
		  schema_name      => 'FBA2',           
		  table_name       => c_tab.table_name);
	   dbms_output.put_line ('Table added '||c_tab.table_name);               
	END LOOP; -- c_tab    
	COMMIT; 
END; /

Die Tabellen sind jetzt zur Anwendung hinzugefügt und die Anwendung ist so registriert, dass sie mit dem Flashback Archive benutzt werden soll, wobei die Archivierung eigentlich gar nicht aktiviert ist. Und an diesem Punkt kommt der Hauptunterschied zwischen der individuellen Verwaltung der Tabellen und der Nutzung der Anwendung ins Spiel. Während einzelne Tabellen jede für sich aktiviert oder deaktiviert werden müssen, kann die Anwendung über einen einzigen Befehl verwaltet werden:

EXECUTE dbms_flashback_archive.enable_application (
   application_name => 'CUSTOMER');

Mit einem entsprechenden Befehl kann die Archivierung außer Kraft gesetzt werden (dbms_flashback_archive.disable_application). Diese Verknüpfung gilt auch noch, wenn Sie das das Flashback Data Archive löschen. So können Sie vor umfangreichen Änderungen die Archivierung mit einem Befehl deaktivieren nach der Änderungen wieder aktivieren. Die Verwaltung wird also wesentlich vereinfacht.

Verwaltung von DDL-Befehlen

Was passiert, wenn Sie Änderungen im Tabellen-Layout machen wollen, z.B. den Namen einer Spalte ändern, eine Spalte hinzufügen oder löschen? Das war mit älteren Veröffentlichungen nicht möglich, aber mit der aktuellen Version funktioniert das ganz einfach. Eine zusätzliche Flaschback-Tabelle namens sys_fba_ddl_colmap_ wird bereit gehalten für jede normale Tabelle. Diese Tabelle listet alle Änderungen an der Struktur einer Tabelle auf.

SQL> ALTER TABLE personen DROP COLUMN bemerkung; 

Table altered. 

SQL> SELECT startscn, endscn, column_name, TYPE, historical_column_name
        FROM sys_fba_ddl_colmap_25308; 
STARTSCN  ENDSCN   COLUMN_NAME          TYPE        HISTORICAL_COLUMN_NAME 
-------- -------- -------------------- ------------ ---------------------- 
11156386          PERSID               NUMBER(10)   PERSID 
11156386          ANREDE               VARCHAR2(5)  ANREDE 
11156386          VORNAME              VARCHAR2(50) VORNAME 
11156386          NACHNAME             VARCHAR2(50) NACHNAME 
11156386          GEBURTSTAG           DATE         GEBURTSTAG 
11503985 11504152 D_11504152_BEMERKUNG VARCHAR2(20) BEMERKUNG

Wie Sie sehen, wird die gelöschte Spalte D_11504152_BEMERKUNG genannt, um zu verdeutlichen, dass diese gelöscht wurde.

Aber seien Sie sich bewusst, dass Änderungen archiviert werden und für den Fall, dass Sie eine Spalte weglassen, der gesamte Inhalt der Tabelle in der Flashback Archiv Tabelle gespeichert wird.

Historische Daten verschieben

Aber was, wenn Sie Ihre Datenbank migrieren wollen? Data Pump ignoriert einfach alle Flashback Tabellen. Also wie können wir die archivierten Informationen zum neuen Ort verschieben? Die Lösung ist: mit einer temporären Historien-Tabelle.

Da es nicht möglich ist, die Flashback Archive Tabellen zu exportieren, müssen Sie zuerst eine Interims-Tabelle erstellen, wie beispielsweise mit diesem Befehl:

CREATE TABLE adressen_archive AS SELECT * FROM SYS_FBA_HIST_25389;

Um sicherzustellen, dass man alle Daten erwischt, egal ob die Abfrage auf aktuelle Daten beschränkt ist oder nicht, sollten Sie folgenden Befehl sowohl auf der Quell- als auch auf der Ziel-Datenbank ausführen:

EXECUTE dbms_flashback_archive.extend_mappings();

Jetzt können Sie Data Pump für den Export und den Import aller Daten benutzen, trotz der Tatsache, dass „adressen_archive“ den Inhalt des Flashback Archivs enthält.

Auf der Ziel-Datenbank müssen Sie das Flashback Archive für Ihre Tabellen wieder in Kraft setzen, da diese Information beim Export-Import-Vorgang verloren geht.

ALTER TABLE adressen FLASHBACK ARCHIVE;

Und als letzten Schritt importieren Sie Ihre historischen Daten wieder in die entsprechende Flashback Archive Tabelle, indem Sie folgenden Befehl benutzen:

BEGIN
   dbms_flashback_archive.import_history (
      owner_name1 => 'FBA3',
	  table_name1 => 'ADRESSEN',
	  temp_history_name => 'ADRESSEN_ARCHIVE'); 
END; 
/

Die Richtigkeit kann verifiziert werden, indem die entsprechene Flashback Archiv Historien-Tabelle wieder abgefragt wird:

SELECT * FROM SYS_FBA_HIST_25373;

Denken Sie daran, dass die Nummer eine andere ist als auf der Quell-Datenbank.

Keine Kommentare zu “Flashback Archive zum Zweiten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Was kann CarajanDB für Sie tun?