Oracle 12c - Das umfassende Handbuch

Kapitel 27

Data Guard

632

Data Guard besteht aus den folgenden Diensten:

쐽 Redo Transport Service

쐽 Apply Service

쐽 Role Management Service

Der Redo Transport Service kontrolliert die Übertragung von Redo Log-Informatio-

nen von der Primärdatenbank auf die Standby-Datenbanken. Er erkennt entstan-

dene Lücken und versucht, diese automatisch zu schließen.

Der Apply Service steuert das Einarbeiten der übertragenen Redo-Daten in die

Standby-Datenbanken. Im Fall einer Physical Standby-Datenbank führt der Apply

Service ein Recovery der Standby-Datenbank durch. Für eine Logical Standby-

Datenbank erfolgt die Umwandlung in SQL-Anweisungen.

Aufgabe des Role Management Service ist es, die Rollen der Datenbanken in einer

Data Guard-Architektur zu ändern und zu verwalten. Ein Rollenwechsel kann auf

zwei verschiedene Arten erfolgen:

쐽 Failover: Die Primärdatenbank fällt infolge eines Fehlers aus, und die Standby-

Datenbank wird für die Applikationen geöffnet.

쐽 Switchover: Es erfolgt ein Rollentausch zwischen Primär- und Standby-Daten-

bank.

Der Data Guard Broker ist ein verteiltes Framework zur automatischen Verwaltung

und Überwachung von Data Guard-Konfigurationen. Die Verwendung des Bro-

kers ist optional, jedoch bietet er eine erweiterte Funktionalität sowie eine verein-

fachte Administration. Die Bedienung kann über das Kommandozeilen-Utility

DGMGRL oder den Enterprise Manager erfolgen.

Seit der Version 10g kann mit Einsatz des Data Guard Broker ein Fast Start Failover

durchgeführt werden. Das Failover erfolgt automatisch ohne manuellen Eingriff.

Dabei kommt ein dritter Server zum Einsatz, auf dem der Observer läuft. Verlieren

sowohl die Standby-Datenbank als auch der Observer den Kontakt zur Primärda-

tenbank, wird das Failover eingeleitet. Seit Oracle 11g ist Fast Start Failover auch im

Maximum Performance-Modus möglich.

27.2 Physical Standby-Datenbanken

Dieser Abschnitt beschreibt an einem Beispiel, wie eine Data Guard-Architektur

mit einer Physical Standby-Datenbank erstellt, konfiguriert und verwaltet werden

kann. Sie lernen die Implementierung der verschiedenen Modi und Optionen

kennen.

27.2

Physical Standby-Datenbanken

633

Am Anfang stellt sich die Frage, welcher Modus verwendet werden soll. Zwar bietet

der Maximum Protection-Modus den Vorteil, dass kein Datenverlust entsteht.

Allerdings müssen hier die Einflüsse auf Performance und Verfügbarkeit der Pri-

märdatenbank beachtet werden. Die Wahl des Modus ist abhängig von den Anfor-

derungen, die von der Applikation und vom Business gestellt werden. Eine

mögliche Verschlechterung der Applikations-Performance wird sehr selten akzep-

tiert, insbesondere nicht bei OLTP-Systemen und Online-Applikationen. Die in

Abbildung 27.1 dargestellte Architektur verwendet den Maximum Performance-

Modus und den Logwriter-Prozess zum asynchronen Transfer der Redo Log-Daten.

Abb. 27.1: Die Data Guard-Architektur mit Physical Standby

Tipp

Das vorliegende Beispiel beschreibt die Implementierung einer Standby-Daten-

bank auf einem separaten Server. Falls Ihnen nur ein Rechner zum Testen zur

Verfügung steht, können Sie das Beispiel trotzdem nachvollziehen. Sie müssen

nur sicherstellen, dass die Standby-Datenbank einen anderen Instanznamen

und andere Verzeichnisnamen erhält. Entsprechende Hinweise finden Sie in

den betreffenden Schritten.

Kapitel 27

Data Guard

634

Der Maximum Performance-Modus garantiert, dass der Einfluss auf die Perfor-

mance der Primärdatenbank minimal oder nicht nachweisbar ist. Wird in der

Applikation eine COMMIT-Anweisung abgeschickt, dann wird diese sofort nach

Einarbeitung der Transaktion in die lokalen Online Redo Log-Dateien bestätigt.

Bei Verwendung der Archiver-Prozesse zur Übertragung der Redo Log-Daten ent-

stünde eine zu große Differenz zwischen Primär- und Standby-Server. In diesem

Fall erfolgt die Übertragung erst mit der Archivierung einer Online Redo Log-

Datei. Aus diesem Grund empfiehlt sich die Verwendung des Logwriter-Prozesses.

Solange keine Netzwerkprobleme bestehen, findet ein nahezu zeitgleicher Trans-

fer auf den Standby-Server statt. Die Übertragung wird dabei nicht vom Logwriter-

Prozess selbst, sondern vom LNS-Prozess vorgenommen. LNS steht für Logwriter

Network Server. Der Logwriter füllt einen Puffer, der vom LNS ausgelesen wird. Für

langsame Netzwerke oder solche mit stark schwankenden Durchsatzwerten kann

der Puffer entsprechend groß konfiguriert werden. Auf dem Standby-Server

nimmt der Remote File Server-Prozess (RFS) die Redo Log-Daten in Empfang und

schreibt sie in die Standby Redo Log-Dateien. Diese wiederum werden vom Archi-

ver-Prozess (ARC) in Archived Redo Log-Dateien gesichert. Der Managed Recovery-

Prozess (MRP) liest die Archived Redo Log-Dateien und führt ein Recovery der

Standby-Datenbank durch. Eine besondere Rolle kommt den FAL-Prozessen zu.

FAL steht dabei für Fetch Archive Log. Der MRP-Prozess aktiviert den FAL, sobald

eine Lücke in den Archived Redo Log-Dateien, ein sogenanntes Archive Gap,

erkannt wird. Der FAL-Client fordert daraufhin die fehlenden Archived Redo Log-

Dateien vom FAL-Server an. Sind diese noch auf der Primärseite verfügbar, wer-

den sie übertragen, und die Lücke wird nachträglich geschlossen. Sie können die

erwähnten Prozesse in der Liste Datenbankhintergrundprozesse wiederfinden.

Für das Erstellen einer Data Guard-Konfiguration gibt es verschiedene Vorgehens-

weisen. Die einfachste ist, im Enterprise Manager auf die Schaltfläche Add

Standby Database zu klicken. Möglicherweise schafft es der Enterprise Manager,

die Standby-Datenbank zu erstellen und die Synchronisation zu starten. Aller-

dings erfahren Sie bei dieser Methode nicht, was in Hintergrund passiert und wel-

che Konfigurationen vorgenommen wurden. Im vorliegenden Beispiel werden wir

die Standby-Datenbank schrittweise aufsetzen und später vom Data Guard Broker

verwalten lassen. Der gesamte Prozess erfolgt ohne Unterbrechung des Betriebs

und ohne Auswirkungen auf die Performance der Primärdatenbank. Vorausset-

zung ist, dass die Datenbank im Archivelog-Modus läuft. Zum Erstellen der

Standby-Datenbank sind folgende Schritte erforderlich:

1. Vorbereitung der Primärdatenbank

2. Vorbereitung für die Standby-Datenbank

3. Kopieren der Primärdatenbank

4. Aktivierung von Data Guard

5. Überwachung der Physical Standby-Datenbank