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

Get Oracle 12c - Das umfassende Handbuch now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.