Über unsMediaKontaktImpressum
Christine Gschoßmann 03. November 2015

Backup großer Datenbanken

Waren noch vor wenigen Jahren Datenbanken mit mehr als 100 Gigabyte eine Ausnahme, so sind heute selbst Datenbanken im Terabyte-Bereich nichts Ungewöhnliches mehr. Das Sicherungskonzept solch großer Datenbanken will aber wohl überlegt sein. Oft treten erst Probleme auf, wenn sich so ein Monstrum im Laufe der Jahre entwickelt hat und die Sicherung mit den bisherigen Mitteln und Methoden nicht mehr handhabbar ist. So dauert die Durchführung eines vollständigen Backups zu lange oder es lassen sich die in den SLAs (Service Level Agreements) vereinbarten Restore-Zeiten mit den bestehenden Möglichkeiten und Ressourcen nicht mehr einhalten.

Ansatzweise sollen hier einige Möglichkeiten aufgezeigt werden, die das Sichern und Wiederherstellen großer Datenbanken beschleunigen und erleichtern können.

Dazu muss die im Rahmen von Backup und Restore verwendete Hardware (zum Beispiel Bandlaufwerke, Platten-Systeme inklusive Controller und I/O-Busse) so weit wie möglich optimiert werden. Die Möglichkeiten, die sich hier bieten, sollten mit dem Hardware-Hersteller erörtert und abgestimmt werden.

Des weiteren bieten auch noch andere Bereiche zum Teil erhebliches Verbesserungspotential, um Backup und Restore zu beschleunigen.

Parallelisierung

Eine deutliche Reduzierung der Backup-Laufzeiten kann durch die parallele Sicherung auf mehrere Band- oder Plattenlaufwerke gleichzeitig erzielt werden. Außerdem sollten die Band- oder Plattenlaufwerke direkt am Datenbankserver angeschlossen sein, das heißt die Sicherung sollte nicht über das Netzwerk erfolgen.

Bei der Planung von parallelen Backups spielen auch die Kapazität sowie der Durchsatz der Bandlaufwerke und die Zugriffszeiten der Festplatten eine Rolle. Weiterhin muss auch der maximale Durchsatz der System- und I/O-Busse berücksichtigt werden. Auch die Anzahl und Leistung der CPUs sollten beim Parallelisierungsgrad des Backups berücksichtigt werden.

Inkrementelle Backups

Die Verwendung von RMAN, dem Oracle Recovery Manager, bietet die Möglichkeit eines inkrementellen Backups (Level 1 Backup). Dabei werden nur die seit der letzten Vollsicherung (Level 0 Backup) oder dem letzten inkrementellen Backup geänderten Blöcke gesichert. Dadurch verringert sich das zu sichernde Datenvolumen.

Ab Oracle 10g kann zusätzlich das Block Change Tracking aktiviert werden, bei dem eine Betriebssystem-Datei angelegt wird, in der Oracle die Datenbank-Blöcke protokolliert, die seit der letzten Vollsicherung geändert wurden. Bei einer inkrementellen Sicherung liest RMAN dann diese Datei aus, um die zu sichernden Blöcke zu bestimmen. Bis einschließlich Oracle 9i musste RMAN noch alle Blöcke der Daten-Dateien lesen, um die Blöcke für das Backup zu bestimmen – auch die nicht veränderten. Durch die Verwendung des Block Change Tracking  ergibt sich in Oracle 10g eine deutliche Laufzeitverbesserung für das inkrementelle Backup.

Der Nachteil inkrementeller Sicherungen ist der, dass bei einem Restore eine Vollsicherung und eine oder mehrere inkrementelle Sicherungen zurückgespielt werden müssen. Da bei einer Vollsicherung mit RMAN aber nur die gefüllten Datenbank-Blöcke gesichert werden, ist dies nicht unbedingt mit längeren Restore-Zeiten als bei anderen Sicherungsmethoden verbunden.

Partielle Backups

Wenn es nicht möglich ist, die gesamte Datenbank innerhalb eines für das Backup zur Verfügung stehenden Zeitfensters zu sichern, so besteht die Möglichkeit, nur Teile der Datenbank zu sichern, wie einzelne Tablespaces oder gar nur eine oder mehrere Daten-Dateien. Für ein vollständiges Backup der Datenbank wird das Backup auf mehrere Zeitfenster wie zum Beispiel Nächte verteilt. Pro Nacht wird dann nur eine bestimmte Teilmenge der Datenbank gesichert.

Dies hat allerdings zur Folge, dass im Falle eines Restores Dateien aus unterschiedlichen Sicherungen zurückgespielt werden müssen und sich somit die Auszeit für das Recovery verlängert, da mehr Offline Redolog-Dateien eingespielt werden müssen. Ein partielles Backup kann offline oder online erfolgen und wird analog zu einer Vollsicherung durchgeführt mit dem Unterschied, dass eben nicht alle, sondern nur bestimmte Daten-Dateien gesichert werden.

Ein gravierender Nachteil von partiellen Backups ist die Überwachung und Anpassung der einzelnen Backups, die in ihrer Gesamtheit eine vollständige Sicherung der Datenbank ergeben. Nur wenn ALLE partiellen Backups erfolgreich abgeschlossen wurden und ALLE notwendigen Dateien der Datenbank gesichert wurden, ist eine vollständige Sicherung der Datenbank vorhanden. Bei einer Wiederherstellung aus einem partiellen Backup werden zusätzlich noch Offline Redo Logs benötigt, um die Daten-Dateien unterschiedlicher Sicherungszeitpunkte wieder auf einen einheitlichen konsistenten Stand zu bringen. Auch Strukturänderungen an der Datenbank wie beispielsweise neue Daten-Dateien müssen berücksichtigt werden und gegebenenfalls in die Definition der partiellen Backup-Jobs aufgenommen werden.

Eine sinnvolle Nutzung von partiellen Backups besteht in der Sicherung von einzelnen Tablespaces mit sehr häufigen und vielen Datenänderungen zusätzlich zu vollständigen Backups. Bei einem Recovery einzelner oder aller Daten-Dateien dieser Tablespaces müssen so nur die seit diesem partiellen Backup angefallenen Redolog-Dateien zurückgespielt werden, also weniger Offline Redolog-Dateien als seit der letzten vollständigen Datenbank-Sicherung erzeugt wurden.

Zwei-Phasen-Backup

Unter einem Zwei-Phasen-Backup versteht man die Aufteilung der Sicherung in zwei Schritte:

Im ersten Schritt wird eine Sicherung auf einen Plattenbereich durchgeführt, die wesentlich schneller ist als eine Bandsicherung. Anschließend wird das Backup auf Band gesichert. Die Vorteile ergeben sich zum einen aus der verkürzten Sicherungsdauer und zum anderen durch die Möglichkeit eines schnellen Restore vom Plattenbereich, sofern das zuletzt erstellte Backup zurückgespielt werden muss. Als Nachteil ist hier der zusätzlich nötige Plattenplatz zu sehen. Außerdem müssen hier zwei Backups statt wie bei einem konventionellen Backup eines durchgeführt werden. Ein spezieller Fall des Zwei-Phasen-Backup ist das Split-Mirror-Backup.

Verschiedene Hardware-Hersteller bieten eine so genannte Snapshot-Methode an. Dabei werden alle Daten zu einem bestimmten Zeitpunkt auf I/O-Ebene eingefroren. Snapshots werden entweder bei geschlossener Datenbank (offline) oder im Backup-Modus (online) erzeugt. Werden anschließend wieder Daten geändert, werden diese beim nächsten Snapshot zusätzlich abgespeichert.

Snapshots

Mit Hilfe von Snapshots können sehr schnell Backups (meist in wenigen Sekunden) auf Platte erzeugt werden. Dabei ist es möglich, mehrere Snapshots von unterschiedlichen Zeitpunkten zu erzeugen. Der zusätzlich dafür benötigte Plattenplatz hält sich in Grenzen, da jeweils nur die geänderten Blöcke gesichert werden. Bei längerem Vorhalten der Snapshots ist zudem ein schneller Restore der Datenbank möglich.

Während der Snapshots kann es zu Performance-Einbußen beziehungsweise Ressourcen-Engpässen kommen.

Multisection Backups

Seit Oracle 11g bietet RMAN auch die Möglichkeit, große Daten-Dateien stückweise zu sichern. Das Multisection Backup bietet den Vorteil, dass große Daten-Dateien parallel gesichert werden können. Dabei wird die Daten-Datei in einzelne Bereiche aufgeteilt, die aus einer Reihe aufeinander folgender Datenbank-Blöcke bestehen. Ein Backup Set beinhaltet stets alle Sektionen einer Daten-Datei.

Split-Mirror Backup

Diese Technologie ermöglicht eine sehr schnelle Durchführung eines Backups. Bei einer Split-Mirror-Lösung wird zunächst blockweise eine vollständige Kopie eines oder mehrerer Volumes angelegt. Unter Volumes (unter Windows auch Partitionen oder Laufwerke) versteht man das Zusammenfassen einer oder mehrerer Platten zu einer logischen Einheit.

Dabei werden die gespiegelten Daten mit den Originalen synchronisiert. Anschließend kann der (Platten-)Spiegel geteilt werden, um ein identisches Abbild des Originals zu diesem Zeitpunkt festzuhalten.

Im Datenbankumfeld kann dieses Verfahren für eine schnelle Datensicherung, online wie offline, auch sehr großer Datenbanken genutzt werden. Selbst für eine Offline-Sicherung beträgt die Ausfallzeit für das Backup je nachdem, wie lange das Auftrennen des Spiegels dauert, im Regelfall nur wenige Minuten. Auch die Last auf dem Datenbankserver durch die Sicherung reduziert sich bei Verwendung eines eigenen Sicherungsservers, der die gespiegelten Daten übernimmt. Allerdings stellt eine Split-Mirror Lösung auch einen hohen Kostenfaktor dar.

Für die weitere Betrachtung einer Split-Mirror-Lösung wird vorausgesetzt, dass folgende Dateien gespiegelt werden:

  • alle Daten-Dateien
  • mindestens eine Kopie der Control-Datei
  • die Konfigurations-Dateien
  • die Offline Redolog-Dateien

Die Online Redolog-Dateien spielen dabei nur eine untergeordnete Rolle. Sie werden auf der Spiegelseite nicht benötigt. Dabei wird natürlich vorausgesetzt, dass die Datenbank im ARCHIVELOG-Modus betrieben wird.

Für den Fall, dass ein Offline-Backup zurückgespielt wird und die Datenbank ohne weiteres Recovery geöffnet werden soll, muss die Option RESETLOGS des ALTER DATABASE OPEN-Befehls verwendet werden. Dabei wird die Log Sequence Nummer zurückgesetzt und eine neue Datenbankinkarnation erzeugt. Soll dies vermieden werden, müssen auch die Online Redolog-Dateien gespiegelt werden.

Ein weiterer Vorteil der Plattenspiegelung ist die Möglichkeit eines schnellen Restore aus der letzten Sicherung, die sich ja noch auf der Spiegelseite befindet. Muss aufgrund eines aufgetretenen Problems die Datenbank aus dem letzten Backup wieder hergestellt werden, kann dies schnell und ohne großen Aufwand durchgeführt werden. Der Zeitaufwand für einen Restore der Datenbank und das anschließende Recovery verkürzt sich dadurch auf ein Minimum.

Folgende Punkte sind jedoch im Fall eines Restore der Datenbank zu beachten:

  • Die Offline Redolog-Dateien müssen aus der Redolog-Sicherung zurückgespielt werden, da die neueren Dateien des Originals durch die auf der Spiegelseite befindlichen älteren Dateien ersetzt werden.
    Dies kann dadurch vermieden werden, dass entweder dieser Bereich nicht überschrieben wird oder die Offline Redolog-Dateien in mehrere Archivelog-Verzeichnisse archiviert werden.
  • Die Konfigurations-Dateien, sollten sie auf Originalseite seit dem Auftrennen des Spiegels geändert worden sein, dürfen ebenfalls nicht durch die Kopien ersetzt werden. Gegebenfalls müssen sie nach jeder Änderung separat gesichert werden.
  • Auch die Control-Dateien sollten, je nach Szenario, nicht durch die Kopien ersetzt werden.

Die Durchführung des Backups unterscheidet sich von der konventionellen Methode im Großen und Ganzen nur dadurch, dass anstatt der Sicherung der Daten-Dateien auf der Original-Datenbank erst der Spiegel geteilt wird und anschließend auf der Spiegelseite das Backup erfolgt. Somit kann ein Backup fast wie gewohnt durchgeführt werden.

Nach Auftrennen des Spiegels müssen die Dateien noch auf ein entsprechendes Backup-Medium zur längeren Aufbewahrung kopiert werden, da ja beim nächsten Synchronisieren der Spiegelseite die Dateien wieder überschrieben werden. Das Synchronisieren der beiden Spiegelhälften wird immer erst kurz vor der Sicherung durchgeführt, wodurch für die restliche Zeit ein vollständiges Backup der Datenbank auf Platte vorgehalten wird.

Im weiteren Verlauf dieses Kapitels wird vorausgesetzt, dass sich die Datenbank im ARCHIVELOG-Modus befindet und die Offline Redolog-Dateien unter Berücksichtigung der Aufbewahrungsfrist laufend gesichert und auf den Backup-Medien vorgehalten werden.

Split-Mirror Offline-Backup

Wie beim herkömmlichen Offline-Backup besteht auch dieses Backup grundsätzlich aus drei Schritten. Zusätzlich muss die Datenbankkopie, die sich nach dem Auftrennen der Volumes auf der Spiegelseite befindet, noch auf entsprechende Backup-Medien kopiert werden.

Bevor das Backup durchgeführt wird, muss sichergestellt sein, dass die Spiegelseite vollständig synchronisiert wurde, die Blöcke von Original und Spiegel also identisch sind.

Vorausgesetzt, dass sich sowohl die Daten-Dateien, als auch die Konfigurations-Dateien und zumindest eine Kopie der Control-Datei auf den gespiegelten Volumes befinden, läuft ein Backup folgendermaßen ab:

  1. Konsistentes Beenden der Original-Datenbank:
    SHUTDOWN [ NORMAL ] | [ TRANSACTIONAL ] | [ IMMEDIATE ]
  2. Auftrennen des Spiegels
  3. Starten der Original-Datenbank

Nach dem Auftrennen des Spiegels befindet sich eine komplette Sicherungskopie auf der Spiegelseite. Diese kann nun auf entsprechende Backupmedien gesichert werden.

Split-Mirror Online-Backup

Ein Online-Backup ist auch in diesem Umfeld etwas aufwändiger als ein Offline-Backup. Trotzdem bietet eine Split-Mirror-Umgebung auch für eine Online-Sicherung einige Vorteile. Der Zeitaufwand ist sehr gering und das Kopieren der Dateien wird wesentlich erleichtert.
Im Unterschied zum Offline-Backup muss in dieser Umgebung eine Kopie der Control-Datei manuell erzeugt werden. Vorausgesetzt, dass sich sowohl die Daten-Dateien, als auch die Konfigurations-Dateien auf den gespiegelten Volumes befinden, wird ein Online-Backup vereinfacht wie folgt durchgeführt:

  1. Bestimmen der aktuellen Log Sequence Nummer
     SQL> SELECT SEQUENCE# FROM V$LOG WHERE STATUS='CURRENT';
    Alle Offline Redolog-Dateien, die von nun an während des Backup erzeugt werden, also alle größer oder gleich dieser Log Sequence Nummer, werden für die Sicherung benötigt. In diesem Fall werden dabei durch die stark verkürzte Backup-Dauer aber wesentlich weniger Redolog-Dateien erzeugt.
  2. Datenbank in den Online Backup-Modus setzen
     SQL> ALTER DATABASE BEGIN BACKUP;
  3. Auftrennen des Spiegels
  4. Datenbank wieder aus dem Backup-Modus nehmen
     SQL> ALTER DATABASE END BACKUP;
  5. Backup der Control-Datei erzeugen
     SQL> ALTER DATABASE BACKUP CONTROLFILE TO '<pfad>/<dateiname>' [REUSE];
    Die Angabe von REUSE ist nötig, wenn die Datei bereits existiert und überschrieben werden soll, beispielsweise wenn für das Online-Backup immer wieder derselbe Ablageort zur Sicherung der Control-Datei verwendet wird. Die dadurch erzeugte Datei ist ein wichtiger Bestandteil des Backups und muss auch auf der Spiegelseite verfügbar sein.
  6. Bestimmen der aktuellen Log Sequence Nummer
     SQL> SELECT SEQUENCE# FROM V$LOG WHERE STATUS='CURRENT';
    Die Redolog-Datei mit dieser Log Sequence Nummer ist damit die letzte, die für ein konsistentes Backup erforderlich ist. Da es sich dabei um eine Online Redolog-Datei handelt, in die die aktuellen Datenbankänderungen geschrieben werden, muss die Datei archiviert werden, um sie sichern zu können. Dies wird durch einen Log Switch veranlasst.
     SQL> ALTER SYSTEM SWITCH LOGFILE;
    Dadurch wird auf die nächste Log Sequence Nummer umgeschaltet und einer der Archiver-Prozesse schreibt die Informationen dieser Online Redolog-Datei in das ARCHIVELOG-Verzeichnis. Nach Abschluss dieser Aktion können alle Redolog-Dateien, beginnend mit der anfangs abgefragten Log Sequence Nummer bis einschließlich der zuletzt archivierten Datei, auf das Backupmedium kopiert werden. Dieses Backup der Redolog-Dateien ist gemeinsam mit der Datenbankkopie auf Spiegelseite vorzuhalten.
  7. Abschließend müssen auch hier alle für das Backup relevanten Dateien (Daten-Dateien, Offline Redolog-Dateien, Kopie der Control-Datei und die Konfigurations-Dateien), die sich jetzt auf der abgetrennten Spiegelseite befinden, auf die dafür vorgesehenen Backup-Medien kopiert werden, da sie sonst durch das nächste Backup überschrieben werden.

Das Backup ist damit erfolgreich beendet.

Standby-Datenbank und Backup

Oracle bietet zwei unterschiedliche Typen von Standby-Datenbanken an: Die logische und die physische. Bei der hier im Zusammenhang mit Backup und Recovery beschriebenen Datenbank handelt es sich stets um eine physische Standby-Datenbank.

Eine physische Standby-Datenbank ist eine Kopie einer produktiven Datenbank, die aus einem Backup der Primär-Datenbank erzeugt wurde und die transaktional konsistent in Echtzeit oder mit Zeitversatz durch das Nachfahren der Offline Redolog-Dateien (Redo-Apply) aus der Primär-Datenbank aktualisiert wird.

Die Standby-Datenbank befindet sich dabei im MOUNT-Status und wird sinnvollerweise auf einem separaten Server betrieben, da sie meist der Ausfallsicherheit der Produktions-Datenbank dient. Voraussetzung für den Betrieb einer Standby-Datenbank ist deshalb der aktivierte ARCHIVELOG-Modus. Außerdem muss die Übertragung der Offline Redolog-Dateien von der Primär- zur Standby-Datenbank sichergestellt sein. Dies kann beispielsweise durch ein gemeinsames ARCHIVELOG-Verzeichnis oder durch automatisiertes, scriptgesteuertes Kopieren erfolgen.

Dabei müssen in den Oracle-Versionen bis einschließlich 10g die beiden Server die gleiche Betriebssystem-Plattform besitzen sowie ein identisches Oracle-Release inklusive Patchlevel. Seit Oracle 11g unterstützt Data Guard auch unterschiedliche Prozessor-Architekturen, Betriebssysteme und 32- und 64-bit Kombinationen.

Bei Ausfall der Produktions-Datenbank kann die Standby-Datenbank aktiviert werden und so die Funktionen der produktiven Datenbank übernehmen.

Des Weiteren werden Standby-Datenbanken auch zum Abfangen logischer Fehler genutzt. Dies wird durch das zeitversetzte Einspielen der Änderungen der Primär-Datenbank in die Standby-Datenbank erreicht. Damit kann beispielsweise nach dem versehentlichen Löschen einer Tabelle in der Primär-Datenbank das Einspielen der Offline Redolog-Dateien angehalten werden. Wurde die Änderung (Löschen der Tabelle) noch nicht in die Standby-Datenbank eingespielt, kann die Standby-Datenbank durch ein Point-in-Time Recovery bis kurz vor diesem Zeitpunkt aktualisiert werden. Anschließend übernimmt die Standby-Datenbank die Funktion der Primär-Datenbank (Switchover). Die Änderungen seit dem Löschen der Tabelle in der Primär-Datenbank sind dann allerdings verloren.

Außerdem kann eine Standby-Datenbank auch für das Reporting und weitere Auswertungen genutzt werden. Dazu muss sie allerdings im Read-Only-Modus geöffnet werden und kann während dieser Zeit nicht aktualisiert werden. Mit Oracle 11g steht auch eine so genannte Snapshot Standby-Datenbank zur Verfügung. Eine physische Standby-Datenbank kann schnell zu einer Snapshot Standby-Datenbank konvertiert werden.

Die Snapshot Standby-Datenbank wird im Read-Write-Modus geöffnet und kann dann zum Beispiel für Testzwecke genutzt werden. Während die Datenbank im Read-Write-Modus geöffnet wird, werden weiterhin die Offline Redolog-Dateien der Primär-Datenbank übertragen, aber es findet kein Redo-Apply statt.

Die Snapshot Standby-Datenbank kann mit nur einem SQL-Befehl wieder in eine physische Standby-Datenbank konvertiert werden (ALTER DATABASE CONVERT TO PHYSICAL STANDBY;). Dabei wird Flashback Database genutzt. Während die Snapshot Standby-Datenbank geöffnet ist, kann kein Switchover stattfinden.

Oracle Data Guard bietet ein reichhaltiges Angebot für den Betrieb von Standby-Datenbanken vom Erzeugen über die Verwaltung bis hin zum Monitoring. Oracle Data Guard ist ein Feature der Oracle Database Enterprise Edition und bedarf wie RMAN keiner zusätzlichen Installation. RMAN und Data Guard können dabei gemeinsam für die Administration einer Data Guard-Konfiguration genutzt werden.

Näheres zum Thema Standby-Datenbanken und Oracle Data Guard findet man in der Oracle Dokumentation oder in entsprechender Fachliteratur [1]. Das Hauptaugenmerk in diesem Artikel liegt aber auf den Möglichkeiten, die eine Standby-Datenbank im Hinblick auf Backup und Restore bietet. Ein großer Nutzen der Standby-Datenbank liegt darin, dass sie anstelle der Primär-Datenbank gesichert werden kann. Außerdem stellt sie auch ein immer aktuelles Backup der produktiven Datenbank dar.

Dadurch ergeben sich folgende Vorteile:

  • die primäre Datenbank steht bei einem Offline-Backup der Standby-Datenbank während der Sicherung uneingeschränkt zur Verfügung.
  • der Datenbank-Server der primären Datenbank wird nicht durch die I/O-Operationen des Backups belastet.
  • sämtliche System-Ressourcen des produktiven Servers stehen auch während der Sicherung für den Online-Betrieb zur Verfügung.
  • alle System-Ressourcen des Standby-Servers können für das Backup genutzt werden.
  • die Server von Primär- und Standby-Datenbank können räumlich voneinander getrennt sein und bieten dadurch eine sehr hohe Ausfallsicherheit.
  • kurze Ausfallzeiten in Fehlersituationen, bei denen ein Restore der Datenbank erforderlich ist. Dabei kann die Standby-Datenbank nach dem Recovery der letzten Redolog-Dateien sofort die Aufgaben der Primär-Datenbank übernehmen. Es müssen weder Daten-Dateien noch Offline Redolog-Dateien von Band zurückgespielt werden, da sich alle für das Recovery notwendigen Dateien bereits auf dem Standby-Server befinden.
  • die Offline Redolog-Dateien werden durch das Einspielen in die Standby-Datenbank auf Korruptionen und Lesbarkeit überprüft.
  • zusätzlich lassen sich durch eine Standby-Datenbank auch Wartungsarbeiten ohne längere Auszeiten durchführen, da die Standby-Datenbank während dieser Zeit die Aufgaben der Primär-Datenbank übernehmen kann.
  • bei logischen Fehlern kann auf der Standby-Datenbank temporär ein FLASHBACK DATABASE auf einen Zeitpunkt vor dem Fehler durchgeführt werden. Dadurch können die Daten auf der Primär-Datenbank wesentlich einfacher wiederhergestellt werden.

Nachteil einer Standby-Datenbank ist neben den hohen Kosten für die meist doppelten Komponenten auch der erhöhte Aufwand für die Administration dieser Lösung.

Vorgehensweise für die Komplettsicherung
Ein Offline-Backup einer Standby-Datenbank, ohne dabei näher auf Data Guard und RMAN einzugehen, unterscheidet sich in einigen Punkten von einem normalen Offline-Backup. Zuerst müssen die Dateien bestimmt werden, die für eine Komplettsicherung der Datenbank benötigt werden. Für das Backup müssen die Daten-Dateien der Standby-Datenbank und die Control-Datei sowie die Konfigurations-Dateien der Primär-Datenbank gesichert werden, da ja im schlimmsten Fall die Primär-Datenbank wiederhergestellt werden soll.

  1. Daten-Dateien: Informationen über alle Daten-Dateien inklusive Pfad, Namen und Größe der Dateien kann man über die View V$DATAFILE bestimmen. Die View DBA_DATA_FILES ist bei nicht geöffneter Datenbank – also auch im MOUNT-Status, in dem sich die Standby-Datenbank meist befindet – nicht verfügbar.
    Pfad und Dateinamen sowie Größe der Daten-Dateien:
    Standby-Datenbank:
     SQL> SELECT NAME, BYTES FROM V$DATAFILE; NAME                         BYTES ---------------------------- ----------------- C:\ORACLE\STBY\SYSTEM01.DBF   503316480 C:\ORACLE\STBY\UNDOTBS01.DBF  26214400 C:\ORACLE\STBY\SYSAUX01.DBF   262144000 ...
    Um sich alle Tablespaces – außer den temporären – und ihre zugehörigen Daten-Dateien anzeigen zu lassen, kann folgendes SQL-Statement abgesetzt werden:
     SQL> SELECT t.NAME "Tablespace", f.NAME "Datafile"      FROM V$TABLESPACE t, V$DATAFILE f      WHERE t.TS# = f.TS#      ORDER BY t.NAME; Tablespace       Datafile ----------------------------------------------------- SYSAUX           C:\ORACLE\STBY\SYSAUX01.DBF SYSTEM           C:\ORACLE\STBY\SYSTEM01.DBF UNDOTBS1         C:\ORACLE\STBY\UNDOTBS01.DBF USERS            C:\ORACLE\STBY\USERS01.DBF

    Falls sich die Verzeichnisstrukturen von Primär- und Standby-Datenbank unterscheiden, sind die Initialisierungs-Parameter LOG_FILE_NAME_CONVERT und/oder DB_FILE_NAME_CONVERT in der Primär- und der Standby-Datenbank zu setzen.
    Zum Beispiel:

     LOG_FILE_NAME_CONVERT = 'C:\ORACLE\GC\', 'C:\ORACLE\STBY\' DB_FILE_NAME_CONVERT = 'C:\ORACLE\GC\', 'C:\ORACLE\STBY\'
    An erster Stelle steht dabei der Pfad der Primär-Datenbank gefolgt vom Pfad auf der Standby-Seite. Bei einem Restore des Backups zum Wiederherstellen der Primär-Datenbank muss darauf geachtet werden, dass die Dateien in das richtige Verzeichnis zurückgesichert werden.
  2. Control-Datei: Das Backup der Control-Datei wird als binäre Kopie aus der Primär-Datenbank erzeugt.
  3. Konfigurations-Dateien: Für das Backup werden die Konfigurations-Dateien von der Primär-Datenbank benötigt. Es gibt zwei unterschiedliche Arten der Parameter-Datei. Eine so genannte Text Initialisierungsparameter-Datei INIT.ORA und eine Server Parameter-Datei SPFILE.
    Wird eine Server Parameter-Datei SPFILE genutzt, kann diese wie folgt bestimmt werden:
    Primär-Datenbank:
     SQL> SHOW PARAMETER SPFILE NAME          TYPE        VALUE ------------- ----------- --------------------------------------------------- spfile        string      C:\ORACLE\DB_1\DATABASE\SPFILEGC.ORA

    Bei Nutzung der Parameter-Datei INIT.ORA liegt diese unter $ORACLE_HOME/dbs oder %ORACLE_HOME%/database (Windows).
    Eventuell ist in der Datei INIT.ORA nur der Speicherort der Parameter-Datei über die Parameter IFILE = <Pfad>/init<SID>.ora hinterlegt!
    Im selben Verzeichnis wie die Parameter-Datei befindet sich auch die Passwortdatei pwd<SID>.ora.
    tnsnames.ora, listener.ora und sqlnet.ora liegen im Verzeichnis $ORACLE_HOME/network/admin (UNIX) beziehungsweise %ORACLE_HOME\network\admin (Windows).
    Da die Standby-Datenbank laufend durch das Einspielen der Offline Redolog-Dateien der Primär-Datenbank aktualisiert wird, muss zuerst das Recovery durch folgenden Befehl angehalten werden.
    Standby-Datenbank:

     SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

    Dies kann unter Umständen einige Zeit dauern, falls gerade eine Offline Redolog-Datei eingespielt wird.
    Nun wird eine Kopie der Control-Datei der Primär-Datenbank erzeugt. Dazu wird folgendes Statement auf der Primär-Datenbank abgesetzt:
    Primär-Datenbank:

     SQL> ALTER DATABASE BACKUP CONTROLFILE TO '<pfad>/<dateiname>' [REUSE];

    Die Option REUSE ist dabei wieder für den Fall, dass die Datei bereits vorhanden ist und überschrieben werden soll.
    Jetzt befindet sich die Datenbank in konsistentem Zustand und kann mittels SHUTDOWN gestoppt werden:
    Standby-Datenbank:

     SQL> SHUTDOWN IMMEDIATE;

    Das vollständige Backup besteht nun aus folgenden Dateien:
    •    Daten-Dateien der Standby-Datenbank
    •    Konfigurations-Dateien der Primär-Datenbank
    •    Kopie der Control-Datei der Primär-Datenbank

    Wurden die Dateien gesichert, kann die Standby-Datenbank wieder gestartet und in den Recovery-Modus gebracht werden. Die Vorgehensweise hierfür unterscheidet sich in den Oracle Versionen 9i und den Nachfolgeversionen von 9i.
    •    Oracle 9i

     SQL> STARTUP NOMOUNT; SQL> ALTER DATABASE MOUNT STANDBY DATABASE; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

    •    Ab Oracle 10g

     SQL> STARTUP MOUNT; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

    Durch die Angabe von DISCONNECT FROM SESSION wird der Prozess in den Hintergrund geschickt und man gelangt wieder zum SQL-Prompt zurück.
    Die Standby-Datenbank wird jetzt wieder mit den Offline Redolog-Dateien der Primär-Datenbank aktualisiert. Da während der Sicherung in der Primär-Datenbank aber neue Redolog-Dateien erzeugt wurden, ist die Standby-Datenbank noch nicht auf dem aktuellen Stand und muss den Rückstand erst wieder aufholen.

Literaturverweise
  1. A. Held, 2004: Oracle 10g Hochverfügbarkeit. Die ausfallsichere Datenbank mit RAC, Data Guard und Flashback.
    s. a. hier: Informatik Aktuell: Hochverfügbarkeit und Downtime: Eine Einführung (und folgende Artikel der Serie)

Dies ist Teil einer Artikelserie zu Oracle Backup und Recovery. Vorige Artikel befassen sich mit

Backupstrategien

Grundlagen des physischen Backups

Autorin

Christine Gschoßmann

Christine Gschoßmann ist Geschäftsführerin der GC GmbH, die im Bereich der SAP Basis-Beratung tätig ist. Sie betreut SAP-Systeme überwiegend auf der Basis von Oracle und beschäftigt sich auch hier intensiv mit Backup und Recovery…
>> Weiterlesen

Publikationen

  • Oracle Backup und Recovery - Das Praxisbuch - Für alle Versionen bis einschließlich 11g Edition Oracle
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben