Zum Inhalt springen

Oracle: Backup und Recover

Aus Wikibooks


Backup-Strategie

[Bearbeiten]

Offline-Backup

Die Datenbank-Dateien werden gesichert, während die Datenbank nicht geöffnet ist.

Vorteile:

  • einfache Handhabung
  • das Backup kann mit Betriebsystem-Mitteln durchgeführt werden

Nachteile:

  • die Datenbank muss heruntergefahren werden
  • falls ein Recover erforderlich ist, dann kann nur die Sicherung wiederhergestellt werden. Alle danach erfolgten Änderungen können nicht automatisch nachgezogen werden.
  • Die Datenbank kann nur als Ganzes wiederhergestellt werden.

Online-Backup

Während der Benutzung der Datenbank von Anwendern kann auch eine Datensicherung hergestellt werden. Diese Sicherung enthält aber keinen Snapshot, sondern die Änderungen, die während der Erstellung der Sicherung ausgeführt wurden, sind teilweise in der Sicherung enthalten.

Online-Sicherungen sind nur möglich, wenn auch die Redolog-Dateien durch den ARCH-Prozess gesichert werden.

Vorteile:

  • Kein SHUTDOWN erforderlich zur Erstellung der Sicherung
  • beim Recover kann eine Sicherung eingespielt werden und dann die Änderungen automatisch nachvollzogen werden bis zu einem bestimmten Punkt z.B. bis vor den Start eines bestimmten Programms
  • Einzelne Tablespaces können gesichert werden

Nachteile:

  • Das Erstellen einer online-Sicherung belastet die anderen Aktivitäten der Instanz
  • ein Recover auf die Datensicherung alleine ist nicht möglich, da die Sicherung keine konsistenten Daten eines Snapshots enthält.


Offline-Backup

[Bearbeiten]

Beispiel-Script für die Durchführung eines offline-Backup (unter Windows) 

set heading off
set feedback off
set underline off
set termout off

spool c:\backup\backup.bat

select 'copy ' || name   || '  c:\backup' from v$datafile;
select 'copy ' || name   || '  c:\backup' from v$controlfile;
select 'copy ' || member || '  c:\backup' from v$logfile;

spool off

shutdown immediate

host c:\backup\backup.bat

startup


Aufruf des Scripts: 

 SQLPLUS "sys/<Passwort> as sysdba" @c:\<Name des Scripts>

Zur Durchführung eines Recover müssen alle Dateien wieder an ihren Ursprungsort kopiert werden. Falls die Datenbank-Dateien auf unterschiedlichen Platten gespeichert waren, dann muss darauf geachtet werden, dass alle Dateien wieder an ihren richtigen Ort kopiert werden. Es darf keine einzige Datei ausgelassen werden. Am besten hebt man sich die generierte Backup-Datei auf oder man erstellt sich gleich eine geeignete Recover-Datei, mit der ein Recover automatisch abläuft.

Online-Backup

[Bearbeiten]

Ein Online-Backup ist nur zu gebrauchen, wenn die Redolog-Dateien über den ARCH-Prozess gesichert werden. Denn die einzelnen Dateien werden parallel zu den Änderungen der Datenbank erstellt. Bestimmte Änderungen sind in den Dateien bereits enthalten, andere noch nicht.

Wenn man später eine Online-Sicherung für das Recover verwenden will, dann müssen nach dem Einspielen der Sicherung die archivierten Redolog-Dateien ausgewertet werden, um alle Datenänderungen bis zu einem bestimmten Timestamp nachzuvollziehen. Erst dann ist ein bestimmter, konsistenter Zustand der Datenbank wieder hergestellt.

Ein Online-Backup kann durch folgende Befehlsfolge ausgeführt werden:

1. Beginn der Online-Sicherung dem System mitteilen 

 ALTER TABLESPACE <Name> BEGIN BACKUP

2. Mit Betriebssystem-Mitteln wird die Datei in das Backup-Verzeichnis kopiert

3. Das Ende der Online-Sicherung dem System mitteilen 

 ALTER TABLESPACE <Name> END BACKUP

Für die Durchführung von Online-Backups kann man sich auch Skripte generieren, die dann automatisiert ablaufen. Dabei muss man darauf achten, dass immer nur ein Tablespaces im Backup-Status ist. Für jeden Tablespace, der gesichert werden soll, müssen die oben genannten drei Schritte durchlaufen werden.

Control-Dateien wiederherstellen

[Bearbeiten]

Falls die Controldateien zerstört wurden (und alle anderen Dateien noch ok sind), dann kann man die Control-Dateien neu erstellen lassen mit folgender Befehlsfolge: 

 SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE

oder 

 SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS 'zu_speichernde_pfad_mit_name'
 SQL> SHUTDOWN IMMEDIATE

Dadurch wird in dem Trace-Verzeichnis ein Script erstellt, mit dem man die Control-Dateien sichern kann. Die Trace-Datei findet man in dem Verzeichnis: 

 C:\oracle\admin\<SID>\udump

Datei mit dem letzten Datum suchen.

In der Datei muss man die Header-Zeilen und die Kommentar-Zeilen entfernen. Dann kann man die Datei z.B. speichern unter c:\con_neu.sql und ausführen: 

 SQL> @c:\con_neu.sql

Nun sind die Controldateien neu angelegt worden.

ARCH-Prozess

[Bearbeiten]

Der ARCH-Prozess hat die Aufgabe, die voll geschriebenen LOG-Dateien zu sichern. Der LGWR (Log-Writer-Prozess) überschreibt und hat nur eine bestimmte Anzahl von Log-Dateien zur Verfügung. Wenn die eine Datei voll ist, dann schreibt er die Log-Informationen in die nächste Datei weiter. Dabei wird der alte Inhalt der Log-Datei überschrieben. Der ARCH-Prozess sorgt dafür, dass die Log-Dateien nach ihrem Beschreiben gesichert werden.

Der ARCH-Prozess wird aktiviert durch:

Einträge in der Datei init.ora: (Beispiel) 

 log_archive_start = true
 log_archive_dest = C:\oracle\oradata\ora1g\archive
 log_archive_format = %%ORACLE_SID%%T%TS%S.ARC

Dann muss der ARCH-Prozess noch aktiviert werden. Das geht nur, wenn die Datenbank in der MOUNT-Phase ist, (nicht in der OPEN-Phase) 

 shutdown immediate;
 startup mount;
 alter database archivelog;
 alter database open;

Nun kann man die Arbeit des ARCH-Prozesses beobachten.

Die Data-Dictionary-Views geben über seine Aktivitäten Auskunft: 

 V_$ARCHIVED_LOG
 V_$ARCHIVE_DEST
 V_$ARCHIVE_PROCESSES

Man kann einen Logswitch erzwingen, auch wenn die aktuelle Logdatei noch nicht voll ist mit dem Befehl 

 alter system switch logfile;

Recover

[Bearbeiten]

Recover allgemeine Bemerkungen

[Bearbeiten]

Vor dem Starten eines Recover sollte immer eine genaue Fehleranalyse stehen. Dabei können grundsätzlich zwei Fehlerarten unterschieden werden:

logische Fehler

  • Datenfehler durch fehlerhafte Programme
  • Ein Programm oder Skript ist in seiner Verarbeitung abgebrochen und hinterläßt die Daten in einem inkonsistenten Zustand.
  • Operator-Fehler z.B. ein Programm zur Erhöhung der Gehälter wurde aus Versehen zwei mal gestartet
  • Anwender oder Administratoren haben aus Versehen wichtige Tabellen oder Datensätze gelöscht
  • es stehen keine ausreichenden Systemressourcen zur Verfügung (Systemüberlastung, Tablespace-Dateien sind voll, Rollbacksegmente sind zu klein, Deadlocks)

technische Fehler

  • Stromausfall
  • Hardwarefehler z.B. bei den Speicherplatten
  • Die Ausführung von Tools ist fehlgeschlagen, so dass sich die Daten in einem inkonsistenten Zustand befinden

Recover planen

[Bearbeiten]

Wenn ein Datenfehler festgestellt wurde, dann sollten die einzelnen Schritte für das Recover genau geplant werden.

Erst wenn

  • die Fehlerursache genau eingegrenzt ist und
  • der Umfang der erforderlichen Recover-Massnahme genau ermittelt ist

ist es sinnvoll, mit dem Recover zu beginnen.

Recover ausführen mit einer offline-Sicherung

[Bearbeiten]

Offline-Sicherungen können nur als Ganzes verwendet werden. Einzelne Teile oder einzelne Dateien können nicht wiederhergestellt werden. Es müssen alle beteiligten Dateien einschließlich dem System-Tablespace, den Control-Dateien und den Redolog-Dateien aus der Sicherung übernommen werden. Alle Datenänderungen, die seit dem Zeitpunkt der Erstellung der offline-Sicherung ausgeführt wurden, müssen wiederholt werden.


Recover ausführen mit einer online-Sicherung

[Bearbeiten]

Einzelne Dateien können wiederhergestellt werden. Eine viel granularere Steuerung ist möglich. Die Änderungen an den Daten, die seit dem Herstellen der Sicherung ausgeführt wurden sind, können durch Auslesen der Log-Dateien nachvollzogen werden, ohne dass die Anwendungsprogramme neu ablaufen müssen. Für das Recover mit online-Sicherungen gibt es eine große Vielzahl von Möglichkeiten, auf die in diesem Seminar nicht eingegangen werden kann. Beispielhaft soll das recovern einer einzelnen Tablespace-Datei dienen, das auf der nächsten Seite erläutert ist.

Recover Beispiel 1

[Bearbeiten]

Es wurde eine Datei, gelöscht, in der die Daten eines Tablespace mit Anwendungstabellen gespeichert waren. Es handelt sich um einen Tablespace, dessen Anlegen noch in den zur Verfügung stehenden LOG-Dateien verzeichnet ist.

1. Beim Hochfahren der Datenbank wird ausgegeben, dass eine Datei fehlt. 

 SQLPLUS  "SYS/<Passwort> as SYSDBA"
 STARTUP

Ausgabe: 

 ORA-01110: Datendatei 3: c:\ORACLE\ORADATE\ORCL\USERTS.DBF'

Die Datenbank konnte nicht geöffnet werden. Sie befindet sich im Status MOUNT 

 ALTER DATABASE DATAFILE 3 OFFLINE;
 ALTER DATABASE OPEN

Nun ist die Datenbank geöffnet. Man kann auf alle Objekte zugreifen, ausser auf die Daten in dem defekten Tablespace.

Nun wird der Name des Tablespace ermittelt, der den Datafile 3 verwendet: 

 SELECT tablespace_name from dba_extents where file_id = 3;

Es handelt sich um den Tablespace "USERS" 

 RECOVER TABLESPACE USERS;

Die Datenbank kann selbständig auf die Daten der Sicherung zugreifen und die fehlende Datei wieder herstellen. Nun ist der Tablespace wieder in Ordnung. 

 ALTER TABLESPACE USERS ONLINE;

Anmerkung: Falls der Tablespace vor einem Jahr angelegt worden ist und die Log-Dateien nicht mehr vorhanden sind für den gesamten Zeitraum dazwischen, dann ist der oben skizzierte Ablauf nicht möglich. Es muss mindestend die Log-Datei vorhanden sein, die das Anlegen des Tablespace protokolliert und alle zeitlich nachfolgenden Log-Dateien.

Recover Beispiel 2

[Bearbeiten]

Es wurde eine Datei, gelöscht, in der die Daten eines Tablespace mit Anwendungstabellen gespeichert waren. Es steht eine Offline-Sicherung zur Verfügung und alle Log-Dateien seit der letzten Offline-Sicherung stehen auch zur Verfügung.

Dann kann man die betroffene Daten-Datei von der Offline-Sicherung kopieren und anschließend die Datenbank wieder hochfahren. Die Meldungen des STARTUP Befehls und des anschließenden Recover sind in dem nachfolgenden Script wiedergegeben: 

 SQL> startup
 ORACLE-Instanz hochgefahren.
 ...
 Datenbank mit MOUNT angeschlossen.
 ORA-01113: Fur Datei '1' ist Datenträger-Recovery notwendig
 ORA-01110: Datendatei 1: 'C:\ORACLE\ORADATA\ORA1G\SYSTEM01.DBF'

 SQL> recover
 Wiederherstellung des Datenträgers abgeschlossen.

 SQL> alter database open;
 Datenbank wurde geändert.
Abgerufen von „https://de.wikibooks.org/w/index.php?title=Oracle:_Backup_und_Recover&oldid=953755“