Logo Oracle Deutschland   DBA Community  -  Mai 2014
Flashback Data Archives: Ein gutes Gedächtnis für DBA und Entwickler
Flashback Data Archives: Ein gutes Gedächtnis für DBA und Entwickler
von Heinz-Wilhelm Fabry, ORACLE Deutschland B.V. & Co. KG

Daten werden gespeichert und zum Teil lange aufbewahrt. Mitunter werden Daten nach ihrer ersten Speicherung geändert, vielleicht sogar mehrfach. Je nach gesetzlicher oder betrieblicher Vorgabe müssen die Veränderungen sogar nachverfolgbar sein. Damit sind zugleich Mechanismen gefordert, die sicherstellen, dass die Folge der Versionen lückenlos ist. Und implizit bedeutet das zusätzlich, dass die Versionen auch vor Löschen und Verändern geschützt sein müssen.

Häufig erfolgt das Versionieren über die Anwendung, mit der die Daten auch erfasst werden, und ist damit durch Umgehen der Anwendung zu unterlaufen. Die Versionierung kann auch durch Trigger erfolgen, was eventuell auf Kosten der Performance geht, denn die Transaktionslast des Systems steigt durch das Abarbeiten der Trigger. Oder die Versionierung erfolgt durch besondere Werkzeuge und ist deshalb mit höheren Kosten und / oder höherer Komplexität verbunden. Neben den genannten Schwächen der jeweiligen Lösung, bleibt bei allen drei Lösungsansätzen zusätzlich die Frage nach dem Schutz vor unerlaubtem Löschen oder Ändern versionierter Daten offen.

Flashback Data Archives lösen diese Frage, denn sie bieten nicht nur einen wirksamen Mechanismus zum Versionieren von Datensätzen, sondern sie schützen diese Versionen auch vor Veränderung und löschen sie schließlich sogar automatisch nach Ablauf ihrer Aufbewahrungsfrist. Dieser letzte Punkt mag auf den ersten Blick weniger wichtig erscheinen, aber Gesetze und Vorschriften beinhalten in der Regel nicht nur strenge Fristen zur Aufbewahrung von Daten, sondern ebenso strenge Fristen zu ihrer Löschung.

Ursprünglich wurden die Archive als eigenständige Option zur Enterprise Edition der Oracle Database 11g unter dem Namen Total Recall eingeführt - was übersetzt so viel heißt wie 'das perfekte Gedächtnis'. Ende Juni 2012 verloren die Flashback Data Archives ihren Status als eigenständige Option. Weil die Archive aber grundsätzlich komprimiert wurden, hat Oracle sie stattdessen zu einem Feature der Advanced Compression Option der Enterprise Edition (ACO) gemacht. Seit der Version 11.2.0.4 der Datenbank ist das Komprimieren aber für die Archive nicht mehr zwangsläufig, sondern optional. Damit gibt es lizenzrechtlich erneut eine Änderung: Wer die Kompression verwendet, der muss nach wie vor ACO lizensieren. Wer die Flashback Data Archives dagegen ohne Kompression verwendet - also zum Beispiel Entwickler -, dem stehen sie ab 11.2.0.4 aufwärts im Lieferumfang aller Editionen der Datenbank zur Verfügung. Diese Änderung ist in den Handbüchern zur Lizensierung der Versionen 11.2 und 12.1 der Datenbank dokumentiert.

Archive anlegen und verwalten

Das Anlegen von Archiven in einer Datenbank setzt voraus, dass das Undo Management dieser Datenbank auf AUTO steht. Zudem müssen Archive immer mindestens einem Tablespace zugeordnet werden. Sie können sich jedoch auch über mehrere Tablespaces erstrecken. Egal ob ein Tablespace oder mehrere Tablespaces: Jedes Tablespace, das Archivdaten aufnehmen soll, muss über Automatic Segment Space Management verwaltet werden. Natürlich sollten die für ein Archiv vorgesehenen Tablespaces auch über ausreichend Speicherplatz verfügen. Ist das nicht der Fall, erhält der Anwender beim Arbeiten auf einer Tabelle, für die das Archivieren eingeschaltet ist, unter Umständen die Fehlermeldung "ORA-55617: Flashback Archive NAME runs out of space and tracking on NAME is suspended", und weitere Änderungsaktionen auf dieser Tabelle werden verhindert.

Archive sind Objekte, die nur mit dem Privileg FLASHBACK ARCHIVE ADMINISTER anzulegen, zu ändern oder zu löschen sind. Die Rolle DBA enthält dieses Privileg. Ausserdem wird das Privileg CREATE TABLESPACE benötigt sowie ausreichend Quota in den Tablespaces, die von den Archiven benutzt werden sollen.

Der DBA legt mit folgendem Befehl ein Archiv an:

CREATE FLASHBACK ARCHIVE archiv1
TABLESPACE example QUOTA 100G
OPTIMIZE DATA
RETENTION 5 YEAR
Die Zeilen 2 bis 4 sind erläuterungsbedürftig. Im Beispiel ist der Tablespacename mit Quota angegeben. Fehlt die Klausel QUOTA steht das gesamte Tablespace für das Archiv zur Verfügung. Mit dem Befehl CREATE FLASHBACK ARCHIVE kann auch nur ein Tablespace angegeben werden. Soll ein Archiv mehrere Tablespaces nutzen, muss das über den Befehl ALTER FLASHBACK ARCHIVE veranlasst werden.

Die Klausel OPTIMIZE DATA steht erst in den Datenbankversionen 11.2.0.4 und 12.1 zur Verfügung. Sie bewirkt, dass die Datenbank das Archiv komprimieren kann. Die Datenbank greift dazu 'nach eigenem Ermessen' auf folgende Kompressionsmethoden zurück: Advanced Row Compression, Advanced LOB Compression, Advanced LOB Deduplication, Segment-level Compression Tiering und Row-level Compression Tiering (eine kompakte Einführung in das Thema Komprimierung in der Oracle Datenbank bietet Ulrike Schwinns Dojo, das hier zum Herunterladen zur Verfügung steht). Es sei an dieser Stelle nochmals darauf hingewiesen, dass die Verwendung der Klausel OPTIMIZE DATA die Lizensierung von ACO voraussetzt. Fehlt die Klausel oder wird die Klausel NO OPTIMIZE DATA verwendet, werden die Archive nicht komprimiert und es ist auch keine Lizenz für ACO nötig.

In der RETENTION-Klausel wird schliesslich festgelegt, wie lange die Daten in dem Archiv nicht verändert oder gelöscht werden dürfen. Die Frist kann nicht nur in Jahren (YEAR) angegeben werden, sondern auch in Tagen (DAY) und Monaten (MONTH). Nach Ablauf der angegebenen Frist löscht die Datenbank die Daten in dem Archiv automatisch. Das Löschen erfolgt dabei effizient durch ein DROP der Partition, in der die archivierten Daten intern gespeichert sind.

Informationen über angelegte Archive sind zugänglich über die Views DBA_ / USER_FLASHBACK_ARCHIVE und DBA_ / USER_FLASHBACK_ARCHIVE_TS:
SELECT flashback_archive_name, flashback_archive#, retention_in_days, 
       to_char(create_time, 'dd.mm.yy hh24:mi:ss') create_time
FROM dba_flashback_archive;

FLASHBACK_ARCHIVE_NAME FLASHBACK_ARCHIVE# RETENTION_IN_DAYS CREATE_TIME          
---------------------- ------------------ ----------------- --------------------
ARCHIV1                                 1              1825 12.05.14 14:22:50
Die Verbindung zwischen einem angelegten Archiv und einer Tabelle oder mehreren Tabellen wird im Rahmen eines CREATE oder ALTER TABLE-Befehls über die Klausel FLASHBACK ARCHIVE hergestellt. Kriterium für die Ablage von Archivdaten unterschiedlicher Tabellen in einem gemeinsamen Archiv ist eine gleiche Aufbewahrungszeit.

Der Anwender, der eine Tabelle mit Archivierung anlegt oder ändert, benötigt für das Archiv, in das geschrieben werden soll, das Privileg FLASHBACK ARCHIVE. Außerdem muß das Archiv bereits existieren.
CREATE TABLE tabname (spalte1 NUMBER(10) NOT NULL, ...)
FLASHBACK ARCHIVE archiv1
zum Beispiel als Benutzer SCOTT für seine vorhandene Tabelle EMP
ALTER TABLE emp FLASHBACK ARCHIVE archiv1
Wird bei den gerade beschriebenen CREATE oder ALTER TABLE-Befehlen der Name des Archivs nicht angegeben, wird in ein sogenanntes Default Flashback Archive archiviert. Dieses muß bereits existieren und kann nur als SYSDBA angelegt, geändert oder gelöscht werden.

Wenn noch kein Default Archiv existiert, kann es zum Beispiel mit folgendem Befehl angelegt werden
CREATE FLASHBACK ARCHIVE DEFAULT defarcname
TABLESPACE tsname
NO OPTIMIZE DATA
RETENTION 5 YEAR
oder, sofern ein bestehendes Archiv zum Default Archiv werden soll
ALTER FLASHBACK ARCHIVE archiv1 SET DEFAULT
Gibt es bereits ein Default Archiv, verliert dieses mit dem Befehl ALTER FLASHBACK ARCHIVE automatisch seinen Default Status, und an seine Stelle tritt das neue Default Archiv.

Mit dem Befehl ALTER FLASHBACK ARCHIVE kann einem Archiv ausserdem ein Tablespace hinzugefügt oder entzogen werden, Quoten und Aufbewahrungszeiten verändert, der Inhalt von Archiven komplett oder teilweise gelöscht und das Komprimieren ein- oder ausgeschaltet werden.

Der Befehl
DROP FLASHBACK ARCHIVE archiv1
löscht die archivierten Daten, aber nicht das Tablespace oder die Tablespaces des Archivs. Im Zusammenhang mit dem Löschen von Archiv-Daten muß ebenfalls darauf hingewiesen werden, dass das zeitweilige Ausschalten des Archivierens zum Beispiel für die Tabelle EMP durch den Befehl
ALTER TABLE emp NO FLASHBACK ARCHIVE
nicht nur dazu führt, dass das Archivieren für die genannte Tabelle eingestellt wird, sondern auch dazu, dass sämtliche bis zu diesem Zeitpunkt für die Tabelle archivierten Daten gelöscht werden. Voraussetzung für das erfolgreiche Durchführen dieses ALTER TABLE-Befehls ist deshalb das Privileg FLASHBACK ARCHIVE ADMINISTER. Das bedeutet also, dass mit dem Privileg FLASHBACK ARCHIVE zwar das Archivieren angestoßen werden kann, aber für das Stoppen des Archivierens aus Sicherheitsgründen das weitergehende FLASHBACK ARCHIVE ADMINISTER benötigt wird!

Informationen zu den Tabellen, für die das Archivieren aktiviert ist, sind über die Views DBA/USER_FLASHBACK_ARCHIVE_TABLES zugänglich.
SELECT *
FROM user_flashback_archive_tables;

TABLE_NAME  OWNER_NAME  FLASHBACK_ARCHIVE_NAME  ARCHIVE_TABLE_NAME     STATUS
----------  ----------  ----------------------  ---------------------  ---------
EMP         SCOTT       ARCHIV1                 SYS_FBA_HIST_87108     ENABLED
Zugriff auf archivierte Daten

Die Existenzberechtigung von Archiven besteht darin, dass sie gelesen werden, um die Version eines Datensatzes zu einem Zeitpunkt in der Vergangenheit zu dokumentieren. Das kann dadurch erfolgen, dass man sich durch den Aufruf der Prozeduren ENABLE_AT_TIME oder ENABLE_AT_SYSTEM_CHANGE_NUMBER des Package DBMS_FLASHBACK quasi zu dem Zeitpunkt begibt, dessen Datenzustand man betrachten will. Es geht aber auch und im Fall einer einzelnen Abfrage sicherlich weniger umständlich durch eine Abfrage mit der AS OF TIMESTAMP Klausel. Das könnte dann zum Beispiel so aussehen:
SELECT * FROM scott.emp
AS OF TIMESTAMP TO_TIMESTAMP('14.05.12 11:42', 'dd.mm.yy hh24:mi')
Noch einfacher wäre es für SCOTT als Eigentümer der Historientabelle. SCOTT könnte nämlich direkt aus der Historientabelle SYS_FBA_HIST_87108 selektieren.

An dieser Stelle sei auch darauf hingewiesen, dass die Abfrage auf ein Flashback Data Archive auch zum Recovery versehentlich gelöschter oder geänderter Datensätze einer Tabelle im Rahmen eines INSERT- oder Update-Befehls angewendet werden könnte. Damit wird hier ein Nebeneffekt aus dem Bereich der Hochverfügbarkeit sichtbar, der Archive auszeichnet. Denn im Vergleich zu den bisher bekannten Flashback-Möglichkeiten, die auf noch vorhandene Undo-Informationen angewiesenen sind, stehen Archive durch ihre häufig jahrelange Aufbewahrungszeit deutlich länger für ein Recovery zur Verfügung.

Mechanismen und Strukturen

Beim Anlegen eines Archivs werden im angegebenen Tablespace eine Reihe von Objekten angelegt:
SELECT object_name, object_type
FROM user_objects
WHERE object_name like 'SYS%';

OBJECT_NAME                    OBJECT_TYPE
------------------------------ ------------------------------
SYS_FBA_DDL_COLMAP_87108       TABLE
SYS_FBA_HIST_87108             TABLE PARTITION
SYS_FBA_HIST_87108             TABLE
SYS_FBA_TCRV_87108             TABLE
SYS_FBA_TCRV_IDX_87108         INDEX
Diese Objekte können ausschließlich mit den oben beschriebenen Varianten der Befehle CREATE / ALTER FLASHBACK ARCHIVE bzw. CREATE / ALTER TABLE bearbeitet werden.

Das entscheidende Objekt des Archivs ist eine partitionierte Historientabelle mit dem Namen TABELLENBESITZER.SYS_FBA_HIST_n, also im Beispiel dieses Artikels SCOTT.SYS_FBA_HIST_87108. Der Versuch, mit den bekannten DML-Befehlen (INSERT, UPDATE, DELETE) auf diese Tabelle zuzugreifen, führt unmittelbar zur Fehlermeldung "ORA-55622: DML, ALTER and CREATE UNIQUE INDEX operations are not allowed on table SCOTT.SYS_FBA_HIST_87108".

Die Tabelle wird übrigens erst angelegt, wenn sie tatsächlich benötigt wird - also erst dann, wenn neue Versionen von Datensätzen entstehen - und enthält alle Spalten der Tabelle, für die archiviert wird, sowie weitere Spalten zum Administrieren des Archivs. Die Historien-Tabelle wird gefüllt mit Daten, die ein eigener Hintergrundprozess namens FBDA (neu seit Oracle Database 11g und unschwer als FlashBack Data Archiver zu identifizieren) aus den Undo-Informationen erzeugt, die bei UPDATE- und DELETE-Aktionen entstehen. Ein INSERT erzeugt im übrigen keine Archivdaten, denn der aktuelle Zustand ist hier die einzig existierende Version.

Der FBDA-Prozess arbeitet nicht permanent, sondern asynchron etwa alle 5 Minuten. Sollte dieses Intervall nicht ausreichen, um die anstehenden Informationen zu verarbeiten, startet er selbständig öfter. Steigt die Last des FBDA so weit, dass er trotz häufigerer Starts nicht mehr alles verarbeiten kann, unterstützen ihn Benutzerprozesse bei der Arbeit. Natürlich ist gewährleistet, dass Undo-Informationen so lange nicht überschrieben werden, bis sie für ein eventuell stattfindendes Archivieren verarbeitet sind.

Abschließend sei an dieser Stelle ausdrücklich nochmals auf einen wesentlichen Unterschied zwischen den Möglichkeiten der bekannten UNDO-Mechanismen und denen der Archive hingewiesen: Der normale UNDO-Mechanismus der Datenbank sammelt für alle Veränderungen in der Datenbank UNDO-Informationen und dürfte wegen der Datenmenge, die in einer produktiven Datenbank anfällt, in der Regel auf einige Stunden oder maximal Tage begrenzt sein. Durch die Verbindung mit einzelnen Tabellen sind Archive deshalb viel effizienter und können unbegrenzt und selektiv Daten vorhalten.

Einschränkungen

Nicht jede Tabelle kann mit Flashback Data Archives archiviert werden. So dürfen zum Beispiel in den zur Archivierung vorgesehenen Tabellen keine Spalten mit den Namen RID, STARTSCN, ENDSCN, XID, OPERATION und OP angelegt sein. Das ist auch unmittelbar einleuchtend, denn - wie man am folgenden DESCRIBE sieht - diese Spaltennamen (bis auf OP) würden mit den Spaltennamen kollidieren, die die Datenbank in jeder Historientabelle im Zusammenhang mit der Administration der Archive verwendet.
DESC SYS_FBA_HIST_87108

Name              Null?    Type
----------------- -------- ------------------------------------
RID                        VARCHAR2(4000)
STARTSCN                   NUMBER
ENDSCN                     NUMBER
XID                        RAW(8)
OPERATION                  VARCHAR2(1)
EMPNO                      NUMBER(4)
ENAME                      VARCHAR2(10)
...
DEPTNO                     NUMBER(2)
Es ist ebenfalls nicht möglich, beispielsweise Tabellen mit nested table-, LONG-Spalten oder Spalten, die über Hybrid Columnar Compression komprimiert sind, zu archivieren. Auch für external, clustered, remote und - sicherlich logischerweise - temporary tables steht die Funktionalität der Flashback Data Archives nicht zur Verfügung.

Eine Tabelle, deren geänderte Sätze archiviert werden, kann nicht mit den Befehlen DROP gelöscht werden. Der Versuch führt zur Fehlermeldung "ORA-55610: Invalid DDL statement on history-tracked table".

Änderungen an der Struktur einer Tabelle, deren geänderte Sätze archiviert werden, sind weitgehend unproblematisch. Allerdings gibt es einige Ausnahmen. Sie betreffen zum Beispiel ALTER TABLE Befehle, die eine UPGRADE TABLE Klausel enthalten oder die eine Partition oder Subpartition verschieben oder austauschen. Die genannten ALTER TABLE Befehle sind nur zulässig, wenn sie zwischen den Aufrufen der Prozeduren DBMS_FLASHBACK_ARCHIVE.DISASSOCIATE_FBA und DBMS_FLASHBACK_ARCHIVE.REASSOCIATE_FBA erfolgen. Da zwischen den Aufrufen der beiden Prozeduren NICHT archiviert wird, ist eine derartige Aktion sicherlich immer in Zeiten ohne Datenbankaktivität ratsam. Ausserdem sollte schon der Aufruf der Prozedur DISASSOCIATE_FBA wohl grundsätzlich nur nach Rücksprache mit den Compliance- und Sicherheitsverantwortlichen des Unternehmens erfolgen.

Besonderheiten in Oracle Database 12c

Die vorangegangenen Informationen beziehen sich sowohl auf die Datenbankversion 11.2.0.4 als auch auf die Version 12.1.0.1 - jedenfalls sofern die klassische Datenbankarchitektur verwendet wird: Unter der neuen Architektur mit Container (CDB) und Pluggable (PDB) Datenbanken werden die Flashback Data Archives nämlich noch nicht unterstützt. Der Versuch, hier ein Archiv anzulegen, führt zu der eindeutigen Fehlermeldung "ORA-65131: The feature Flashback Data Archive is not supported in a pluggable database." Natülich kann man erwarten, dass diese Einschränkung in einem der bevorstehenden Patch Releases fällt.

Allerdings bietet die aktuellste Version - Oracle Database 12c in der klassischen Architektur - auch einige erfreuliche Weiterentwicklungen. So bietet das user context tracking die Möglichkeit, neben den ursprünglichen Werten eines veränderten Datensatzes Informationen aus dem Kontext des ändernden Benutzers in den Archiven zu erfassen. Dies wird über das Package DBMS_FLASHBACK_ARCHIVE implementiert.

Ebenfalls unter Zuhilfename des Package DBMS_FLASHBACK_ARCHIVE sowie zusätzlicher Werkzeuge wie zum Beispiel Datapump können archivierte Daten aus Historientabellen exportiert und auch in Historientabellen importiert werden. Das geht so weit, dass sogar eigene Daten in die Archive importiert werden können. Dabei dürften in der Regel strenge Sicherheits- und Konsistenzgesichtspunkte zu berücksichtigen sein. Aber allein die Möglichkeit stellt einen erwähnenswerten Fortschritt dar bei der Konsolidierung von Flashback Data Archives und Archiven, die über Applikationen oder Trigger gepflegt wurden.

Mehr Komfort bietet das sogenannte database hardening, das ebenfalls auf das Package DBMS_FLASHBACK_ARCHIVE zurückgreift. Hinter der etwas seltsam anmutenden Bezeichnung verbirgt sich die Fähigkeit, logische Container - sogenannte Applikationen - zu definieren, diesen Applikationen dann Tabellen zuzuweisen und schliesslich mit nur einem Aufruf (ENABLE_APPLICATION) für alle Tabellen der definierten Applikation das Archivieren einzurichten.
EXECUTE dbms_flashback_archive.register_application
        (application_name       => 'anwendungsname',
         flashback_archive_name => 'archiv1')

EXECUTE dbms_flashback_archive.add_table_to_application
        (application_name => 'anwendungsname', 
         table_name       => 'emp',
         schema_name      => 'scott')

(Weitere Tabellen hinzufügen ...)

EXECUTE dbms_flashback_archive.enable_application
        (application_name => 'anwendungsname')
Abschliessende Hinweise

Im Rahmen der DBA Community ist bereits über die Flashback Data Archives berichtet worden. Der hier vorliegende Artikel ersetzt alle vorangegangenen Beiträge zum Thema.

Die Lektüre dieses Beitrags ersetzt keineswegs die Beschäftigung mit den relevanten Handbüchern. Das sind für diejenigen, die mit der Version 11 der Datenbank arbeiten, vor allem Abschnitte aus dem und für diejenigen, die mit der Version 12 arbeiten, die entsprechenden Abschnitte aus dem

Zurück zur Community-Seite