Neues bei Oracle: 10gR2 (Teil II)

Data Guard: Oracle goes Cluster

Oracle Data Guard ist eine im Oracle Umfeld etablierte teilautomatisierte Lösung zur Herstellung einer hochverfügbaren Umgebung, die von vielen Kunden bereits eingesetzt wird. Um die Akzeptanz zu erhöhen, bietet Oracle mit dem Release 10gR2 die Möglichkeit der vollständigen Automatisierung an. Diese wollen wir im Folgenden genauer betrachten.

Historisches

Seit Oracle 9.0 hat uns jedes Release neue, wichtige Features beschert. Einige Features aus dem Bereich Verfügbarkeit möchten wir hier noch einmal aufführen:

Alles nützliche Dinge, die Schritt für Schritt in Richtung einer automatischen Übernahme der Produktion durch eine physikalische Standby-Datenbank führen. Genau das hat Oracle mit 10gR2 realisiert. Das neue Feature heißt "Fast Start Failover".

Wir wollen das Thema in zwei Schritten angehen. Im ersten betrachten wir das Konzept und im zweiten werden wir eine Bewertung vornehmen.

Fast Start Failover: Idee

Bei einem Ausfall der Produktionsdatenbank oder des Netzwerks führt Data Guard automatisch einen Failover zu einer vorher de finierten Standby-Datenbank durch. Dies geschieht ohne manuelle Eingriffe.

Konzept

Die Umsetzung von Fast Start Failover zeigen die Abbildungen 1 bis 3.

In Abbildung 1 ist die Situation vor dem Fast Start Failover dargestellt. Die Redo Log Daten werden von der Produktionsdatenbank zur Standby Seite übertragen. Der Observer hat Kontakt zu den beteiligten Datenbanken.

Abbildung 2 zeigt die Failover-Situation. Der Observer hat keinen Kontakt mehr zur Produktionsseite. Die Standby-Seite wird produktiv.

Nach der Beseitigung der Störung bekommt der Observer wieder Kontakt zur alten Produktionsdatenbank. Die Datenbank wird automatisch zur Standby-Datenbank gemacht (siehe Abbildung 3).

Voraussetzungen

Fast Start Failover funktioniert natürlich nicht von selbst. Um es einsetzen zu können, fällt zunächst einiges an Konfigurationsarbeiten an.

Flashback

Auf beiden Datenbanken muss Flashback Database eingeschaltet sein. Dabei reicht es aus, den Parameter DB_FLASHBACK_RETENTION_TARGET auf einen Wert von 10 Minuten zu stellen, um die Fast Start Failover Funktionalität sicherzustellen.

Lautet die Anforderung an die Konfiguration Fast Start Failover und Point in Time Recovery gleichzeitig, so ist DB_FLASHBACK_RETENTION_TARGET natürlich größer zu wählen.

Real Time Apply

Auch wenn es keine zwingende Voraussetzung ist, so empfiehlt es sich im Sinne einer schnelleren Übernahme, Real Time Apply einzuschalten, um jegliche Verzögerung durch ein eventuell notwendiges Recovery zu vermeiden.

Broker-Konfiguration

Natürlich müssen die Datenbanken Bestandteil einer Data Guard Broker Konfiguration sein. Damit der Failover möglichst verlustfrei funktioniert, ist dafür die Variante Maximum Availability zu wählen. Damit ist garantiert, dass die synchrone Übertragung der Redo Log Informationen per Logwriter-Prozess der Standard ist.

Observer

Auf dem Server, der die Observer-Funktion übernehmen soll, muss selbstverständlich ebenfalls die Oracle Software installiert werden.

Erfolgt die Administration ausschließlich über das Kommandozeilen-Werkzeug DGMGRL, so reicht es, bei der Installation die Variante Administrator Client Kit zu installieren. Bei Nutzung von Grid Control muss das gesamte Oracle Software Paket installiert werden.

Natürlich ist auch Oracle Net auf dem Observer vollständig zu konfigurieren, damit der Observer Kontakt zu den beteiligten Datenbanken aufnehmen kann.

Konfiguration

Letztlich bleiben vier Dinge zu tun:

1. FastStartFailoverTarget: Das ist diejenige Standby-Datenbank innerhalb der Konfiguration, auf die umgeschaltet werden soll (nur notwendig bei mehr als einer Standby-Datenbank innerhalb der Konfiguration):
   DGMGRL> EDIT DATABASE 'ordixprod' SET PROPERTY FastStartFailoverTarget 'ordixstdby1';
   DGMGRL> EDIT DATABASE 'ordixstdby1' SET PROPERTY FastStartFailoverTarget 'ordixprod';
2. FastStartFailoverThreshold: Nach welcher Zeit (in Sekunden) erfolgloser Kontaktversuche soll umgeschaltet werden:
   DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 45;
3. Aktivierung des Fast Start Failovers:
   DGMGRL> ENABLE FAST_START FAILOVER;
4. Starten des Observers:
   DGMGRL> START OBSERVER;

Wird der Observer nicht sofort nach dem Aktivieren des Fast Start Failovers gestartet, erhalten wir die folgende Fehlermeldung:

Ereignisse, die einen Fast Start Failover auslösen

Bei folgenden Ereignissen wird ein Fast Start Failover ausgelöst:

• Instanzfehler: betrifft bei RAC nur die letzte Instanz
• Shutdown abort: Shutdown immediate, transactional oder normal lösen keinen Fast Start Failover aus
• Offline setzen von Datenbankdateien aufgrund von I/O-Fehlern
• Sowohl der Observer, als auch die Standby-Datenbank verlieren den Kontakt zur Produktionsdatenbank. Zusätzlich bestätigt die Standby-Datenbank, dass sie synchronisiert ist.

Fazit

Bisher (10gR1) war ein Failover immer mit anschließender Handarbeit verbunden und daher keine echte Option für eine automatisierte Lösung. Fast Start Failover erweitert jedoch die bisherigen Data Guard Funktionalitäten in Richtung Betriebssystem Cluster- Ersatz. Die alte Produktionsdatenbank wird nach einem Failover automatisch zur neuen Standby-Datenbank. Damit ist es möglich, mit Data Guard echte 7x24-Konfigurationen zu bauen. Ohne Cluster Know-how und ausschließlich mit dem Datenbankadministrator bekannten Mitteln.

Und das Ganze mit einem echten Mehrwert. Betriebssystem-Cluster oder RAC stellen eine mehr oder weniger hochverfügbare Instanz zur Verfügung. Mit Data Guard Fast Start Failover erhalten wir aber eine 7x24-Lösung für die Datenbank.

Sie wollen mehr über Data Guard und Fast Start Failover erfahren? Es selbst testen? Besuchen Sie unseren viertägigen Data Guard Workshop in Wiesbaden.
Detaillierte Seminarinhalte und -termine finden Sie in unserem Trainingsshop unter http://training.ordix.de. Schauen Sie mal rein!

Andreas Kother (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen