Table of Contents
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) ) ) ...
-
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.