Oracle 12c Data Guard: Far Sync und Zero-Data-Loss
Oracle Data Guard bietet mit seinen Standby-Datenbanken Schutz vor dem Ausfall – und dies über weite Strecken hinweg. Mit Oracle Database 12c kamen nun einige Erweiterungen hinzu. Uwe Hesse berichtet über die neuen Features.
Standby Datenbanken wurden bereits mit Oracle Version 8 eingeführt. Mit Oracle Data Guard lassen sich Datenbanken gegen regionale Katastrophen auch über weite Strecken hinweg absichern. So kann der Datenbankserver beliebig große Entfernungen überbrücken, zumindest soweit man sich auf irdische Entfernungen bezieht. Eine Standby-Datenbank kann in einem Rechenzentrum eines anderen Kontinents liegen, für Oracle Data Guard ist das kein Problem. Mit dem neuen Release 12c gibt es nun einige Erweiterungen, die die bisherige Architektur noch weiter verbessern.
Ausbau von Oracle Data Guard 12c
Oracle Data Guard bietet schon seit längerem drei Modi für den Ausfallschutz:
- Maximum Protection: Überträgt synchron, Datenänderungen werden erst als commitet verzeichnet, wenn diese auch von der Standby-Seite entgegengenommen wurden.
- Maximum Performance: Überträgt Datenänderungen asynchron und bietet eine gute Performance
- Maximum Availability: Ein Mix aus beiden vorgenannten Modi.
Bislang war allerdings bei sehr großer Entfernung der Primary und der Standby Datenbank der einzig sinnvolle Schutzmodus Maximum Performance, während Maximum Availability und Maximum Protection aufgrund der dabei erforderlichen synchronen Übertragung des Redo-Protokolls die Performance der primären Datenbank zu stark beeinträchtigt hätten. Dies hat sich mit 12c geändert: Far Sync Instanzen bzw. Real-Time Cascade Standby Datenbanken ermöglichen nun die höheren Schutzmodi trotz großer Distanz der Desaster Recovery Site.
Dieser Artikel beschreibt die dazu nötigen Schritte, und dies ausgehend von einer bereits bestehenden Data Guard Konfiguration im Maximum Performance Schutzmodus. Wir gehen von folgender Konfiguration aus:
DGMGRL> show configuration; Configuration - myconf Protection Mode: MaxPerformance Databases: prima - Primary database physt - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS DGMGRL> show database physt logxptmode; LogXptMode = 'ASYNC'
Im obigen Beispiel sendet die primäre Datenbank Redo asynchron direkt an die Standby Datenbank. Eine solche Konfiguration wählt man beispielsweise dann, wenn die primäre und die Standby-Datenbank durch eine sehr große Distanz getrennt sind. Die Datenbank "prima" befindet sich beispielsweise in den USA und die physische Standby Database "physt" in Deutschland.
Remote Standby mit Far Sync
Mit Oracle Database 12c lässt sich nun eine Far Sync Instanz dazwischen schalten. Sie nutzt eine synchrone Übertragung und kann anschließend das empfangene Redo mittels asynchroner Übertragung an die eigentliche Standby Datenbank weiterleiten (siehe Abbildung 1).
Auf diese Weise kann trotz großer Distanz zwischen primärer Datenbank und Standby Datenbank der Schutzmodus Maximum Availability – und damit Zero-Data Loss – erreicht werden.
Was ist dazu erforderlich? Die Implementierung ist im Grunde recht einfach. Eine Far Sync Instanz benötigt nur ein spezielles Controlfile und Standby Redo Logfiles – also keine Datendateien – und kann daher auch kein Redo Apply durchführen. Sie wird folgendermaßen implementiert:
SQL> alter database create far sync instance controlfile 2 as '/stage/control01.ctl'; Database altered.
Dieser Befehl wird in einer Session der primären Datenbank durchgeführt. Nun muss ein Administrator das Far Sync Controlfile auf den für die Far Sync Instanz vorgesehenen Rechner kopieren, ebenso wie das Passwordfile der primären Datenbank. Oracle Net Connectivity muss ebenfalls hergestellt werden. Diese Schritte unterscheiden sich nicht von der üblichen Vorgehensweise zur Implementierung einer Standby Datenbank. Hauptsächlicher Unterschied ist, dass kein RMAN duplicate erforderlich ist.
Die nächsten Schritte sind auf dem Far Sync Rechner auszuführen:
SQL> connect sys/oracle@fs1 as sysdba; Connected to an idle instance. SQL> startup mount ORACLE instance started. Total System Global Area 521936896 bytes Fixed Size 2290264 bytes Variable Size 364907944 bytes Database Buffers 146800640 bytes Redo Buffers 7938048 bytes Database mounted. SQL> select database_role from v$database; DATABASE_ROLE ---------------- FAR SYNC
Die Far Sync Instanz ist nun bereit, empfängt und sendet aber noch kein Redo. Daher die nächsten Schritte:
DGMGRL> add far_sync fs1 as connect identifier is fs1; far sync instance "fs1" added DGMGRL> edit database prima set property redoroutes = '(LOCAL:fs1 SYNC)'; Property "redoroutes" updated DGMGRL> edit far_sync fs1 set property redoroutes = '(prima:physt ASYNC)'; Property "redoroutes" updated DGMGRL> enable far_sync fs1; Enabled. DGMGRL> show configuration; Configuration - myconf Protection Mode: MaxPerformance Databases: prima - Primary database fs1 - Far Sync physt - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS DGMGRL> edit configuration set protection mode as maxavailability; Succeeded. DGMGRL> show configuration; Configuration - myconf Protection Mode: MaxAvailability Databases: prima - Primary database fs1 - Far Sync physt - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
Die Konfiguration entspricht nun Abbildung 1. Was aber, wenn ein Switchover erfolgen soll?
DGMGRL> switchover to physt; Performing switchover NOW, please wait... Error: ORA-16627: operation disallowed since no standby databases would remain to support protection mode Failed. Unable to switchover, primary database is still "prima"
Das ist im momentanen Zustand der Konfiguration nicht erlaubt. Es gibt nun zwei Möglichkeiten.
1.) Der Schutzmodus wird vor dem Switchover auf Maximum Performance abgesenkt, und die neue primäre Datenbank überträgt anschließend direkt asynchron zur neuen Standby Datenbank:
Die Data Guard Broker Konfiguration gemäß obiger Abbildung sieht nach der Implementierung so aus:
DGMGRL> show configuration; Configuration - myconf Protection Mode: MaxAvailability Databases: prima - Primary database fs1 - Far Sync physt - Physical standby database fs2 - Far Sync (inactive) Fast-Start Failover: DISABLED Configuration Status: SUCCESS
So ist ein Switchover ohne Absenkung des Schutzmodus erlaubt:
DGMGRL> switchover to physt; Performing switchover NOW, please wait... Operation requires a connection to instance "physt" on database "physt" Connecting to instance "physt"... Connected as SYSDBA. New primary database "physt" is opening... Operation requires startup of instance "prima" on database "prima" Starting instance "prima"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "physt"
Wie zu sehen ist, ist der Befehl für das Switchover derselbe wie bei einer Konfiguration ohne Far Sync Instanz, und das gilt auch für das Failover:
DGMGRL> show configuration; Configuration - myconf Protection Mode: MaxAvailability Databases: prima - Primary database fs1 - Far Sync physt - Physical standby database fs2 - Far Sync (inactive) Fast-Start Failover: DISABLED Configuration Status: SUCCESS DGMGRL> failover to physt; Performing failover NOW, please wait... Failover succeeded, new primary is "physt"
Real-Time Cascade
Kaskadierende Standby Datenbanken – also Standby Datenbanken die ihrerseits ein Redo-Protokoll an Standby Datenbanken senden – sind nicht neu. Vor 12c konnte diese Übertragung von Standby Datenbank zu Standby Datenbank allerdings nur mittels des Archiver-Hintergrundprozesses erfolgen. Real-Time Cascade bedeutet also, dass die erste Standby Datenbank per LNS-Hintergrundprozess an die zweite Standby Datenbank übertragen kann – typischerweise macht sie dies asynchron:
Zunächst wird hierzu eine weitere Standby Datenbank erstellt und der Data Guard Broker Konfiguration hinzugefügt. Diese Schritte unterscheiden sich nicht von den bereits vor 12c bekannten und führen zu dieser Ausgangslage:
DGMGRL> show configuration; Configuration - myconf Protection Mode: MaxPerformance Databases: prima - Primary database physt - Physical standby database physt2 - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
physt und physt2 empfangen momentan Redo direkt von prima. Das wird nun geändert:
DGMGRL> edit database prima set property redoroutes = '(LOCAL:physt SYNC)'; Property "redoroutes" updated DGMGRL> edit database physt set property redoroutes = '(prima:physt2 ASYNC)'; Property "redoroutes" updated DGMGRL> show configuration; Configuration - myconf Protection Mode: MaxPerformance Databases: prima - Primary database physt - Physical standby database physt2 - Physical standby database (receiving current redo) Fast-Start Failover: DISABLED Configuration Status: SUCCESS DGMGRL> edit configuration set protection mode as maxavailability; Succeeded.
Die Konfiguration entspricht jetzt Abbildung 3. Zur Verdeutlichung nun ein Blick auf die Redo Apply Aktivität der beiden Standby Datenbanken:
SQL> connect sys/oracle@prima as sysdba Connected. SQL> select database_role from v$database; DATABASE_ROLE ---------------- PRIMARY SQL> select sequence# from v$log where status='CURRENT'; SEQUENCE# ---------- 27 SQL> connect sys/oracle@physt as sysdba Connected. SQL> select database_role from v$database; DATABASE_ROLE ---------------- PHYSICAL STANDBY SQL> select sequence#,status from v$managed_standby where process='MRP0'; SEQUENCE# STATUS ---------- ------------ 27 APPLYING_LOG SQL> connect sys/oracle@physt2 as sysdba Connected. SQL> select sequence#,status from v$managed_standby where process='MRP0'; SEQUENCE# STATUS ---------- ------------ 27 APPLYING_LOG
Hier ist zu sehen, dass beide Standby Datenbanken ein Real-Time Apply durchführen, obwohl das Redo-Protokoll kaskadierend übertragen wird. Genau das war vor 12c nicht möglich. Im Unterschied zur Konfiguration mit Far Sync Instanzen kann bei Real-Time Cascade auch im Schutzmodus Maximum Protection operiert werden:
DGMGRL> edit configuration set protection mode as maxprotection; Succeeded. DGMGRL> show configuration; Configuration - myconf Protection Mode: MaxProtection Databases: prima - Primary database physt - Physical standby database physt2 - Physical standby database (receiving current redo) Fast-Start Failover: DISABLED Configuration Status: SUCCESS
In diesem Fall ist allerdings eine zweite kaskadierende Standby Datenbank (die Redo synchron empfängt) dringend zu empfehlen, um die Verfügbarkeit der primären Datenbank auch bei Ausfall einer der synchron empfangenden Standby Datenbanken weiterhin zu gewährleisten.
Gegenüberstellung Far Sync vs. Real-Time Cascade
| Far Sync Instanz | Real-Time Cascading Standby Datenbank |
|---|---|
| Nur Controlfile und Standby Redologs | Vollständige Standby Datenbank |
| Redo Apply nicht möglich | Redo Apply wird durchgeführt |
| Maximum Protection nicht möglich | Alle Schutzmodi möglich |
Abschließend bleibt zu erwähnen, dass sowohl Far Sync als auch Real-Time Cascade die zusätzliche Lizenzierung der Active Data Guard Option erfordern.
