Backup und Recovery mit Oracle 10g (Teil I):

Alles neu macht 10g:
Backup und Recovery mit Oracle 10g

In dieser Ausgabe der ORDIX News wollen wir uns mit allgemeinen Erweiterungen bei Backup und Recovery mit Oracle 10g beschäftigen.

Automatisches Starten des Archive Prozesses

In den Oracle Releases bis einschließlich Oracle 9.2 waren für das ordnungsgemäße Funktionieren des Archivelog Modes zwei Schritte notwendig:

• Den Parameter log_archive_start = true in der Parameter-Datei setzen
• In der Mount Phase einmalig die Betriebsart der Datenbank umschalten:
  alter database archivelog;

Mit Oracle 10g ist der Parameter log_archive_start nicht mehr notwendig. Die ARCn Prozesse werden automatisch beim Öffnen (alter database open) gestartet, wenn sich die Datenbank in der Betriebsart Archivelog befindet. Wird der Parameter noch verwendet, wird eine Warnung ausgegeben (ORA-32004 - obsolete and/or deprecated parameter(s) specified).

Full DB begin backup

Seit Oracle 9i gibt es das Kommando
alter database end backup;

Zur Vervollständigung gibt es jetzt das Kommando
alter database begin backup;

Beide Kommados zusammen erleichtern das Erstellen von Backup Skripten, mit denen über Plattenspiegelung gesichert wird (Proxy Copies).

Alle nicht vorhandenen, read only bzw. offline gesetzten Dateien werden übersprungen. Es wird keine Fehlermeldung ausgegeben!

In der View v$backup stehen read only Dateien auf NOT ACTIVE. Dateien, die nicht vorhanden sind bzw. offline gesetzt sind, werden in der View v$backup nicht gelistet.

Der init.ora Parameter ARCHIVE_LOG_FORMAT

Das Format der Dateinamen für die archivierten Redo Log Dateien hat sich geändert. Bisher gab es, außer bei OPS- oder RAC Systemen, nur die Sequenznummer, die in den Namen der Archivdatei eingebaut sein sollte. Mit Oracle 10g gibt es ein Mindest-Format für die Dateinamen der archivierten Redo Log Dateien: log_archive_format=%t_%r_%s

Dabei haben %t und %s ihre bisherige Bedeutung behalten:

• %t für den Thread (Instance-Nummer)
• %s für die Sequenznummer

Der Parameter %r steht für die neu hinzugekommene Resetlognummer. Optional lässt sich noch der Parameter %a für die jeweils neu vergebene Activation-Id hinzufügen. Die Verwendung von %a empfiehlt sich allerdings nicht, wie wir noch zeigen werden. Hier stellt sich natürlich die Frage, wozu die zusätzliche Information benötigt wird.

Recovery durch Resetlogs

Mit den Releases vor 10g war es nach dem Öffnen der Datenbank mit der Option resetlogs zwingend erforderlich, ein vollständiges Backup der Datenbank zu erstellen, da eine neue Inkarnation der Datenbank erstellt wurde. Eine Inkarnation ist eine neue (interne) Version.

Mit Oracle 10g ist dies nicht mehr erforderlich. Hier wurde ein Mechanismus integriert, der ein Recovery durch ein Resetlogs hindurch ermöglicht (Erweiterung des Parameters log_archive_format durch %r).

Ein Recovery mit einem alten Backup einer mit open resetlogs geöffneten Datenbank stellt sich nun folgendermaßen dar:

• Einspielen der defekten Datenbank-Datei bzw. der defekten Datenbank-Dateien
• recover database;
• Danach kann auto eingegeben werden.
• Das Recovery der Datenbank läuft automatisch bis zur current Redo Log Datei. Bei Bedarf auch durch mehr als ein Resetlogs.
• Ist allerdings im Namen der Archive %a verwendet, so muss jede einzelne Archivdatei namentlich eingegeben werden. Der Parameter %a wird jeweils mit 0 vorbelegt.

Transportable Tablespaces

Transportable Tablespaces können nun zwischen verschiedenen Plattformen ausgetauscht werden. Das ist auch dann möglich, wenn Quell- und Zielsystem unterschiedliche Byte-Ordnungen aufweisen (endian ordering). Die Datenkonvertierung von Little-Endian in Big-Endian und umgekehrt wird mit Hilfe vom RMAN durchgeführt. Dazu müssen die betreffenden Tablespaces zuvor auf read only gesetzt werden. Ein Beispiel für diesen Vorgang finden Sie in Abbildung 1.

Abb. 1: Beispiel für die Konvertierung eines Tablespaces auf eine andere Plattform (vergrößern!).

Wird als Ziel kein absoluter Pfad angegeben, so wird die konvertierte Datei in der Flash Recovery Area abgelegt (default $ORACLE_HOME/dbs). Mit dem Thema Flash Recovery werden wir uns in der nächsten Ausgabe beschäftigen.

Einschränkungen:

• Die beteiligten Datenbanken müssen über den Parameter COMPATIBLE >=10.0 verfügen.
• Die Tablespaces müssen einmal read writ geöffnet worden sein.

Die View v$transportable_platform liefert eine Übersicht der Plattformnamen und des Datenformates (siehe Abbildung 2).

Abb. 2: Auflistung der unterstützten Plattformen in der View V$TRANSPORTABLE_PLATFORM (vergrößern!).

Fazit

Von den hier beschriebenen Neuerungen im Backup und Recovery Umfeld erscheinen das Recovery mit einem alten Backup durch eine Resetlogssituation und das Kopieren von Tablespaces über unterschiedliche Betriebssysteme als interessante Optionen.

Ersteres ermöglicht eine sofortige Inbetriebnahme einer Datenbank nach einem unvollständigen Recovery ohne vorheriges Backup, welches je nach Datenmenge und Verfügbarkeitsansprüchen eine erhebliche Verbesserung darstellt.

Der zweite Punkt vereinfacht z. B. das Zusammenführen mehrerer kleiner Datenbanken, die auf unterschiedlichen Betriebssystemen laufen, zu einer größeren Datenbank.

In den nächsten Ausgaben werden wir uns mit der Flash Recovery Area, dem Recovery Manager und den Neuigkeiten im Data Guard Umfeld beschäftigen.

Andreas Kother (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen