Oracle 10g Flashback

Transcription

A.Held / Deutsche Post ITSolutions
Oracle Flashback – Der Rewind-Button für die
Datenbank
Wer kennt Sie nicht, die Benutzer, die angeblich „nichts gemacht“ haben, und denen es beim vorgeblichen
Nichts-Tun gelang, den ganzen Datenbestand zu demolieren? Administratoren und Entwickler machen
sich recht gerne lustig über sogenannte DAUs. Beim Lachen über andere lässt sich ja so schön
vergessen, dass man selbst vielleicht auch schon versehentlich in der Produktion und nicht – wie geplant
– in der Testumgebung Tabellen oder ganze Benutzer entfernt hat. Doch was tun, wenn das Kind in den
Brunnen gefallen ist? Oracle bietet in Form der neuen Flashback-Technologie ganz hervorragende
Möglichkeiten, die eine Wiederherstellung um ein Vielfaches beschleunigen können.
Human Error Correction ist das Thema, auf das Oracle mit einigen neuen Features zielt. Menschliche Fehler
sind tatsächlich eine der häufigsten Ursachen für Systemausfälle. Einer Studie von Gartner zufolge fallen 32% der
Downtimes in diese Fehlerkategorie. Oracle will hier Abhilfe schaffen und hat mit der neuen Version 10g eine
Restore Möglichkeit geschaffen, die kein anderes DBMS derzeit in diesem Umfang beherrscht. Flashback heißt die
neue Technologie, die uns allen das Leben leichter machen soll. Sie reduziert die Recovery Time von Stunden auf
wenige Minuten. Da nicht alles Gold ist, was glänzt, haben wir diese neuen Fähigkeiten etwas genauer unter die
Lupe genommen.
Generell zielt Flashback auf Benutzerfehler. Hat ein Benutzer versehentlich Daten gelöscht oder in
unbeabsichtigter Weise verändert, so gab es früher nur eine Möglichkeit: Die Datenbank musste in solchen Fällen
mit einem Backup wiederhergestellt werden, um anschließend alle Transaktionen bis zum Zeitpunkt unmittelbar vor
dem Benutzerfehler mittels Transaktonslogs nachzufahren. Insbesondere bei einer großen Datenbank kann dieses
Vorgehen ausgesprochen zeitaufwendig sein. Zudem sind alle Datenänderungen, die Transaktionen nach dem
Benutzerfehler betreffen, verloren.
Flashback bietet für diese Problemstellung erweiterte Möglichkeiten an, die allesamt - je nach Geschmack entweder durch die intuitive Benutzerführung des Oracle Verwaltungstools EM 10g (Enterprise Manager 10g
Database Control) oder aber über eine SQL Schnittstelle wie Oracles SQL*Plus durchgeführt werden können.
Generell gibt es unter Oracle drei Level des Flashbacks:
•
•
•
Flashback Query und Flashback Table
Flashback Drop
Flashback Database
Architektur, Implementierung und Funktionalität dieser Level ist jeweils etwas unterschiedlich. Alle drei
Möglichkeiten lassen sich jederzeit in ein und derselben Datenbank anwenden.
Undo Tablespace und Änderungshistorie
Bereits in Oracle 9 wurde Flashback Query eingeführt. Flashback Query erlaubt die konsistente Abfrage eines
Datenbestandes zu verschiedenen historischen Zeitpunkten. Hintergrund ist folgender: Auch wenn Änderungen
bereits mit einem Commit bestätigt wurden, bewahrt Oracle die ursprünglichen Daten in Form von Before-Images
noch einige Zeit auf. Wie lange diese Historie dann noch zur Verfügung steht, hängt vom Transkationsaufkommen,
aber auch von der Größe des Undo Tablespaces ab. Der Undo Tablespace ist einigen sicherlich aus einem
ähnlichen Kontext bekannt: Er stellt den Speicherplatz bereit, in dem vor der Änderung eines Datensatzes eine
Sicherungskopie abgelegt wird. Diese wird normalerweise genutzt, um im Fall des Befehls Rollback die
Seite 1
Änderungen wieder rückgängig machen zu können. Bislang wurden diese Before-Images aber nach einer
Bestätigung der Änderungen durch einen Commit-Befehl zum Überschreiben freigegeben. Damit waren diese
Sicherungskopien verloren.
Oracle 10g nutzt diesen Undo-Speicherbereich nun, um Änderungen auch nach einem Commit noch einsehen
und – falls gewünscht – auch wieder rückgängig machen zu können. Allerdings ist dies nur für einen begrenzten
Zeitraum möglich: Ist der Undo-Tablespace irgendwann einmal voll, so werden die ältesten Before Images wieder
beschrieben. Nach einiger Zeit sind also jeweils jene Daten, deren Änderung am längsten her ist, verloren. Die
Größe des Zeitraumes, für den die Änderungshistorie zur Verfügung steht, hängt von der Größe des UndoBereiches ab. Dieser kann frei konfiguriert werden. Hat man also ausreichend Plattenplatz, so kann man bei Bedarf
durchaus auch einen Undo Bereich von 8 GB oder größer wählen. Erstellung und Konfiguration eines Undo
Tablespaces sind nebenstehend im Textkasten beschrieben.
Der Undo Tablespace ist also eine Art Ringspeicher für Before Images bei Datenänderungen:
• Solange noch freier Speicherplatz vorhanden ist, wird dieser beschrieben.
• Ist der gesamte Undo-Bereich gefüllt, wird mit dem beschreiben sozusagen wieder „von Vorne“ begonnen.
Dabei werden die ältesten Bereiche überspeichert.
Möchte man die Erhaltung der Before Images für einen bestimmten Mindestzeitraum garantieren, kann der
Datenbankparameter UNDO_RETENTION eingesetzt werden. Er gibt den Zeitraum in Sekunden an, für den Before
Images im Undo Tablespace gehalten werden. Neu in Oracle 10g ist die Möglichkeit einer Retention Guarantee.
Wurde ein Undo Tablespace mit dieser Option belegt, wird die Retention Time in jedem Fall eingehalten, auch dann
wenn ein DML Statement im Zweifelsfall mangels Speicherplatz nicht durchgeführt werden kann.
Einsatz von Flashback Query
Flashback Query lässt sich mit einigen ganz einfachen Mitteln einsetzen. Dabei wird in einer Abfrage einfach
nur angegeben, auf welchen Zeitpunkt man zurückgreifen möchte. Ein Beispiel: Montag, der 02.03.2004 kurz vor der
Mittagspause. Herr Müller aus der Personabteilung ruft an. Herr Müller berichtet, er habe ganz sicher gar nichts
gemacht. Dennoch sei – wie er feststellen musste - die Abteilung mit der Abteilungsnummer 50 plötzlich und
gänzlich ohne sein Zutun aus dem Datenbestand einer Oracle Datenbank verschwunden ist. Werfen wir einen Blick
in die betreffende Datenbank. Hierzu kann der graphische Enterprise Manager oder aber – wie im folgenden Beispiel
- SQL*Plus genutzt werden. Wir setzen also ein Select Statement mit SQL*Plus auf die Department-Tabelle [dept],
in der die Datensätze der Abteilungen gespeichert sind, ab:
SQL> SELECT * FROM dept;
ABTNR
----10
20
30
40
DNAME
-----------ACCOUNTING
RESEARCH
SALES
OPERATIONS
LOC
--------------- ------------NEW YORK
DALLAS
CHICAGO
BOSTON
Wir stellen fest: Herr Müller hat recht. Hier gibt es aktuell wirklich keine Abteilung mit der Nummer 50.
Betreiben wir ein wenig Forschung: Wie sah der Datenbestand denn am 02.03.2004 um 07:00 Uhr in der Frühe aus?
SQL> SELECT * FROM dept
3>
AS OF TIMESTAMP
2>
to_timestamp('02-03-2004 07:00:00','dd-mm-yyyy hh24:mi:ss');
DEPTNO DNAME
-----------10 ACCOUNTING
20 RESEARCH
30 SALES
LOC
--------------- ------------NEW YORK
DALLAS
CHICAGO
Seite 2
40 OPERATIONS BOSTON
50 IT
FRANKFURT
Aha! Da sind wir doch schon einen Schritt weiter: Morgens um 7 war die Abteilung 50 also noch vorhanden.
Das obenstehende Beispiel zeigt, wie die Syntax von Flashback Query eingesetzt werden kann:
1. Abfragetext in SQL formulieren und
2. zusätzlich den historischen Zeitpunkt, zu dem der Datenbestand angezeigt werden soll, mit der Syntax AS
OF TIMESTAMP angeben.
Möchte man jetzt herausfinden, wie sich der Datensatz über den Tag verändert hat oder aber wann er genau
gelöscht wurde, so kann man mit der Syntax VERSIONS BETWEEN alle Versionen innerhalb des angegebenen
Zeitraumes inklusive sämtlicher Änderungen ausgeben lassen:
SQL>
SELECT
deptno, dname, loc,
versions_operation, versions_xid, versions_starttime
FROM
scott.dept
VERSIONS BETWEEN TIMESTAMP MINVALUE AND MAXVALUE
ORDER BY
deptno, versions_starttime
DEPTNO DNAME
---------- -------------10 ACCOUNTING
20 RESEARCH
30 SALES
40 OPERATIONS
50 IT
50 MARKETING
50
50
8 Zeilen ausgewählt
LOC
------------NEW YORK
DALLAS
CHICAGO
BOSTON
FRANKFURT
FRANKFURT
FRANKFURT
FRANKFURT
V VERSIONS_XID
VERSIONS_STARTTIME
- ---------------- --------------------------
U 1E000A0008000000 02.03.04 09:30:02
U 1E000B0008000000 02.03.04 09:31:15
D 1E000C0008000000 02.03.04 09:32:20
Und siehe da, der Datensatz wurde zunächst um 09:30 Uhr und 2 Sekunden geändert. In Zeile 5 stand in der
Spalte [dname] noch der Wert „IT“. Zu diesem Zeitpunkt wurde der Name der Abteilung von „IT“ auf „Marketing“
geändert. Erkennbar ist dies in Zeile 6. Hier steht in der Spalte [versions_operation] ein U wie Update und als neuer
Wert der Spalte [dname] der Begriff „MARKETING“, während in Zeile 5 noch „IT“ zu finden war. Um 09:31 und 15
Sekunden erfolgte das nächste Update: Wieder enthält die Spalte [versions_operation] ein U für Update, der Wert
der Spalte [dname] ist nun leer. Die letzte Änderung stammt dann von 09:32 Uhr und 20 Sekunden. Hier wurde der
Satz gelöscht. Erkennbar ist dies wieder in der Spalte [versions_operations] am Flag D, das für Delete steht.
Datenbank mit Rückwärtsgang
In der letzten Abfrage werden mehrere Pseudo Columns angesprochen: [versions_operation], [versions_xid]
und [versions_starttime]. Diese Spalten sind nicht physisch in der Tabelle in Form von Spalteninhalten gespeichert.
Vielmehr erhalten wir durch sie zusätzliche Informationen, die aus dem internen Data Dictionary der Datenbank
stammen. Die Pseudo-Spalte [versions_operation] gibt Auskunft über die Operation, die ausgeführt wurde: I für
Insert, U für Update, D für Delete. Unter [versions_xid ] finden wir die interne Transaktionsnummer innerhalb der
Datenbank. Diese werden wir gleich noch benötigen. Unter [versions_starttime] ist der Zeitpunkt zu verstehen, ab
dem diese Änderung gültig wurde. Dabei handelt es sich um den Zeitpunkt, zu dem die Änderung mit Commit
bestätigt wurde.
In unserem Beispiel kann durch Nutzung der zuvor ermittelten Transaktions-ID aus der Spalte [versions_xid]
das UNDO- Statement gefunden werden, um die Veränderungen an der Tabelle [dept] wieder rückgängig zu
machen. Über die Pseudo-Spalte [VERSIONS_XID] in der oben genannten Flashback Query konnten wir die
Transaktions-ID ermitteln. Die Datenbank-View [flashback_transaction_query] liefert
Seite 3
Informationen über das UNDO-SQL Statement, das zur Transaktion mit der ID '1E000C0008000000' gehört:
SQL> SELECT logon_user, table_name,
table_owner, undo_sql
FROM
flashback_transaction_query
WHERE table_owner='SCOTT'
-- xid = Transaktions-ID
AND
xid= '1E000C0008000000';
LOGON_USER TABLE_NAME TABLE_OWNER UNDO_SQL
-----------------------------------------------------------SMUELLER
DEPT
SCOTT
insert into "SCOTT"."DEPT"("DEPTNO","DNAME","LOC") values ('50','UUuuups','Frankfurt');
Die Ergebnisse der Abfrage geben Auskunft über den Logon-User, die betreffende Tabelle und deren Besitzer
sowie das Undo SQL Statement zum Rückgängig-Machen der Transaktion. Wer die Augen nicht vor der Spalte
Logon-User verschließt, der wird bemerken, dass ein als SMUELLER angemeldeter Benutzer die Transaktion zum
Löschen des Datensatzes durchgeführt hatte. Das klingt doch sehr nach Herrn Müller aus der Personalabteilung.
Aber das behalten wir schmunzelnd einfach für uns!
Betrachtet man das Insert Statement aus der Spalte [undo_sql], so fällt auf, dass hier nur das Delete der Zeile,
dass durch die letzte Transaktion abgesetzt wurde, rückgängig gemacht wird. Möchte man tatsächlich auf den
ursprünglichen Stand von heute früh zurück, so muss man einfach alle undo_sql Statements in umgekehrter
zeitlicher Reihenfolge (also immer das letzte zuerst), verwenden, um die Änderungen schrittweise wieder rückgängig
zu machen.
SQL>
1
2
3
4
5*
SELECT
FROM
WHERE
AND
ORDER BY
undo_sql
flashback_transaction_query
table_owner = 'SCOTT'
table_name = 'DEPT'
commit_timestamp desc
UNDO_SQL
-------------------------------------------------------------------------------insert into "SCOTT"."DEPT"("DEPTNO","DNAME","LOC") values ('50','UUuuups','Frankfurt');
update "SCOTT"."DEPT" set "DNAME" = 'MARKETING' where ROWID = 'AAALy6AAEAAAAAOAAA';
update "SCOTT"."DEPT" set "DNAME" = 'IT' where ROWID = 'AAALy6AAEAAAAAOAAA';
Sehr viel leichter lassen sich solche Änderungen mit dem Enterprise Manager 10g vornehmen. Hier kann man
sich durch ein graphisches Werkzeug gestützt durch die Masken des Flashback hangeln und mit einem Mausklick
einen Datensatz wiederherstellen. Auch wenn das Vorgehen mit dem EM 10g sehr viel bequemer ist, sollte man
doch die Hintergründe verstanden haben. In schweren Problemfällen macht einem dies das Finden einer Lösung
sehr viel einfacher machen.
Im Vergleich zur Flashback
Table- Technologie, die wir gleich
noch kennenlernen werden, stellt diese
Technik
eine
Alternative
bei
versehentlich
oder
fehlerhaften
Änderungen
an
einzelnen
Tabellendaten dar. Neben dem
Zeitpunkt via „AS OF TIMESTAMP“
oder „VERSIONS BETWEEN“ kann
auch die Oracle System Change
Number verwendet werden. Diese ist
sehr viel genauer als ein Timestamp.
Die System Change Number (auch
als SCN bezeichnet) ist ein interner
Abbildung 1: Recovery gelöschter Tabellen im EM 10g
Seite 4
Transaktionszähler und vergleichbar einer Auftragsnummer in einem Auftragsbearbeitungssystem. Durch jede
Bestätigung einer Datenänderung durch ein Commit einer Transaktion wird intern in der Datenbank eine eindeutige
System Change Number hochgezählt. Diese wird in den Transaktionsprotokollen - unter Oracle sind das die “Redo
Logs” – aber auch im Header aller Datenbankfiles verzeichnet. Die SCN hat während einer Datenbankrecovery, aber
auch im Kontext von Lesekonsistenz eine zentrale Bedeutung. Diese eindeutige Transaktionsnummer kann in der
folgenden Syntax verwendet werden:
SELECT deptno, dept, dname
FROM scott.dept
VERSIONS BETWEEN
SCN minvalues AND maxvalue
WHERE deptno = 50;
Man kann mit dieser Syntax entweder eine feste SCN verwenden oder minvalue und maxvalue als Variable
eingesetzen. minvalue zeigt das älteste Before-Image, das für diesen Datensatz noch im UNDO-Tablespace
vorhanden ist. Bei maxvalue handelt es sich um die letzte Änderung. Die Syntax mit „VERSIONS BETWEEN SCN
minvalue AND maxvalue“ zeigt also alle noch im UNDO Bereich gespeicherten Variationen aller vom SQL Statement
betroffenen Datensätze an. Alternativ kann auch eine einzelne SCN benannt werden.
Zurücksetzen ganzer Tabellen
Wir haben im obigen Beispiel die Datenmanipulation eines einzelnen Datensatzes verfolgt und konnten diese
bei Bedarf über ein Undo SQL wieder in den ursprünglichen Zustand zurücksetzen. Wurden in einer Tabelle sehr
viele Sätze verändert, ist es unter Umständen leichter, die gesamte Tabelle zurückzusetzen. Oracle stellt hierfür die
folgende Syntax bereit:
FLASHBACK TABLE dept
TO TIMESTAMP to_timestamp('02.03.2004 09:30');
Dies birgt jedoch einige Gefahren in Bezug auf Datenkonsistenz: Wurden in der Mitarbeitertabelle alle
Mitarbeiter der Abteilung 50 sowie in der Abteilungstabelle die Abteilung mit der Nummer 50 gelöscht, erhält man
beim alleinigen Zurücksetzen der Mitarbeitertabelle inkonsistente Daten. In solchen Fällen müssen immer alle
voneinander abhängigen Tabellen synchron zurückgesetzt werden. Im letzten Beispiel wären also beide Tabellen zu
reseten: Mitarbeiter- und Abteilungstabelle.
Flashback Query und Flashback Table sind wunderbar für das Monitoring bzw. zum Widerherstellen
veränderter und gelöschter Datenbestände geeignet. Was aber, wenn jemand versehentlich eine ganze Tabelle
gelöscht hat? Flashback Query funktioniert nur, wenn an der betreffenden Tabelle keine Strukturänderungen
vorgenommen wurden. Wurde eine ganze Tabelle mit einem DROP TABLE Statement gelöscht, funktioniert
Flashback Query also nicht mehr!
Gelöschte Tabellen wiederherstellen
Wird eine Tabelle gelöscht, so war diese bis Version 9i unwiederbringlich verloren. Einzige Möglichkeit war die
relativ aufwendige Wiederherstellung aus einem validen Backup. Mit dem neuen Release 10g haben die Oracle
Entwickler eine ebenso einfache wie hilfreiche Erweiterung des Flashback einbezogen: Flashback Table. Statt die
Tabelle „hart“ zu löschen, wird sie intern in den Recycle Bin verschoben. Das geht – unabhängig von der Größe der
zu löschenden Tabelle - unglaublich schnell, da intern nur ein paar geringfügige Änderung im Data Dictionary der
Datenbank vorgenommen werden. Das Konzept ist nicht neu. Im Grunde handelt es sich um einen ganz ähnlichen
Vorgang wie die Nutzung des Papierkorbs unter Windows. Ein Beispiel:
DROP TABLE dept CASCADE CONSTRAINTS;
Seite 5
Mit diesem Befehl wird die Tabelle [dept] gelöscht. Die Option CASCADE CONSTRAINTS bewirkt, dass dabei
auch nicht auf referenzielle Integrität Rücksicht genommen wird. Stattdessen werden Foreign Key Constraints,
soweit betroffen, gleich mit gelöscht. Schwupps, ist die Tabelle weg.
Seite 6
Mit dem folgenden Befehl lässt sich die Tabelle wieder herstellen:
FLASHBACK TABLE dept to BEFORE DROP;
Und schon ist die Tabelle wieder da. Eine Warnung noch: Obwohl die Wiederherstellung so leicht und schnell
funktioniert, sollte man Tests mit dem Undrop natürlich nur in Testumgebungen durchführen. Auch Objekte des
Recycle Bin bleiben dort nicht beliebig lange bestehen. Bei einer Reorganisation, einer Größenänderung des
Tablespaces oder auch dann, wenn die Speicherbegrenzung des Benutzers überschritten würde, wird der Recycle
Bin entleert. Darüber hinaus gibt es noch den Purge Befehl, der ein Objekt gezielt aus dem Recycle Bin entfernt.
Zwei Beispiele zum „Purgen“:
DROP TABLE dept PURGE; -- Löscht die Tabelle endgültig
PURGE RECYCLEBIN;
-- Leert den Recycle Bin
Den Inhalt des Recycle Bin kann man sich in SQL*Plus auch mit dem Befehl show recyclebin ausgeben
lassen:
SQL> show recyclebin
ORIGINAL NAME
RECYCLEBIN NAME
OBJECT TYPE DROP TIME
---------------- ------------------------------ ------------ ------------------DEPT
RB$$48444$TABLE$0
TABLE
2004-03-02 10:29:40
Noch ein Hinweis für versierte DBAs: Möchte man sehen, welche Daten derzeit im Recycle Bin vorliegen, kann
die Data Dictionary View [dba_recyclebin] bzw. [user_recyclebin] abgefragt werden. Hier sind alle Informationen
über Objektnamen, Typen und Löschzeitpunkt zu finden. Die Handhabung im EM 10g ist natürlich viel einfacher,
als das mühselige Werkeln mit Scripten und SQL Befehlen.
Zurücksetzen ganzer Datenbanken
Manchmal genügt es nicht, einzelne Tabellen zurückzusetzen. Hier bietet Flashback Database Hilfe. Flashback
Database ist sicherlich die weitaus mächtigste Möglichkeit des Flashback. Hiermit wird die gesamte Datenbank in
einen historischen Zustand zurückgefahren. Dies
betrifft alle Objekte eines jeden Users dieser
Datenbank. Auf einzelne Benutzer lässt sich diese
Form des Zurücksetzens leider nicht beschränken.
Das Ergebnis entspricht dem eines konventionellen
Point-in-Time Recovery. Doch der Vorgang an sich
ist weit weniger kompliziert und benötigt
wesentlich weniger Zeit. Damit ein Flashback der
gesamten Datenbank überhaupt möglich ist, sind
ein paar Voreinstellungen notwendig. So muss die
Datenbank im sogenannten Archivelog Mode
betrieben werden. In diesem Modus werden
Abbildung 2: Konfiguration des Flashback Recovery Area im
DBCA
Transaktionslogs der Datenbank, die Online Redo
Logs, in ein Archivierungsziel weggesichert bevor
sie neu überschrieben werden. Diese archivierten Transaktionslogs werden im Fall eines Flashback Database
benötigt. Weiterhin muss die Datenbank auf flashback on geschaltet worden sein. Scripte zum Umstellen können
unter www.itc-frankfurt.de/download/scripte heruntergeladen werden. Der Befehl zum eigentlichen Zurücksetzen ist
dann denkbar einfach: Er lautet einfach FLASHBACK DATABASE. Allerdings lässt sich dieser Befehl nur im Mount
Zustand der Datenbank absetzen.
Seite 7
Hier ein Beispiel:
-- Herunterfahren der Datenbank
SHUTDOWN IMMEDIATE;
-- Hochfahren in den Mount Modus
STARTUP MOUNT;
-- Flashback absetzen
FLASHBACK DATABASE TO TIMESTAMP to_timestamp ('02.03.2004 09:30:00');
-- Datenbank öffnen
ALTER DATABASE OPEN RESETLOGS;
Abschließend muss die Datenbank mit einem Reset der Redo Logs geöffnet werden. Sie befindet sich dann mit
allen Daten sämtlicher Datenbankbenutzer auf dem Stand des im Flashback Befehl angegebenen Zeitpunktes, im
Beispiel also auf 09:30 Uhr und 0 Sekunden. Möchte man vor dem Reset sichergehen, dass man auch tatsächlich
den richtigen Zeitpunkt gewählt hat und der Datenbestand den Erwartungen entspricht, kann man die Datenbank
zunächst auch im Read Only Modus öffnen und durch einige Abfragen den korrekten Status verifzieren.
Man sieht, die Handhabung der verschiedenen Flashback Möglichkeiten ist recht einfach. Logische Fehler, die
durch Benutzerfehler, fehlerhafte Software oder ungewollte Administrationskommandos entstanden sind, können
mit Flashback in kürzester Zeit und ohne längere Ausfallzeiten behoben werden. Trotzdem sollte man nicht
leichtsinnig werden. Ein Flashback bedeutet häufig Datenverlust, da Transaktionen, die nach dem
Flashbackzeitpunkt erfolgten, ebenfalls zurückgerollt werden.
Zusammenfassung
Generell zielt Flashback auf Benutzerfehler. Hat ein Benutzer versehentlich Daten gelöscht oder in
unbeabsichtigter Weise verändert, so gab es früher nur eine Möglichkeit: Die oft aufwendige Wiederherstellung
über Backup. Mit Flashback können geänderte oder gelöschte Daten entweder mit SQL Befehlen oder aber über
den intuitiv bedienbaren Enterprise Manager 10g Database Control (kurz EM 10g) wiederhergestellt werden.
Flashback funktionierte bereits in der 10g Beta recht zuverlässig und deckt alle wesentlichen logischen Fehlertypen
ab. Nur die View [flashback_transaction_query] zeigt noch einige Fehler: Die Abfrage der View dauert
unverhältnismäßig lang, Updates werden gelegentlich nicht angezeigt. Bei letzterem Fehler scheint es sich um einen
Beta Bug zu handeln. Dieser lässt sich auf Windows Plattformen in der Beta-Version reproduzieren, tritt jedoch in
den bereits veröffentlichten Releases unter Solaris und HPUX nicht auf.
Generell gibt es unter Oracle 10g drei Level des Flashbacks:
•
•
•
Flashback Query gab es bereits in Oracle 9i und wurde in 10g auf Flashback Table erweitert,
Flashback Drop steht ab 10g zur Verfügung,
Flashback Database wurde ebenfalls mit Oracle 10g eingeführt.
Alle drei Möglichkeiten lassen sich jederzeit in ein und derselben Datenbank anwenden. Architektur,
Implementierung und Funktionalität dieser Level ist jeweils etwas unterschiedlich. Flashback Query und Flashback
Table nutzen den Undo Tablespace, Flashback Drop den Recycle Bin und Flashback Database verwendet
archivierte Redo Logs und Flashback Logs.
Seite 8
Anhang A: Automatisches Undo Management
Der Undo Tablespace speichert sogenannte Before Images. Diese Before Images werden als Undo
Informationen für das Zurückrollen einer Transaktion durch den Befehl Rollback verwendet. Oracle hat die Undo
Funktion nun dazu genutzt, Abfragen zu historischen Zuständen von Datensätzen durchzuführen und Änderungen
rückgängig zu machen, die bereits mit einem Commit in der Datenbank festgeschrieben wurden.
Sollte in einer Oracle Datenbank noch der Vorläufer des Undo-Tablespaces (sogenannte Rollback Segmente)
verwendet werden, empfiehlt es sich, auf das modernere Automatic Undo Management umzusteigen. Hierzu muss
zunächst ein Undo Tablespace erstellt werden. Ein Beispiel:
CREATE UNDO TABLESPACE undotbs
DATAFILE '/u01/oracle/rbdb1/undo0201.dbf'
SIZE 2000M REUSE AUTOEXTEND OFF;
Danach sollten einige Parameter der Oracle Datenbank geändert werden:
UNDO_MANAGEMENT:
Auf AUTO setzen
UNDO_TABLESPACE:
Name des UNDO Tablespaces
UNDO_RETENTION:
Anzahl Sekunden, für die der UNDO Tablespace
die Before Images aufbewahrt
Bei Nutzung des neuen SPFILEs zur Konfiguration, können diese Parameter folgendermaßen geändert werden:
-- Ändern des Management Typs
ALTER SYSTEM
SET UNDO_MANAGEMENT = AUTO
SCOPE=SPFILE;
-- Einstellen des Tablespaces,
-- der für Undo verwendet werden soll
ALTER SYSTEM
SET UNDO_TABLESPACE = 'undotbs'
SCOPE=SPFILE;
-- Einstellen des Zeitraumes,
-- für den Before Images aufbewahrt
-- werden sollen
ALTER SYSTEM
SET UNDO_ RETENTION = 18000
SCOPE=SPFILE;
Diese Befehle werden mit einem SQL-Interface wie z.B. SQL*Plus abgesetzt. Sollte bei der eben genannten
Syntax der Fehler ”ORA-32001: Schreiben in SPFILE angefordert, beim Hochfahren jedoch keine SPFILE
angegeben“ auftauchen, so wird noch das etwas veraltete Ascii Parameter File verwendet. In diesem Fall kann man
die obigen Parameter in der entsprechenden init.ora einfügen bzw. ändern. Alternativ kann einfach auf SPFile
umgestellt werden:
CREATE SPFILE FROM PFILE;
Hierdurch wird aus der vorhandenen Init.ora ein SPFile erzeugt, dass zukünftig beim Hochfahren der Datenbank
zieht. Danach können oben genannte Befehle erfolgreich abgesetzt werden.
Generell ziehen einiger dieser Änderungen erst nach Restart der Instanz, da Parameter wie UNDO_MANAGENT
nicht dynamisch (also zur Laufzeit) geändert werden können.
Seite 9
Anhang B: Flashback- Parameter und Befehlsübersicht
Typ
Architektur
Flashback
Undo Management
Query / Row
History
DB Parameter
Informationen
Befehle
UNDO_MANAGEMENT=AUTO
UNDO_RETENTION=<Sekunden>
UNDO_TABLESPACE=<undo_ts_name>
Undo Parameter in SQL*Plus abfragen:
Erstellen eines Undo Tablespaces:
SHOW PARAMETER UNDO
Aufbewahrungszeit der Before Images:
CREATE UNDO TABLESPACE undotbs1
DATAFILE '\dsk1\oradata\o10\undotbs01.dbf'
SIZE 10M AUTOEXTEND ON
RETENTION GUARANTEE;
SELECT tablespace_name,
retention
FROM
dba_tablespaces;
Flashback Query mit SCN:
SELECT versions_starttime "START DATE",
versions_endtime "END DATE",
salary
FROM
employees
VERSIONS BETWEEN SCN
MINVALUE AND MAXVALUE
WHERE last_name = 'Fox';
Flashback Query nach Zeitpunkt:
SELECT versions_starttime "START DATE",
versions_endtime "END DATE",
salary
FROM employees
VERSIONS BETWEEN TIMESTAMP
TO_TIMESTAMP ('20021216', 'YYYYMMDD')
AND TO_TIMESTAMP (SYSDATE)
WHERE last_name = 'Fox';
Flashback
Table
Undo Management
Wie Flashback Query
Wie Flashback Query
FLASHBACK TABLE dept
TO TIMESTAMP to_timestamp('02.03.2004
09:30');
Flashback
nach einem
Drop Table
Verwendung eines
internen Recycle Bin
Keine
Abfragen des Recycle Bin:
Löschen einer Tabelle mit
Wiederherstellungsmöglichkeit:
SELECT * FROM user_recyclebin;
DROP TABLE dept;
SELECT * FROM dba_recyclebin;
SHOW RECYCLEBIN in SQL*Plus
Wiederherstellen einer Tabelle:
FLASHBACK TABLE dept TO BEFORE DROP;
Wiederherstellen unter neuem Namen:
Seite 11
Typ
Architektur
DB Parameter
Informationen
Befehle
flashback table dept to before drop
rename to dept_old;
Fortsetzung nächste Seite
Fortsetzung
Flashback
nach einem
Drop Table
Endgültiges Löschen einer Tabelle:
DROP TABLE dept PURGE;
Entfernen aus dem Recycle Bin:
PURGE TABLE dept;
PURGE RECYCLEBIN;
Flashback
Database
Before Images
geänderter Datenbankblöcke werden von
einem Oracle Prozess,
dem RVWR in die
Flashback Database
Logs gesichert. Diese
Before Images werden
bei einem Flashback
Database in die
Datenfiles zurück
geschrieben.
Zusätzlich werden
Redo Information der
archivierten Redo
Logs verwendet.
Flashback Recovery Area im Filesystem:
DB_RECOVERY_FILE_DEST
Monitoren des Flashback Status einer
Datenbank:
SELECT flashback_on,
Größe des Speichers, der im Flashback
Recovery Area allokiert werden darf:
current_scn FROM
DB_RECOVERY_FILE_DEST_SIZE
Monitoren des Flashback Retention
Target:
v$database;
Zeitraum, für den Blöcke aufbewahrt
werden sollen:
SELECT *
DB_FLASHBACK_RETENTION_TARGET
v$flashback_database_log;
Die Datenbank muss im Archive Log
Mode betrieben werden. Flashback muss
auf Datenbankebene angeschaltet werden.
Scripte zur Umstellung können unter
www.itc-frankfurt.de/download/scripte
heruntergeladen werden.
Adjustieren der Recovery Area Disk
Quota:
Aktivieren der Möglichkeit eines Flashback Database:
1. DB Parameter setzen
2. Shutdown immediate der Datenbank
3. Startup nomount;
4. Initiales Aktivieren von Flashback
mit dem Befehl
ALTER DATABASE FLASHBACK ON;
5. Datenbank öffnen mit
FROM
SELECT *
FROM
v$flashback_database_log;
ALTER DATABASE OPEN;
Datenbank mit Zeitpunkt oder SCN zurücksetzen:
1. Shutdown immediate der Datenbank
2. Startup mount
3. Flashback Befehl absetzen:
FLASHBACK DATABASE
TO TIMESTAMP(SYSDATE-1/24);
oder
FLASHBACK DATABASE TO SCN 53943;
Seite 12

Oracle 10g Flashback

Transcription

Similar documents

5 Migration von Oracle zu SQL Server

Verwalten von Contact Recorder

Arbeitszeugnisse - Fakultät Wirtschafts

PDF-Version (Booklet)

Freie Reporting-Tools im Vergleich

Distrelec AG 1 Business Case - Joller-Voss

Bedienungsanleitung

Arbeitsklima-Index Gesundheitsberufe AK Studie

MxVision WeatherSentry® Die aktuelle Wetterlage immer im Blick!

grundlagen der computernutzung

Big Sister is watching