Testdaten mit Flashback zurücksetzen

Das seit Oracle 10g in der Enterprise Edition eingebaute Feature „Flashback Database“ wird in den meisten Beispielen zur kurzfristigen Korrektur von Änderungen anstelle eines Point-in-Time-Recovery benutzt. Es lässt sich aber auch bequem einsetzen, um die Daten zwischen einzelnen Testzyklen zurückzusetzen, was z.B. für „Continuous Integration“ sehr praktisch ist.

Szenario

  • Testdaten werden durch Test verändert; vor dem nächsten Testlauf ist ein Rücksetzen der DB erforderlich.
  • Die Änderungen während der Testzyklen betragen nur einen Bruchteil der Gesamtgröße der DB.
  • Die Testläufe finden in regelmäßigen Abständen statt.
  • Die Test-DB wird nicht gesichert bzw.
  • exp/imp oder ein Klon kommen wegen Größe und/oder Zeitbedarf nicht in Frage.

Flashback einschalten

Dieses Feature ist nur in der Enterprise Edition verfügbar. Es muß die Größe der Flash Recovery Area (FRA), der Pfad dorthin sowie der gewünschte Zeitraum für ein Flashback vorgegeben werden. Nach Erreichen dieses Zeitraumes werden ältere Dateien bei Bedarf aus der FRA gelöscht; vor Erreichen dieses Zeitraums kann die FRA potentiell vollaufen (siehe „Fallstricke“).

init.ora:

DB_RECOVERY_FILE_DEST_SIZE=1000M     # 1 GB FRA
DB_RECOVERY_FILE_DEST='/Beispiel/ORCL/flash_recover'
DB_FLASHBACK_RETENTION_TARGET=1440   # 24 h Flashback vorhalten
log_archive_dest_1='LOCATION=use_db_recovery_file_dest NOREOPEN ALTERNATE=LOG_ARCHIVE_DEST_2'
log_archive_dest_2='LOCATION=/alternativer/Pfad/fuer/Archive/Logs'   # falls die FRA überläuft
log_archive_dest_state_1='enable'
log_archive_dest_state_2='alternate'
log_archive_start=TRUE
shutdown immediate;
startup mount exclusive;
alter database flashback on;
shutdown;
startup;

Beispiel

Shell-Script für ein automatisches Flashback, bei dem auch gleich alte Archive Logs gelöscht werden:

#/usr/bin/sh
#
. /home/oraculix/.profile.10gR2        # Oracle-Einstellungen laden
export ORACLE_SID=TSTDB1

echo
echo shutdown TSTDB1
echo
sqlplus /nolog <<EOF
connect / as sysdba
shutdown immediate
startup mount
DECLARE
 v_fbdat   VARCHAR2 (20);
BEGIN
 -- Auf Vortag, 22 Uhr zuruecksetzen
 SELECT TO_CHAR( TRUNC (SYSDATE) - 1, 'dd.mm.yyyy') || ' 22:00'
 INTO v_fbdat
 FROM DUAL;
 EXECUTE IMMEDIATE 'flashback database to timestamp to_timestamp('''
 || v_fbdat || ''',''dd.mm.yyyy hh24:mi'')';
END;
/
alter database open resetlogs;
exit
EOF
#
# Entfernen ueberfluessiger Archive Logs
#
rman target / nocatalog <<EOF
crosscheck archivelog all;
delete noprompt archivelog all completed before 'sysdate-1';
## alternativ alle Archive Logs löschen:
## delete noprompt archivelog all;
EOF

Dazu passender Eintrag in der crontab:

# Flashback Database TSTDB1 tgl. 6h
0 6 * * 0-6 /oradata/scripts/flashback_tstdb1.sh

Fallstricke

Fehlermeldungen:
ORA-16014: log 6 sequence# 31 not archived, no available destinations
ORA-00312: online log 6 thread 1: '/oradata/TSTDB1/redoTSTDB1_06.log'

…und im Alert Log:

ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 13999104 bytes disk space from 1048576000 limit
ARC1: Error 19809 Creating archive log file to '/oradata/TSTDB1/flash_recover/TSTDB1/archivelog/2009_06_29/o1_mf_1_31_689944_.arc'
ARCH: Archival stopped, error occurred. Will continue retrying

Schnelle Abhilfe:

alter system set DB_RECOVERY_FILE_DEST_SIZE=4G; -- höhere Speichergrenze setzen

Wenn die o.g. Einstellungen in der init.ora beherzigt werden, dann sollte zumindest der Fehler mit den Archive Logs nicht auftreten, da im Falle einer vollen FRA die „log_archive_dest_2“ als Alternative benutzt wird.

Ansonsten hilft ein Blick in die Metalink Note 305812.1. Darin wird der Umgang mit Platzproblemen in der FRA ausführlich behandelt.

Fazit

In dem oben beschriebenen Szenario, speziell wenn die Menge der Datenänderungen deutlich geringer ist als die Gesamtgröße der DB, ist Flashback eine komfortable Variante zum Zurücksetzen einer DB auf den Beginn des Testzkylus.

Im Vergleich zu exp/imp kann ein deutlicher Zeitvorteil erreicht werden, da der Neuaufbau von Indizes und die Validierung von Constraints beim Import viel Zeit in Anspruch nehmen können. Selbst wenn nur ausgewählte Tabellen mit Originaldaten beladen werden sollen: Wenn diese Tabellen Abhängigkeiten, z.B. durch Foreign Keys, haben, dann müssen diese vor einer Löschung und anschließendem Import berücksichtigt und aufgelöst werden. Dieser Aufwand entfällt bei Flashback.

Im Vergleich zum Aufbau aus einer Vollsicherung hat Flashback dann Vorteile, wenn die angefallenen Änderungen die Größe der Sicherung deutlich unterschreiten. Einerseits wird dann Plattenplatz gespart, andererseits damit auch Zeit für’s Zurücksetzen. Darüber hinaus kann man mit Flashback flexibler auf Änderungen reagieren und den Datenstand eines bestimmten Zeitpunktes wiederherstellen.

Weblinks

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s