Data Guard Far Sync mit Oracle 12c Release 1

Ziel

Heute möchte ich euch zeigen, wie man das mit Oracle 12c Release 1 eingeführte Feature Data Guard Far Sync konfiguriert. Mithilfe dieses Data Guard Features sollen Zero-Data-Loss Konfigurationen auch über weite Entfernungen möglich sein, ohne die Performance der Produktivdatenbank zur beeinträchtigen (z.B. durch verzögerte Commits).

 

Lizenzierung

Für die Verwendung von Far Sync wird eine Active Data Guard Lizenz benötigt.

 

Testumgebung

Meine Testumgebung besteht aus zwei virtuellen Servern, die mithilfe von Oracle VirtualBox erstellt wurden.

Server  Betriebssystem  Architektur
L12CR1-RE1.dba-blog.de  CentOS 6.4  x86_64
L12CR1-RE2.dba-blog.de  CentOS 6.4 x86_64

 

Neben der Oracle Database wurde die Oracle Grid Infrastructure in der aktuellen Version 12c Release 1 installiert. Konfiguriert wurde das System als Oracle Restart.

 

Die Data Guard Konfiguration wird aus den folgenden Datenbanken bestehen.

Datenbank Servive Name Server Oracle Home  Aufgabe 
PROD  PROD.dba-blog.de L12CR1-RE1 /u01/app/oracle/product/12.1.0/dbhome_1 Primär Datenbank 
PRODFS PRODFS.dba-blog.de  L12CR1-RE1 /u01/app/oracle/product/12.1.0/dbhome_1 Far Sync Instanz
STBY STBY.dba-blog.de L12CR1-RE2 /u01/app/oracle/product/12.1.0/dbhome_1  Physical Standby Datenbank 

 

Die Primär Datenbank wurde mit dem Datenbankkonfigurations-Assistenten (DBCA) angelegt. 

 

Vorbereitung

Für die Konfiguration und den Betrieb von Data Guard ist es wichtig, dass statische Listener Einträge vorhanden sind. Dies ist notwendig, weil die Datenbanken zum Beispiel bei einem Rollenwechsel neugestartet werden. Durch die statischen Listener Einträge kann jederzeit auf die Datenbanken zugegriffen weden, unabhängig von dem Status in dem sie sich befinden.

 

Server: L12CR1-RE1 – Primär Datenbank und Far Sync Instanz

... SID_LIST_LISTENER =   (SID_LIST =     (SID_DESC =       (GLOBAL_DBNAME = PROD.dba-blog.de)       (ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1)       (SID_NAME = PROD)     )     (SID_DESC =       (GLOBAL_DBNAME = PRODFS.dba-blog.de)       (ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1)       (SID_NAME = PRODFS)     )   ) ...

Server: L12CR1-RE2 – Physical Standby Datenbank

... SID_LIST_LISTENER =   (SID_LIST =     (SID_DESC =       (GLOBAL_DBNAME = STBY.dba-blog.de)       (ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1)       (SID_NAME = STBY)     )   ) ...

 

Zusätzlich werden lokale Service Namen definiert. Der Inhalt der tnsnames.ora ist auf beiden Servern identisch.

... PROD.dba-blog.de =   (DESCRIPTION =     (ADDRESS = (PROTOCOL = TCP)(HOST = L12CR1-RE1.dba-blog.de)(PORT = 1521))     (CONNECT_DATA =       (SERVER = DEDICATED)       (SERVICE_NAME = PROD.dba-blog.de)     )   ) PRODFS.dba-blog.de =   (DESCRIPTION =     (ADDRESS_LIST =       (ADDRESS = (PROTOCOL = TCP)(HOST = L12CR1-RE1.dba-blog.de)(PORT = 1521))     )     (CONNECT_DATA =       (SERVICE_NAME = PRODFS.dba-blog.de)     )   ) STBY.dba-blog.de =   (DESCRIPTION =     (ADDRESS_LIST =       (ADDRESS = (PROTOCOL = TCP)(HOST = L12CR1-RE2.dba-blog.de)(PORT = 1521))     )     (CONNECT_DATA =       (SERVICE_NAME = STBY.dba-blog.de)     )   ) ...

 

  1. Konfiguration: Primär Datenbank

Im ersten Schritt werde ich die Primär Datenbank konfigurieren. 

 

Aktivierung Archive Log Modus

Falls noch nicht geschehen, muss der Archive Log Modus aktiviert werden. Die Datenbank muss dafür im MOUNT Modus gestartet sein.

sqlplus sys/oracle@PROD.dba-blog.de as sysdba   SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCHIVELOG; ALTER DATABASE OPEN;

 

Aktivierung Force Logging

Damit die Standby Datenbank konsistent bleiben kann, muss dafür gesorgt werden, dass keine Redo Informationen verloren gehen, wie zum Beispiel durch NOLOGGING Aktionen. Aus diesem Grund wird Force Logging aktiviert.

sqlplus sys/oracle@PROD.dba-blog.de as sysdba   ALTER DATABASE FORCE LOGGING;

 

Aktivierung Flashback

Dieser Schritt ist optional, vereinfacht aber vieles bei einem Rollenwechsel. Wurde ein Switchover durchgeführt und die ehemalige Primär Datenbank schreibend geöffnet, können alle Änderungen nach dem Öffnen der Datenbank mithilfe von Flashback innerhalb weniger Sekunden/Minuten zurückgerollt werden. Nachdem Zurückrollen auf dem Stand vor dem Öffnen, kann die Synchronisation nahtlos wieder aufgenommen werden.

ALTER DATABASE FLASHBACK ON;

 

Standby Redo Logs anlegen

Damit die Primär Datenbank nach einem Rollenwechsel das Real-Time Apply Feature nutzen kann, müssen entsprechende Standby Redo Logs angelegt werden.

sqlplus sys/oracle@PROD.dba-blog.de as sysdba   ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 50m; ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 50m; ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 50m; ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 50m;

Hinweis: Die Anzahl muss um 1 höher sein als die vorhandenen Redo Log Gruppen. Bei der Berechnung der Anzahl helfen die Views V$LOG und V$THREAD

 

Parameter anpassen

Für die Primär Datenbank müssen die folgenden Parameter angepasst werden. 

Parameter Wert  Anmerkung 
DB_UNIQUE_NAME PROD   
LOG_ARCHIVE_CONFIG ‘DG_CONFIG=(PROD,PRODFS,STBY)’  
LOG_ARCHIVE_DEST_1

‘LOCATION=USE_DB_RECOVERY_FILE_DEST

VALID_FOR=(ALL_LOGFILES,ALL_ROLES)

DB_UNIQUE_NAME=PROD’

Lokales Ziel für die Archive Logs 
LOG_ARCHIVE_DEST_2

‘SERVICE=PRODFS.dba-blog.de SYNC AFFIRM

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)

DB_UNIQUE_NAME=PRODFS’

Übertragung der Archive Logs zur Far Sync Instanz
LOG_ARCHIVE_DEST_3

‘SERVICE=STBY.dba-blog.de ASYNC

ALTERNATE=LOG_ARCHIVE_DEST_2

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)

DB_UNIQUE_NAME=STBY’

Direkte Übertragung der Archive Logs zur Standby Datenbank bei Ausfall der Far Sync Instanz.
LOG_ARCHIVE_DEST_STATE_2

‘DEFER’

Optional: Übertragung der Archive Logs zur Far Sync Instanz wird bis zum Abschluss der Konfiguration ausgesetzt.
LOG_ARCHIVE_DEST_STATE_3

‘DEFER’

Optional: Alternative Übertragung der Archive Logs zur Standby Datenbank wird bis zum Abschluss der Konfiguration ausgesetzt.
LOG_ARCHIVE_DEST_STATE_3 EXCLUSIVE  
LOG_ARCHIVE_FORMAT ‘%t_%s_%r.arc’ Standardformat
FAL_SERVER ‘STBY.dba-blog.de’  
DB_FILE_NAME_CONVERT ‘STBY’,’PROD’ Wird nicht unterstützt bei Verwendung von Oracle Managed Files.
LOG_FILE_NAME_CONVERT ‘/STBY/’,’/PROD/’ Wird nicht unterstützt bei Verwendung von Oracle Managed Files.
STANDBY_FILE_MANAGEMENT AUTO  

Hinweis: Ich verwende bei allen Datenbanken Oracle Managed Files (OMF) (Aktivierung durch das Setzen des Parameter DB_CREATE_FILE_DEST). Aus diesem Grund müssen die beiden Parameter DB_FILE_NAME_CONVERT und LOG_FILE_NAME_CONVERT nicht gesetzt werden. Oracle ignoriert diese Parameter, weil sie ansonsten zu ungültigen OMF Namen führen würden.

 

Die Parameter können entweder über das Parameter File gesetzt werden oder mithilfe der folgenden ALTER SYSTEM Anweisungen.

sqlplus sys/oracle@PROD.dba-blog.de as sysdba   ALTER SYSTEM SET DB_UNIQUE_NAME='PROD' SCOPE=spfile SID='*'; ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(PROD,PRODFS,STBY)' SCOPE=both SID='*'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PROD' SCOPE=both SID='*'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2='defer' SCOPE=both SID='*'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=PRODFS.dba-blog.de SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PRODFS' SCOPE=both SID='*'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3='defer' SCOPE=both SID='*'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=STBY.dba-blog.de ASYNC ALTERNATE=LOG_ARCHIVE_DEST_2 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=STBY' SCOPE=both SID='*'; ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=spfile SID='*'; ALTER SYSTEM SET LOG_ARCHIVE_FORMAT='%t_%s_%r.arc' SCOPE=spfile SID='*'; ALTER SYSTEM SET FAL_SERVER='STBY.dba-blog.de' SCOPE=both SID='*'; ALTER SYSTEM SET DB_FILE_NAME_CONVERT='STBY','PROD' SCOPE=spfile SID='*'; ALTER SYSTEM SET LOG_FILE_NAME_CONVERT='/STBY/','/PROD/'  SCOPE=spfile SID='*'; ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO SCOPE=spfile SID='*';

Da manche Parameter nicht im laufenden Betrieb angepasst werden können, muss die Datenbank neugestartet werden.

SHUTDOWN IMMEDIATE  STARTUP

 

Parameter File erzeugen

Nachdem alle Parameter korrekt gesetzt wurden, werden zwei Parameter Files erzeugt. Diese bilden die Grundlage für die Far Sync Instanz und die Physical Standby Datenbank.

sqlplus sys/oracle@PROD.dba-blog.de as sysdba   CREATE PFILE='/tmp/initPRODFS.ora' FROM SPFILE; CREATE PFILE='/tmp/initSTBY.ora' FROM SPFILE;

 

Konfiguration: Far Sync Instanz

Weiter geht es mit der Konfiguration der Far Sync Instanz. Die Far Sync Instanz ist keine vollwertige Datenbank. Sie besteht lediglich aus einem Controlfile und Redo Logs

 

Verzeichnisse anlegen

Für die Ablage von Audit Informationen lege ich ein neues Verzeichnis an. Ebenfalls werden alle Datenbank-relevanten Dateien im Dateisystem und nicht wie die Primär Datenbank im ASM abgelegt.

mkdir -p /u01/app/oracle/admin/PRODFS/adump mkdir -p /u01/app/oracle/oradata/PRODFS/CONTROLFILE mkdir -p /u01/app/oracle/fast_recovery_area

 

Controlfile erzeugen

Die Far Sync Instanz benötigt ein spezielles Controlfile. Dieses muss aus der Primär Datenbank heraus erstellt werden.

sqlplus sys/oracle@PROD.dba-blog.de as sysdba   ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS '/u01/app/oracle/oradata/PRODFS/CONTROLFILE/control01.ctl';

 

Parameter anpassen

Ich werde nun das Parameter File für die Far Sync Instanz anpassen. Zur Errinnerung, ich verwende eine Kopie des Parameter Files der Primär Datenbank.

Parameter Wert Anmerkung
DB_UNIQUE_NAME PRODFS  
CONTROL_FILES ‘/u01/app/oracle/oradata/PRODFS/ CONTROLFILE/control01.ctl’  
DB_CREATE_FILE_DEST ‘/u01/app/oracle/oradata’ Optional
DB_RECOVERY_FILE_DEST ‘/u01/app/oracle/fast_recovery_area’ Optional
LOG_ARCHIVE_DEST_1

‘LOCATION=USE_DB_RECOVERY_FILE_DEST

VALID_FOR=(ALL_LOGFILES,ALL_ROLES)

DB_UNIQUE_NAME=PRODFS’

 
LOG_ARCHIVE_DEST_2

‘SERVICE=STBY.dba-blog.de ASYNC

VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)

DB_UNIQUE_NAME=STBY’

 
FAL_SERVER ‘PROD.dba-blog.de’  
DB_FILE_NAME_CONVERT ‘PROD’,’PRODFS’ Wird nicht unterstützt bei Verwendung von Oracle Managed Files.
LOG_FILE_NAME_CONVERT ‘/PROD/’,’/PRODFS/’ Wird nicht unterstützt bei Verwendung von Oracle Managed Files.

 

Die Werte habe ich direkt in der Datei /tmp/initPRODFS.ora geändert. Zusätzlich habe ich die folgenden Parameter entfernt.

  • LOCAL_LISTENER
  • DISPATCHERS

 

Passwordfile kopieren

Data Guard benutzt standardmäßig den SYS Benutzer zur Kommunikation. Damit dieser sich an den jeweiligen Datenbanken einloggen kann, muss das Passwordfile identisch sein. Am einfachsten geht dies, indem man das Passwordfile der Primär Datenbank kopiert.

cp $ORACLE_HOME/dbs/orapwPROD $ORACLE_HOME/dbs/orapwPRODFS

 

Hinweis: Das Passwort für den SYS Benutzer habe ich auf oracle festgelegt.

 

Starten der Datenbank

Nun kann die Far Sync Instanz gestartet werden. Dafür melde ich mich per SQL*Plus an.

sqlplus sys/oracle@PRODFS.dba-blog.de as sysdba

 

Anschließend erzeuge ich aus dem temporären Parameter File ein Server Parameter File.

sqlplus sys/oracle@PRODFS.dba-blog.de as sysdba   CREATE SPFILE FROM PFILE='/tmp/initPRODFS.ora';

 

Zum Abschluss wird die Datenbank gemountet.

STARTUP MOUNT

 

Über die DATABASE_ROLE Spalte in der V$DATABASE View kann man sehen, dass es sich um eine Far Sync Instanz handelt.

sqlplus sys/oracle@PRODFS.dba-blog.de as sysdba   SELECT database_role FROM v$database;   DATABASE_ROLE ---------------- FAR SYNC

 

Standby Redo Logs anlegen

Das Anlegen von Standby Redo Logs ist Voraussetzung für die Far Sync Instanz, um den synchronen Übertragungsmodus verwenden zu können. Deshalb werden, wie schon bei der Primär Datenbank, Standby Redo Logs angelegt.

sqlplus sys/oracle@PRODFS.dba-blog.de as sysdba   ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 50m; ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 50m; ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 50m; ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 50m;

 

Aktivierung des Log Shippings

Damit die Primär Datenbank die Archive Logs korrekt zur Far Sync Instanz übertragt, muss das entsprechende Archive Ziel aktiviert werden.

sqlplus sys/oracle@PROD.dba-blog.de as sysdba   ALTER SYSTEM SET LOG_ARCHIVE_DEST_2_STATE='ENABLE' SCOPE=both SID='*';

 

Hinweis: Standardmäßig sind alle Archive Ziele aktiviert. Ich hatte dies aber mit dem Wert DEFER überschrieben.

 

Konfiguration: Physical Standby Datenbank

Zu guter letzt wird die Physical Standby Datenbank konfiguriert.

 

Passwordfile kopieren

Wie schon bei der Far Sync Instance, wird das Passwordfile der Primär Datenbank kopiert.

scp $ORACLE_HOME/dbs/orapwPROD L12CR1-RE2:$ORACLE_HOME/dbs/orapwSTBY

 

Parameter anpassen

Für die Physical Standby Datenbank müssen die Parameter wie folgt angepasst werden. Grundlage ist wieder eine Kopie des Parameter Files der Primär Datenbank.

 

Parameter Wert Anmerkung
DB_UNIQUE_NAME STBY  
LOG_ARCHIVE_DEST_1

‘LOCATION=USE_DB_RECOVERY_FILE_DEST

VALID_FOR=(ALL_LOGFILES,ALL_ROLES)

DB_UNIQUE_NAME=STBY’

 
LOG_ARCHIVE_DEST_2

‘SERVICE=PROD.dba-blog.de ASYNC

VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)

DB_UNIQUE_NAME=PROD’

 
FAL_SERVER ‘PROD.dba-blog.de’,’PRODFS.dba-blog.de’  
DB_FILE_NAME_CONVERT ‘PROD’,’STBY’ Wird nicht unterstützt bei Verwendung von Oracle Managed Files.
LOG_FILE_NAME_CONVERT ‘/PROD/’,’/STBY/’ Wird nicht unterstützt bei Verwendung von Oracle Managed Files.

Die Werte habe ich direkt in der Datei /tmp/initSTBY.ora geändert. Zusätzlich habe ich die folgenden Parameter entfernt.

  • CONTROL_FILES
  • LOCAL_LISTENER
  • DISPATCHERS

 

Die initSTBY.ora wurde per scp auf den zweiten Server kopiert.

scp /tmp/initSTBY.ora L12CR1-RE2:/tmp 

 

Instanz starten 

Die angehende Physical Stanbdy Datenbank muss im NOMOUNT Modus gestarten werden. Bevor ich dies mache, erzeuge ich mir ein Server Parameter File.

sqlplus sys/oracle@STBY.dba-blog.de as sysdba   CREATE SPFILE FROM PFILE='/tmp/initSTBY.ora';

 

Anschließend kann die Instanz gestartet werden.

STARTUP NOMOUNT

 

Anlegen der Physical Standby Datenbank

Für das Anlegen der Physical Standby Datenbank verwende ich den Recovery Manager (RMAN) und das DUPLICATE … FOR STANDBY Kommando.

 

Der RMAN muss sich sowohl mit der Primär als auch mit der Standby Datenbank verbinden.

rman target sys/oracle@PROD.dba-blog.de auxiliary sys/oracle@STBY.dba-blog.de

 

Anschließend kann das Erstellen der Physical Standby Datenbank beginnen.

DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE;

 

Hinweis: Durch den Zusatz FROM ACTIVE DATABASE werden die Datenbankdateien der Primär Datenbank direkt zur Standby Datenbank kopiert. Dies erzeugt eine zusätzliche Last auf der Primär Datenbank. Möchte man stattdessen auf ein bestehendes RMAN Backup zurückgreifen, muss man diesen Zusatz entfernen.

 

Aktivierung Log Shipping

Damit die Archive Logs korrekt von der Far Sync Instanz an die Physical Standby Datenbank weitergeleitet werden, muss das entsprechende Archive Ziel aktiviert sein.

sqlplus sys/oracle@STBY.dba-blog.de as sysdba   ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2='ENABLE' SCOPE=both SID='*';

Das gleiche gilt für das alternative Archive Ziel der Primär Datenbank. Dieses muss ebenfalls aktiviert werden, um der Primär Datenbank zu erlauben, bei Ausfall der Far Sync Instanz, die geänderten Daten direkt an die Physical Standby Datenbank schicken zu können. 

sqlplus sys/oracle@PROD.dba-blog.de as sysdba   ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3='ENABLE' SCOPE=both SID='*';

 

Aktivierung Flashback 

Ich aktiviere für die Physical Standby Datenbank das Flashback Feature. 

sqlplus sys/oracle@STBY.dba-blog.de as sysdba   ALTER DATABASE FLASHBACK ON;

 

Aktivierung des Real-Time Redo Apply

Damit die Synchronisation beginnt, aktiviere ich zum Abschluss der Konfiguration das Real-Time Redo Apply.

sqlplus sys/oracle@STBY.dba-blog.de as sysdba   ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

 

Änderung des Protection Mode

Standardmäßig befindet sich eine neue Datenbank im MAXIMUM PERFORMANCE Modus. Dieser Modus erlaubt Datenverlust, da auf keine Bestätigung von der Standby Datenbank gewartet wird. Aus diesem Grund sollte bei der Verwendung des Far Sync Features die Primär Datenbank mindestens im MAXIMUM AVAILABILTY Modus betrieben werden.

sqlplus sys/oracle@PROD.dba-blog.de as sysdba   ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

 

Überprüfung der Data Guard Konfiguration

Um zu überprüfen, ob die Synchronisation korrekt funktioniert, führe ich zwei kleine Tests durch.

 

Test 1: Übertragung Redo zur Far Sync Instanz

Im ersten Schritt überprüfe ich die aktuelle Sequenz Nummer der archivierten Redo Logs in der Far Sync Instanz und der Physical Standby Datenbank.

sqlplus sys/oracle@PRODFS.dba-blog.de as sysdba   SELECT sequence#, archived, applied, deleted FROM v$archived_log ORDER BY sequence#;    SEQUENCE# ARC APPLIED   DEL ---------- --- --------- ---         75 YES YES       NO         75 YES NO        NO 

sqlplus sys/oracle@STBY.dba-blog.de as sysdba SELECT sequence#, archived, applied, deleted FROM v$archived_log ORDER BY sequence#; SEQUENCE# ARC APPLIED DEL ---------- --- --------- --- 74 YES YES NO 75 YES NO NO

 

Wie man sieht, ist die Sequenz Nummer 75 zurzeit aktuell.

Um sicherzustellen, dass auch tatsächlich der Weg über die Far Sync Instanz genommen wird, deaktiviere ich das alternative dritte Archive Ziel (direkte Verbindung zur Physical Standby Datenbank). Anschließend führe ich einen Logswitch aus.

sqlplus sys/oracle@PROD.dba-blog.de as sysdba   ALTER SYSTEM SET log_archive_dest_state_3='DEFER' SCOPE=memory; ALTER SYSTEM SWITCH LOGFILE;

 

Zum Abschluss des Tests überprüfe ich wieder die aktuelle Sequenz Nummer. 

sqlplus sys/oracle@PRODFS.dba-blog.de as sysdba   SELECT sequence#, archived, applied, deleted FROM v$archived_log ORDER BY sequence#;  SEQUENCE# ARC APPLIED   DEL ---------- --- --------- ---         75 YES NO        NO         75 YES NO        NO         76 YES NO        NO 

sqlplus sys/oracle@STBY.dba-blog.de as sydba SELECT sequence#, archived, applied, deleted FROM v$archived_log ORDER BY sequence#; SEQUENCE# ARC APPLIED DEL ---------- --- --------- --- 75 YES IN-MEMORY NO 76 YES IN-MEMORY NO

Wie man sieht, war der Test erfolgreich. Die Redo Informationen wurden korrekt zur Far Sync Instanz und dann weiter zur Physical Standby Datenbank übertragen.

 

Test 2: Ausfall Far Sync Instanz

Im zweiten Test möchte ich einen Ausfall der Far Sync Instanz simulieren. Durch das Setzen des alternativen Archive Ziels LOG_ARCHIVE_DEST_3 in der Primär Datenbank, sollten die Redo Informationen direkt an die Physical Standby Datenbank übertragen werden. Dies möchte ich testen.

 

Zunächst überprüfe ich die aktuelle Sequenz Nummer in der Physical Standby Datenbank.

sqlplus sys/oracle@STBY.dba-blog.de as sydba   SELECT sequence#, archived, applied, deleted FROM v$archived_log ORDER BY sequence#;    SEQUENCE# ARC APPLIED   DEL ---------- --- --------- ---         75 YES YES       NO         76 YES YES       NO         77 YES IN-MEMORY NO

Anschließend stoppe ich die Far Sync Instanz.

sqlplus sys/oracle@PRODFS.dba-blog.de as sysdba SHUTDOWN ABORT

Die Überprüfung der Archive Ziele zeigt, dass das LOG_ARCHIVE_DEST_2 ungültig ist.

sqlplus sys/oracle@PROD.dba-blog.de as sysdba   SELECT dest_name, status, error FROM v$archive_dest WHERE status <> 'INACTIVE';   DEST_NAME                      STATUS    ERROR ------------------------------ --------- -------------------------------------------------- LOG_ARCHIVE_DEST_1             VALID LOG_ARCHIVE_DEST_2             ERROR     ORA-03113: Unerwartetes Ubertragungsende in                                          Kommunikation LOG_ARCHIVE_DEST_3             VALID

Wie man sieht, wird das Archive Ziel der Far Sync Instanz als feherhaft gekennzeichnet.

 

Ich führe nun einige Logswitches durch.

ALTER SYSTEM SWITCH LOGFILE;

Zum Abschluss überprüfe ich erneut die aktuelle Sequenz Nummer der Physical Standby Datenbank.

sqlplus sys/oracle@STBY.dba-blog.de as sysdba   SELECT sequence#, archived, applied, deleted FROM v$archived_log ORDER BY sequence#;    SEQUENCE# ARC APPLIED   DEL ---------- --- --------- ---         75 YES YES       NO         76 YES YES       NO         77 YES YES       NO         78 YES YES       NO         79 YES YES       NO         80 YES YES       NO         81 YES IN-MEMORY NO

Wie man sieht, wurden die Redo Informationen auch ohne die Far Sync Instanz übertragen. In diesem Fall aber über eine asynchrone Verbindung, um die Performance der Primär Datenbank nicht zu beeinträchtigen.

 

Referenzen

Leave a Reply

Your email address will not be published.