Die Standby-Datenbank:
Data Guard aus Kundensicht

Standby-Datenbanken wurden mit der Version 7.3 eingeführt. Mit der Version 9.0 wurde die Standby Datenbank namentlich in "Data Guard" umgetauft und mit 9.2 kam die Funktionalität des Logical Data Guard hinzu. Hiermit wird eine grundsätzlich neue Philosophie vertreten und die Betrachtung der Kundenanforderungen muss unter neuen Gesichtspunkten erfolgen. In einer zweiteiligen Artikelreihe beschreiben wir Einsatz, Vorgehen und Nutzen von Standby Datenbanken.

Erschienen in der Zeitschrift der Deutschen Oracle-Anwendergruppe "DOAG News", Ausgabe Q2/2003

In vielen Projekten stehen wir vor der Frage, ob sich der Einsatz einer Standby-Datenbank lohnt, denn der Einsatz erfolgt sinnvollerweise nur mit zusätzlicher Hardware. Viele Kunden haben darüber hinaus spezielle Anforderungen, die unter den Stichworten Backup, Hochverfügbarkeit (Switch Over), produktive, parallele Nutzung der Standby Datenbank und schnelles Recovery nach logischen Fehlern zusammengefasst werden können.

1. Backup Konzept: Hiermit ist eine Nutzung der Standby Datenbank als alternative Backuplösung gemeint, um den Online Betrieb nicht durch zusätzliche Backup-Aktivitäten zu beeinträchtigen. Es gibt Kunden, die über dieses Szenario ihre Sicherung fahren wollen.

2. Hochverfügbarkeitslösung: Nutzung der Standby Datenbank als Hochverfügbarkeitslösung anstelle eines Einsatzes von OPS/RAC.

3. Möglichkeit eines externen Reportings: Wenn schon eine Kopie der Datenbank auf einem fremden Rechner vorhanden ist, so sollte der Datenbestand auch z. B. für Auswertungen genutzt werden können.

4. Delay: Für viele Kunden ist es wichtig, einen zweiten Bestand zu haben, der zeitverzögert hinter dem Originalbestand hinterherläuft. Durch diese Funktionalität sollen logische Fehler schneller abgefangen werden können, also das Point-In-Time-Recovery schneller möglich sein.

5. Switch Over: Der problemlose Tausch des Originalsystems mit dem Standby-System sollte möglichst ohne Downtime erfolgen können.

In diesem Artikel werden nun die einzelnen Releases von Oracle unter dem Aspekt der Erfüllung dieser definierten Forderungen betrachtet; angefangen mit der Version 7.3, über 8.0 und 8.1 zu 9.0 und schließlich zu Version 9.2.

Grundsätzlich gelten für die Standby-Datenbank bzw. Physical Data Guard folgende Voraussetzungen:

• Das Oracle Release muss identisch sein: Auf den beiden beteiligten Maschinen muss inklusive Patchlevel eine identische Oracle-Version installiert sein.
• Die Produktions-Datenbank muss sich im Archivelog Mode befinden: Das Originalsystem muss mit Archivierung laufen, da über die archivierten RedoLog-Dateien in der Standby-Datenbank die Transaktionen nachgefahren werden.
• Die Rechner müssen dieselbe Plattform besitzen, d. h. das Betriebssystem muss nicht identisch sein, aber aus der gleichen "Familie" stammen.
• Idealerweise sind 2 Maschinen im Einsatz: Die Standby-Datenbank sollte auf einer anderen Maschine installiert werden als das Originalsystem. Eine Installation auf derselben Maschine ist theoretisch möglich, aber nicht sinnvoll. Die Plattenkapazität sollte nahezu identisch sein, der CPU-Ausbau kann differieren.

Version 7.3/8.0

In der Oracle-Version 7.3 wurde erstmals die Standby-Datenbank eingeführt, in der Version 8.0 funktional aber nur ein wenig erweitert.

Abb. 1: Installation und Ablauf einer Standby-Datenbank in Version 7.3/8.0.

Um eine solche Standby-Datenbank aufzusetzen, muss man folgendermaßen vorgehen:

1. Backup einspielen: Auf dem Standby-Server wird eine Kopie der Produktions-Datenbank eingespielt. Hierbei kann es sich um ein Offline- oder ein Onlinebackup handeln. Eingespielt werden alle Data Files des Originalsystems.

2. Init.ora kopieren: Die init.ora kann ohne Veränderung auf das Standby-System übertragen werden.

3. Standby Controlfiles erzeugen: Für das Standby-System müssen aus dem Original heraus Standby Controlfiles erzeugt und anschließend zum Standby-Server übertragen werden.

alter database create standby controlfile as ‘...‘;

Diese erzeugte Datei wird auf der Standby-Seite an alle Stellen übertragen, auf die in der init.ora verwiesen wird.

4. Instance starten: Die Instance (Standby) wird in die NOMOUNT-Phase gebracht und die Standby-Datenbank wird anschließend gemountet.

startup nomount;
alter database mount standby database;

Die Grundfunktionalität ist somit installiert. Nun müssen die archivierten RedoLog-Dateien das vollständig übertragen und eingespielt werden:

• Transport der archivierten RedoLog-Dateien mit Betriebssystem-Mitteln
  Wurde eine archivierte RedoLog-Datei vom ARCH-Prozess vollständig geschrieben, kann die Datei auf das Standby-System übertragen werden. Hierzu ist es notwendig, festzustellen, wann diese Datei vorhanden und vollständig ist. Über eine Übertragungssoftware, wie ftp, rcp oder scp kann die Datei dann zum Standby-System übertragen werden. Beide Schritte lassen sich z. B. durch Skripte realisieren.

• Einspielen der archivierten RedoLog-Dateien im Standby System
  Das Einspielen der archivierten RedoLog-Dateien in die Standby-Datenbank geschieht über das Kommando

recover standby database;

Dies wird üblicherweise auch über ein Skript realisiert.

Entscheidet der Administrator, dass die Standby-Datenbank die Funktionalität des Originalsystems übernehmen soll, muss folgendes Verfahren angewendet werden:

1. RedoLogs nachfahren
Kopieren und Nachfahren aller noch nicht übertragenen und eingespielten, archivierten RedoLog-Dateien und Online RedoLog-Dateien in die Standby-Datenbank. Soweit möglich und soweit gewollt, wird dies vollzogen.

2. Aktivieren der Standby-Datenbank
Die Standby-Datenbank wird zur Original-Datenbank. Das geschieht mit dem Kommando

alter database activate standby database;

3. Herunterfahren der Standby-Datenbank
Die Datenbank wird heruntergefahren und kann dann als normale Datenbank neu gestartet werden.

4. Backup der neuen Produktions-Datenbank
Vor Produktionsübergabe ist ein neues Backup zwingend erforderlich, da nach einem eventuellen Crash vor einem Backup keine Basis für ein Recovery vorhanden ist.

5. Hochfahren der neuen Produktions-Datenbank
Die Datenbank kann jetzt für die Anwender wieder geöffnet werden. Es muss jedoch eine Planung vorliegen, wie die Clients möglichst problemlos das neue System finden. Hier gibt es diverse Möglichkeiten:

• Im DNS kann die Adresse der Maschine geändert werden, die Standby-Maschine bekommt den Namen des ehemaligen Original Servers.
• In der tnsnames.ora (Client) kann die Alternativadresse vorkonfiguriert werden.
• Bei Verwendung von Oracle Names oder LDAP kann hierüber der neue Server gefunden werden.

Anschließend muss ein neues Standby-System aufgebaut werden.

Die Überwachung des Standby Systems stellt an den zuständigen Administrator gewisse organisatorische Anforderungen:

Änderungen an der physikalischen Struktur der Datenbank führen zu Fehlern beim Einspielen der archivierten RedoLog-Dateien. Wird auf dem Originalsystem eine neue Datendatei erzeugt, so muss diese zunächst auf dem Standby-System kreiert werden:

alter database create datafile as ‘...‘;

Wird dieser Schritt unterlassen, läuft das Recovery zunächst auf einen Fehler. Das Anlegen muss dann im Nachhinein vollzogen werden.

Welche oben definierten Kundenanforderungen sind nun in dem Release 7.3/8.0 realisiert?

Erfüllbare Kundenanforderungen:

• Ein Offline Backup über die Standby-Datenbank ist möglich.
• Ein zeitverzögertes Einspielen (Delay) der archivierten RedoLog-Dateien ist möglich, da die Dateien skriptgesteuert eingespielt werden.
• Ein Desaster Recovery ist möglich: Das Wiederherstellen eines komplett zerstörten Systems ist über das Standby-System realisierbar. Es müssen lediglich ein eventueller Datenverlust (Current Logfile) und eine gewisse Zeitverzögerung in Kauf genommen werden.

Nicht erfüllbare Kundenanforderungen:

• Es ist kein Reporting auf der Standby-Datenbank möglich. Das System kann nicht zum Lesen geöffnet werden.
• Ein Tausch der Funktionalität zwischen Standby-Datenbank und Original-Datenbank (Switch Over) ist nicht möglich.

Version 8.1

In der Version 8.1 sind einige Modifikationen vorgenommen worden, die den Ablauf teilweise erleichtert haben. Abb. 2 zeigt den grundsätzlichen Ablauf.

Abb. 2: Ablauf in der Version 8.1.

In dieser Version sind zwei grundsätzliche Funktionalitäten hinzugekommen:

Die Übertragung der archivierten RedoLog-Dateien kann direkt über den ARCH Prozess durchgeführt werden.

1.) Dazu sind in der init.ora des Originalsystems folgende Einträge notwendig:

log_archive_dest_1=‘Location=...‘
log_archive_dest_2=
‘Service=<tns_alias>‘

2.) Die Oracle Net Konfiguration vom Produktivsystem zum Standby-System muss vorgenommen werden.

• In der tnsnames.ora des Produktivsystems muss dazu ein tns_alias auf die Standby-Datenbank erstellt werden.
• Die listener.ora auf der Standby-Seite muss konfiguriert werden und
• der Listener auf dem Standby-Server muss gestartet werden.

3.) Die init.ora auf der Standby-Seite muss folgenden zusätzlichen Eintrag erhalten:

standby_archive_dest=...

Weiterhin können die neuen, archivierten RedoLog-Dateien nun automatisiert in die Standby-Datenbank eingespielt werden. Dazu muss folgende Syntax genutzt werden:

recover managed standby database;

Die Überwachung des Standby-Systems stellt an den zuständigen Administrator weitere organisatorische Anforderungen:

1.) Änderungen an der physikalischen Struktur der Datenbank führen weiterhin zu Fehlern. Hier muss manuell eingegriffen werden.

2.) Ist die Übertragungskette einmal unterbrochen, müssen die archivierten, nicht übertragenen RedoLog-Dateien manuell übertragen und eingespielt werden. Erst dann kann die automatisierte Übertragung wieder aufgesetzt werden.

Welche der eingangs definierten Kundenanforderungen sind nun in dem Release 8.1 realisiert?

Erfüllbare Kundenanforderungen:

• Das Offline Backup über die Standby-Datenbank ist möglich.
• Eine zeitverzögerte Einspielung (Delay) der archivierten RedoLog-Dateien ist über ein zusätzlich ausgeliefertes Perlskript möglich.
• Das Desaster Recovery ist möglich: Das Wiederherstellen eines komplett zerstörten Systems ist über das Standby-System realisierbar. Es müssen lediglich ein eventueller Datenverlust (Current Logfile) und eine gewisse Zeitverzögerung in Kauf genommen werden.
• Die Datenbank kann im Read-Only Modus geöffnet werden. Es können also Reportings stattfinden, allerdings nicht bei gleichzeitigem Recovery.

Nicht erfüllbare Kundenanforderungen:

• Reporting und Recovery sind auf der Standby-Datenbank nicht parallel möglich.
• Ein Tausch der Funktionalität zwischen Standby-Datenbank und Original-Datenbank (Switch Over) ist ebenfalls nicht möglich.

In der kommenden Ausgabe werden wir die Funktionalitäten der Releases 9.0 und 9.2 unter den oben definierten Gesichtspunkten näher beleuchten.

Klaus Reimers (info@ordix.de).