Erschienen in der Zeitschrift der Deutschen ORACLE Anwendergruppe "DOAG News", Ausgabe Q3/2003

Die Standby-Datenbank:
Data Guard aus Kundensicht (Teil II)

In der letzten Ausgabe der ORDIX News betrachteten wir die Entwicklung der physikalischen Standby-Datenbank von Oracle 7.3 bis zur Version 8.1. In diesem Beitrag werden wir nun die noch offenen Kundenanforderungen in Verbindung mit den Funktionalitäten des Releases 9.0 näher beleuchten. Wir konzentrieren uns in diesem Artikel auf die händische Darstellung, da die internen Abläufe dadurch deutlich werden. In der Praxis wird üblicherweise das GUI oder das CLI genutzt. Diese werden in einem 3. Teil der Reihe dargestellt.

Als häufig formulierte Kundenanforderungen ließen sich dabei wie folgt zusammenfassen:

1. Backup Konzept
2. Hochverfügbarkeitslösung
3. Möglichkeit des externen Reportings
4. Delay
5. Switch Over

Die mit Oracle 8.1 erfüllbaren 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. Voraussetzung dafür ist ein installiertes Perl auf beiden Rechnern.
• 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.

Noch nicht erfüllbare Anforderungen des Kunden:

• Reporting und Recovery sind auf der Standby-Datenbank nicht parallel möglich.
• Ein Tausch der Funktionalität zwischen Standby-Datenbank und Produktionsdatenbank (Switch Over) ist ebenfalls nicht möglich.
• Auch das Desaster Recovery hat mit dem potentiellen Verlust der aktuellen (current) Log Datei noch einen Schwachpunkt.

Darüber hinaus gibt es noch weitere Schwierigkeiten:

• Neue Datenbank Dateien auf dem Produktionssystem führen zu Fehlern beim Recovery der Standby-Datenbank. Dazu gibt es jedoch einen Workaround: Die neue Datenbank-Datei wird zunächst der Standby-Datenbank hinzugefügt und danach der Produktionsdatenbank.
• Nach einem Netzausfall setzt das Recovery der managed Standby-Datenbank nicht selbstständig wieder auf. In einem solchen Fall muss man die RedoLog Dateien, die während des Netzausfalls anfielen, mit Betriebssystem-Mitteln auf das Standby System übertragen. Anschließend startet man das automatische Recovery neu.

Im Folgenden betrachten wir nun die oben genannten Punkte in Verbindung mit den Funktionalitäten des Releases 9.0.

Physical Data Guard

Mit der Version 9.0 hat Oracle das Konzept der physikalischen Standby-Datenbank entscheidend weiterentwickelt. Es sind neue Funktionalitäten hinzugekommen, die dem Datenbankadministrator den Aufbau und die Verwaltung eines solchen Systems deutlich vereinfachen.

Der Name dieses Systems wurde umbenannt und heißt jetzt PHYSICAL DATA GUARD.

Auf dem Standby System kommen zusätzlich einige neue Prozesse hinzu:

• Remote File Server Process (RFS):
  Der RFS empfängt die RedoLog Dateien vom Produktionssystem.
• Managed Recovery Process (MRP):
  Der MRP sorgt für das Recovery der Redo-Informationen.

Abb. 1 zeigt den grundsätzlichen Ablauf mit Oracle 9.0 unter Nutzung des Archive Prozesses.

Abb. 1: Grundsätzlicher Ablauf mit Version 9.0 unter Nutzung des Archive Prozesses.

Neu hinzugekommene Funktionen:

1. Unterbrechungen der Übertragung erkennen

Es ist möglich, Unterbrechungen der Übertragung zu erkennen und die fehlenden RedoLog Dateien automatisch nachzuziehen. Die dazu notwendigen init.ora Parameter werden ausschließlich in die Parameter-Datei der Standby-Datenbank eingetragen:

FAL_CLIENT=<Standby tns alias>
FAL_SERVER=<Produktions tns alias>

Weiterhin muss die tnsnames.ora des Standby Systems entsprechend erweitert werden, um beide Alias-Namen auflösen zu können.

2. Automatische Änderungen der physikalischen Struktur

Änderungen der physikalischen Struktur mussten bisher auf dem Standby System von Hand nachgezogen werden. Dies kann jetzt automatisch geschehen.

Dazu ist in beiden init.ora Dateien der Eintrag standby_file_management=auto notwendig.

3. Zeitverzögertes Einspielen der RedoLog Dateien

Durch den Eintrag von log_archive_dest_n =´Services= delay = m´ in die init.ora der Produktionsdatenbank ist ein zeitverzögertes Einspielen der RedoLog Dateien möglich. Die Dateien werden sofort auf das Standby System übertragen. Beim Recovery wird jedoch das angegebene Intervall abgewartet.

Die auf der Produktionsseite eingestellte Verzögerung lässt sich auf der Standby-Datenbank durch das folgende Kommando übersteuern, damit man im Fall der Produktionsübernahme nicht länger als unbedingt notwendig warten muss: recover managed standby database nodelay;

4. Recovery Prozess im Hintergrund

Mit Oracle 8i war es notwendig, ein SQLPLUS Fenster offen zu halten, da das recover Kommando den Prompt nicht zurückgab. Mit Oracle 9i ist es nun möglich, den Recovery Prozess in den “Hintergrund“ zu legen, indem das Recovery mit recover managed standby database disconnect; gestartet wird. Das Schlüsselwort disconnect sorgt dafür, dass nach Beginn des Recoverys das SQLPLUS Prompt zurückkommt. Danach kann man SQL-PLUS mit exit verlassen. Abbrechen lässt sich das Recovery mit dem Kommando recover managed standby database cancel;

5. Möglichkeit des Datenverlusts gebannt

Bis einschließlich Version 8i besteht grundsätzlich die Möglichkeit, dass die Transaktionen, die in der aktuellen RedoLog Datei protokolliert werden, im Katastrophenfall verloren gehen. Werden die RedoLog Informationen jedoch nicht erst nach dem Logswitch vom Archive Prozess zum Standby System transportiert, sondern bereits vom Logwriter auf das Standby System geschrieben, verringert sich die Menge der verlorenen Transaktionen bei einem plötzlichen Systemausfall des Produktionssystems. Im Idealfall gehen keine Transaktionen verloren.

Für das Aufsetzen dieser Variante ist auf der Produktionsseite nicht viel mehr zu tun. Lediglich der bisherige Eintrag bezüglich des zweiten Log Pfades muss angepasst werden: LOG_ARCHIVE_DEST_n = ‘SERVICE=<tns_alias> LGWR SYNC

Auf dem Standby System sind mittels des Kommandos ALTER DATABASE ADD STANDBY LOGFILE ´...´ SIZE n [K|M]; Standby Log Dateien anzulegen. Werden auf der Produktionsdatenbank nur RedoLog Dateien gleicher Größe verwendet, so ist es zwar technisch ausreichend, auf dem Standby System zwei Gruppen mit eben dieser Größe anzulegen, besser ist jedoch, mindestens eine gleich große Anzahl an Standby RedoLog Gruppen vorzusehen. Abhängig ist dies in erster Linie von der Fähigkeit des Standby Systems, Lastspitzen abzufangen. Sind die Produktionsgruppen jedoch alle unterschiedlich groß, so ist für jede Gruppe eine entsprechend große Standby Log Gruppe anzulegen.

Weiterhin ist zu beachten, dass auch auf dem Standby System der ARCn Prozess gestartet wird sowie in der init.ora eine Archive Log Destination und ein Archive Log Format gesetzt werden. Das ist notwendig, damit die Standby RedoLog Dateien archiviert werden können. Den Ablauf mit 9.0 und LGWR zeigt Abb. 2.

Abb. 2: Ablauf mit 9.0 und LGWR.

Die Option SYNC für den LGWR sollte jedoch nur dann gewählt werden, wenn die zur Verfügung stehende Bandbreite und das Standby System ausreichend dimensioniert sind. Sonst wird die Produktion künstlich ausgebremst, denn nach dem commit durch den Anwender kommt der Prompt erst dann zurück, wenn der LGWR geschrieben hat.

Bei Netzausfällen führt dies jedoch nicht zu einem vollständigen Stillstand der Produktion. In die alert.log werden entsprechende Vermerke geschrieben und es kommt zu einem kurzzeitigen “Hängen“ der Datenbank. Das System schaltet dann selbstständig auf lediglich lokales Schreiben um. Steht das Netz wieder zur Verfügung, so werden die archivierten RedoLog Dateien mittels Archive Prozess (FAL) zum Standby System transportiert und der Logwriter schreibt wieder auf das Standby System.

Bei nicht ausreichender Bandbreite und/oder ausreichender Rechenleistung des Standby Systems kann der LGWR auch mit dem Parameter ASYNC betrieben werden. Zusätzlich wird ein Puffer definiert. Dabei schreibt der LGWR nicht direkt in die Standby RedoLog Dateien, sondern die Schreiboperationen werden auf dem Produktionssystem gepuffert, je nach Bandbreite bzw. Last auf dem Standby System.

6. Graceful Switchover

Die letzte Neuerung mit Version 9.0 ist der sogenannte “Graceful Switchover“. Dies bedeutet, dass Produktions- und Standby-Datenbank mit wenigen Kommandos ihre Rollen tauschen können. Bis einschließlich 8.1 bedeutet eine Übernahme der Produktion durch das Standby System, dass die Datenbank auf dem Produktionssystem wertlos ist.

Voraussetzung für das problemlose Um- und wieder Zurückschalten zwischen den Datenbanken sind

• eine angepasste Oracle Net Konfiguration und
• vorbereitete Parameter Dateien (init.ora)

Bei den in Abb. 3 gezeigten Ausschnitten aus den init.ora Dateien einer Produktions- und der zugehörigen Standby-Datenbank ist die Zeile für die zweite Archive Destination auf dem Standby System auskommentiert. Das ist im Falle des Switchover entsprechend anzupassen.

Ist der betreuende DBA tolerant gegenüber Fehlermeldungen, so ist das Auskommentieren dieser Zeile nicht zwingend notwendig.

Insgesamt eine Hilfe für den DBA

Die mit der Version 9.0 eingeführten Neuerungen erleichtern den Betrieb einer physikalischen Standby-Datenbank erheblich. Neue Dateien werden automatisch in die Standby-Datenbank eingepflegt, das Wiederaufsetzen nach Netzausfällen geschieht selbstständig und zu Wartungszwecken lässt sich die Produktion kurzfristig auf das Standby System umschalten.

Abb. 3: Auszüge aus zwei init.ora Dateien für Produktion und Standby.

Um logische Fehler abzufangen, kann die Standby-Datenbank einen definierten Zeitraum hinter dem Produktionssystem hereilen.

Damit sind beinahe alle anfangs definierten Anforderungen erreicht:

• Das Offline Backup über die Standby-Datenbank ist möglich.
• Eine zeitverzögerte Einspielung (Delay) der archivierten RedoLog Dateien ist ohne großen Aufwand möglich.
• Das Desaster Recovery ist möglich: Das Wiederherstellen eines komplett zerstörten Systems ist über das Standby System realisierbar. Es muss lediglich eine gewisse Zeitverzögerung in Kauf genommen werden. Auch das Risiko des potentiellen Verlusts der aktuellen (current) Log Datei ist nur noch als minimal einzustufen.
• Die Datenbank kann im Read-Only Modus geöffnet werden. Es können also Reportings stattfinden, allerdings nicht bei gleichzeitigem Recovery.
• Ein Tausch der Funktionalität zwischen Standby-Datenbank und Produktionsdatenbank (Switch Over) ist möglich.

Abb. 4: Auszug aus der alert Datei.

Die einzige noch nicht erreichte Anforderung ist das gleichzeitige Lesen und Recovery. Dieses Ziel lässt sich mit Oracle 9.2 umsetzen. Da es sich hierbei um ein vollständig neues Konzept handelt, dessen Darstellung den Rahmen dieses Artikels sprengen würde, werden wir dies in einer kommenden Ausgabe näher beleuchten. Weiterhin werden wir auf das GUI und das CLI des DataGuard Broker eingehen.

Welche Funktionalitäten sind nun Bestandteil der Standard Edition und welche sind Bestandteil der Enterprise Edition? Zusammenfassend lässt sich sagen, dass sämtliche Funktionalitäten, die mit 8i und 9i neu hinzugekommen sind, die Enterprise Edition benötigen.

Andreas Kother (info@ordix.de).