Viele unserer Kunden nutzen seit Jahren Export / Import bzw. Data Pump als Backup Lösung für dne Fall, dass Tabelleninhalte durch fehlerhafte Prozeduren verloren gehen. Da die Datenbanken allerdings die Angewohnheit haben, immer größer zu werden, werden natürlich auch die Exports größer und, was noch viel problematischer ist, die Zeitdauer für die Exports nimm zu.
Vor einiger Zeit hatte einer meiner Kunden das Problem, dass die Zeit, die er für den „normalen“ Datenbank Backup, den Export und den anschließenden Batchlauf vorgesehen hatte, nicht mehr ausreichte. Das führte zu massiven Performanceproblemen und Einschränkungen in der Anwendung, da beim Start des Tagesbetriebs der Batchlauf noch nicht fertig war.
Die Frage ist also: wie kann man die Zeitdauer für den Export reduzieren?
Die Antwort ist ganz einfach: keinen Export machen, das spart jede Menge Zeit!
Die Proteste des Kunden waren allerdings zunächst sehr stark. Das Argument: vor einiger Zeit hatten wir mal ein Problem mit unserem Batchlauf und mussten deshalb einige Tabellen aus dem Export wieder herstellen.
Beispiele für das Recovery von Tabellen
Flashback Database
Wenn Flashback Database eingeschaltet ist, dann kann man einfach die Datenbank auf einen älteren Zeitpunkt zurücksetzen.
Diese Lösung ist dann hilfreich, wenn man die gesamte Datenbank zurücksetzen kann oder muss. Oft scheitert diese Methode aber daran, dass mehrere Anwendungen in einer Datenbank betrieben werden, die im Falle des Rewinds natürlich alle zurückgesetzt werden würden. Außerdem darf natürlich nicht außer acht gelassen werden, dass, gerade bei Batch Operationen, jede Menge Flashback Logs anfallen, d.h. der benötigte Platz entsprechend zunimmt. In einigen Fällen, z.B. wenn neue Anwendungen ausgerollt werden, kann es auch ausreichend sein, einen „Guaranteed Restore Point“ zu setzen. Diese Möglichkeit kann man immer nutzen, wenn man Archiving aktiviert hat, d.h. Flashback muss dafür nicht „enabled“ sein. D.h. vor dem Update wird der Restore Point gesetzt und wenn der Update erfolgreich durchgelaufen ist, kann der Restore Point wieder gelöscht werden. Damit werden dann auch alle in der Zwischenzeit angefallenen Flashback Logs wieder gelöscht.
Standby Datenbank
Wenn man Data Guard oder eine ähnliche Lösung (z.B. Dbvisit Standby) im Einsatz hat, ist es, je nach Konfiguration, möglich, den Redo Apply Prozess anzuhalten und die Standby Datenbank entweder Read Only oder (z.B. mit einem Guaranteed Restorepoint) Read Write zu öffnen. Anschließend kann die Tabelle exportiert werden oder alternativ die fehlerhaften Datensätze aus der Tabelle gelesen und in die Produktion eingefügt werden. Einzige Voraussetzung ist, dass die Standby Datenbank die fehlerhaften Änderungen noch nicht ausgeführt hat. Wenn es sich um Batchanwendungen handelt, kann es daher hilfreich sein, denn der Redo-Apply angehalten wird, bevor der Batchprozess startet. Der Apply Prozess wird dann nach der erfolgreichen Beendigung wieder gestartet. Im sehr seltenen Fall, dass genau während dieser Zeit ein Desaster eintritt, der die Umschaltung auf die Standby Seite erforderlich macht, muss man einkalkulieren, dass das Recovery jetzt etwas länger dauert.
RMAN Table Recovery
Seit Oracle 12c gibt es als „neues“ Feature den RMAN Table Recovery. Das ist sicherlich eine sehr hilfreiche Funktion, die den oben angesprochenen Export in vielen Fällen überflüssig machen kann.
Aber was passiert an dieser Stelle?
Leider ist es immer noch nicht möglich, Datenbankobjekte aus einem RMAN Backup „herauszulesen“. Stattdessen wird bei Table Recovery eine Auxiliary Datenbank mit dem SYSTEM, SYSAUX und UNDO Tablespace angelegt. Außerdem benötigt diese Datenbank natürlich den Tablespace des zurückzusichernden Objektes.
Beispiel für ein Table recovery:
RMAN> RECOVER TABLE demo.personen_drop
UNTIL TIME „to_date(‚31.05.2013 09:30:00′,’DD.MM.YYYY HH24:MI:SS‘)“
AUXILIARY DESTINATION ‚/u03/orabackup/recover‘;
Die Verzeichnis „AUXILIARY DESTINATION“ muss existieren und ist für die Syntax zwingend erforderlich. In dieser Standardvariante wird die Tabelle aus der Auxiliary Datenbank per Data Pump Export herausgelesen und automatisch in die Produktionsdatenbank importiert. Wenn die Tabelle noch existiert, schlägt das Recovery fehl. Glücklicherweise wird die Existenz der Tabelle bereits zu Beginn des Prozesses überprüft, d.h. man kann frühzeitig entsprechende Maßnahmen ergreifen. Folgende Optionen sind (unter anderem) möglich:
- NOTABLEIMPORT: in diesem Fall wird nur die Data Pumpt Exportdatei im Verzeichnis DP_DUMP_DIR angelegt.
- REMAP TABLE: die originale Tabelle bleibt erhalten und die „neue“ Tabelle wird als Kopie importiert. Hier muss man natürlich auf ausreichenden Platz in dem entsprechenden Tablespace achten.
Hier das Beispiel für den reinen Export der Tabelle
sql statement: create or replace directory TSPITR_DIROBJ_DPDIR as “/u03/orabackup/recover“
Performing export of tables…
EXPDP> Starting „SYS“.“TSPITR_EXP_CeFE_accc“:
EXPDP> Estimate in progress using BLOCKS method…
EXPDP> Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
EXPDP> Total estimation using BLOCKS method: 256 KB
EXPDP> Processing object type TABLE_EXPORT/TABLE/TABLE
EXPDP> Processing object type TABLE_EXPORT/TABLE/IDENTITY_COLUMN
EXPDP> Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
EXPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
EXPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER
EXPDP> . . exported „DEMO“.“PERSONEN_DROP“ 26.34 KB 576 rows
EXPDP> Master table „SYS“.“TSPITR_EXP_CeFE_accc“ successfully loaded/unloaded
EXPDP> ******************************************************************************
EXPDP> Dump file set for SYS.TSPITR_EXP_CeFE_accc is:
EXPDP> /u03/orabackup/recover/tspitr_CeFE_69803.dmp
EXPDP> Job „SYS“.“TSPITR_EXP_CeFE_accc“ successfully completed at Fri May 31 10:04:17 2013 elapsed 0 00:00:38
Export completed
Not performing table import after point-in-time recovery
Removing automatic instance
shutting down automatic instance
Oracle instance shut down
Es ist einleuchtend dass die Dauer und der Erfolg eines Table Recoveries davon abhängt, wie groß die Tabelle und der dazugehörige Tablespace sind. Wenn z.B. alleine das SYSTEM Tablespace wegen einer riesigen AUD$ Tabelle schon 20 GB groß ist, dauert dieser Vorgang natürlich entsprechend lange. Außerdem sollte beachtet werden, dass die Auxiliary Instanz natürlich auch ihre Größe (Buffer Cache, Shared Pool) hat und dem entsprechend den Server belastet.
Wenn man dem allerdings gegenüber stellt, dass in über 90% aller Fälle das Export gar nicht benötigt wird sondern nur in dem seltenen Fall, dass der Batchlauf fehlerhaft ist, dann sollte man schon überlegen, ob dieses Verfahren nicht effektiver ist. Übrigens ist die Funktionalität des Table Recoveries gar nicht so neu, man kann sie natürlich auch in einer Oracle 10g oder 11g Datenbank realisieren, allerdings muss man sich dann selbst um den Aufbau der Auxiliary Datenbank kümmern.