Über unsMediaKontaktImpressum
Uwe Hesse 11. Juni 2014

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.

Autor

Uwe Hesse

Uwe Hesse ist Oracle Certified Master. Er schreibt unter anderem über Oracle-Datenbanken, Oracle Data Guard, Hochverfügbarkeit.
>> Weiterlesen
botMessage_toctoc_comments_9210