Backup & Recovery kann Oracle 10g noch Interessantes bieten?

Transkript

1 Donnerstag, 10. November h00, Variohalle 3 Backup & Recovery kann Oracle 10g noch Interessantes bieten? Marco Podolak Trivadis AG Stuttgart, Freiburg, München, Frankfurt, Hamburg, Zürich, Bern, Basel, Lausanne Schlüsselworte: Backup, Recovery, RMAN, Flashback Database, Restore Points, Guaranteed Restore Points, Encrypted Backup, Compressed Backup Zusammenfassung Auch in Oracle 10g wurde der Bereich Backup/Recovery nicht vergessen. In Release 1 wie auch Release 2 hat Oracle sehr interessante Features herausgebracht, die nicht nur Spezialanforderungen abdecken, sondern auch im täglichen Business eingesetzt werden können. Flashback Database erweitert die Recovery Möglichkeiten einer Datenbank enorm. Mit Oracle 10g Release 2 sind Szenarien denkbar, die insbesondere im Bereich von Entwicklungs-Datenbanken sehr interessant sein können. Aber auch für produktive Datenbanken kann die Repair-Zeit unter Umständen deutlich reduziert werden. Compressed Backups wurden früher z.t. manuell implementiert, was nicht immer ganz unproblematisch war. Seit Oracle 10g kann RMAN selbst komprimieren und dies auch noch effizienter als OS Utilities. Sicherheit wird in vielen Firmen immer grösser geschrieben und diesen Anforderungen können wir jetzt auch im Backup Bereich gerecht werden. Mit Encrypted Backup, verschlüsselt RMAN nun auch das Backup Set. Flashback Database Mit Oracle 10g Release 1 wurde neu das Konzept von Flashback Database eingeführt. Eine neue Möglichkeit für eine rasche Recovery einer gesamten Datenbank. Mit Oracle10g Release 2 hat Oracle das Feature nochmals erweitert und auch wichtige Restriktionen aufgehoben. Das Konzept von Flashback Database ist interessant, weil wir damit in einigen Fehlersituationen die Downtime drastisch reduzieren können. Dank Flashback Database ist es möglich, eine Datenbank ohne Restore von Datenfiles auf einen älteren Zeitpunkt (also Vergangenheit) zurück zu rollen. Abb. 1: Konzept Flashback Database

2 18. Deutsche ORACLE-Anwenderkonferenz Das klassische Datenbank Point-in-Time Recovery bedingt immer den Restore eines Backups und eine anschliessende Recovery (rollforward). Flashback Database ist in erster Linie dafür vorgesehen, Datenfehler, User Fehler oder Datenkorruptionen zu korrigieren bzw. rückgängig zu machen. Für Hardware Fehler (z.b. Disk Crash) ist das Konzept ungeeignet. Hierfür werden weiterhin konventionelle Backups und Recoveries benötigt. Gegenüber einer konventionellen Recovery, kann mit Flashback Database, insbesondere bei sehr grossen Datenbanken, unter Umständen einige Stunden der Repair Zeit eingespart werden, da das Restore der Datenbank entfällt. Aber auch für die Zeit des Flashback Database muss die Datenbank offline sein (Mount Status). Voraussetzungen Für Flashback Database werden spezielle Logfiles, so genannte Flashback Logs, benötigt. Die Flashback Logs müssen zwingend in die Flash Recovery Area geschrieben werden. Das Schreiben der Flashback Informationen übernimmt der neue Hintergrundprozess RVWR (Recovery Writer). Um Flashback Database überhaupt aktivieren zu können, muss die Datenbank bereits im Archivelog Modus betrieben werden und die Flash Recovery Area muss, für die entsprechende Datenbank, spezifiziert sein. Aktivieren des Flashback Database erfolgt im MOUNT Status. Mit dem Befehl "ALTER DATABASE FLASHBACK ON". Zusätzlich sollte die Aufbewahrungsfrist der Flashback Logs mit dem Parameter DB_FLASHBACK_RETEN- TION_TARGET definiert werden. Monitoring Für das Monitoring stehen zwei Views zur Verfügung. V$FLASHBACK_DATABASE_LOG V$FLASHBACK_DATABASE_STAT Aus der View V$FLASHBACK_DATABASE_LOG ist ersichtlich, wie weit momentan ein Flashback in die Vergangenheit möglich ist. Ebenso kann die View benutzt werden, um eine Spaceberechnung aufgrund des aktuellen Workloads zu machen. Die View V$FLASHBACK_DATABASE_STAT zeigt das I/O der letzten 24 Stunden, das für Flashback erzeugt wurde, an. Oder wer es einfacher mag, kann Flashback Informationen auch im Enterprise Manager 10g einsehen. Insbesondere in Oracle10g Release 2 werden sehr detaillierte Informationen über die Auslastung der Flash Recovery Area und die Flashback Logs angezeigt. Architektur Abb. 2: Flash Recovery Area Informationen des EM 10g

3 Einschränkungen Wie alle anderen Recovery Funktionalitäten, ist auch Flashback Database nicht das Heilmittel für alle Fehler Situationen. Einige Restriktionen schliessen ein Flashback Database aus. So kann beispielsweise kein Flashback Database benutzt werden, wenn... Ein Tablespace oder Datenfile gedropped wurde Ein Controlfile restored oder rekreiert wurde Ein Datenfile verkleinert wurde NOLOGGING und/oder Direct Path Operationen zum Zeitpunkt des Flashback Ziels stattgefunden haben. Dies kann zu korrupten Datenblöcken führen Flashback Database kann sowohl im SQL*Plus als auch im RMAN aufgerufen werden. Vorzugshalber sollte man jedoch RMAN verwenden, da dieser nebst den Flashback Logs auch die Verfügbarkeit der Archivelogs kennt. Denn beide Log Typen werden für ein Flashback Database benötigt. Für das eigentliche Flashback muss das "Recovery" Ziel, wie beim Recover Befehl, mit einer SCN (System Change Number), einer Sequence oder einem Zeitpunkt (Timestamp) spezifiziert werden. RMAN> FLASHBACK DATABASE TO SCN ; Ebenso wird Flashback Database auch im Enterprise Manager unterstützt. Abb. 3: Flashback Database Flashback Database über Resetlogs In der Version war ein Flashback über den Punkt eines OPEN RESETLOGS nicht möglich. Mit Oracle10g Release 2 ist diese Restriktion aufgehoben worden. Damit wird das Einsatzgebiet des Flashback Database nochmals stark erweitert. Den nahe liegenden Gedanken Wofür mache ich dann noch ein Backup? empfehle ich jedoch, sofort wieder zu verwerfen. Denn es gibt immer noch genügend Fehlersituationen, die zwingend auf ein konventionelles Backup zurückgreifen müssen. Restore Points Wie gesehen, muss für eine Flashback Database der Zeitpunkt oder die SCN bekannt sein, um das Recovery Ziel bestimmen zu können. Um das Flashback zu vereinfachen, hat Oracle mit Oracle10g Release 2 die Restore Points eingeführt. Mit dem Restore Point kann eine Art Alias oder "Bookmark" gesetzt werden. Diesen entsprechenden Punkt können wir später wieder mit Flashback Database ansprechen. Die Restore Points setzen Flashback Logging voraus. Damit eröffnet sich insbesondere auch bei Entwicklungs-Datenbanken ein neues weites Feld von Möglichkeiten. Denkbar ist der Einsatz von Restore Points z.b. auch bei Applikations Upgrades oder Ähnlichem.

4 18. Deutsche ORACLE-Anwenderkonferenz Die Nutzung der Restore Points ist sehr einfach. Vor dem Start einer kritischen Verarbeitung setzt man einen Restore Point. Sollte sich die Änderung in der Datenbank als Fehlerhaft herausstellen, kann bequem über den Restore Point der ursprüngliche Zustand wieder hergestellt werden. RMAN> FLASHBACK DATABASE TO RESTORE POINT 'Vor_Fibu_Upgrade'; Restore Points können auch mit FLASHBACK TABLE und Point-in-Time Recovery (recover database until ) verwendet werden. Was ist aber, wenn der Restore Point aus Versehen weiter zurück liegt als die Flashback_Retention? Oder gar Platzprobleme im Bereich der Flashback Logs auftraten und einige Logs automatisch gelöscht wurden? Garantierte Restore Points Die Antwort von Oracle auf obige Fragen heisst, 'Guaranteed Restore Point'. Garantierte Restore Points können unter allen Umständen wieder angesprungen werden. Für die garantierten Restore Points verwendet Oracle nochmals einen eigenen Logging Mechanismus. Die Logging Informationen werden jedoch ebenfalls in die Flashback Logs geschrieben. Dank dem erweiterten Log Mechanismus ermöglichen die garantierten Restore Points aber auch ein Flashback auf Zeitpunkte, in denen NOLOGGING oder Direct Path Operationen stattfanden. Um garantierte Restore Points verwenden zu können, muss Flashback NICHT eingeschaltet sein. Das Setzen eines ersten garantierten Restore Points muss dann aber im MOUNT Status erfolgen. Der Grund liegt darin, dass Oracle in diesem Fall ein eingeschränktes Flashback Logging einschalten muss. Oracle löscht garantierte Restore Points nicht automatisch. Sie müssen explizit wieder gelöscht werden. Nach dem Löschen der garantierten Restore Points werden auch automatisch die nicht mehr benötigten Flashback Logs gelöscht. Garantierte Restore Points und Flashback über Resetlogs Die Kombination der beiden Features bringt ungeahnte Möglichkeiten im Recovery Bereich. So erlaubt nun Oracle mit Flashback Database nicht nur ein Flashback in die Vergangenheit. Je nach aktuellem Punkt, wo wir uns nach einem ersten Flashback befinden, kann anschliessend auch ein Flashback in die Zukunft erfolgen. Wie die nachfolgende Grafik zeigt, sind Szenarien möglich, dass problemlos über mehrere Inkarnationen, jeder beliebige Restore Point von jedem beliebigen Punkt, mit Flashback, angesprungen werden kann. Am Zielpunkt kann die Datenbank mit Read Only geöffnet werden, um beispielsweise den Dateninhalt zu kontrollieren oder Daten zu exportieren. Architektur Abb. 4: Garantierte Restore Points in verschiedenen Inkarnationen Somit lassen sich in kürzester Zeit verschiedene Systemzustände ohne langwierigen Restore herstellen. Es ist durchaus denkbar, dass sich damit auch Snapshot Mechanismen ersetzen lassen.

5 Compressed Backups Compressed Backups hat Oracle mit Oracle10g Release 1 eingeführt. Sie erlauben RMAN Backup Sets binär zu komprimieren. Für Image Copies ist Komprimierung nicht unterstützt. Komprimierte Backup kosten zwar einiges an CPU Leistung. So wurde in Vergleichstests festgestellt, dass z.t. die CPU Last um 20 30% höher lag als für unkomprimierte Backups. In einigen Fällen ist es jedoch möglich, dass sich die gesamte Laufzeit der Backups, dank eingesparten I/O, trotzdem reduziert. Abb. 5: Laufzeiten und Komprimierungs Gewinn mit Compressed RMAN Backup Sets Die Platzersparnis mit komprimierten Backups ist recht gross. So sind Komprimierungsfaktoren, je nach Dateninhalt, von 3,5 bis 6 realistisch. RMAN benötigt keine spezielle Konfiguration für komprimierte Backups. Es reicht, wenn beim Backup Befehl dies spezifiziert wird. RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE FORMAT '<bp_name>'; Mittels des CONFIGURE Befehls ist es auch möglich, komprimierte Backup Set's als default zu konfigurieren. RMAN> show device type; RMAN configuration parameters are: CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO COMPRESSED BACKUPSET; CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 1 BACKUP TYPE TO COMPRESSED BACKUPSET; Der Nutzen von komprimierten Backups ist für Disk -, wie auch Tape Backups gegeben. Denn nebst massiver Platzersparnis und geringerem I/O auf dem Backup Medium, profitieren auch Tape Backups von einer geringeren Netzwerk Belastung. Encrypted Backups Mit verschlüsselten Backups bietet Oracle nun in Oracle10g Release 2 erstmals Datenschutz auf Ebene des Backup. Das Einlesen eines verschlüsselten RMAN Backup Set's ohne entsprechendem Passwort oder Wallet ist nicht möglich. Drei verschiedene Verschlüsselungs Algorithmen werden unterstützt: AES128 AES192 AES256

6 18. Deutsche ORACLE-Anwenderkonferenz Verschlüsselte Backups sind nur für RMAN Backup Set's unterstützt und die Advanced Security Option wird vorausgesetzt. Somit ist auch bereits erkennbar, dass verschlüsseltes Backup nur die Enterprise Edition unterstützt ist. Ist die Verschlüsselung für die Datenbank konfiguriert, erfolgt das Ver- und Entschlüsseln während der Backup und Restore Operationen transparent. RMAN bietet drei verschiedene Varianten für die Konfiguration von Verschlüsselung an: Transparent Mode (Verwendung des Oracle Encryption Wallets) Password Mode (Eingabe eines Passwortes) Dual Mode (Kombination der obigen Varianten) Methoden des Encrypted Backup Für den Transarent Mode muss ein Oracle Encryption Wallet für die Datenbank erstellt und ein Master Key im Wallet gespeichert werden. Nach dem Startup der Instanz ist das Wallet einmalig zu öffnen. Alternativ kann das Wallet auch mit Autologin konfiguriert werden. In diesem Fall entfällt das einmalige Öffnen des Wallets. Anschliessende Backup und Restore Operationen können dann ohne weitere Intervention des DBA verschlüsselt ausgeführt werden. Backups die mit Transparent Mode verschlüsselt wurden, können nur auf demselben Rechner restored werden. Beim Password Mode muss vor jeder Backup und Restore Operation vom DBA ein Passwort gesetzt werden. Automatisierte nächtliche Backups werden dadurch unmöglich. RMAN> SET ENCRYPTION ON IDENTIFIED BY <password> ONLY; RMAN> BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT; Backups die mit Passwort Mode verschlüsselt wurden, können auch problemlos auf einem Remote Rechner restored werden. Mit dem Dual Mode lassen sich die beiden vorgängig beschriebenen Methoden kombinieren. Somit sind für die "nächtlichen" automatisierten Backups keine Interventionen nötig und sollte mal ein bestimmtes Backup auf einem Remote Rechner restored werden müssen, kann für diese Aufgabe ein Backup mit explizitem Passwort erzeugt werden. Performance Wie bei vielen neuen Features stellt sich auch hier die Frage, wieviel Overhead das Verschlüsseln schlussendlich kostet. Beim Backup fällt häufig eine etwas längere Laufzeit nicht allzu stark ins Gewicht. Aber insbesondere bei Restore und Recover darf sich die Repair-Zeit nicht zu stark verlängern. Gemäss unseren Tests ist glücklicherweise der Overhead für die Verschlüsselung vernachlässigbar. Architektur Abb. 6: Laufzeitvergleich für verschlüsselte Backups

7 Ein Feature also, das für Datenbanken mit sehr sensitiven Daten, durchaus zur Anwendung kommen darf. Voraussetzung ist hierfür aber, dass ein sicheres und geregeltes Wallet Management gewährleistet ist. Fazit Die wichtigsten Anforderungen an ein Backup sind aus meiner Sicht: Effizienz, Sicherheit und kurze Repair-Zeit. In allen drei Bereichen hat Oracle Verbesserungen gebracht. Wie überall gibt es zwei Seiten einer Medaille. So haben auch diese Features ihre Nachteile bzw. ihren Overhead und sind darum nicht für jegliche Anforderung bedenkenlos geeignet. Aber richtig eingesetzt, getestet und dokumentiert, können alle drei Features zur Verbesserung der Effizienz und Sicherheit beisteuern. Kontaktadresse: Marco Podolak Senior Consultant Trivadis AG Papiermühlestrasse 73 CH-3015 Bern Telefon: +41(0) Fax: +41(0) Internet: