Oracle9i: Backup und Recovery verstehen

Warum, wie oft und wie soll meine Datenbank gesichert werden?
Backup und Recovery sind mit die wichtigsten Aufgaben eines DBA. Hard- und Software sind ersetzbar, Daten sind es nicht. Selbst unter besten Bedingungen kann es gelegentlich vorkommen, dass Datenbankeinträge zerstört werden, sei es wegen eines Benutzerfehlers, sei es wegen eines Hard- oder Softwarefehlers. Die einzige Möglichkeit, sich auf ein solches Desaster vorzubereiten, sind regelmäßige Backups.

Bevor Sie eine Backup-Strategie entwickeln können, müssen Sie einen Aktionsplan erstellen. Evaluieren Sie Ihr Unternehmen und fragen Sie sich, wie hoch die maximale Ausfallzeit ist, mit der das Unternehmen leben kann. Ist dies geschehen und sind die zentralen Fragen geklärt, können Sie die richtige Vorgehensweise festlegen, indem Sie den Grad der Datensicherung den Anforderungen Ihres Unternehmens anpassen.

Bevor man eine Oracle Datenbank erzeugt, sollte man entscheiden, wie man sie gegen Ausfälle schützen will. Beantworten Sie dazu folgende Fragen:

Ist es akzeptabel, Daten zu verlieren, wenn eine Festplatte versagt und dadurch Datenbankdateien beschädigt werden?
Muss man vielleicht irgendwann einmal einen vorherigen Zustand wiederherstellen können?
Muss die Datenbank rund um die Uhr verfügbar sein?

Arten von Ausfällen

Es gibt verschiedene Typen von Ausfällen, zu denen es bei einer Oracle Datenbank kommen kann:

Statement Failure
Ursachen: Logischer Fehler im Statement; Versuch nicht erlaubte Daten einzugeben oder Operationen mit ungenügenden Privilegien durchzuführen; Erstellen eines Objekt scheitert an Platzmangel auf der Festplatte.
Folgen: Ausgabe eines Error-Codes und einer Nachricht; automatischer Rollback.
Abhilfe: den Error-Code auflösen und dafür sorgen, dass der beschriebene Fehler nicht nochmal vorkommt
User Process Failure
User Error

Instance Failure -- Eine Oracle-Instanz 'hängt sich auf', ohne den regulären Shutdown-Prozess durchlaufen zu haben.
Nach einem 'Instance Crash' führt Oracle automatisch und selbständig eine Recovery-Operation durch
Media Failure -- Die benutzten Festplatten sind korrumpiert oder physikalisch beschädigt. Nach einem Medienversagen muss der DBA die Recovery einleiten.
Network Failure

Wir müssen uns hauptsächlich mit der Recovery bei Media Failure beschäftigen. Doch vor der Recovery kommt erstmal die Sicherung der Daten.

Sicherungsstrategien - Wann muss ich sichern? Was ist grundsätzlich sinnvoll?

Unbedingt komplettes Datenbankbackup machen:
- zu Anfang, sobald die Datenbank erstellt wurde.
  Dieses erste Backup ist die Basis für die weiteren Backups, denn dort haben sie Backups der Datenfiles und Controlfile der zugehörigen Datenbank.
- nach unrecoverable/unlogged Operationen
- nach einem Öffnen der Datenbank mit der RESETLOGS-Option
Backups häufig und regelmäßig durchführen. Wie häufig Sie Backups machen sollten, hängt von der Häufigkeit folgender Änderungen in der Datenbank ab:
- Addition and deletion of tables.
- Insertions and deletions of rows in existing tables.
- Updates to data within tables
If users generate a significant amount of DML, database backup frequency should be proportionally high. Alternatively, if a database is mainly read-only, and updates are issued only infrequently, you can back up the database less frequently.
Use either Recovery Manager or operating system methods to create backup scripts. RMAN scripts, which are stored in the recovery catalog, are an especially efficient method for performing routine, repetitive backup operations.
Backups immer nach allen strukturelle Änderungen durchführen
Administrators as well as users make changes to a database. If you make any of the following structural changes, then perform a backup of the appropriate portion of your database immediately before and after completing the alteration:
- Create or drop a tablespace.
- Add or rename a datafile in an existing tablespace.
- Add, rename, or drop an online redo log group or member.
Machen Sie sich auch ein Backup der Control-File, wenn die Datenbank strukturell geändert worden ist. Bei Arbeit im ARCHIVELOG-Modus und bei offener Datenbank können Sie dazu entweder den RMAN benutzen oder das ALTER DATABASE Statement mit der Option BACKUP CONTROLFILE.
Archivieren Sie nicht nur das letzte, sondern auch ältere Backups (mindestens das vorletze), das letzte könnte korrupt sein!
Ein älteres Backup ist notwendig, wenn eine inkomplette Recovery gemacht werden muss und der Zeitpunkt vor dem jüngsten Backup liegt, weil beispielsweise das jüngste Backup korrupt ist. Wenn Sie z.B. Ihr Backups am 1. und 14. Februar gemacht haben, und am Ende des Monat entdecken, dass Sie auf den Zustand der Datenbank am 7. Februar zurückmüssen, brauchen Sie das Backuip vom 1. Februar.

Also: Das für die Recovery benutzte Backup sollte immer vor einem möglichen Recovery-Zeitpunkt liegen - und die Control File bei dieser recovery sollte natürlich die passende Datenbankstruktur zum gewünschten Recovery-Zustands-Zeitpunkt wiederspiegeln - nur dafür sind die alten Control Files gut.

Arten von Sicherungen

Die logische Sicherung: Export der Datenbank als 'Schnappschuss' ihres aktuellen Zustandes

Zur Datensicherung ist ein Export nur bedingt geeignet. Er ist eigentlich gedacht für den Datentransfer zwischen Betriebssystemen oder beim Wechsel von Releases des DBMS, also z.B. bei der Migration zu einem neueren Release. Er kann zur Reduziereung der Fragmentierung einer Datenbank dienen. Man kann Datenbanken aufteilen und 'Karteileichen' löschen, also sich überlegen, ob man die gesamte Datenbank exportiert oder nur einzelne Benutzer und einzelne Tabellen. Der Export ist daher auch geeignet für das Ein- und Auslagern von Daten, z.B. auch für Übungs- oder Testzwecke.

Bei einer logischen Online Sicherung werden keine Dateien kopiert, sondern die Daten aus der Datenbank ausgelesen und in einer speziellen binären Datei (Export-Datei, Dump-Datei) abgelegt. In einer Export-Datei sind die verschiedenen Befehle zum Anlegen der gesamten Datenbankstruktur enthalten wie z.B. Anlegen der Tabellen, Anlegen der Indizes, Zuweisen von Rechten, Befehle zum Analysieren der Daten usw.

Für einen Export wird ein spezielles Programm "exp" benutzt. Diese Programm kann sowohl interaktiv als auch mit Parametern gesteuert werden. Zum Sichern einer gesamten Datenbank eignet sich z.B. die folgende Vorgehensweise:

exp userid=system/<pwd> file=full_export.dmp full=yes rows=y consistent=yes

Der Datenbestand in der Export-Datei umfasst ausschliesslich die Daten zum Zeitpunkt des Export Starts. Daten die nach dem Export Start verändert wurden, werden nicht berücksichtigt. Der Export ist dadurch in seinem Datenbestand konsistent. Wenn während des Exports weiter gearbeitet wird, sollte auf genügend Platz in den Rollback-Segmenten geachtet werden.

Die echte Sicherung: Backup

Auch hier gibt es unterschiedliche Modi: Anhand unserer Vorüberlegungen können wir entscheiden, in welchem Modus unsere Datenbank laufen muss.

ARCHIVELOG oder NOARCHIVELOG ?

Ist es akzeptabel, Daten zu verlieren, wenn eine Festplatte versagt und dadurch Datenbankdateien beschädigt werden?

Wenn nein, sollte die Datenbank im ARCHIVELOG-Modus laufen, idealerweise mit mehrfach gespiegelten Online-Redo-Log, Controlfiles und Archive-Redo-Logs. Wenn man es verschmerzen kann, kleine Datenmengen zu verlieren, kann man im NOARCHIVELO-Modus fahren und den Aufwand für die Spiegelungen etc. sparen.
Muss man vielleicht irgendwann einmal einen vorherigen Zustand wiederherstellen können?

Wenn Sie denken, dass es für Sie wichtig ist, eine solche inkomplette Recovery durchführen zu können, weil beispielsweise Fehler in die Datenbank gekommen sind, sollten Sie auch im ARCHIVELOG-Modus arbeiten und Backups der Control-Files nach jeder strukturellen Änderung machen und aufheben. Es erleichtert eine inkomplette Recovery ungemein, wenn man auf das Backup der Controlfile zum gewünschten Zustand in der Vergangenheit zurückgreifen kann.
Muss die Datenbank rund um die Uhr verfügbar sein?

Wenn das der Fall ist, dürfen Sie nicht im NOARCHIVELOG-Modus arbeiten, denn die erforderlichen vollständigen Sicherungen der Datenbank könnten sonst nicht oder nicht häufig genug gemacht werden, weil man dazu die Datenbank herunterfahren muss. Hochverfügbare Datenbanken arbeiten deshalb immer im ARCHIVELOG-Modus um die Datenfiles im laufenden Betrieb sichern zu können.

Cold Backup - Datenbank ist Offline - Backup einer Datenbank im NOARCHIVELOG-Modus

Im NOARCHIVELOG-Modus werden gefüllte Gruppen von Online-Redo-Logs nicht archiviert. Daher ist der einzige Schutz gegen Versagen der Festplatte das Zugreifen auf das jüngste vollständige Backup der Datenbank. Dazu sollten Sie folgendes beachten:

Planen Sie regelmäßige vollständige Backups der Datenbank.
Die Intervalle machen Sie davon abhängig, wieviel Datenverlust Sie sich leisten können. Wenn Sie also die Daten einer Woche in einem akzeptablen Zeitraum erneut eingeben könnten, sollten Sie wöchentliche Backups machen. Wenn Sie schon bei dem Verlust der Daten eines Tages ins Schleudern geraten, sollten Sie tägliche vollständige Backups machen. Für größerer Datenbanken mit hoher Aktivität kommt sicher nur der ARCHIVELOG-Modus in Frage.
Wann immer Sie die physische Struktur einer Datenbank im NOARCHIVELOG-Modus ändern, sollten Sie unmittelbar danach ein konsistentes, vollständiges Backup machen.

Ein kaltes Backup ist das einfachste aller Backup-Arten und beruht auf einer Kopie auf Filesystem-Ebene. Und diese Art von Backups gibt es ja in fast allen Unternehmen, von einem hausgemachten dump bis hin zu teuren kommerziellen Systemen.

Wie es geht:

Fahren Sie die Datenbank geregelt herunter und machen Sie Ihre Sicherung. Oracle setzt bei einem normalen (nicht 'abort') Shutdown einen Checkpoint, schreibt alle flüchtigen Daten aus dem Arbeitsspeicher auf die Festplatte, stoppt alle Prozesse und verhindert damit weitere Änderungen an der Datenbank.
Alle Daten sind damit in einem saubenren, konsistenten Zustand. Das setzt freilich das Aufsetzen auf einem Filesystem voraus.

Die Datenbank könnte aber auch auf raw devices sitzen - dann macht unser kaltes Backup schon etwas mehr Mühe und setzt tieferes Verständnis für die Struktur der Datenbank voraus. Es beginnt natürlich auch mit einem geregelten Shutdown. Auch die Programme und Datenbankobjekte wie etwa das Control File sitzen auf dem Filesystem auf und können gesichert werden. Aber wo genau liegen die Daten? Hhhmm. Ein Script könnte man sich schreiben, das aus Oracle diese Informationen abfragt, aber erstmal wissen, wie. Das Script oraback.sh, das Sie nachher sehen werden, macht übrigens genau das automatisch. Wenn man die Lokalisation hat, müsste man mit dd die Daten auf eine andere Festplatte, ein Band o.ä. schaufeln. Wenn man sie in eine Datei hineinschreibt, kann man sie natürlich auch wieder zusammen mit den anderen Dateien ins normale Backup laufen lassen. Also, alles in allem etwas mehr Arbeit.

Hot Backup - Datenbank bleibt online - Backup einer Datenbank im ARCHIVELOG-Modus

Wenn die Datenbank im ARCHIVELOG-Modus läuft, archiviert der Prozess ARC Gruppen der Online-Redo-Log-Dateien. Dadurch können archivierte Redo-Logs zusammen mit dem Online Redo-Log und der Data-files die Datenbank gegen Festplattenschäden schützen, denn die Datenbank kann vollständig wiederhergestellt werden - und zwar exakt bis zu dem Zeitpunkt, zu dem der Fehler auftrat, bzw. bis zu einem gewählten Zeitpunkt vorher.

Auch wenn Sie Ihr Hot Backup später mit Hilfsmitteln (RMAN oder Storage Manager) durchführen, sollten Sie sich mit dem manuellen Backup auskennen, denn die ablaufenden Prozesse sind identisch, und das Verständnis dieser Prozesse ist essentiell für den sinnvollen Umgang mit Backup-Systemen!

Vorüberlegungen

Storage Management Systeme können sehr teuer sein und sind daher nicht überall verfügbar. Und selbst wenn Sie eines haben, kann es sein, das man wegen einer 'kleinen' Datenbank nicht tausende Euros für die passende Oracle-Schnittstelle ausgeben will. Aber das muss man auch nicht: Man kann sichere Oracle-Backups auf die Festplatte machen und diese dann mit den im Hause üblichen Backup-Prozeduren sichern, evtl. auch direkt aufs Band.

Egal, welche Hot-Backup-Strategie Sie später verfolgen - Datenbank muss dazu im Archivelog-Modus laufen (siehe Kapitel: Oracle-Architektur)

Mehrfache Kopien an verschiedenen Speicherorten für Control Files, Online Redo Logs und Archived Redo Logs vorhalten

Schritte eines Hot Backup:

Strukturen bestimmen:

Aus Oracle die Liste aller Tablespaces und Datenfiles herausbekommen
Die Ablage der Archived Redo Logs herausfinden
Den Ort der Control-File herausfinden (Optional - Immer Vorsicht vor alten Control Files - die will man meistens nicht wiederherstellen!!

In einer Schleife Tablespaces in Backup-Mode bringen und Daten kopieren: Einen Tablespace nach dem anderen

in den Backup- Modus versetzen (alter tablespace [tablespace_name] begin backup) und
die Daten an einen anderen Platz kopieren und
ihn wieder aus dem Backup-Modus herausnehmen (alter tablespace [tablespace_name] end backup).

Zeitpunkt festmachen und zusammengehörige Daten sichern

Einen Redo Log File Switch auslösen
Das Control File mit dem Befehl backup control file sichern
Das Control File kopieren (Optional - Immer Vorsicht vor alten Control Files - die will man meistens nicht wiederherstellen!!)
Die aktuellen Online Redo Logs kopieren.
Sicherstellen, dass alle archived redo logs gesichert werden, die bis zu diesem Backupvorgang nicht gesichert wurden.

Das Ergebnis: Ein Redundanz-Set

Den kompletten Satz aus Dateien, die man nach einem Oracle-Ausfall besitzten sollte, nennt man ein Redundanz-Set.
Ein Redundanz-Set besteht aus:

dem letzten Backup aller Datenbankdateien
allen archivierten Redo-Logs nach dem letzten Backup
einer Kopie der Online Redo-Logs (von Oracle oder dem Betriebssystem gespiegelt)
einer Kopie des aktuellen Control-File (von Oracle oder dem Betriebssystem gespiegelt)
aktuellen Konfigurationsfiles wie intialization parameter file, tnsnames.ora und listener.ora
Manche DBAs packen noch einen aktuellen Export dazu.

Wohin mit dem Redundanz-Set - abgesehen vom Kopieren aufs Backup-Tape? Dafür gelten folgende 'goldene' Regeln:

Die Festplatten oder sonstigen Medien, auf denen das Redundanz-Set abgelegt wird, sollten möglichst an einem anderen Standort sein als die Speicherorte für Datenfiles, Online-Redo-Logs und Controlfiles. Nur so kann sichergestellt werden, dass ein Plattencrash der Datenfiles nicht auch noch den Verlust der Backups und Redo-Logs bedeutet, die man braucht, um die Datenfile wiederherzustellen. Daher braucht man für eine Produktionsdatenbank ein Minimum von zwei Festplatten: Eine für das Redundanz-Set und eine für die Datenfiles.
Halten Sie das Redundanz-Set auch möglichste in jeder anderen Weise getrennt von den Datenfiles: auf getrennten Verzeichnissen, anderen Filesystemen und getrennten RAID-Platten. Die sind zwar sehr zuverlässig, aber auch sie können mal versagen.
Lassen Sie mindestens eine Kopie des kompletten aktuellsten Redundanz-Sets auf der Platte. Für viele Installationen ist das wirtschaftlich sinnvoll.
Wenn die Redundanz-Kopie über das Kopieren von einer Festplatte generiert wird, ist das nicht so gut wie wenn sie über OS oder RMAN erzeugt wird, denn bei einem Hardware-Fehler wären wieder Original und Kopie betroffen.
Wenn die Datenbank auf einem RAID-System sitzt, sollte das Redundanz-Set nicht auf dem selben RAID sitzen.

Es erfordert einiges an Oracle Know-How, aber auch an Scripting-Wissen, um ein schönes Backup-Script zu bekommen, das ein solches Redundanz-Set anglegt. Sie brauchen natürlich das Rad nicht neu zu erfinden - Sie bekommen ja ein Script von uns. Allerdings sollten Sie genau verstehen, was Sie da machen. Deshalb schauen wir und das ganze noch etwas näher an.

TODO!!!!!!!

Archiving Older Backups

Recovery

Funktionieren die Backups auch wirklich?

Der Schlüssel zu einer angemessenen Backup- und Recovery-Strategie ist das Üben. Man muss die Recovery mit Backups auf dem Testsystem geübt haben, bevor man in Produktion geht. Es kommt leider immer noch zu häufig vor, dass sich Backupmedien nicht als zuverlässig erweisen, oder dass sich die geplante Häufugkeit der Backups als unzureichend hersustellt.
Und so etwas stellt man besser vorher in Testsituationen fest als nachher, wenn die Produktion steht.

Arten von Recovery nach einem Media Failure:

Komplette Recovery einer Datenbank bis zum Zeitpunkt, zu dem der Fehler auftrat
Inkomplette Recovery bringt die Datenbank wieder auf den Stand zu einem bestimmten Zeitpunkt in der Vergangenheit (von dem man sich beispilesweise sicher ist, dass die Datenbank noch konsistent war, oder bevor ein betsimmter Fehler gemacht wurde, oder wenn die komplette Recovery nicht mehr gelingt etc.). Hier können wir drei Arten unterscheiden:
- Tablespace point-in-time Recovery: Recovery eines Tablespace bis zum Zustand zu einem anderen Zeitpunkt als der Rest der Datenbank
- Time-based oder point-in-time Recovery einer Datenbank: Recovery der gesamten Datenbank bis zum Zustand zu einem Zeitpunkt vor dem Fehler
- Change-based oder Log-Sequence-Recovery: Wiederherstellung bis zu einer ganz bestimmten SCN

Eine Recovery bedeutet immer: Alte Kopien der beschädigten Datafiles wiederherstellen und ein sogenanntes 'Rolling Forward' veranlassen, indem man die in den Redo Logs und Archive Logs gespeicherten Aktionen erneut ausführen lässt.

TODO!!!!

Kein Backup-Roboter? Wie geht das Tape-Backup am besten in kleineren Firmen?

Wie folgt (geht bei meinen DAU's wunderbar): Du nimmst 10, 15 Baender, nummerierst sie wie folgt:

Montag, Dienstag, Mittwoch, Donnerstag Freitag 1, Freitag 2, Freitag 3, Monat 1, Monat 2, Monat 3

wobei man die Anzahl der Freitag n und Monat n Baender variieren kann, je nach Geschmack und Anforderung.

Dann machst einen Backup-Kalender (das kann man mit jeder handelsueblichen und -unueblichen Tabellenkalkulation in 10 Minuten erledigen), wo fuer jeden Tag (auch Montag bis Donnerstag) ein Eintrag ist, wo drauf steht, welches Band einzulegen ist. Das schaut so aus:

Wie die Baender da angeordnet sein muessen ist wohl klar, d.h.
Mo, Di, Mi, Do, Fr1, Mo,..,Do, Fr2,...,Fr3,.. Monat 1, ..... Fr1, ...., Fr2
und so weiter. Wenn der User das Band einlegt und das Backup startet, so soll der eine Marke, Paraphe oder Unterschrift in das Eingelegt-Feld vom Kalender machen, der der das Band rausnimmt ebenso.

Man braucht zwar einen Haufen Baender fuer das System, aber jeder kapiert es, den Kalender begreifen auch extrem unwillige Leute und man hat eine gute Kontrollmoeglichkeit, was wann passiert ist. Die Bandln kosten eh nicht so viel. Wenn man eine kleine Backup-Anleitung mit dem Kalender kombiniert, so faehrt man ganz besonders sicher - weil wenn da haben die Leute ihren Spickzettel immer auch gleich bei der Hand. Man kann auch die Wartungsinterfalle (Reinigungskassette und dergleichen) in den Kalender eintragen, damit gibts auch gute Chancen, das die Leute auch das machen.

Das Ausscheiden von Baendern nach der Lebensdauer der Dinger kann man auch in den Kalender eintragen. Das einzige was man dann noch machen muss ist von Zeit zu Zeit die Baender mit der Backup Software zu scannen und zu schauen, ob auf den Baendern auch was drauf ist und ob es lesbar ist.

Vergiss alle elektronischen Varianten des Kalenders - das hat sich nicht bewaehrt. DAU's lieben Papier und hassen Computer.

Petra Haberer Version 0.0.0