Total synchron Daten retten ohne Downtime?! Oracle DataGuard und Flashback

Transkript

1 Mittwoch, 10. November h00, Mozartsaal Total synchron Daten retten ohne Downtime?! Oracle DataGuard und Flashback Mike Dietrich ORACLE Deutschland GmbH, München Schlüsselwörter DataGuard, Flashback, Datenrettung ohne Downtime, Standby-Datenbank, Oracle Database 10g, Point-In-Time-Recovery 1. Zusammenfassung Versehentlich gelöschte Daten wiederherzustellen ist eine mühsame und zeitraubende Aufgabe, die im produktiven Datenbank-Alltag des öfteren notwendig ist. Die Kombination einer Standby-Datenbank mit Oracle DataGuard in Verbindung mit der Flashback-Technologie ab Oracle Database 10g macht zum einen eine Produktivumgebung hochverfügbar und sicher gegen Ausfälle, zum anderen können Daten in Minutenschnelle wiederhergestellt werden ohne den Produktiv-Betrieb zu beeinträchtigen. 2. Einleitung Kennen Sie dieses Szenario? Es ist Freitag, 17:25h. Sie freuen sich aufs wohlverdiente Wochenende und packen gerade Ihre Sachen zusammen. Da klingelt das Telefon. Eine aufgeregte Stimme am anderen Ende der Leitung berichtet hastig, mit einem Batch-Job, der versehentlich auf der Produktions- anstelle der Testdatenbank abgelaufen ist, wichtige Tabellen mit TRUNCATE geleert zu haben. Sie wissen genau: TRUNCATE ist dieses tolle SQL-Kommando, mit dem man in Sekundenbruchteilen alle Datensätze einer gigabyte-großen Tabelle rückstandslos verschwinden lassen kann. Dabei hinterläßt TRUNCATE fast keine Spuren und schreibt auch keinerlei Rollback-Informationen. Und jetzt? Im Normalfall bieten sich folgende Optionen: Ein Point-In-Time-Recovery der kompletten Datenbank durchführen damit gehen aber auch alle nach dem TRUNCATE-Job getätigten Änderungen verloren. Einen Export-Dump heranziehen und in eine leere Datenbank importieren oder mithilfe eines Backups den Zeitpunkt vor dem Löschen anfahren, dann die Daten aus der Test-Datenbank mit exp/imp oder einem Database Link aufs Produktiv-System zurückspie-

2 17.Deutsche ORACLE-Anwenderkonferenz Database len.. Allen Optionen ist gemein: Sie sind sehr zeitaufwändig und es wird an besagtem Freitag wahrscheinlich sehr spät für Sie werden. Die Alternative: Benützen Sie eine Physical Standby Datenbank zur Absicherung Ihrer Produktiv-Umgebung und stellen Sie dort FLASHBACK ein. Damit können Sie die Daten mit wenigen Kommandos aus der Standby-Datenbank extrahieren und auf ihr Produktiv-System zurückspielen. Die Nebeneffekte dabei sind die totale Synchronisation der beiden Datenbanken, was bei einem unvorhergesehen Ausfall zu einer minimalen Umschaltzeit führt. Sie müssen bei einem Totalausfall des Produktiv-Systems nach dem Umschalten auf die Standby-Datenbank die Standby-Umgebung nicht neu aufbauen. Damit sparen Sie in erheblichem Maße Zeit und Geld und schonen Ihre Nerven. 3. Grundlagen und Technik 3. 1 Oracle DataGuard Um sich gegen unvorhergesehene Ausfälle einer produktiven Datenbank abzusichern, bietet sich die Oracle DataGuard-Technologie an. Ausfälle können sehr teuer werden. Angefangen von einer Lagerverwaltung bis hin zu einem Online- Brokerage-System können die Ausfallkosten in die Millionen Euro gehen. Zusätzlich sind heutzutage viele Systeme "sichtbar" sprich der Image-Schaden, eventuell sogar einhergehend mit Regressforderungen Geschädigter, kann immens sein. Standby-Funktionalität existiert bereits seit Oracle7.3. Seit Oracle8 ist Oracle DataGuard verfügbar. Dieses Paket inkludiert alle notwendigen Funktionen zum Aufbau und zur Adminstration einer Standby-Datenbank. Dabei werden zwei Typen von Standby-Datenbanken unterschieden: a) Physical Standby Hierbei handelt es sich um eine reine Desaster-Recovery-Lösung. Eine physikalische Standby-Datenbank ist eine blockidentische Kopie der Produktionsdatenbank. Die archivierten Redolog-Dateien des Produktionssystems werden auf ihr nachgefahren und so werden alle Änderungen vom Hauptsystem auch auf dem Standby-System angewendet. Kommt es zum Fehlerfall (bspw. Totalausfall des Produktiv-Systems), so kann manuell auf das Standby- System umgeschaltet werden. Dort sind dann auch alle Änderungen vorhanden und die Anwender können auf dem Stand von "Vor-dem-Ausfall" weiter arbeiten. Zusätzlich kann die Standby-Datenbank auch im Lese- Modus (Read Only) geöffnet werden. In diesem Zeitraum können allerdings keine archivierten Logdateien angewendet werden. Diese müssen dann nach dem Zurücksetzen des Standby-Systems in den Managed Recovery-Modus nachgefahren werden. Außerdem kann solch ein Standby-System mit dem DataGuard Broker und/oder dem Enterprise Manager mit wenigen einfachen

3 Kommandos administriert werden. Es können bis zu 9 Standby-Datenbanken zu einem Produktionssystem angelegt werden. Diese können auch kaskadierend sein. Seit Oracle Database 10g kann mithilfe von Standby Logfiles und dem Prozess LGWR (Log Writer) die totale Synchronisation der Produktiv- und Standby-Seite (Real Time Apply) herbeigeführt werden. Das bedeutet, dass ein Datensatz, der auf dem Produktiv-System eingetragen und comitted wird, unmittelbar nach dem Commit auch auf der Standby-Seite vorhanden ist. Bei einem Failover bedeutet dies, dass nicht mehr das letzte Logfile der Produktionsumgebung angewendet werden muß und damit die Umschaltzeit um ein Vielfaches kürzer wird. Nimmt man nun noch die Flashback- Funktionalität hinzu, ist auch eine Verzögerung beim Einspielen der Logfiles (Delay) überflüssig. Dazu weiter unten mehr. b) Logical Standby Eine logische Standby-Datenbank unterscheidet grundsätzlich von einer physikalischen, dass es sich um keine Desaster-Recovery-Lösung handelt. Eine Logical Standby-Datenbank ist eine logische und keine blockidentische Kopie eines Produktiv-Systems. Sie muß noch nicht einmal alle Daten der Produktionsdatenbank enthalten, sondern kann nur einen speziell ausgewählten Bereich umfassen. Ziel einer logischen Standby-Datenbank ist das Online- und Echtzeit-Reporting. Im Gegensatz zur Physical Standby werden hier die ankommenden Log-Informationen mit Logminer-Technologie extrahiert und wieder in SQL-Statements übersetzt diese werden dann auf die Objekte der Logical Standby-Datenbank angewendet. Daraus ergibt sich, dass selbige geöffnet und verfügbar ist. Es findet folglich kein Recovery statt. Diese Funktionalität existiert seit Oracle Database 9.2. Mit Oracle Database 10g fallen einige Limitationen: so kann bspw. der Aufbau der Logical Standby-Database online erfolgen, die Produktiv-Instanz muß dazu nicht mehr gestoppt werden. Desweiteren werden alle wichtigen Datentypen (auch LOB und LONG, sowie IOTs) unterstützt. Zusätzlich wird ab dem Datenbank-Patchlevel auch das Rolling Release Upgrade mithilfe einer Logical Standby-Datenbank unterstützt. 3.2 Oracle Flashback 40% der Ausfälle auf einem Datenbanksystem resultieren aus Benutzerfehlern wie zum Beispiel versehentlich gelöschten oder veränderten Daten oder gar Tabellen. Um diese Fehler schnell beheben zu können, stellt Oracle in der Oracle Database 10g die Flashback-Technologie zur Verfügung. Ziel ist es, Daten in wenigen Sekunden wiederherzustellen, deren Recovery in vorherigen Releases meist im Stundenbereich lag. Dabei werden drei Typen unterschieden: a) Flashback Query, Flashback Versions Query und Flashback Transaction Query stellen Mechanismen zur Verfügung, um Veränderungen an den Daten einer Tabelle mittels einer einfachen SQL-Abfrage nachzuvollziehen

4 17.Deutsche ORACLE-Anwenderkonferenz Database b) Flashback Table und Flashback Drop können eingesetzt werden, um Daten und Tabellen inklusive direkt abhängiger Indizes und Constraints aus dem datenbank-internen Recycle Bin wiederherzustellen c) Flashback Database wird dazu benutzt, um ein Point-In-Time-Recovery der kompletten Datenbank vorzunehmen. Der Unterschied zum herkömmlichen Point-In-Time- Recovery besteht vor allem in der Geschwindigkeit und der Tatsache, dass kein Backup eingespielt werden muß. Man kann auch vom "Rückspulknopf in der Datenbank" sprechen. Vorraussetzung für alle geschilderten Szenarien ist, dass sowohl auf der Produktiv- als auch auf der Standby-Datenbank eine Flash Recovery Area definiert wurde und Flashback eingeschaltet ist: SQL> select flashback_on from v$database; FLASHBACK_ON YES Andernfalls muß Flashback eingeschaltet werden dabei muß die Datenbank sich die Datenbank im MOUNT EXCLUSIVE Status befinden: SQL> startup mount exclusive; SQL> alter database flashback on; Die Zeitdauer, wie lange Flashback-Informationen zur Verfügung stehen sollen, wird über den init-parameter flashback_retention_target eingestellt. Dies legt eine Mindest-Dauer fest, kann aber bei ausreichendem Plattenplatz auch durchaus länger sein. Die Datenbank schreibt dann im Hintergrund über den neuen Prozess RVWR (Recovery Writer) die "alten" Inhalte geänderter Blöcke in die Flashback Log Files. Der Performance Overhead, wenn Flashback-Funktionalität eingeschaltet wurde, beträgt weniger als 2%. 3.3 Allgemeine Vorraussetzungen Hilfreich ist es, wenn Real Time Apply für das Anwenden der Log-Informationen auf der Standby-Datenbank benutzt wird dann sind alle Änderungen, die an der Produktiv-Datenbank vorgenommen werden, sofort auch in der Standby- Datenbank vorhanden, da sie in die sogenannten Standby-Logfiles eingetragen werden. Im Folgenden sollen drei Szenarien erläutert werden, die durch die Kombination Oracle DataGuard und Oracle Flashback eine signifikante Zeit- und

5 Kostenersparnis beim Wiederherstellen von Daten oder beim Re-Instantiieren der Standby-Umgebung nach einem Failover darstellen. Der Übersichtlichkeit wegen wird jeweils immer mit einer SCN anstelle eines Zeitstempels gearbeitet. In der Praxis wird man sicherlich eher bis zu einem bestimmten Zeitpunkt zurückspulen die Syntax bleibt die gleiche. 4. DataGuard/Flashback-Szenarien 4.1 Szenario I: Daten wiederherstellen Ausgangspunkt: Daten wurden unabsichtlich auf der Produktionsdatenbank gelöscht (bspw. mit einem TRUNCATE TABLE). Dieses Szenario erfordert normalerweise das Einspielen der Daten auf einem Testsystem (bspw. aus einem Backup) oder das Betreiben einer Standby-Umgebung mit verzögertem Log-Apply. Erstere Möglichkeit ist in Abhängigkeit von der Größe der Datenbank sehr zeitraubend, letztere bewirkt längere Umschaltzeiten bei einem Failover bzw. Switchover, denn die zwischengelagerten Logfiles müssen erst auf der Standby-Datenbank nachgefahren werden, wenn es zum Failover oder kontrollierten Umschalten kommt. Ziel: Die Daten so schnell und einfach wie möglich wiederherstellen und auf der Produktionsdatenbank zur Verfügung stellen, wobei die Produktiv-Umgebung nicht beeinträchtigt werden soll. Vorgehensweise: Die physikalische Standby-Datenbank wird mit FLASHBACK DATABASE auf einen Zeitpunkt in der Vergangenheit zurückgestellt. Flashback erlaubt es dabei, die Datenbank beliebig oft noch weiter zurück oder auch näher an die Gegenwart heran zu bewegen. Die Standby-Datenbank kann hierzu read only geöffnet werden, um den Status der gesuchten Daten zu überprüfen. Anschließend werden diese Daten dann exportiert und auf der Produktionsdatenbank eingespielt. Die physikalische Standby-Datenbank wird anschließend wieder in den Managed Recovery Modus versetzt und synchroniert sich automatisch wieder mit der Produktiv-Datenbank. Ablauf: 1. Auf der Produktions-Datenbank (hier: PROD) wurden Daten gelöscht 2. Die physikalische Standby-Datenbank (hier: PHYS) daraufhin mit FLASH- BACK DATABASE auf einen gewünschten Zeitpunkt bewegen 3. PHYS im Lesemodus (Read Only) öffnen und die benötigten Daten oder User- Schemata exportieren 4. Danach wieder PHYS in den Managed Recovery Modus versetzen es findet eine automatische Re-Synchronisation mit PROD statt 5. Die Daten dann auf PROD importieren

6 17.Deutsche ORACLE-Anwenderkonferenz Database PROD PHYS SQL> select current_scn from v$database; SQL> truncate table scott.emp; SQL> select oldest_flashback_scn from $flashback_database_log; SQL> flashback standby database to scn <CURRENT_SCN von PROD>; SQL> alter database open read nly; $> exp scott/tiger tables=emp SQL> alter database recover managed standby database disconnect; ** automatische Synchronisation ** $> imp scott/tiger file=exp.dmp ** Daten stehen wieder zur Verfügung ** ** Keine Downtime auf der PROD-DB ** Mit diesem Vorgehen wurden Daten, die versehentlich gelöscht wurden, in wenigen Minuten auf dem Standby-System wiederhergestellt und per Import wieder auf der Produktionsdatenbank zur Verfügung gestellt. 4.2 Szenario II: Point-In-Time-Recovery der Produktionsdatenbank ist notwendig Ausgangspunkt: Ein Point-In-Time-Recovery der Produktionsdatenbank wird notwendig. Dies ist erst nach dem aufwändigen Einspielen eines Backups und der zugehörigen archivierten Logfiles möglich. In einer Standby-Umgebung führt das dazu, dass die Standby-Datenbank neu aufgebaut werden muß und die Produktionsdatenbank für den Zeitraum des Aufbaus quasi ohne "Netz und doppelten Boden" betrieben wird. Ziel: Nach einem Point-In-Time-Recovery der Produktionsdatenbank soll die Standby- Datenbank nicht neu aufgebaut werden müssen.

7 Vorgehensweise: Auf PROD wird ein Point-In-Time-Recovery mithilfe von FLASHBACK DATABASE durchgeführt. Damit wird die langwierige Prozedur des Einspielens eines Backups umgangen. PROD wird dann mit OPEN RESETLOGS geöffnet. Daraufhin wird PHYS auf eine bestimmte SCN auch mit FLASHBACK DATABASE zurückgesetzt und es findet eine automatische Re-Synchronisation mit PROD statt. Ablauf: 1. FLASHBACK DATABASE auf PROD als Point-In-Time-Recovery 2. PROD mit RESETLOGS öffnen 3. RESETLOGS_CHANGE# - 2 bestimmen und FLASHBACK STANDBY DATA- BASE bis zu diesem Wert durchführen 4. Anschließend automatische Re-Synchronisation mit PROD PROD PHYS SQL> select current_scn from v$database; SQL> update emp set sal=1; SQL> commit; SQL> shutdown abort; SQL> flashback database to scn <CURRENT_SCN von oben>; SQL> alter database open resetlogs; SQL> select resetlogs_change#-2 from v$database; SQL> select sal from scott.emp; ** Daten stehen wieder zur Verfügung ** SQL> flashback standby database to scn <RESETLOGS_CHANGE#-2 von PROD>; SQL> alter database recover managed standby database disconnect ** automatische Synchronisation ** Damit ist obwohl auf der Produktionsdatenbank ein Point-In-Time-Recovery mit anschließendem RESETLOGS durchgeführt worden ist - die Standby-Daten-

8 17.Deutsche ORACLE-Anwenderkonferenz Database bank erhalten geblieben. Der Neuaufbau wurde umgangen. 4.3 Szenario III: Failover ist erfolgt Neuaufbau der Standby-Datenbank umgehen Ausgangspunkt: Nach einem Fehlerfall wurde ein Failover vom Produktiv- auf das Standby- System initiiert. Bisher führte das dazu, dass eine neue Standby-Datenbank aufgebaut werden musste, um dann einen kontrolloierten Switchover durchzuführen und den Ausgangszustand wieder herzustellen. Dieses Prozedere ist sehr zeitaufwändig und ressourcen-intensiv. Ziel: Kein Neuaufbau einer Standby-Datenbank nach einem Failover. Vorgehensweise: Die ehemalige Produktionsdatenbank auf eine bestimmte SCN zurückstellen, ein neues Standby-Controlfile anlegen, die Synchronisation mit der neuen Produktionsdatenbank herbeiführen und dann gegebenenfalls einen Switchover durchführen. Ablauf: 1. Failover von PROD nach PHYS ist erfolgt. PHYS ist nun die neue Produktionsdatenbank 2. Flashback auf der PROD, die nun inaktiv ist, bis STANDBY_BECAME_PRIMARY_SCN 3. Standby-Controlfile anlegen 4. Log-Transport wieder einschalten und gegebenenfalls Switchover PROD PHYS SQL> select standby_became_primary_scn from v$database; SQL> flashback database to scn <STANDBY_BECAME_PRIMARY_SCN>; SQL> alter database flashback off; SQL> alter database create standby controlfile as <filename>; SQL> startup mount SQL> alter database flashback on;

9 SQL> alter system set log_archive_dest_state_2=enable; SQL> alter database recover managed standby database disconnect from session; ** Jetzt kontrollierter Rollentausch ** ** (Switchover) möglich, um zur ** ** Ausgangssituation zurückzukehren ** Mit diesem Verfahren wurde der zeit- und ressourcenintensive Neuaufbau einer Standby-Umgebung nach einem Failover verhindert. Flashback wurde aus- und wieder angeschaltet, um die Flashbacklogs zu bereinigen. 7. Fazit Oracle DataGuard ist das Produkt, um eine ausfallsichere Standby-Umgebung aufzubauen, die selbst im Katastrophenfall garantiert, dass keinerlei Datenverlust entsteht. Durch Real-Time-Apply ist die 100%-prozentige Synchronisation mit der Produktiv-Datenbank möglich, was sowohl beim Switchover, als auch beim Failover einen deutlichen Zeitgewinn bedeutet und zusätzlich beim Reporting selbiges auf den Live-Daten durchführbar macht und gleichzeitig das Produktionssystem entlastet. Oracle Flashback ist das Mittel, um sich gegen das unbeabsichtige Ändern oder Löschen von Daten zu wappnen. Dabei ist es so einfach zu handhaben, dass sowohl Zeit- als auch Kostenaspekte bei der Wiederherstellung dieser Daten unschlagbare Argumente für den Einsatz liefern. Gemeinsam bilden Oracle DataGuard und Oracle Flashback eine Kombination, die die Vorzüge beider Funktionalitäten verbindet und mit der man Fehler in Minutenschnelle ausbügeln kann, ohne den Produktiv-Betrieb zu beinflussen. Kontaktadresse: Mike Dietrich Riesstr. 25 D München Telefon: +49(0) Fax: +49(0) Internet: