Backup und Recovery mit Oracle 10g (Teil III):

Näher am Original: Data Guard

In der letzten Ausgabe der ORDIX News beschäftigten wir uns mit den neuen Flashback Funktionalitäten von Oracle 10g. In dieser Ausgabe wollen wir uns die Neuerungen bei Data Guard anschauen und das Zusammenspiel mit Flashback betrachten.

Oracle Data Guard ist eine Möglichkeit, Hochverfügbarkeit bei Oracle Datenbanken zu realisieren. Der ursprüngliche Ansatz, die sogenannte Standby Datenbank, dient dazu, logische oder physikalische Fehlersituationen abzufangen. Allerdings lassen sich mit einer Oracle Data Guard Konfiguration noch andere Dinge tun, als auf den Ausfall zu warten.

Je nachdem, welche weiteren Anforderungen realisiert werden sollen, bietet sich eine der beiden Data Guard Varianten, Physical oder Logical, an.

Eine physikalische Standby Datenbank ist eine blockgenaue Kopie der Produktions-Datenbank und befindet sich normalerweise ständig im Recovery Modus.

Bei einer logischen Standby Datenbank werden die Änderungen nicht recovert, sondern es werden über LogMiner-Techniken die SQL Statements aus den archivierten Redo Log Dateien extrahiert und als SQL-Anweisung in die Datenbank eingespielt.

Damit wird ein weiterer Unterschied zwischen den beiden Formen des Data Guard deutlich: eine physikalische Standby Datenbank befindet sich üblicherweise im Zustand MOUNT, während eine logische Standby Datenbank sich ständig im Zustand READ_WRITE (OPEN) befindet.

Grundsätzlich werden die beiden Typen unter folgenden Rahmenbedingungen eingesetzt:

Physikalische Standby Datenbank:

• Hochverfügbarkeitsansatz
• Abfangen von logischen Fehlern durch bewusstes zeitversetztes Recovery
• Backup entzerrt vom Primärsystem, somit eine Entlastung
• Reporting - die Datenbank kann lesend geöffnet werden, dann ist allerdings das Recovery unterbrochen

Logische Standby Datenbank:

• Hochverfügbarkeitslösung
• Reporting - die Datenbank ist ständig READ WRITE geöffnet

Real Time Apply

In Oracle 9.x konnten die Redolog Informationen erst in die Standby-Datenbank eingefahren werden, wenn sie in Form archivierter Redo Log Dateien vorlagen, also ein Logswitch stattgefunden hat. Somit hing die Standby-Datenbank mindestens das CURRENT LOG hinterher.

Mit Oracle 10g ist es nun möglich, die Redo Informationen sofort nach ihrem Erhalt auf dem Standby System zu recovern beziehungsweise als Transaktion auszuführen. Diese neue Technik wird als REAL TIME APPLY bezeichnet.

Die Vorteile dieser neuen Technik bestehen in der höheren Aktualität der Daten und in kürzeren Ausfallzeiten während einer Switchover oder Failover Operation.

Den Unterschied zwischen den beiden Techniken verdeutlicht Abbildung 1.

REAL TIME APPLY bietet folgende Vorteile:

Physical Data Guard:
Bei einem Failover oder Switchover geht weniger Zeit verloren, da es weniger zu recovern gibt.

Logical Data Guard:
Beim Reporting stehen aktuellere Daten zur Verfügung.

Flashback

Die bereits in der ORDIX News 1/2005 vorgestellte Flashback Database Funktionalität ist vollständig in das Oracle Data Guard Umfeld integriert.

Bisher erforderte die Anforderung, logische Fehler abzufangen und gleichzeitig im Failover-Fall sofort verfügbar zu sein, den Betrieb von mindestens zwei physikalischen Standby Datenbanken. Eine Datenbank die sofort verfügbar sein soll, darf keinen großen Delay zur Produktions-Datenbank haben.

Genau diesen Delay braucht man jedoch, um logische Fehler abfangen zu können. Dies ist mit Oracle 10g und Flashback Database nicht mehr zwingend erforderlich.

Die Standby Datenbank lässt sich mit nur wenig, oder bei Nutzung von Real Time Apply im optimalen Fall ohne Zeitversatz (Delay) hinter der Produktionsdatenbank betreiben. Damit ist die Anforderung der sofortigen Verfügbarkeit im Fehlerfall erfüllt.

Soll die Produktions-Datenbank aufgrund eines logischen Fehlers zurückgesetzt werden, so ist dies ebenfalls möglich. Dabei wird die Flashback Funktionalität genutzt, um das erneute Anlegen einer Standby Datenbank nach einem OPEN RESETLOGS der Produktions-Datenbank zu verhindern.

Ein Öffnen der Datenbank mit der OPEN RESTLOGS Option bedeutet, dass der Zähler für die Sequenznummer der Redo Log Dateien auf 1 zurückgesetzt wird. Ein Überspringen dieser Option war mit bisherigen Standardmitteln beim Recovery nicht möglich.

Konzept bei OPEN RESETLOGS

Damit Flashback genutzt werden kann, muss vor dem Aufbau der Standby Datenbank auf dem Produktions-System bereits Flashback initialisiert sein.

Die Vorteile der Nutzung von Flashback beim open resetlogs der Produktions-Datenbank verdeutlicht Abbildung 2. Nach einem OPEN RESETLOGS der Produktions-Datenbank wird die Standby Datenbank mittels Flashback Technik auf einen Stand vor dem OPEN RESETLOGS zurückgesetzt.

Durchführung

Das Nachfahren der Redo Log Dateien wird während des Recoverys der Produktionsdatenbank kurz gestoppt.

Nach dem Zurücksetzen des Produktionssystems wird mit dem Kommando
select resetlogs_change# -2 from v$database;
die SCN ermittelt, die kleiner als die SCN des OPEN RESETLOGS ist.

Die Standby Datenbank muss jetzt auf jeden Fall auch auf eine SCN gebracht werden, die kleiner als die SCN des Produktionssystems ist.

Die aktuelle SCN erhalten wir über das Kommando:
select current_scn from v$database;

Ist die aktuelle SCN kleiner als die OPEN RESETLOGS SCN, so lässt sich jetzt mit dem Kommando
recover managed standby database ...;
das Recovery der Standby Datenbank wieder anstoßen.

Sollte jedoch die aktuelle SCN der Standby Datenbank größer sein als die SCN beim OPEN RESETLOGS, so können wir die Standby Datenbank mit dem Kommando
flashback standby database to scn <resetlogs_SCN - 2>;
entsprechend zurücksetzen. Danach kann wieder mit dem normalen Recovery begonnen werden.

Dieses Procedere lässt sich im Falle eines Misserfolgs solange wiederholen, bis der richtige Aufsatzpunkt, sprich die richtige SCN, gefunden wurde.

Mit diesem Vefahren lässt sich eine Standby Datenbank, die ohne Zeitversatz (delay=0) betrieben wird, sehr schnell wieder in den Recovery Mode bringen. Sie muss dazu nicht aufwändig neu aufgebaut werden, sondern kann mit Flashback Database einfach zurückgesetzt werden. Dies bedeutet, dass der Datenbank Administrator viel kostbare Arbeitszeit und somit seinem Arbeit- oder Auftraggeber Geld spart.

Konzept bei einem Failover

Ein Failover ist die ungeplante Übernahme der Produktion durch die Standby Datenbank. In den allermeisten Fällen ist ein Failover mit einem Datenverlust verbunden, da nicht alle Redo Daten auf das Standby System übertragen werden konnten. Da es sich bei einem Failover um ein unvollständiges Recovery handelt, bedeutet es immer ein OPEN RESETLOGS der Standby Datenbank.

Mit Oracle 9i galt, dass nach einem Failover die alte Produktions-Datenbank als Standby Datenbank neu aufgebaut werden muss. Es fand ein OPEN RESETLOGS auf der Standby Seite statt. Damit war das Nachfahren der neu anfallenden archivierten Redo Log Dateien auf der neuen Standby Seite nur mit einem Neuaufbau möglich.

Unter Nutzung von Flashback lässt sich die alte Produktions-Datenbank auf einen Zeitpunkt vor dem Failover zurücksetzen und dann per recover managed standby database wieder an den aktuellen Stand heranführen.

Das Konzept zeigt die Abbildung 3.

Bisher war ein Failover zwingend mit dem Neuaufbau der Standby Datenbank verbunden, da die neue Produktions-Datenbank mit OPEN RESETLOGS geöffnet wird. Der Neuaufbau der Standby Datenbank ist aber deutlich zeitaufwendiger, als das neue Standby System mit einem Flashback Kommando an die richtige Stelle zurückzusetzen und danach das Recovery zu beginnen.

Initialisierungsparameter

Bisher galten die Initialisierungsparameter bezüglich der Archivierung unabhängig von der jeweiligen Datenbank-Rolle. Die Datenbank-Rolle kann sein:

• Primary: Das ist die Produktions-Datenbank
• Physical Standby: Die physikalische Standby Datenbank
• Logical Standby: Die logische Standby Datenbank

Mit Oracle 10g lassen sich die Archivierungsparameter derart definieren, dass sie je nach aktueller Datenbank-Rolle (Primary oder Standby) wirken. Ein kleines Beispiel verdeutlicht das:

LOG_ARCHIVE_DEST_3 = "service=stdby valid for = (online_logfile, primary role)"

Der Archive Prozess soll die anfallenden Redo Log Dateien an die Standby Datenbank stdby kopieren. Und zwar nur dann, wenn er dabei auf normale Online Redo Log Dateien als Quelle zurückgreifen kann und die „Quell“-Datenbank sich in der Rolle PRIMARY (also Produktion) befindet.

Damit ist es möglich, eine init.ora Datei für alle Rollen einer Datenbank zu erstellen. Der Inhalt bleibt immer gleich, egal ob die Datenbank Produktions- oder Standby Datenbank ist.

Neuerungen spezifisch für physical Data Guard

Für die physikalische Standby Datenbank hat sich das Verhalten des startup Kommandos beziehungsweise des Kommandos alter database [ mount | open ] geändert.

In den Oracle Versionen 8i und 9i erfolgte das Starten der Datenbank folgendermaßen:

startup nomount
alter database mount standby database;
alter database open read only;

In der Version 10g lassen sich folgende Kommandos absetzen:

startup mount
alter database open;

oder

startup

Dabei erkennt Oracle beim Mounten der Datenbank, dass es sich bei der Control Datei um eine Standby Control Datei handelt und verhält sich entsprechend. Ebenso verhält es sich beim Öffnen der Datenbank. Die Information STANDBY CONTROLFILE wird ausgewertet und die Datenbank automatisch READ ONLY geöffnet.

Neuerungen Logical Data Guard

Mit Oracle 9i war es möglich, mit dem LGWR Dateien auf die Archive Log Destination einer logischen Standby Datenbank zu schreiben, aus denen anschließend per LogMiner-Technik die Transaktionen ausgelesen werden. Dabei schreibt die logische Standby Datenbank eigene online und archivierte Redo Log Dateien.

Mit Oracle 10g ist es jetzt auch bei der logischen Standby Datenbank möglich, mit Standby Redo Log Dateien zu arbeiten. Dies bedeutet, dass jetzt auch eine logische Standby Datenbank Bestandteil einer DataGuard Konfiguration sein kann, die sich im Modus MAXIMUM PROTECTION befindet. Dort gelten Transaktionen erst dann als beendet, wenn der LGWR in alle Redo Log Dateien geschrieben hat.

Mit Oracle 10g werden mit der logischen Standby Datenbank weitere, bisher nicht unterstützte Datentypen und Objekte, unterstützt. Tabellen, die die Datentypen LONG, LONG RAW oder NCLOB enthalten, können nun auch in diesem Konzept bearbeitet werden:

Index Organized Tables (IOT) können jetzt auch übertragen werden, es sei denn, die IOT hat Über­laufsegmente oder LOB Spalten.

Was weiterhin nicht unterstützt wird, sind User-definierte Datentypen. Dazu gehören leider auch funktionsbasierte Indizes.

Fazit

Beim Logical Data Guard ist eine erfreuliche Tendenz zur Komplettierung zu beobachten. Die Anzahl der nicht unterstützten Datentypen ist stetig sinkend. Eine fundamentale Verbesserung ist jedoch die Integration von Flashback Database in das Data Guard Konzept. Dort lässt sich im Falle eines Failovers sehr viel Zeit sparen, was für den Kunden letztlich weniger Kosten bedeutet.

In der kommenden ORDIX News werden wir uns mit den Neuerungen beim Oracle Recovery Manager beschäftigen.

Andreas Kother (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen