Backup etwas für Feiglinge?

Transkript

1 Interview Backup etwas für Feiglinge? Autor: Mike Dietrich, ORACLE Deutschland GmbH Was ist die beste Backup-Strategie? Soll man auf Band oder auf Disk sichern? Wie kann man eine Sicherung schnellstmöglich zurückspielen? Dieser Artikel beantwortet Fragen rund um das Thema "Backup & Recovery" denn Backup ist nicht nur etwas für Feiglinge Gute Backups weiß man spätestens dann zu schätzen, wenn tatsächlich einmal etwas schiefgelaufen ist. Dabei ist nicht nur entscheidend, dass sich ein Backup einspielen und die Datenbank zu einem gewünschten Zeitpunkt wiederherstellen lässt, sondern auch, wie lange dieser Vorgang dauert. Ausfälle sind nicht nur unschön, in der Regel verursachen sie auch erhebliche Kosten bis hin zum Stillstand der operativen Abläufe. Nicht unterschätzen sollte man in diesem Zusammenhang auch den Imageschaden, denn Ausfälle können auch nach außen sichtbar sein; ganz zu schweigen von eventuellen Regressforderungen, die Dritte in Rechnung stellen könnten. Deshalb ist vor der Implementierung eines Backup- und Recovery-Konzepts zuallererst die Frage zu klären, wie viel Zeit bis zur Wiederherstellung der Umgebung verstreichen darf und ob Datenverlust wenn ja, in welchem Umfang in Kauf genommen wird. Diese so genannte Recovery Time Objective (RTO) definiert die zeitliche Obergrenze bis zum Wiedererlangen der vollen Datenbank-Funktionsfähigkeit und umfasst nicht nur das reine Datenbank- Recovery, sondern auch die Zeit, die benötigt wird, um Hardware zu reparieren und Backups von Sicherungsmedien einzuspielen. Des Weiteren gilt es, mit einer Retention Policy festzulegen, wie lange und wie viele Versionen an Backups vorgehalten werden müssen. Ein "gutes" Datenbank-Backup Grundsätzlich versteht man unter einem guten Backup ein vollständiges Backup, das es ermöglicht, eine Datenbank auf einen beliebigen, konsistenten Zustand ohne Datenverlust wiederherzustellen. Dafür muss die Datenbank im Archivelog-Modus betrieben sein. Ansonsten kann bei einem Recovery immer nur das komplette Backup eingespielt werden. Full Database Exports sind kein gutes Backup, da sie nur die Wiederherstellung zum Export-Zeitpunkt ermöglichen, alle danach vorgenommenen Änderungen sind verloren. Backups sollten als Online Backups mit dem Oracle Recovery Manager (RMAN) erzeugt werden. Seit 10g bietet der RMAN auch denjenigen, die sich bisher nicht mit diesem Tool anfreunden konnten, einige zusätzliche Sympathiepunkte: Der Befehlssatz wurde deutlich vereinfacht und RMAN ist vollständig grafisch über das Database Control bzw. das Grid Control zu bedienen (siehe Abbildung 1). Ein großer Vorteil bei der Online-Backup-Erstellung mit RMAN besteht darin, dass Tablespaces gegenüber einem manuellen Online-Backup nicht in den Backup-Modus versetzt werden müssen und deshalb kein zusätzliches 18

2 Backup und Recovery Sichere Datenhaltung Abbildung 1: Oracle Recovery Manager im Database Control Redo während des Online-Backups und damit keine zusätzliche Systemlast anfallen. Außerdem erkennt RMAN beispielsweise Blockkorruptionen bereits beim Sichern. Man kann aber auch gezielt, ohne ein Backup zu erstellen, mit RMAN> backup validate database; die Untersuchung einer kompletten Datenbank auf korrupte Datenblöcke starten, die möglicherweise durch ein beschädigtes Plattenmedium aufgetreten sind. Wohin mit dem Backup? Klassisch werden Datenbank-Backups auf Tapes archiviert. RMAN arbeitet dabei mit den gängigsten Tape-Management-Lösungen zusammen. Oracle bietet aber auch seit April 2006 mit Oracle Secure Backup (OSB) eine eigene Tape- Management-Lösung an, die es erlaubt, Datenbanken und File-System-Daten sehr schnell und kostengünstig zu sichern. Eine kostenfreie Version (Oracle Secure Backup Express) zur lokalen Sicherung steht ebenfalls zur Verfügung. OSB ist in den Enterprise Manager integriert, allerdings momentan nur in Englisch verfügbar. Abbildung 2: Oracle Secure Backup im Database Control Ausführliches Reporting wird mit der nächsten Version zur Verfügung stehen. Die Vorteile von OSB liegen vor allem in der hohen Sicherungsgeschwindigkeit und der Fähigkeit, leere Datenbank-Blöcke bei der Sicherung auf Band zu überspringen, was sich vor allem positiv auf die Zeit auswirkt. Zusätzlich beherrschen RMAN und OSB durch Unterstützung der Advanced Security Option auch die Backup-Verschlüsselung einen Mechanismus, der zunehmend an Bedeutung gewinnt und den man auf jeden Fall nicht außer Acht lassen sollte (vgl. computerwoche.de/index.cfm?pid=254&pk=554053). Seit 10g schlägt Oracle vor, Backups zuerst auf Festplatten zu schreiben. Dafür wird ein Bereich reserviert, die so genannte Flash Recovery Area (FRA), in die auch die archivierten Log-Dateien abgelegt werden können. Die FRA kann dabei auf einem günstigen Storage-Array liegen. Der Vorteil dieses Konzepts besteht vor allem darin, dass alle notwendigen Daten bei einem Recovery sehr viel schneller zur Verfügung stehen. Zusätzlich sind Festplatten in der Anschaffung und Wartung kostengünstig und bieten hohe Lese- und Schreib-Raten. Trotzdem sollte man diese Backups von Zeit zu Zeit auf Tapes oder andere, zuverlässige Medien sichern. Die FRA kann im Filesystem oder in einem vom Automatic Storage Manager (ASM) verwalteten Bereich liegen und wird durch die Parameter db_recovery_file_dest und db_recovery_file_dest_size spezifiziert. Beide Parameter sind dynamisch zu ändern. In der FRA werden auch die Flashback-Logs abgelegt, wenn Flashback für die Datenbank eingeschaltet wurde. Dateien, die außerhalb der eingestellten Retention Policy liegen, werden automatisch aus der FRA gelöscht. Zur richtigen Dimensionierung gilt folgende Faustregel: Zunächst nimmt man die doppelte Datenmenge der archivierten Log-Dateien und Controlfile-Backups an einem produktiven Tag. Ist Flashback Database eingeschaltet, fällt zusätzlich ungefähr die gleiche Menge an Flashback-Logs und Archive-Logs an. Werden inkrementelle Backups in die FRA geschrieben, muss deren Größe, die stark mit der Transaktionslast auf der Datenbank variieren kann, hinzugezählt werden. Werden außerdem noch vollständige Backups in der FRA abgelegt, addiert man in etwa die Größe der Datenbank hinzu, abzüglich der temporären Dateien. Sollte der Bereich zu groß dimensioniert sein, lässt sich der Wert für db_recovery_file_dest_size jederzeit nachträglich anpassen. Backup Best Practices Vor dem ersten Backup sollte die Frage geklärt sein, wie lange Backups vorgehalten werden müssen und wo das "Gedächtnis" des RMAN liegen soll. Standardmäßig benutzt der Recovery Manager das Controlfile der Datenbank, um Buch über die bereits erzeugten Backups zu führen. Das hat zwar den Effekt, dass das Controlfile anwächst, aber in übersichtlichen Umgebungen sollte dies kein Problem darstellen. Erst wenn eine weit in die Vergangenheit zurückreichende Historie erforderlich ist, Schreibvorgänge auf dem Controlfile zum Performance-Engpass werden oder viele Datenbanken auf unterschiedlichen Servern gesichert sind, sollte man über die Benutzung einer so genannten Katalog-Datenbank nachdenken. Bei der Verwendung des Controlfiles als "Gedächtnis" ist aber in jedem Fall zu beachten, dass es unbedingt bei jeder Änderung mitgesichert werden muss. Dazu schaltet man im RMAN zuerst CONTROLFILE AUTOBACK auf ON. Nächster 19

3 Sichere Datenhaltung Backup und Recovery Schritt ist die Anpassung des Initialisierungsparameters CONTROL_FILE_RECORD_KEEP_TIME, der per Standard nur auf "7 Tage" gesetzt ist; ein Wert, der meist als zu gering anzusehen ist. Einträge im Controlfile werden in diesem Fall bereits nach 7 Tagen überschrieben. Im nächsten Schritt wird mit der Retention Policy festgelegt, wie viele Sicherungen gleichzeitig vorgehalten werden müssen. Der Recovery Manager löscht veraltete Sicherungen aber nicht automatisch, sondern zeigt diese nur an und löscht sie erst nach einem 'DELETE OBSOLETE'- Befehl. Beim Einstellen der Retention Policy gibt es zwei Alternativen: Redundancy: Die Redundanz gibt an, welche Anzahl an Sicherungen immer zur Verfügung stehen soll Recovery Window: Mit dem Zeitfenster wird definiert, wie viele Tage maximal rückwärts recovert werden sollen Der RMAN kann nun mit einem einzigen Befehl die Datenbank komplett online sichern: RMAN> backup database plus archivelog; In diesem Fall wird ein Backup Set erzeugt und falls nicht anders definiert in die Flash Recovery Area geschrieben. Es stehen aber auch weitere Zeit und Platz sparende Strategien zur Verfügung. Inkrementelle Backups bieten den großen Vorteil, nur geänderte Blöcke zu sichern. Dadurch verkürzen sich Backup-Zeit und Speicherplatzbedarf. Oracle unterscheidet zwischen inkrementellen 'Level 0'- und 'Level 1'- Backups. Ein 'Level 0'-Backup sichert alle Datenblöcke und ist die Basis für alle weiteren 'Level 1'-Backups, welche nur die geänderten Blöcke seit dem letzten Backup enthalten. Es gibt zwei Strategien, um 'Level 1'-Backups zu erstellen: Differentielle Backups enthalten alle geänderten Blöcke seit dem letzten 'Level 1'-Backup Kumulative inkrementelle Backups umfassen alle modifizierten Blöcke seit dem letzten 'Level 0'-Backup Die beiden Grafiken veranschaulichen die Unterschiede der beiden Strategien: Abbildung 3: Differentielle inkrementelle Backups (Default-Einstellung) Abbildung 4: Kumulative inkrementelle Backups Daraus ergeben sich sofort die Vor- und Nachteile der beiden Strategien. Bei einem differentiellen Backup müssen weniger Blöcke gesichert werden, was einen geringeren Platz- und Zeitbedarf für die Sicherung bedeutet. Im Gegenzug ist jedoch das Einspielen einer Sicherung im kumulativen Fall schneller, da hier weniger Backup-Sets angewendet werden müssen. Ist der für die Flash Recovery Area zur Verfügung stehende Platz stark limitiert, lässt sich auch vor einem neuen, inkrementellen Backup ein Art Verschmelzung des in der FRA befindlichen Image Backups und einer früheren inkrementellen Sicherung herbeiführen. So können beispielsweise die Image Copy vom Sonntag und die inkrementellen 'Level 1'-Sicherungen vom Montag und Dienstag in der FRA liegen. Bevor nun am Mittwoch erneut eine inkrementelle Sicherung durchgeführt wird, die das Delta zu Dienstag enthält, wird die Image Copy vom Sonntag mit dem 'Level 1'-Backup von Montag verschmolzen. Diesen Vorgang bezeichnet man als Rolling Forward Image Copies. Eine Möglichkeit, inkrementelle Backups weiter zu beschleunigen, bietet sich mit dem Block Change Tracking File (BCTF) an. Dieses spiegelt das Block-Layout der Datenbank in einer Bitmap-Struktur wider. Wird ein Block in der Datenbank verändert, ändert sich das Bit an dieser Stelle im BCTF. RMAN erkennt nun, dass dieser Block beim nächsten inkrementellen Backup gesichert werden muss. Der große Vorteil dabei ist, dass nur noch die zu sichernden Blöcke direkt angesprungen werden, wohingegen ansonsten die Datenfiles anhand der SCN auf geänderte Blöcke komplett überprüft werden müssen. Das BCTF kann an beliebiger Stelle liegen, findet aber in der FRA einen guten Platz. Es ist mindestens 10 MB groß, für eine etwa 200 GB große Datenbank wächst es auf circa 25 MB, bei einer Datenbank im TB-Bereich wird es 128 MB umfassen. Die Zeitersparnis beim Sichern kann um rund 80 Prozent gegenüber einer inkrementellen Sicherung ohne BCTF betragen. Geschwindigkeit ist keine Hexerei Die Geschwindigkeit eines Backups kann niemals höher sein als die Leserate der Festplatten-Systeme und die Schreibgeschwindigkeit auf Tape oder in das Sicherungsarray. Zur Optimierung bieten sich allerdings einige Möglichkeiten an. In diesem Zusammenhang soll erst einmal auf das Multiplexing eingegangen werden, das es RMAN 20

4 Backup und Recovery Sichere Datenhaltung erlaubt, gleichzeitig aus mehreren Dateien in ein gemeinsames Backup Set zu sichern. Bei der Benutzung von Hochleistungs-Bandlaufwerken kann man mit dieser Technik erreichen, dass ein kontinuierlicher Datenstrom am Laufwerk ankommt und so das Tape mit maximaler Geschwindigkeit und ohne Stopps beschrieben wird. Multiplexing definiert dabei einen höheren Durchsatz, gleichzeitig verlängert sich allerdings das Zurückspielen einzelner Teile eines Backups deutlich. Wenn beispielsweise nur ein einzelnes Datenfile beschädigt wurde, müssen die auf dem Tape befindlichen Informationen zur Wiederherstellung dieses einzelnen Datenfiles an unterschiedlichen Stellen zusammengesucht werden. Sind die Daten aber schon über viele Plattenspindeln "gestriped", sollte auf Multiplexing verzichtet werden, denn bei klug gewählten Stripe-Sets ist der Durchsatz bereits sehr gut. Ein Backup Set enthält im Gegensatz zu einer Image Copy keine bisher benutzten Datenblöcke und ist damit auch kleiner. Beim Sichern auf Disk wird automatisch asynchron geschrieben, soweit das Betriebssystem diesen Mechanismus unterstützt. Die Sicherung auf Bänder kann auch asynchron erfolgen. Hierzu sollte der Parameter BACKUP_ TAPE_IO_SLAVES auf TRUE gesetzt und zusätzlich ein Large Pool mit LARGE_POOL_SIZE definiert werden, um Contention im Shared Pool zu verhindern. Wird mit SGA_TARGET ab 10g gearbeitet, stellt die Datenbank automatisch zur Laufzeit einen ausreichend großen Large Pool zur Verfügung und erweitert diesen bei Bedarf. Media Recovery Best Practices Inkrementelle Backups haben beim Recovery noch einen großen Vorteil: Ihre Anwendung ist schneller als das Nachfahren von archivierten Logfiles. Der RMAN benutzt soweit vorhanden alle notwendigen inkrementellen Backups, bevor er zum Apply des Archive-Logs übergeht. Die kumulativen inkrementellen Backups haben hier noch einen Vorteil gegenüber den differentiellen es müssen weniger Backup-Sets angewendet werden. Beim Media Recovery werden die Archive-Logs daraufhin gelesen, welche Änderungen angewendet werden müssen. Anschließend wird der benötigte Datenblock in den Buffer Cache geladen und Redo-Information nachgefahren. Am Ende eines komplett archivierten Logfiles wird nun ein Checkpoint geschrieben, das den Database Writer (DBWR) dazu veranlasst, so genannte Dirty Blocks auf Disk abzulegen. Um diese Mechanismen auf mehrere Prozesse zu verteilen und somit die Geschwindigkeit beim Recovery zu steigern, ist ab 10g paralleles Recovery automatisch eingestellt. Der Grad der Parallelität in der Grundeinstellung entspricht der Anzahl der CPUs, die sich im System befinden. Wenn allerdings beispielsweise nur eine kleine Anzahl an Datenfiles wiederhergestellt werden muss, kann der Koordinierungsaufwand der einzelnen Recovery-Prozesse den Geschwindigkeitsvorteil übersteigen. In v$session_wait findet man dann "PX deq"-wait-events, die anzeigen, dass auf den Koordinator der parallelen Aktionen gewartet wird. Grundsätzlich gilt, dass man von einer Datenbank- Instanz, die im Normalbetrieb Performance-Engpässe aufweist, keine Wunderdinge beim Media Recovery erwarten professional it software & services Die PITSS GmbH ist der führende Anbieter von Komplettlösungen für das effektive Management von Oracle Forms Applikationen. Mit der innovativen firmeneigenen Software PITSS.CON unterstützen wir unsere internationalen Kunden schnell und günstig bei allen Themen rund um Oracle Forms! Für unser internationales Wachstum suchen wir erfahrene Professionals: Software Developer IT-Consultant Key Account Manager Weitere Informationen: PITSS ist ISV Partner von ORACLE PITSS GmbH Tel.:

5 Sichere Datenhaltung Backup und Recovery darf. Die Bereiche, in denen sich Datenbank-Tuning sehr positiv auf das Media Recovery auswirken wird, sind: I/O: Aufgrund der vielen Lese- und Schreiboperationen beim Recovery hat dieser Bereich sehr große Auswirkungen auf die Geschwindigkeit beim Recovery. DBWR-Performance: Wenn Redo auf Blöcke beim Recovery im Buffer Cache angewendet wurde, müssen diese Buffer auf Disk geschrieben werden. Kann der DBWR mit dem Recovery-Prozess nicht mithalten, erkennt man das anhand von "free buffer waits" in der View v$session_wait. Wenn nicht gleichzeitig I/O der Engpass ist, sind mehrere Database Writer in diesem Fall hilfreich. Ultra-schnelles Recovery Liegt eine Image Copy, also eine vollständige Kopie, in der Flash Recovery Area, so kann im Fehlerfall beispielsweise, weil eine Datendatei verloren gegangen ist zur Laufzeit auf die Kopie umgeschaltet werden: RMAN> switch datafile <filespec> to copy; Im Controlfile wird der Eintrag für dieses Datenfile geändert und nach einem kurzen Recovery und dem Online-Setzen des Datenfiles ist es sehr schnell wieder verfügbar. Der Befehl switch to copy ist übrigens sowohl auf komplette Tablespaces als auch auf die gesamte Datenbank anwendbar. Extrem schnelles Point-In-Time-Recovery Flashback Database ist ein Feature der Enterprise Edition und spart nicht nur Geld, sondern auch Nerven. Ziel ist es, ein extrem schnelles Point-In-Time-Recovery (PITR) der Datenbank durchzuführen, ohne aber Sicherungen von Bändern restaurieren zu müssen. Voraussetzung dafür ist, in der Datenbank im MOUNT-Status Flashback Database einzuschalten: SQL> alter database flashback on; Nach dem Starten der Datenbank werden nun periodisch Flashback-Logs in die Flash Recovery Area geschrieben. Diese enthalten die Before-Images der geänderten Datenblöcke. Es werden aber nicht alle veränderten Blöcke in diese Logs geschrieben; deshalb muss sich die Datenbank im Archivelog-Modus befinden, denn beim PITR greift RMAN bei fehlenden Informationen automatisch auf die archivierten Logdateien zurück. Das Besondere am Flashback Database ist nun, mit einem einzigen Befehl im SQL*Plus, RMAN oder Enterprise Manager die komplette Datenbank auf einen Zeitpunkt in der Vergangenheit zurückstellen zu können. Und das geschieht sehr viel schneller, als es beim herkömmlichen Media-Recovery möglich ist. In einem Vergleichstest dauerte es beispielsweise etwas über 10 Stunden, um eine 10-TB-Datenbank mit einem schnellen Bandlaufwerk wiederherzustellen und anhand der archivierten Logdateien und auf einen eine Stunde zurückliegenden Zeitpunkt zu recovern. Mit Flashback Database war die Datenbank in 6 Minuten zurückgestellt also um den Faktor 100 schneller. Sollen nur einzelne Inhalte aus der Vergangenheit bereitgestellt, nicht aber die gesamte Datenbank zurückgesetzt werden, gibt es unter Verwendung einer Physical- Standby-Datenbank einen guten Mechanismus: Die Standby-Datenbank wird dabei mit Flashback-Database auf den gewünschten Punkt zurückgestellt. Übrigens kann man so oft wie notwendig vor- und zurückfahren und die Daten dabei aus der Standby-Datenbank beispielsweise mit Export extrahieren und auf dem Produktivsystem wieder importieren. Wird die Standby-Datenbank mit dem Oracle Data Guard betrieben, synchronisiert sich das System automatisch nach dem Wiedereinschalten des Log Apply mit dem Produktionssystem. An das Testen denken! Abschließend noch ein Hinweis: Die beste Strategie zum Backup & Recovery erweist sich in der Praxis manchmal als löcherig, wenn sie nicht getestet wurde. Deshalb müssen auf jeden Fall regelmäßige (!) Tests durchgeführt werden, um einen Eindruck zu bekommen, ob die festgelegten Ziele eingehalten werden. Es hat schon Fälle gegeben, in denen der Tape-Roboter wochenlang immer die gleichen, defekten Bänder in das Bandlaufwerk eingelegt hat. Oder dass beim Sichern zwei wichtige Tablespaces nie mitgesichert wurden, weil sie nicht im Skript notiert waren. Solche Dinge werden leider meist erst dann bemerkt, wenn es zu spät ist und Zeit kostbar wird. Und selbstverständlich sollte die Gesamtstrategie auch dokumentiert sein. ORACLE-Newsticker Kontakt: Mike Dietrich mike.dietrich@oracle.com Im ersten Geschäftsquartal des Fiskaljahres 2007 verbuchte die Oracle Corporation mit einem GAAP-Umsatz von 3,6 Milliarden US-Dollar eine Steigerung von 30 Prozent. Der GAAP-Reingewinn stieg um 29 Prozent auf 670 Mio. US-Dollar. Das entspricht einem Gewinn pro Aktie von 0,13 US-Dollar (plus 28 Prozent). Insgesamt stiegen die Software-Erlöse nach GAAP um 29 Prozent auf 2,7 Milliarden US- Dollar, wozu die Neulizenzen für Datenbanken und Middleware mit 15 Prozent und neue Applikations-Lizenzen mit 80 Prozent beitrugen. Der GAAP-Services-Umsatz belief sich auf 846 Mio. US-Dollar ein Plus von 33 Prozent im Vergleich zum Vorjahresquartal. Der Non- GAAP Gewinn pro Aktie war 0,18 US-Dollar im ersten Quartal; eine Steigerung um 24 Prozent. Der Reingewinn nach Non-GAAP erhöhte sich um 26 Prozent auf 931 Mio. US-Dollar verglichen mit dem selben Quartal des Vorjahres. 22