Über unsMediaKontaktImpressum
Christine Gschoßmann 20. Oktober 2015

Grundlagen des physischen Backups

Das physische Backup einer Oracle-Datenbank ist im Produktivbetrieb eine zwingende Notwendigkeit, um im Fehlerfall beispielsweise bei Ausfall des Betriebssystems, einer oder mehrerer Festplatten oder des Rechners einen konsistenten Datenbestand rekonstruieren zu können.

Physische Backups sind Sicherungen der Dateien, die für die Speicherung und Wiederherstellung der Datenbank benutzt werden, wie Daten-Dateien, Control-Dateien und Offline Redolog-Dateien. Die Datenbank lässt sich je nach gewählter Sicherungsstrategie und Fehlertyp vollständig oder nur mit Datenverlust wiederherstellen.

Dazu gibt es zwei grundsätzliche Sicherungsmöglichkeiten, die hier im Einzelnen beschrieben werden sollen.

  • Offline-Backup: Die Datenbank ist geschlossen; kein Zugriff auf Daten möglich
  • Online-Backup: Die Datenbank ist geöffnet und steht uneingeschränkt zur Verfügung. Die Datenbank muss sich im ARCHIVELOG-Modus befinden.

Ein Offline-Backup ist oft nötig, wenn mehrere Datenbanken oder Anwendungen, die ändernd auf Daten zugreifen, in einem Systemverbund stehen und ein konsistenter Aufsetzpunkt innerhalb dieses Verbunds sichergestellt werden muss. Dazu müssen alle beteiligten Systeme zur gleichen Zeit konsistent angehalten oder beendet und anschließend gesichert werden. So wird gewährleistet, dass im Fall eines Restore der gesamten Systemlandschaft keine Inkonsistenzen auftreten.

Ein Online-Backup benötigt zur Wiederherstellung der Daten alle während des Backups angefallenen Redolog-Dateien. Die während des Backups angefallenen Offline Redolog-Dateien sollten deshalb ebenso lange wie das Online-Backup selbst aufbewahrt werden. Zusätzlich sollten Offline Redolog-Dateien unabhängig vom Backupzyklus laufend gesichert werden. Für Produktivsysteme empfiehlt es sich, die Offline Redolog-Dateien mehrfach beispielsweise auf zwei unterschiedliche Bänder zu sichern, um bei eventuellen Fehlern auf den Sicherungsmedien (z. B. Band-Lesefehler) eine Ausfallsicherheit zu gewährleisten.

Die Sicherung der Dateien kann auf verschiedene Medien erfolgen und wird entweder mit Betriebssystemmitteln, über den Oracle Recovery Manager oder mit Tools von Drittanbietern auf das jeweilige Backup-Medium kopiert. Die Backup-Medien (z. B. Platten oder Bandlaufwerke) sollten dabei direkt am Datenbank-Server angeschlossen sein.

Offline-Backup

Unter einem vollständigen Offline-Backup versteht man die physische Sicherung aller für das Wiederherstellen einer Datenbank notwendigen Dateien im "kalten" Zustand. Das bedeutet, die Datenbank muss vor dem Backup geschlossen werden. Dadurch wird gewährleistet, dass während dieser Zeit keine Änderungen in der Datenbank stattfinden. Nach einem Offline-Backup der gesamten Datenbank verfügt man über eine konsistente Sicherung der Datenbank.

Es können aber während eines Offline Backups auch nur einzelne Tablespaces oder Daten-Dateien gemeinsam mit der Control-Datei gesichert werden. Diese partielle Sicherung einer Datenbank kann nicht für eine konsistente Wiederherstellung der gesamten Datenbank verwendet werden. Hierfür werden zusätzlich die Offline Redolog-Dateien zwischen den einzelnen partiellen Sicherungen benötigt.

Ein vollständiges Offline-Backup muss folgende Dateien beinhalten:

  1. alle Daten-Dateien sämtlicher Tablespaces (Tempfiles müssen dabei nicht gesichert werden),
  2. mindestens eine Kopie der Control-Datei,
  3. die Konfigurations-Dateien der Datenbank, wie die Parameter-Datei (PFILE beziehungsweise SPFILE), tnsnames.ora und listener.ora sowie die Passwort-Datei und
  4. die Online Redolog-Dateien, um das Öffnen der Datenbank nach einem Restore der kompletten Datenbank ohne weiteres Recovery und ohne die Option RESETLOGS zu ermöglichen, sowie um das Crash Recovery zu vereinfachen, falls die Datenbank nicht konsistent gestoppt werden konnte.

Die Sicherung der Online Redolog-Dateien ist jedoch nicht zwingend erforderlich. In vielen Umgebungen werden diese bei einem Offline-Backup nicht gesichert. Vor einem Offline-Backup muss die Datenbank möglichst konsistent gestoppt werden. Wird die Datenbank im NOARCHIVELOG-Modus betrieben, so ist das konsistente Beenden zwingend erforderlich! Dies bedeutet, dass die Datenbank mit SHUTDOWN NORMAL | IMMEDIATE | TRANSACTIONAL beendet werden muss.

Dadurch wird sichergestellt, dass keine offenen Transaktionen in der Datenbank existieren. Wird die Datenbank automatisch für das Backup beendet, was beispielsweise bei einem scriptgesteuerten Backup der Fall ist, so sollte immer SHUTDOWN IMMEDIATE verwendet werden, um die Datenbank so schnell wie möglich konsistent zu beenden. SHUTDOWN IMMEDIATE lässt keine Neuanmeldungen zu und es können keine neuen Transaktionen angestoßen werden. Alle offenen Transaktionen werden abgebrochen (rollback). Wenn noch lang laufende, offene Transaktionen existieren, kann es sein, dass auch diese Methode zur Beendigung der Datenbank länger dauert. Außerdem werden alle Verbindungen der angemeldeten Benutzer getrennt.

Beim SHUTDOWN NORMAL können sich zwar keine Benutzer mehr anmelden, die Datenbank wird aber erst beendet, wenn sich alle User abgemeldet haben.

Durch das Stoppen mit SHUTDOWN TRANSACTIONAL wird verhindert, dass neue Transaktionen gestartet werden, allerdings wartet die Datenbank solange bis alle offenen Transaktionen abgeschlossen wurden, egal ob erfolgreich (commit) oder nicht (rollback). Es sind keine Neuanmeldungen möglich und nach Beendigung der letzten Transaktion werden alle noch verbundenen Benutzer abgemeldet.

Ermittlung der für das Offline-Backup benötigten Dateien

Um die Dateien zu bestimmen, die für eine Komplettsicherung benötigt werden, stehen unter anderem folgende Möglichkeiten zur Verfügung.

Daten-Dateien
Für die Sicherung der Datenbank müssen nur die aktuellen Daten-Dateien gesichert werden. Manchmal kann es vorkommen, dass sich im Filesystem noch "Leichen" befinden, die vom Löschen nicht mehr benötigter Tablespaces herrühren. Diese Dateien werden für die Sicherung nicht benötigt. Den aktuellen Bestand mit Pfad, Namen und Größe der Dateien kann man über die Views DBA_DATA_FILES oder V$DATAFILE bestimmen.

Pfad und Dateinamen sowie Größe der Daten-Dateien:

SQL> SELECT FILE_NAME, BYTES FROM DBA_DATA_FILES;
FILE_NAME                  BYTES
-------------------------- ------------------
C:\ORACLE\GC\USERS02.DBF   5242880
C:\ORACLE\GC\USERS01.DBF   5242880
C:\ORACLE\GC\SYSAUX01.DBF  262144000
...
SQL> SELECT NAME, BYTES FROM V$DATAFILE;
NAME                         BYTES
---------------------------- -----------------
C:\ORACLE\GC\SYSTEM01.DBF   503316480
C:\ORACLE\GC\UNDOTBS01.DBF  26214400
C:\ORACLE\GC\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\GC\SYSAUX01.DBF
SYSTEM           C:\ORACLE\GC\SYSTEM01.DBF
UNDOTBS1         C:\ORACLE\GC\UNDOTBS01.DBF
USERS            C:\ORACLE\GC\USERS01.DBF

Dateien von Temporary Tablespaces / Tempfiles
Tempfiles gehören immer zu Temporary Tablespaces. Wie der Name schon sagt, können in ihnen keine permanenten Objekte wie Tabellen abgelegt werden. Sie werden typischerweise für die Ablage temporärer Datenbankobjekte, die zum Beispiel beim Sortieren entstehen, genutzt.

Nach Abschluss eines Sortiervorgangs, wie zum Beispiel einer ORDER BY-Anweisung in einem SQL-Statement, werden die belegten Extents wieder freigegeben. Somit werden diese Dateien nicht für das Backup benötigt.

Allerdings müssen sie nach einem Restore der Datenbank mit dem Befehl ALTER TABLESPACE ADD TEMPFILE wieder neu angelegt werden. Tempfiles werden dabei nicht auf allen Betriebssystemen initial mit der Größe aus der Storage-Anweisung des CREATE/ALTER TABLESPACE Kommandos erzeugt, sondern wachsen erst, wenn in ihnen temporäre Objekte abgelegt werden. Dies sollte auch bei der Dateisystem-Überwachung berücksichtigt werden. Der Vollständigkeit halber soll auch die Bestimmung dieser Dateien hier aufgezeigt werden. Die Views DBA_TEMP_FILES und V$TEMPFILE enthalten darüber die notwendigen Informationen.

Pfad und Dateinamen sowie Größe der Tempfiles:

SQL> SELECT FILE_NAME, BYTES FROM DBA_TEMP_FILES;
FILE_NAME                      BYTES
------------------------------ --------------------
C:\ORACLE\GC\TEMP01.DBF        20971520
SQL> SELECT NAME, BYTES FROM V$TEMPFILE;
NAME                           BYTES
------------------------------ --------------------
C:\ORACLE\GC\TEMP01.DBF        20971520

Konfigurations-Dateien
Es gibt zwei unterschiedliche Arten der Parameter-Datei: Eine so genannte Text Initialisierungsparameter-Datei init<SID>.ora und eine Server Parameter-Datei spfile[<SID>].ora. Eine dieser Dateien muss vorhanden sein. Oracle liest beim Starten der Datenbank-Instanz dabei das Verzeichnis $ORACLE_HOME/dbs beziehungsweise %ORACLE_HOME%\database aus. Finden sich in diesem Verzeichnis mehrere Parameter-Dateien, entscheidet sich Oracle in folgender Reihenfolge für eine dieser Dateien:

  • spfile<SID>.ora
  • spfile.ora
  • init<SID>.ora

Wird eine Server Parameter-Datei spfile[<SID>].ora genutzt, kann diese wie folgt bestimmt werden:

SQL> SHOW PARAMETER SPFILE
NAME          TYPE        VALUE
------------- ----------- ---------------------------------------------------
spfile        string      C:\ORACLE\DB_1\DATABASE\SPFILEGC.ORA

Bei Nutzung der Parameter-Datei init<SID>.ora liegt diese unter $ORACLE_HOME/dbs (UNIX) oder %ORACLE_HOME%\database (Windows). Eventuell ist in der Datei init<SID>.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 Passwort-Datei pwd<SID>.ora. tnsnames.ora, listener.ora und sqlnet.ora liegen im Verzeichnis $ORACLE_HOME/network/admin beziehungsweise %ORACLE_HOME%\network\admin (Windows).

Control-Dateien
Pfade und Namen der Control-Dateien lassen sich über den Parameter CONTROL_FILES oder die View V$CONTROLFILE ermitteln.

Pfad und Dateinamen der Control-Dateien:

SQL> SHOW PARAMETER CONTROL_FILES
NAME                             TYPE       VALUE
-------------------------------- ---------- ------------------------------
control_files                    string     C:\ORACLE\PRODUCT\10.2.0\ORADA
                                            TA\GC\CONTROL01.CTL, C:\ORACLE
                                            \PRODUCT\10.2.0\ORADATA\GC\CON
                                            TROL02.CTL, C:\ORACLE\PRODUCT\
                                            10.2.0\ORADATA\GC\CONTROL03.CTL
oder
SQL> SELECT NAME FROM V$CONTROLFILE;
NAME
------------------------------------------------------------
C:\ORACLE\PRODUCT\10.2.0\ORADATA\GC\CONTROL01.CTL
C:\ORACLE\PRODUCT\10.2.0\ORADATA\GC\CONTROL02.CTL
C:\ORACLE\PRODUCT\10.2.0\ORADATA\GC\CONTROL03.CTL

Online Redolog-Dateien
Die Online Redolog-Dateien werden nicht benötigt, um die Datenbank aus einem Offline-Backup wiederherzustellen, vorausgesetzt die Datenbank wurde konsistent geschlossen. Soll ein Offline-Backup zurückgespielt und die Datenbank ohne weiteres Recovery geöffnet werden, muss die Option RESETLOGS des ALTER DATABASE OPEN-Befehls verwendet werden. Dabei wird die Log Sequence Nummer zurückgesetzt und eine neue Datenbankinkarnation erzeugt. Falls dies vermieden werden soll, müssen auch die Online Redolog-Dateien gesichert werden. Die Online Redolog-Dateien lassen sich am einfachsten über die View V$LOGFILE ermitteln.

Pfad und Dateinamen der Online Redolog-Dateien:

SQL> SELECT MEMBER FROM V$LOGFILE;
MEMBER
---------------------------------------------------
C:\ORACLE\GC\REDO02.LOG
C:\ORACLE\GC\REDO01.LOG
C:\ORACLE\GC\REDO03.LOG

Ablauf eines Offline-Backups

Ein Offline-Backup gliedert sich grundsätzlich in folgende drei Phasen, wobei sich das Kopieren der Dateien auf das Backup-Medium recht unterschiedlich gestalten kann, je nachdem welche Backup-Medien verwendet werden (Band, Platte, etc.) und mit welchen Mitteln das Kopieren stattfindet (Betriebssystemmittel, RMAN oder Drittanbieter-Tools).

  1. Konsistentes Beenden der Datenbank: SHUTDOWN [ NORMAL ] | [ TRANSACTIONAL ] | [ IMMEDIATE ]
  2. Kopieren der Daten-Dateien, Control-Datei und der Konfigurations-Dateien (Betriebssystemmittel, RMAN oder Drittanbietertools), optional auch Kopieren der Online Redolog-Dateien
  3. Starten der Datenbank

Der Betrieb der Datenbank ist nun wieder uneingeschränkt möglich.

Offline-Backup im NOARCHIVELOG-Modus

Wird die Datenbank im NOARCHIVELOG-Modus betrieben, sollte zusätzlich noch Folgendes beachtet werden:

Beim konsistenten Beenden der Datenbank mit SHUTDOWN NORMAL, TRANSACTIONAL oder IMMEDIATE werden alle offenen Transaktionen beendet. Die Datenbank befindet sich dann in einem konsistenten Zustand.

Sollte aus irgendwelchen Gründen ein konsistentes Stoppen der Datenbank nicht beziehungsweise nicht mehr möglich sein, so müssen in diesem Fall zusätzlich auch die Online Redolog-Dateien gesichert werden, um bei der Wiederherstellung der Datenbank aus diesem Backup ein Crash Recovery zu ermöglichen. Nur so kann die Datenbank alle Transaktionen, die beim Stoppen der Datenbank noch offen waren, konsistent beenden. Dabei werden die bei erfolgreich beendeten Transaktionen (commit) geänderten Daten in die Datenbank übernommen und Datenänderungen abgebrochener Transaktionen verworfen (rollback). Die hierzu erforderlichen Informationen befinden sich in den Online Redolog-Dateien.

Online-Backup

Der Hauptvorteil des Online-Backups liegt sicherlich darin, dass die Datenbank im laufenden Betrieb gesichert wird und somit der Betrieb uneingeschränkt möglich ist. Im Gegensatz zum Offline-Backup kann eine Sicherung im laufenden Betrieb natürlich nicht konsistent sein. Um trotzdem im Fehlerfall auf ein Online-Backup zurückgreifen zu können, benötigt man zusätzlich die Offline Redolog-Dateien, die seit Beginn der Sicherung geschrieben wurden.

Während eines Online-Backups, also zwischen dem Setzen (BEGIN BACKUP) und dem Zurücknehmen (END BACKUP) des Backup Modus, werden die Checkpoint Zeitstempel nicht mehr in die Header der Daten-Dateien, für die das Backup initiiert wurde, geschrieben. Das bedeutet, dass die Header der gesicherten Dateien den Zeitstempel des letzten Checkpoints vor Beginn des Backups aufweisen und Oracle somit bei einem Wiederherstellen dieser Dateien aus der Sicherung feststellen kann, welche Redolog-Dateien nachgefahren werden müssen.

Jede Redolog-Datei, die archiviert wird, erhält eine Log Sequence Nummer, die fortlaufend nummeriert ist. Für ein Online-Backup beziehungsweise ein Recovery dieses Backups ist diese Nummer unentbehrlich. Sie sollte deshalb mit dem Online-Backup protokolliert werden. Ein entscheidender Unterschied zum Offline-Backup ist, dass bei Wiederherstellung der Datenbank aus einem Online-Backup immer ein Recovery der zurückgespielten Daten-Dateien nötig ist, um die Datenbank auf einen konsistenten Stand zu bringen.

Online-Backups sind grundsätzlich nur dann möglich, wenn die Datenbank im ARCHIVELOG-Modus betrieben wird.

Auch für das Online-Backup gilt, dass sämtliche Dateien gesichert werden müssen, die für das Wiederherstellen der Datenbank benötigt werden.

Ein vollständiges Online-Backup besteht aus folgenden Dateien:

  • allen Daten-Dateien sämtlicher Tablespaces (tempfiles müssen dabei nicht gesichert werden),
  • allen während des Backups erzeugten Offline Redolog-Dateien,
  • mindestens einer Kopie der Control-Datei und
  • den Konfigurations-Dateien der Datenbank, wie der Parameter-Datei (pfile beziehungsweise spfile), tnsnames.ora, listener.ora, sqlnet.ora sowie der Passwort-Datei.

Ebenso wie beim Offline-Backup kann die Sicherung der Dateien auf verschiedene Medien erfolgen und wird entweder mit Betriebssystemmitteln, über den Oracle Recovery Manager oder mit Tools von Drittanbietern auf das jeweilige Backup-Medium kopiert.

Ermittlung der für das Online-Backup benötigten Dateien

Um die Dateien zu ermitteln, die für ein vollständiges Online-Backup benötigt werden, stehen unter anderem folgende Möglichkeiten zur Verfügung.

Daten-Dateien
Informationen über alle Daten-Dateien inklusive Pfad, Namen und Größe der Dateien kann man über die Views DBA_DATA_FILES oder V$DATAFILE bestimmen.

Pfad und Dateinamen sowie Größe der Daten-Dateien:

SQL> SELECT FILE_NAME, BYTES FROM DBA_DATA_FILES;
FILE_NAME                  BYTES
-------------------------- ------------------
C:\ORACLE\GC\USERS02.DBF   5242880
C:\ORACLE\GC\USERS01.DBF   5242880
C:\ORACLE\GC\SYSAUX01.DBF  262144000
...
SQL> SELECT NAME, BYTES FROM V$DATAFILE;
NAME                         BYTES
---------------------------- -----------------
C:\ORACLE\GC\SYSTEM01.DBF   503316480
C:\ORACLE\GC\UNDOTBS01.DBF  26214400
C:\ORACLE\GC\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 verwendet 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\GC\SYSAUX01.DBF
SYSTEM           C:\ORACLE\GC\SYSTEM01.DBF
UNDOTBS1         C:\ORACLE\GC\UNDOTBS01.DBF
USERS            C:\ORACLE\GC\USERS01.DBF

Offline Redolog-Dateien
Die Offline Redolog-Dateien, die für das Online-Backup benötigt werden, können erst nach Ende des Backups der Daten-Dateien bestimmt werden. Das Verzeichnis und das Format der Offline Redolog-Dateien werden dabei am einfachsten über die Parameter LOG_ARCHIVE_DEST, LOG_ARCHIVE_DUPLEX_DEST oder LOG_ARCHIVE_DEST_n sowie LOG_ARCHIVE_FORMAT ermittelt.

Wurde eine Flash Recovery Area definiert (Parameter DB_RECOVERY_FILE_DEST), können sich die Redolog-Dateien auch in den Verzeichnissen unterhalb des Verzeichnisses DB_RECOVERY_FILE_DEST\<SID>\ARCHIVELOG befinden.

Der Parameter LOG_ARCHIVE_FORMAT kann sich dabei aus folgenden Variablen zusammensetzen:

Tabelle 1: Variablen des Parameters LOG_ARCHIVE_FORMAT

Variable Bedeutung
%s Log Sequence Nummer
%t Thread Nummer
%a Aktivierungs-ID
%d Datenbank-ID
%r Resetlogs ID, die sicherstellt, dass eindeutige Namen für die Redolog-Dateien auch über mehrere Inkarnationen der Datenbank erzeugt werden

Werden dabei Großbuchstaben für die Variablen, zum Beispiel %S verwendet, werden die Werte auf eine (betriebssystemabhängige) Länge festgelegt und mit führenden Nullen aufgefüllt. Der Name der Datei setzt sich aus diesen beiden Parametern zusammen.

Beispiel:

LOG_ARCHIVE_DEST = 'F:\ORACLE\GC1\arch\GC1'
LOG_ARCHIVE_FORMAT = ARC%S.%T

Dadurch würde sich für die Datei mit der Log Sequence Nummer 787 folgender Name ergeben:

F:\ORACLE\GC1\arch\GC1ARC00787.001

Die Log Sequence Nummer der ersten für die Sicherung notwendigen Offline Redolog-Datei lässt sich bereits zu Beginn des Backups über folgende Datenbankabfrage feststellen.

SQL> SELECT SEQUENCE# FROM V$LOG WHERE STATUS='CURRENT';
SEQUENCE#
------------
787

Dies ist die zurzeit aktive Log Sequence Nummer, deren Redo-Daten daher noch nicht archiviert sind. Die jüngste archivierte Redolog-Datei ist demnach die mit der Sequence Nummer 786. In der Alert-Datei der Datenbank findet man dazu den letzten Log-Switch:

Tue Apr 18 19:51:38 2008 
Thread 1 advanced to log sequence 787
  Current log# 13 seq# 787 mem# 0: F:\...\LOG_G13M1.DBF
  Current log# 13 seq# 787 mem# 1: G:\...\LOG_G13M2.DBF

Nach Ende des Online-Backups muss die aktuelle Log Sequence Nummer erneut abgefragt werden. Damit erhält man die letzte für ein konsistentes Backup erforderliche Redolog-Datei.

Konfigurations-Dateien
Es gibt zwei unterschiedliche Arten der Parameter-Datei. Eine so genannte Text Initialisierungsparameter-Datei init<SID>.ora und eine Server Parameter-Datei spfile[<SID>].ora. Wird eine Server Parameter-Datei spfile[<SID>].ora genutzt, kann diese wie folgt bestimmt werden:

SQL> SHOW PARAMETER SPFILE
NAME          TYPE        VALUE
------------- ----------- ---------------------------------------------------
spfile        string      C:\ORACLE\DB_1\DATABASE\SPFILEGC.ORA

Bei Nutzung der Parameter-Datei init<SID>.ora liegt diese unter $ORACLE_HOME/dbs (UNIX) oder %ORACLE_HOME%/database (Windows). Eventuell ist in der Datei init<SID>.ora nur der Speicherort der Parameter-Datei über die Parameter IFILE = <Pfad>/init<SID>.ora hinterlegt!

In demselben Verzeichnis wie die Parameter-Datei befindet sich auch die Passwortdatei pwd<SID>.ora. tnsnames.ora, listener.ora sowie sqlnet.ora liegen im Verzeichnis $ORACLE_HOME/network/admin beziehungsweise %ORACLE_HOME%\network\admin (Windows).

Control-Dateien
Die Control-Datei muss für ein Online-Backup gesondert betrachtet werden. Anders als bei einem Offline-Backup kann keine Kopie der vorhandenen Control-Dateien verwendet werden, da diese fortlaufend aktualisiert werden (SCN etc.). Stattdessen muss zuerst ein Backup der Control-Datei erzeugt werden. Mit folgendem Befehl wird eine binäre Datei erzeugt, die anschließend für das Online-Backup verwendet werden kann.

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

Es kann aber auch eine Text-Datei generiert werden mittels derer eine neue Control-Datei erzeugt werden kann.

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Die Datei wird in dem Verzeichnis angelegt, das durch den Initialisierungs-Parameter USER_DUMP_DEST festgelegt wurde. Ab Oracle 11g wird die Text-Datei in das Verzeichnis Diag Trace geschrieben. Das Verzeichnis Diag Trace kann über die View V$DIAG_INFO (SELECT * FROM V$DIAG_INFO) ermittelt werden.

Durchführung eines Online-Backup

Anders als beim Offline-Backup wird für das Online-Backup die Datenbank nicht geschlossen. Deshalb muss der Datenbank der Beginn der Sicherung mitgeteilt werden. Dies erfolgt durch den Befehl BEGIN BACKUP. Bis Oracle 9i konnte das Kommando nur für die einzelnen Tablespaces abgesetzt werden. Ab Oracle 10g kann auch die gesamte Datenbank mit allen Daten-Dateien in den Online Backup-Modus gesetzt werden. Aus diesem Grund werden beide Möglichkeiten im Folgenden betrachtet.

Online-Backup eines Tablespace

  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.
  2. Tablespace in den Backup-Modus setzen
    SQL> ALTER TABLESPACE <tablespace_name> BEGIN BACKUP;
  3. Kopieren beziehungsweise Sichern aller zum Tablespace gehörenden Daten-Dateien
  4. Tablespace wieder aus dem Backup-Modus nehme
    SQL> ALTER TABLESPACE <tablespace_name> END BACKUP;
    Sollen mehrere Tablespaces innerhalb dieses Backups gesichert werden, müssen die Aktionen Tablespace in den Backup-Modus setzen, Kopieren der zugehörigen Daten-Dateien und Tablespace aus Backup-Modus nehmen für diese Tablespaces wiederholt werden.
  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. Dies ist beispielsweise dann der Fall, wenn für das Online-Backup immer wieder derselbe Ablageort zur Sicherung der Control-Datei verwendet wird.
  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 noch 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.
  7. Kopieren der Konfigurations-Dateien und der Sicherung der Control-Datei

Damit ist das Online-Backup des Tablespace abgeschlossen. Trotzdem sollte zur Sicherheit noch kontrolliert werden, ob wirklich alle Daten-Dateien des gesicherten Tablespaces wieder aus dem Backup Modus genommen wurden. Dazu wird die View V$BACKUP verwendet. Der Status der Dateien muss den Wert NOT ACTIVE aufweisen.

SQL> SELECT f.FILE_NAME "Dateiname", b.STATUS "Status"
     FROM DBA_DATA_FILES f, V$BACKUP b
     WHERE f.TABLESPACE_NAME='<tablespace_name>'
     AND f.FILE_ID = b.FILE#
     ORDER BY f.FILE_NAME;

Werden hier noch Dateien ausgegeben, die den Status ACTIVE besitzen, so kann entweder für jede Datei einzeln, für alle Dateien eines Tablespace oder für alle Daten-Dateien der Datenbank der Backup-Modus zurückgesetzt werden. Bevor man jedoch den Status für alle Daten-Dateien zurücksetzt, sollte sichergestellt sein, dass kein weiteres Online-Backup läuft.

SQL> ALTER DATABASE DATAFILE '<pfad>/<dateiname>' END BACKUP;
SQL> ALTER TABLESPACE END BACKUP;
SQL> ALTER DATABASE END BACKUP;

Damit haben alle Daten-Dateien den Backup-Modus wieder verlassen und die Zeitstempel der Checkpoints werden wieder in die Header der Daten-Dateien geschrieben.

Online-Backup der gesamten Datenbank
Eine konsistente Online-Sicherung der gesamten Datenbank besteht aus den Kopien aller Daten-Dateien sowie sämtlichen Änderungen, die während dieser Sicherung in der Datenbank durchgeführt wurden. Das bedeutet, dass alle Redolog-Dateien, die im Laufe der Sicherung erzeugt werden, zwingend für die Wiederherstellung eines konsistenten Zustands der Datenbank aus diesem Backup erforderlich sind. Außerdem werden die Informationen über die Datenbank-Struktur zu diesem Zeitpunkt benötigt. Deshalb muss auch eine Kopie der Control-Datei erzeugt werden, die ebenso Bestandteil dieser Sicherung ist. Zu Beginn der Sicherung muss also erst einmal die aktuelle Log Sequence Nummer ermittelt werden.

  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 Nummer, werden für die Sicherung benötigt.
  2. Datenbank in den Backup Modus setzen
    SQL> ALTER DATABASE BEGIN BACKUP;
  3. Kopieren aller Daten-Dateien der Datenbank (keine Tempfiles)
  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. Dies ist beispielsweise dann der Fall, wenn für das Online-Backup immer wieder derselbe Ablageort zur Sicherung der Control-Datei verwendet wird.
  6. Bestimmen der aktuellen Log Sequence Nummer
    SQL> SELECT SEQUENCE# FROM V$LOG WHERE STATUS='CURRENT';
    Die Redolog-Datei mit dieser Sequence Nummer ist damit die letzte, die für ein konsistentes Backup erforderlich ist. Da es sich dabei noch 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-Dateien 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.
  7. Kopieren der Konfigurations-Dateien und der Sicherung der Control-Datei

Damit ist das Online-Backup der Datenbank abgeschlossen. Trotzdem sollte zur Sicherheit noch kontrolliert werden, ob wirklich alle Daten-Dateien wieder aus dem Backup Modus genommen wurden. Dazu wird die View V$BACKUP verwendet. Der Status der Dateien muss den Wert NOT ACTIVE aufweisen.

SQL> SELECT f.FILE_NAME "Dateiname", b.STATUS "Status"
     FROM DBA_DATA_FILES f, V$BACKUP b
     WHERE f.FILE_ID = b.FILE#
     ORDER BY f.FILE_NAME;
oder um nur die unterschiedlichen Status der Dateien auszugeben
SQL> SELECT distinct b.STATUS "Status"
     FROM DBA_DATA_FILES f, V$BACKUP b
     WHERE f.FILE_ID = b.FILE#;

Werden hier noch Dateien ausgegeben, die den Status ACTIVE besitzen, beziehungsweise wird bei der Ausgabe des zweiten SQL-Statements auch noch der Status ACTIVE zurückgeliefert, so kann entweder für jede Datei einzeln, für alle Dateien eines Tablespace oder für alle Daten-Dateien der Datenbank der Backup-Modus zurückgesetzt werden.

SQL> ALTER DATABASE DATAFILE 'dateiname' END BACKUP;
SQL> ALTER TABLESPACE END BACKUP;
Ab Oracle 9i:
SQL> ALTER DATABASE END BACKUP;

Damit haben alle Daten-Dateien den Backup-Modus wieder verlassen und die Zeitstempel der Checkpoints werden wieder in die Header der Daten-Dateien geschrieben.

Dies war der erste Teil einer Artikel-Reihe zum Thema Oracle Backup und Recovery. Der zweite Teil beschäftigt sich mit dem Backup großer Datenbanken, Split-Mirror Backup und Standby-Datenbank und Backup.

Dies ist der zweite Teil einer Artikelserie zu Oracle Backup und Recovery. Der vorige Artikel befasst sich mit Backupstrategien

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
Buch der Autorin:

botMessage_toctoc_comments_9210