Data Guard und das neue Fast Sync Feature

02.
Juni
2016
Veröffentlicht von: Stefan Hartsberger

Seit 12c gibt es neben den altbekannten Redo Transport Varianten SYNC und ASYNC zusätzlich den Modus FASTSYNC. Dieser verbindet sozusagen die Vorteile von synchroner und asynchroner Übertragung. Um jedoch die genaue Funktionsweise und den Vorteil von Fast Sync zu erklären, fangen wir ganz von vorne an.

Seit 12c gibt es neben den altbekannten Redo Transport Varianten SYNC und ASYNC zusätzlich den Modus FASTSYNC

Dieser verbindet sozusagen die Vorteile von synchroner und asynchroner Übertragung. 

Um jedoch die genaue Funktionsweise und den Vorteil von Fast Sync zu erklären, fangen wir ganz von vorne an. 

Wenn wir von Data Guard sprechen, dann reden wir von einer Hochverfügbarkeitslösung.

Es gibt noch weitere HA-Lösungen aus dem Hause Oracle. Jede deckt einen anderen Bereich von möglichen Ausfallszenarien ab. 

Zum Beispiel zielt die RAC (Real Application Clusters) Option darauf ab, den Ausfall eines ganzen Servers zu kompensieren. 

Ein Data Guard-System kommt wiederum zum Einsatz, wenn man die Verfügbarkeit der Datenbank vor dem Ausfall des zentralen Storages, oder auch vor dem Ausfall eines ganzen Rechenzentrums schützen möchte. Data Guard kann auch vor logischen Fehlern schützen. (z. B. versehentliches Löschen einer Tabelle)

Dies ist möglich, indem Data Guard alle Änderungen der primären Datenbank übers Netz (LAN/WAN) auch auf einer physikalisch unabhängigen Spiegel-Datenbank anwendet. Oft werden die primäre DB und die Standby DB an zwei geografisch weit entfernten Standorten/Rechenzentren betrieben. 

Nun gibt es in einer Data Guard-Umgebung spezielle Parameter, mit denen man die Funktionsweise des Systems auf seine individuellen Wünsche anpassen kann. 

Der wichtigste Datenbankparameter in einer Data Guard-Umgebung ist LOG_ARCHIVE_DEST_n

Er gibt den Pfad (lokal) oder Servernamen (remote) an, wohin die Redo Daten geschreben werden sollen und bietet uns darüberhinaus mehrere Konfigurationswerte an. 

LOG_ARCHIVE_DEST_n =
{ null_string |
 { LOCATION=path_name | SERVICE=service_name }
 [ MANDATORY ]
 [ REOPEN[=seconds] ]
 [ DELAY[=minutes] ]
 [ ENCRYPTION=ENABLED|DISABLED ]
 [ NOREGISTER ]
 [ TEMPLATE=template ]
 [ ALTERNATE=destination ]
 [ MAX_FAILURE=count ]
 [ SYNC | ASYNC ]
 [ AFFIRM | NOAFFIRM ]
 [ NET_TIMEOUT=seconds ]
 [ VALID_FOR=(redo_log_type,database_role) ]
 [ DB_UNIQUE_NAME ]
 [ MAX_CONNECTIONS=count ]
 [ COMPRESSION={ENABLE|DISABLE} ]
}

Der Parameter LOG_ARCHIVE_DEST_n hat viele Attribute, von denen wir aber hier ausschließlich die Werte SYNC, ASYNC, AFFIRM und NOAFFIRM betrachten. Sie bestimmen, wie der Transport und das Schreiben der Redologeinträge zur Standbyseite abläuft und damit auch wie sicher der Anwender sich sein kann, dass wirklich alle Commits ohne Datenverlust auch auf der Standby ausgeführt werden.

Bevor ein Commit erfolgreich geschrieben wird:

  • Soll auf eine Antwort der Zieldatenbank (Standby) gewartet werden, die bestätigt, dass die Redos angekommen sind? 
  • (Für diese Attribute ist es absolut unerheblich, wo die Redoeinträge in diesem Moment sind – ob im Memory oder bereits auf Festplatte. Es wird allein die Ankunft zurückgemeldet)
  1. Ja = SYNC
  2. Nein = ASYNC
  • Soll auf eine Bestätigung gewartet werden, dass die Redos auf der Zieldatenbank (Standby) erfolgreich in die Standby Logs auf Festplatte geschrieben wurden?
  1. Ja = AFFIRM
  2. Nein = NOAFFIRM

SYNC - AFFIRM

Ist SYNC gesetzt, wird per Default automatisch auch AFFIRM gesetzt.Voraussetzung für Maximum Protection und Maximum Availability Mode.Bevor eine Transaktion mit COMMIT abgeschlossen wird, sendet die Datenbank die Änderungen (Redos) an die Standby Datenbank. Diese schreibt die Redos in die Standby Logs auf Festplatte und bestätigt das Schreiben der Redos.

Erst nachdem die primäre Datenbank die Bestätigung der Standby Seite bekommen hat, wird die Änderung in die Online Redologs geschrieben und somit der Commit endgültig abgeschlossen.

Somit ist zu jedem Zeitpunkt garantiert, dass bei einem Komplettausfall der primären Seite kein Datenverlust entstehen kann.

Vorteil: kein Datenverlust möglich (bei Maximum Protection Mode)

Nachteil: Performance-Einbußen

ASYNC - NOAFFIRM

Ist ASYNC gesetzt, wird automatisch auch NOAFFIRM gesetzt.

Voraussetzung für Maximum Performance Mode.

Wenn eine Transaktion mit COMMIT abgeschlossen wird, schreibt die lokale Datenbank die Änderungen in die Online Redologs. Der Commit ist danach abgeschlossen.

Parallel dazu sendet die Datenbank die Änderungen (Redos) an die Standby Datenbank. Diese schreibt die Redos in die Standby Logs auf Festplatte und bestätigt das Empfangen der Redos.

Somit ist garantiert, dass die primäre Datenbank nie von einem Komplettausfall der Standby Seite (oder der Verbindung dorthin) negativ beeinflusst wird.

Vorteil: keine Performance-EinbußenNachteil: Datenverlust möglich

SYNC - NOAFFIRM

Seit 12c ist die Kombination von SYNC und NOAFFIRM im Maximum Availability Mode möglich. Dies wird Fast Sync genannt.

Bevor eine Transaktion mit COMMIT abgeschlossen wird, sendet die Datenbank die Änderungen (Redos) an die Standby Datenbank. Diese bestätigt das Empfangen der Redos. Das Schreiben der Redoeinträge in den Standby Logs auf der Festplatte erfolgt erst im Anschluss.

Sobald die primäre Datenbank die Bestätigung der Standby Seite bekommen hat, wird die Änderung in die Online Redologs geschrieben und somit der Commit endgültig abgeschlossen.

Beim Fast Sync ist nicht garantiert, dass alle Daten, die mit einem Commit auf primärer Seite bestätigt sind, auch auf der Standby Seite auf der Festplatte festgeschrieben wurden. Aber man erlangt hier eine relativ hohe Performance, da die primäre Datenbank von I/O-Problemen auf der Standby Seite nicht negativ beeinflusst wird.

Vorteil: weniger Performance-Einbußen
Nachteil: geringer Datenverlust möglich

Worst-Case-Fall:
Es kommt zu Datenverlust, wenn die primäre Seite nicht mehr in einem vertretbaren Zeitraum verfügbar gemacht werden kann (z. B.: Storage/Server crash, langer Stromausfall, Naturkatastrophe) und gleichzeitig auch die Standby Seite einen Stromausfall, Server crash, usw. erleidet. 

Denn in diesem Fall würden zwar die Redos auf der Standby Seite im Server RAM vorhanden sein, jedoch durch den Ausfall nicht mehr auf Festplatte geschrieben werden können und somit verloren gehen.

Data Guard Broker

Verwendet man den Data Guard Broker, kann man die Werte SYNC und NOAFFIRM mit dem folgenden Kommando setzen:

DGMGRL> EDIT DATABASE muenchen SET PROPERTY LogXptMode='FASTSYNC';

Es ergeben sich nun zwei Anwendungsfälle

1. Performance verbessern

Die primäre Datenbank vollendet nun einen Commit ohne auf das Disk I/O der Standby Seite zu warten. Der Effekt der Performance-Verbesserung ist natürlich umso größer, je langsamer die Festplatten auf der Standby Seite sind.

Des Weiteren gibt es hin und wieder Performance-Peaks beim Schreiben auf Festplatte. So kann es z. B. sein, dass 3% aller Schreibvorgänge viel langsamer sind als der Durchschnitt. Diese Peaks verlangsamen die Commits der primären Datenbank. 

Verwendet man Fast Sync, eliminiert man diese Performance-Einbrüche der Standby Festplatten.

2. Größere Distanzen zwischen primärer und Standby Seite bei gleicher Performance

Nun spart man sich die I/O Zeit zum Schreiben in die Standby Logs.

Man kann die gewonnene Zeit für ein weiter entferntes Ziel verwenden, welches meist eine höhere WAN-Latenz hat.

 

Fazit

Die Vor- und Nachteile müssen natürlich für jedes System individuell abgeschätzt werden. Wer jedoch das geringe Risiko eines Datenverlustes in Kauf nehmen kann, hat die Möglichkeit, die Performance der Commits auf der primären Datenbank zu verbessern.

Fast Sync ist unter anderem natürlich auch in einer Far Sync Data Guard-Umgebung denkbar.

Weitere Informationen zu diesen und anderen Data Guard-Themen erhalten Sie von unseren Experten im Rahmen einer Opens internal link in current windowOracle Data Guard-Schulung, die gerne auch bei Ihnen als Inhouse-Schulung ganz auf Ihre Bedürfnisse zugeschnitten werden kann.

Jede Menge Know-how für Sie!

In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.