Backup – etwas für Feiglinge?

Interview
Backup – etwas für Feiglinge?
Autor: Mike Dietrich, ORACLE Deutschland GmbH
18
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 …
Ein "gutes" Datenbank-Backup
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-
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
News Q4-2006
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.
www.doag.org
Backup und Recovery
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 TapeManagement-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.
Sichere Datenhaltung
Backup-Verschlüsselung – einen Mechanismus, der zunehmend an Bedeutung gewinnt und den man auf jeden
Fall nicht außer Acht lassen sollte (vgl. http://www.
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
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
www.doag.org
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
News Q4-2006
19
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 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
Abbildung 3: Differentielle inkrementelle Backups (Default-Einstellung)
20
News Q4-2006
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
www.doag.org
Backup und Recovery
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 DatenbankInstanz, die im Normalbetrieb Performance-Engpässe aufweist, keine Wunderdinge beim Media Recovery erwarten
www.doag.org
Sichere Datenhaltung
professional
it software &
services
®
www.pitss.com
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: www.pitss.de/jobs
PITSS ist ISV Partner von ORACLE®
PITSS GmbH
[email protected]
Tel.: +49 8171 2162-10
News Q4-2006
21
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
22
News Q4-2006
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 PhysicalStandby-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.
Kontakt:
Mike Dietrich
[email protected]
ORACLE-Newsticker
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 USDollar, 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 NonGAAP 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.
www.doag.org