Erstellt März 2015 - Angepasst auf 12c Januar 2016
Oracle Data Guard ist nur in der Enterprise Edition der Datenbank verfügbar, allerdings lässt sich auch manuell eine Standby Umgebung per manuellem Log Shipping in einer Standard Edition realisieren ( siehe Eine manuelle Standby DB mit der Oracle Standard Edition erstellen )
Ziel:
Eine Oracle Dataguard 11g/12c Umgebung unter Microsoft Windows 2008 R2 bzw. 2012 mit Oracle 11gR2 / 12c R1 soll aus einer bestehenden Produktionsumgebung erstellt werden.
Flashback wird aktiviert, um die Standby für Tests zu öffnen und wieder auf den Original Zustand zurückzusetzen.
! Achtung Standby und Produktion benötigen den gleichen Software Version-stand inkl. Patch Level !
Übersicht:
Aufbau der Umgebung:
Konfiguration | Name | Wert |
---|---|---|
Software Installation | Oracle Home | D:\oracle\product\11.2.0\dbhome_1 |
Oracle Base | D:\oracle\product\11.2.0\dbhome_1 | |
Primäre Datenbank | SID | VDS |
Standby Datenbank | SID | VDSSB |
Primäre Server | shadb01 | |
Standby Server | shadb02 |
Übersicht über die beteiligten Prozesse:
Vorbereitung der Primären Datenbank:
Vorbereitung der Standby Datenbank:
SQL*Net Verbindung in alle Richtungen zu 100% prüfen
Klonen der Primaren Datenbank auf den neuen Standby Server mit RMAN Duplicate
Data Guard Broker einrichten
Test der Umgebung
Vorab werden folgende Schritte auf der Primary Datenbank durchgeführt.
Aktuell letzen Patch auf der Produktiven DB einspielen (Stand 03.01.2017 Patch 24922906: WINDOWS DB BUNDLE PATCH 12.1.0.2.161118 ).
Als SYS User an der DB anmelden (OS User in der ORA_DBA Gruppe) und aktuelle Einstellung überprüfen:
export ORACLE_SID=VDS sqlplus / AS sysdba SYS@SQL>SELECT DATABASE_ROLE,LOG_MODE,FORCE_LOGGING,FLASHBACK_ON FROM v$database; DATABASE_ROLE LOG_MODE FORCE_LOGGING FLASHBACK_ON ---------------- ------------ ----------- ------------------ PRIMARY ARCHIVELOG NO NO
Falls die Datenbank noch nicht so wie gewünscht parametrisiert ist, die DB stoppen, im Mount Status die Wert setzen und wieder starten:
sqlplus / AS sysdba shutdown IMMEDIATE startup mount ALTER DATABASE archivelog; ALTER DATABASE flashback ON; ALTER DATABASE force logging; ALTER DATABASE OPEN;
Flashback wird aktiviert, um die Standby für Tests zu öffnen und dann wieder auf den originalen Zustand zurückzusetzen.
Bzgl. den Flashback Modus siehe auch Oracle Flashback aktivieren.
Der LGWR (Logwriter) der Datenbank ist für den Eintrag der Redo Log Daten die lokalen Online Redo Logs zuständig.
Ab der 10gR2 werden die Log Daten über den „LNSn“ (Log Writer Network Server) zum RFS (Remote File Server) auf der Standby übertragen.
Für bestimmte Funktionalitäten, wie zum Beispiel das Feature „Zero Data Loss“, werden daher auf der Standby Seite die Standby Redologs angelegt.
Die Standby Redo Logs werden zwar aktiv nur auf der Standby Site genützt, damit aber auf beiden Seiten bei einem Umschalten der DB System auch der Rollenwechsel immer problemlos funktioniert müssen die Standby Redologs auf beiden Seiten angelegt werden.
Zur Standby DB und damit in die Standby Redo Logs werden die aktiven Redolog Daten von der Primaren DB schnellstmöglich versandt, um bei einem Crash möglichst wenige Daten zu verlieren.
Ab der 10R2 exisiert dafür auch ein neuer Hintergrund Prozess „LNSn“, der direkt die neuen Redo Daten über das Netz zur Standby DB (Prozess RFS) versendet, bei Bedarf muss allerdings das mit dem LGWR noch direkt zu kommunizieren.
Aus dem Redo Log Mechanismus ergeben sich auch die drei Verfügbarkeits-Methoden für die Data Guard Umgebung:
Anzahl der Standby Logs:
Für unsere Umgebung benötigen wir (Maximale Anzahl an Logfiles pro Thread (Instanz) +1) * Maximale Anzahl an Threads (Instanzen), das heißt bei 5 Log Gruppen bei einer Instance = 6 Standby Redo Log Files in der gleichen Größe wie die Online Redo Logs und diese natürlich gespiegelt!
Zusätzlich zuvor prüfen, ob überhaupt so viele Gruppen in dieser Datenbank (Statischer Parameter im Controlfile!) angelegt werden können, zum Beispiel über einen Trace des Controlfile (alter database backup controlfile to trace;) und auf MAXLOGFILES/MAXLOGMEMBERS achten!
Anlegen der Standby Redo Logs mit „alter database add standby logfile ('<file_dest_1>','<file_dest_2>') size xxxM“
ALTER DATABASE ADD standby logfile ('D:\ORACLE\ORADATA\VDS\SBREDO01_A.LOG' ,'D:\ORACLE\ORADATA02\VDS\SBREDO01_B.LOG') SIZE 100M / -- Nach obigen Muster nun 6 weitere Standby Redo Logs anlegen -- prüfen mit; SELECT GROUP#,MEMBER FROM v$logfile WHERE TYPE='STANDBY'; GROUP# MEMBER ---------- ----------------------------------------------- 8 D:\ORACLE\ORADATA\VDS\SBREDO01_A.LOG 8 D:\ORACLE\ORADATA02\VDS\SBREDO01_B.LOG ..... 13 D:\ORACLE\ORADATA\VDS\SBREDO08_A.LOG 13 D:\ORACLE\ORADATA02\VDS\SBREDO08_B.LOG
Werden keine Standby Redo Logs konfiguriert kann es zu folgenden Meldungen in der Data Guard Umgebung kommen:
Anmeldung muss Remote auch bei gestoppter DB möglich sein!
siehe auch ⇒ Mit Password File an der DB als sysdba anmelden und den „ORA-01031: insufficient privileges vermeiden“
D.h. die Datenbank Instance muss in der Listener.ora „registiert“ werden, damit der Listener weiß wie die Anfrage umzusetzen ist. Für die Dataguard Umgebung wird ein „_DGMGRL“ Datenbank Eintrag hinzugefügt.
Der Eintrag muss genau so lauten und sollte auch NUR für die Dataguard Umgebung eingesetzt werden.
Siehe auch entsprechende Support Node: Oracle Data Guard Broker and Static Service Registration (Doc ID 1387859.1)
Auf dem Primären Knoten -shadb01
Datei %ORALCE_HOME%/network/admin/listener.ora:
SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = VDS) (ORACLE_HOME = D:\oracle\product\11.2.0.4\dbhome_1) (SID_NAME = VDS) ) (SID_DESC = (GLOBAL_DBNAME = VDS_DGMGRL) (ORACLE_HOME = D:\oracle\product\11.2.0.4\dbhome_1) (SID_NAME = VDS) ) ) LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = shadb01)(PORT = 1521)) ) ) ADR_BASE_LISTENER = D:\oracle
VDS = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = shadb01)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = VDS) ) ) DG_VDS = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = shadb01)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = VDS_DGMGRL) ) ) VDSSB = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = shadb02)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = VDSSB) ) ) DG_VDSSB = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = shadb02)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = VDSSB_DGMGRL) ) )
Diese Einträge später dann auch genau gleich auf der Standby DB Umgebung anlegen!
Der Standby Server kann sich theoretisch von der Verzeichnis- und Laufwerkstruktur stark vom Server der Primären Datenbank unterscheiden. Das ist aber auf keinen Fall zu empfehlen und kompliziert die Wartung nur stark!
Den gleichen Softwarestand mit möglichst der gleichen Verzeichnisstruktur und dem gleichen OS User auf dem zukünftigen Standby DB Server anlegen. Darauf achten, dass auch der gleiche Patch-Level der DB Software auf dem Standby System installiert wird!
Auf dem Standby Knoten -shadb02
%ORALCE_HOME%/network/admin/listener.ora
SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = VDSSB) (ORACLE_HOME = D:\oracle\product\11.2.0.4\dbhome_1) (SID_NAME = VDSSB) ) (SID_DESC = (GLOBAL_DBNAME = VDSSB_DGMGRL) (ORACLE_HOME = D:\oracle\product\11.2.0.4\dbhome_1) (SID_NAME = VDSSB) ) ) LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = shadb02)(PORT = 1521)) ) ) ADR_BASE_LISTENER = D:\oracle
Tnsnames.ora vom primären Knoten übernehmen!
Die gleiche Verzeichnisstruktur wie auf dem Primären Knoten ist zwar nicht notwendig vorgeschrieben, erleichtert aber die Wartung durch Standardisierung.
Auf dem primären Knoten und der laufenden Datenbank eine init.ora vom spfile erzeugen und zusammen mit der Password Datei auf den Standby Knoten kopieren:
init.ora erzeugen:
sqlplus / AS sysdba sql>CREATE pfile='d:\initVDSSB.ora' FROM spfile;
Erzeugte initVDSSB.ora und password Datei von %ORALCE_HOME%\database\PWDVDS.ora in das %ORALCE_HOME%\database\ Verzeichnis auf der Standby DB kopieren, PWDVDS.ora in PWDVDSSB.ora umbenennen.
Die initVDSSB.ora öffnen und entsprechend auf die neue Maschine anpassen, DB_UNIQUE_NAME aufnehmen:
#Namen anpassen *.db_name='VDSSB' #Unique name mit aufnehme DB_UNIQUE_NAME=VDS
Diese init.ora dient dazu eine erste Instance auf dem Server zu starten, damit später mit RMAN der Klone in diese Instance angelegt werden kann! Der Klone Prozess erzeugt dann den passenden spfile für die spätere Standby Datenbank Instance.
Window Service mit oradim anlegen, Autostart der instance vorerst ausschalten, DB Instance mit „startup nomount“ starten Dos Schell öffnen:
set ORACLE_SID=VDSSB set ORACLE_HOME=d:\oracle\product\11.2.0.4\dbhome_1 d: cd %ORACLE_HOME% oradim -NEW -SID VDSSB rem 12c Enter password for Oracle service user: Instance created.
! In 12c muss diese Session unter dem User „OraRun“ dann später laufen, daher beim anlegen das Password vom User angeben !
Kontrollieren das die Verzeichnisstruktur gleich der Primären DB auch angelegt wurde und das der „ORARUN“ User hier volle Rechte auch hat!
sqlplus / AS sysdba sql>startup nomount
Mit der wichtigsten Voraussetzung, damit alles beim Anlegen und im Betrieb funktioniert, ist das korrekte Anlegen der SQL*Net Konfiguration und ein gut funktionierendes Netzwerk.
tnsping vdssb sqlplus sys@vdssb as sysdba sql>shutdown immediate sql>exit sqlplus sys@vdssb as sysdba sql>startup nomount sql>exit
Das muss alles problemlos funktionieren, falls nicht, siehe ⇒ Mit Password File an der DB als sysdba anmelden und den „ORA-01031: insufficient privileges vermeiden“
Wenn immer möglich sollte das auch für die produktive Datenbank getestet werden.
tnsping vds sqlplus sys@vds as sysdba sql>shutdown immediate sql>exit sqlplus sys@vds as sysdba sql>startup sql>exit
Siehe dazu auch im Detail ⇒ Eine Oracle Datenbank 11g R2 mit RMAN "DUPLICATE TARGET DATABASE TO xxxx FROM ACTIVE DATABASE unter Linux " klonen
Zuvor muss die Standby Instance wieder im nomount Status gestartet werden! (alternativ über RMAN mit „STARTUP AUXILIARY nomount;“ )
RMAN Kommando:
rman RMAN> CONNECT TARGET sys/oracle@VDS RMAN> CONNECT AUXILIARY sys/oracle@VDSSB RMAN> SQL 'alter system archive log current'; #Duplicate Command RMAN> DUPLICATE TARGET DATABASE FOR standby FROM ACTIVE DATABASE NOFILENAMECHECK spfile SET "DB_UNIQUE_NAME"="VDSSB" dorecover;
Fehler:
RMAN-03002: failure of Duplicate Db command at 12/14/2014 06:39:47 RMAN-05501: aborting duplication of target database RMAN-05001: auxiliary file name D:\ORACLE\ORADATA\VDS\EXAMPLE01.DBF conflicts with a file used by the target database RMAN-05001: auxiliary file name D:\ORACLE\ORADATA\VDS\USERS01.DBF conflicts with a file used by the target database
Lösung:
Wenn man sich sicher ist nicht auf der GLEICHEN Umgebung zu sein, hilft hier der Parameter NOFILENAMECHECK ! Falls NAME_CONVERT nicht verwendet wird, muss daher explizit NOFILENAMECHECK angebeben werden!
Die Namen lassen sich umbenennen mit zum Beispiel:
DUPLICATE TARGET DATABASE for standby FROM ACTIVE DATABASE NOFILENAMECHECK spfile PARAMETER_VALUE_CONVERT '\VDSSB\','\VDS\' set "DB_UNIQUE_NAME"="VDS" set LOG_FILE_NAME_CONVERT '\VDSSB\','\VDS\' set DB_FILE_NAME_CONVERT '\VDSSB\','\VDS\' dorecover;
Nach dem Clonen prüfe, das auf der Standby DB das Standby File Management auf „AUTO“ steht (init.ora Parameter standby_file_management=AUTO), damit neue Datendateien auch automatisch auf der Standby Umgebung angelegt werden.
sqlplus sys@vdssb AS sysdba SQL>SHOW parameter standby_file_management SQL>ALTER system SET standby_file_management=AUTO scope=BOTH sid='*';
Siehe auch die Oracle Dokumentation:
Übersicht über die Data Guard Architektur:
Konfiguriert und bedient wird Data Guard mit dem „dgmgrl“ Command Line Interface oder über den Oracle Enterprise Manager.
Auf der primären Datenbank und allen dazugehörigen Standby Datenbanken wird der Prozess DMON gestartet, dieser Prozesse liest seine Konfiguration und steuert die zum Verbund gehöhrenden Datenbanken. Die Kommunikation erfolgt wieder über das SQL*Net Protokoll.
sqlplus sys@vds AS sysdba sql> ALTER system SET dg_broker_start=TRUE scope=BOTH sid='*'; sql> exit
sqlplus sys@vdssb AS sysdba sql> ALTER system SET dg_broker_start=TRUE scope=BOTH sid='*'; sql> exit
sqlplus sys@vdssb AS sysdba sql> ALTER DATABASE flashback ON; sql> exit
Über das „dgmgrl“ Command Line Interface wird Data Guard konfiguriert und bedient.
Per default gilt „Maximum Performance“
dgmgrl # An der primären Datenbank anmelden: DGMGRL> # an der Primären DB anmelden CONNECT sys/oracle@DG_VDS # Konfiguration erstellen create configuration VDS as primary database is VDS connect identifier is DG_VDS; add database VDSSB as connect identifier is DG_VDSSB maintained as physical ; # Konfiguration überprüfen! Achtung die Namen sind Case sensitiv und nun klein! show configuration verbose; show database verbose 'vds'; show database verbose 'vdssb'; show instance verbose 'vds' ; show instance verbose 'vdssb' ; # Konfiguration aktivieren enable configuration ;
Fehler beim Hinzufügen der Standby DB: Error: ORA-16642: DB_UNIQUE_NAME mismatch ⇒ Zuvor beim Clonen den falschen DB Unique Name verwandt ⇒ muss ja VDSSB sein! ⇒ DB_UNIQUE_NAME auf VDSSB gesetzt und Standby DB gestoppt und im Mount Modus wieder gestartet und dann kann die StandBy DB zur Dataguard Konfiguration hinzugefügt werden.
Bei Bedarf den Modus setzen
#Maximum Avalability Modus Setzten edit configuration set protection mode as maxavailability; Error: ORA-16627: operation disallowed since no standby databases would remain to support protection mode => Zuerst muss der Log Transport Mode auf Sync gesetzt werden! edit database vds set property ‘logxptmode’=’sync';
Ist eine Standby DB nicht mehr gestartet, die DB bis zum mount Stadium mit Dataguard start, DataGuard kümmert sich darum das die Standby DB wieder recovered wird.
dgmgrl DGMGRL> CONNECT sys@dg_vdssb Password: Connected. DGMGRL> startup mount ORACLE instance started. DATABASE mounted.
!Daran denken nur bis zum Mount Modus zu starten!
DB stoppen:
dgmgrl DGMGRL> CONNECT sys@dg_vdssb Password: Connected. DGMGRL> shutdown IMMEDIATE ORA-01109: DATABASE NOT OPEN DATABASE dismounted. ORACLE instance shut down.
Autostart über den Service überprüfen ⇒ :Start der Oracle Instance unter Windows
Wert in der Registry ORA_VDSSB_AUTOSTART ⇒ FALSE
Einstellen mit:
oradim -edit -sid VDSSB -startmode manual
Nun startet nur noch der notwendige Windows Dienst, auch missverständliche Oracle Service genannt.
ABER:
DB ist immer noch offline!
Falle!
Wird der Start Mode auf Auto gestellt, öffnet sich die DB readonly und schon wird zur EE eine Oracle “Active Data Guard„ Lizenz benötigt!
In einer ASM Umgbung kann das Problem über Oracle Restart gelöst werden.
In einer Single Instance Standard Umgebung hilft wohl nur ein Script um hier die DB nach dem Start wiederum nur im mount modus zu starten.
Ablauf:
C:\Windows\System32\sc.exe config "ORACLE_MOUNT" depend= "OracleServiceGPI"
(auf das Leerzeichen nach dem = achten!!)
Nach den ersten Tagen im Betrieb prüfen ob die Archivelogs aus auf der Standby DB nach dem Apply gelöscht werden
RMAN Setting setzen auf der Primary:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY BACKED UP 1 TIMES TO DISK;
RMAN Setting setzen auf der Standby:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
Überwachen mit:
SELECT applied , deleted , decode(rectype,11,'YES','NO') AS reclaimable , COUNT(*) , MIN(SEQUENCE#) , MAX(SEQUENCE#) FROM v$archived_log LEFT OUTER JOIN sys.x$kccagf USING(recid) WHERE is_recovery_dest_file='YES' AND name IS NOT NULL GROUP BY applied,deleted,decode(rectype,11,'YES','NO') ORDER BY 5 /
Falls keine Archivelogs als reclaimable angebeben werden, trigger mit:
RMAN> SQL "begin dbms_backup_restore.refreshagedfiles; end;";
Bzw. in 12c mit
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
siehe auch https://blog.dbi-services.com/archivelog-deletion-policy-for-standby-database-in-oracle-data-guard/ und https://www.qualogy.com/techblog/oracle/deleting-archive-log-files-in-a-data-guard-environment#
Bei der Anmeldung darauf achten, dass der richtigen TNS Alias (der bei der DB Konfiguration verwendete DG_XX!) auch verwandt wird!
Von der produktiven primären VDS DB auf dem Knoten 1 auf die Standby DB auf dem Knoten 2 wechseln:
dgmgrl
connect sys@DG_VDS
switchover to VDSSB
Von der produktiven VDSSB DB auf dem knoten 2 wieder auf die ursprüngliche Datenbank VDS auf Knoten 1 umschalten:
dgmgrl connect sys@DG_VDSSB show database verbose 'vds' ; Database - vds Role: PHYSICAL STANDBY Intended State: APPLY-ON .. switchover to VDS ... Switchover succeeded, new primary is "vds" show database verbose 'vds' ; Database - vds Role: PRIMARY Intended State: TRANSPORT-ON
Um ein Lag zu simulieren, schalten wir den Apply der Logs ab:
dgmgrl connect sys@DG_VDSSB edit database vdssb set state=apply-off; show database vdssb;
Alert Log Eintrag prüfen:
adrci show alert ... RFS[7]: Possible network disconnect with primary database 2014-12-19 05:05:33.805000 -08:00 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL MRP0: Background Media Recovery cancelled with status 16037 Errors in file D:\ORACLE\diag\rdbms\vdssb\vdssb\trace\vdssb_mrp0_1384.trc: ORA-16037: user requested cancel of managed recovery operation Managed Standby Recovery not using Real Time Apply Recovery interrupted! Recovered data files to a consistent state at change 1140157 2014-12-19 05:05:34.819000 -08:00 Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL ...
Primary DB create some test data:
SYS@VDS-shadb01>CREATE TABLE HR.T1 tablespace users AS SELECT * FROM dba_objects; TABLE created. SYS@VDS-shadb01>ALTER system switch logfile; System altered. SYS@VDS-shadb01>ALTER system switch logfile; System altered. SYS@VDS-shadb01>CREATE TABLE HR.T2 tablespace users AS SELECT * FROM dba_objects; TABLE created. SYS@VDS-shadb01>ALTER system switch logfile; System altered.
SQL auf der Standby DB:
sqlplus sys@DG_VDSSB AS sysdba SELECT process,STATUS FROM v$managed_standby; PROCESS STATUS --------- ------------ ARCH CLOSING ARCH CONNECTED ARCH CLOSING ARCH CLOSING RFS IDLE RFS IDLE RFS IDLE RFS IDLE COLUMN info format a120 prompt CHECK log LAST applied TO LAST received log TIME SELECT 'Last Applied : ' || to_char(next_time,'dd.mm.yyyy hh24:mi') info FROM v$archived_log WHERE SEQUENCE# = (SELECT MAX(SEQUENCE#) FROM v$archived_log WHERE applied='YES') UNION SELECT 'Last Received : ' || to_char(next_time,'dd.mm.yyyy hh24:mi') info FROM v$archived_log WHERE SEQUENCE# = (SELECT MAX(SEQUENCE#) FROM v$archived_log) / INFO ------------------------------------ LAST Applied : 14.12.2014 08:13 LAST Received : 19.12.2014 05:10 prompt Verify the LAST SEQUENCE# received AND the LAST SEQUENCE# applied TO standby DATABASE SELECT al.thrd "Thread" , almax "Last Seq Received" , lhmax "Last Seq Applied" FROM (SELECT thread# thrd, MAX(SEQUENCE#) almax FROM v$archived_log WHERE resetlogs_change#=(SELECT resetlogs_change# FROM v$database) GROUP BY thread#) al, (SELECT thread# thrd, MAX(SEQUENCE#) lhmax FROM v$log_history WHERE first_time=(SELECT MAX(first_time) FROM v$log_history) GROUP BY thread#) lh WHERE al.thrd = lh.thrd / Thread LAST Seq Received LAST Seq Applied ------------ ----------------- ---------------- 1 49 46
Wieder einschalten:
dgmgrl connect sys@DG_VDSSB show database verbose "vdssb"; Database - vdssb Role: PHYSICAL STANDBY Intended State: APPLY-OFF Transport Lag: 0 seconds (computed 1 second ago) Apply Lag: 14 minutes 43 seconds (computed 1 second ago) Apply Rate: (unknown) edit database vdssb set state=apply-on; show database verbose "vdssb"; Database - vdssb Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 0 seconds (computed 0 seconds ago) Apply Lag: 0 seconds (computed 0 seconds ago) Apply Rate: 0 Byte/s
Im ersten Schritt die Konfiguration der Umgebung prüfen!
Bei Überprüfen der Primären und Standby DB mit „show database verbose '<db_name_lower_letter>';“ und „show instance verbose 'instance_name' on database db_unique_name;“ darauf achten das:
Primare DB:
Standby DB
Per SQL Script die Standby DB Umgebung abfragen:
-- ====================================================== -- GPI - Gunther Pippèrr -- Desc : Check the status of the standby DB for Gaps -- ====================================================== -- http://arjudba.blogspot.de/2011/03/scripts-to-monitor-data-guard.html -- --============================================================================== SET verify off SET linesize 130 pagesize 300 SET serveroutput ON SIZE 1000000 COLUMN dest_name format a20 COLUMN process format a10 COLUMN STATUS format a10 COLUMN error format a20 COLUMN state format a10 COLUMN log_sequence format 999999999 prompt ... CHECK the DB enviroment SELECT dest_name , process , STATUS , error FROM v$archive_dest WHERE STATUS != 'INACTIVE' ORDER BY STATUS / COLUMN process format 999999999 SELECT process , STATUS , log_sequence , state FROM v$archive_processes WHERE STATUS != 'STOPPED' ORDER BY STATUS / prompt ... prompt ... CHECK STATUS OF the Standby processes COLUMN process format a10 SELECT process , STATUS , client_process , SEQUENCE# , block# , active_agents , known_agents FROM v$managed_standby / --============================================================================== -- Where the types of PROCESS may be, -- - RFS - Remote file server -- - MRP0 - Detached recovery server process -- - MR(fg) - Foreground recovery session -- - ARCH - Archiver process -- - FGRD -- - LGWR -- - RFS(FAL) -- - RFS(NEXP) -- - LNS - Network server process -- -- The process status may be, -- UNUSED - No active process -- ALLOCATED - Process is active but not currently connected to a primary database -- CONNECTED - Network connection established to a primary database -- ATTACHED - Process is actively attached and communicating to a primary database -- IDLE - Process is not performing any activities -- ERROR - Process has failed -- OPENING - Process is opening the archived redo log -- CLOSING - Process has completed archival and is closing the archived redo log -- WRITING - Process is actively writing redo data to the archived redo log -- RECEIVING - Process is receiving network communication -- ANNOUNCING - Process is announcing the existence of a potential dependent archived redo log -- REGISTERING - Process is registering the existence of a completed dependent archived redo log -- WAIT_FOR_LOG - Process is waiting for the archived redo log to be completed -- WAIT_FOR_GAP - Process is waiting for the archive gap to be resolved -- APPLYING_LOG - Process is actively applying the archived redo log to the standby database -- -- The client process may be, -- Archival - Foreground (manual) archival process (SQL) -- ARCH - Background ARCn process -- LGWR - Background LGWR process --============================================================================== ------- prompt ... prompt CHECK log LAST applied TO LAST received log TIME COLUMN info format a120 SELECT 'Last Applied : ' || to_char (next_time, 'dd.mm.yyyy hh24:mi') info FROM v$archived_log WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM v$archived_log WHERE applied = 'YES') UNION SELECT 'Last Received : ' || to_char (next_time, 'dd.mm.yyyy hh24:mi') info FROM v$archived_log WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM v$archived_log) / ------- prompt ... prompt Verify the LAST SEQUENCE# received AND the LAST SEQUENCE# applied TO standby DATABASE SELECT al.thrd "Thread", almax "Last Seq Received", lhmax "Last Seq Applied" FROM ( SELECT thread# thrd, MAX (SEQUENCE#) almax FROM v$archived_log WHERE resetlogs_change# = (SELECT resetlogs_change# FROM v$database) GROUP BY thread#) al , ( SELECT thread# thrd, MAX (SEQUENCE#) lhmax FROM v$log_history WHERE first_time = (SELECT MAX (first_time) FROM v$log_history) GROUP BY thread#) lh WHERE al.thrd = lh.thrd / ------------- prompt ... prompt transport lag TIME, apply lag AND apply finish TIME SELECT name, VALUE, unit FROM v$dataguard_stats UNION SELECT NULL, NULL, ' ' FROM dual UNION SELECT NULL, NULL, 'time computed: ' || MIN (time_computed) FROM v$dataguard_stats / ------- Check if that works ------- prompt ------- works only with logical or open physical standby ------- prompt ------- or oracle streams -------------------------------------- prompt ... prompt ... CHECK IF gap EXISTS SELECT thread , consumer_name , seq + 1 first_seq_missing , seq + ( next_seq - seq - 1) last_seq_missing , next_seq - seq - 1 missing_count FROM (SELECT THREAD# thread , SEQUENCE# seq , lead (SEQUENCE#, 1, SEQUENCE#) OVER (partition BY thread# ORDER BY SEQUENCE#) next_seq , consumer_name FROM dba_registered_archived_log WHERE RESETLOGS_CHANGE# = (SELECT MAX (RESETLOGS_CHANGE#) FROM dba_registered_archived_log)) WHERE next_seq - seq > 1 ORDER BY 1, 2 / ----------------------------------------
Siehe auch:
Eigenschaften setzen:
dgmgrl EDIT DATABASE sbo SET PROPERTY TransportDisconnectedThreshold='120'; EDIT DATABASE sbo SET PROPERTY TransportLagThreshold='4';
Lokal abfragen:
dgmgrl "/" "show database verbose vds"
Primäre DB läuft weiter, wenn im Status Max Performance Mode.
Transport abgeschaltet:
connect sys@dg_vds edit database vds set state=transport-off; show database verbose 'vds'; Database - vds Role: PRIMARY Intended State: TRANSPORT-OFF
Auf die Spalte Status = DEFERRED auf der Primary DB achten!!
SYS@VDS-shadb01>@standby_status ... CHECK the DB enviroment DEST_NAME PROCESS STATUS ERROR -------------------- ---------- ---------- ---------------- LOG_ARCHIVE_DEST_2 LGWR DEFERRED LOG_ARCHIVE_DEST_1 ARCH VALID
Über die Spalte STANDBY_BECAME_PRIMARY_SCN in der V$DATABASE kann überprüft werden, ab welcher SCN diese DB zur Primary wurde:
SELECT STANDBY_BECAME_PRIMARY_SCN FROM V$DATABASE;
Es soll automatisch bei einem Ausfall ein Rollenwechsel stattfinden.
Fast Start Failover Einstellungen kontrollieren:
SHOW FAST_START FAILOVER;
Fast Start konfigurieren und aktivieren:
#nach 180 sekunden umschalten DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = '180'; DGMGRL> EDIT DATABASE vds SET PROPERTY FastStartFailoverTarget = 'vdssb'; DGMGRL> EDIT DATABASE vdssb SET PROPERTY FastStartFailoverTarget = 'vds'; DGMGRL> ENABLE FAST_START FAILOVER; DGMGRL> START OBSERVER;
Einstellungen überpürfen:
DGMGRL>show configuration verbose;
..
Observer: shadb01
..
Ist der Observer nicht gestartet(Wert none) dann Observer mit Logfile starten: (nur ein Observer kann pro Umgebung gestartet werden!)
# starten mit einem Logfile: dgmgrl -logfile d:\temp\dg_observer.log "sys/oracle@DG_VDS" "start observer"
Netz:
See:
siehe ⇒ http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/active_standby/index.html
See ⇒ „Information Center: Oracle Data Guard Physical Standby Database (Doc ID 1395508.2)“ und die Node „How do you apply a Patchset,PSU or CPU in a Data Guard Physical Standby configuration (Doc ID 278641.1)“
Beispiel für den Oracle Critical Patch Update Advisory - April 2017 ⇒ Patch 25632533: WINDOWS DB BUNDLE PATCH 12.1.0.2.170418
PS D:\ps> dgmgrl DGMGRL for 64-bit Windows: Version 12.1.0.2.0 - 64bit Production Copyright (c) 2000, 2013, Oracle. All rights reserved. Welcome to DGMGRL, type "help" for information. DGMGRL> connect vds Password: Connected as SYSDG. DGMGRL> show database vds Database - vds Role: PRIMARY Intended State: TRANSPORT-ON Instance(s): vds Database Status: SUCCESS DGMGRL>edit database vds set state='LOG-TRANSPORT-OFF'; Succeeded. DGMGRL> show database vds Database - vds Role: PRIMARY Intended State: TRANSPORT-OFF Instance(s): vds Database Status: SUCCESS
PS C:\ps> dgmgrl DGMGRL> connect vdssb Password: Connected as SYSDG. DGMGRL> shutdown immediate ORA-01109: database not open Database dismounted. ORACLE instance shut down. DGMGRL> exit
# Umgebung setzen wie Oacle Home etc cd D:\install\patch\p25632533_121020_MSWIN-x86-64\25632533 D:\oracle\product\12.1.0.2\dbhome_1\OPatch\opatch.bat apply OPatch succeeded.
# Umgebung setzen wie Oacle Home etc cd D:\install\patch\p25632533_121020_MSWIN-x86-64\25632533 D:\oracle\product\12.1.0.2\dbhome_1\OPatch\opatch.bat apply OPatch succeeded.
cd D:\oracle\product\12.1.0.2\dbhome_1\OPatch .\datapatch -verbose ORA-24327: need explicit attach before authenticating a user (DBD ERROR: OCISessionBegin) => DB zu starten vergessen .-( DB Starten und nochmal starten .-) geht! testen mit: sqlplus>select * from DBA_REGISTRY_SQLPATCH;
PS D:\ps> dgmgrl DGMGRL> connect VDS Password: Connected as SYSDG. DGMGRL> edit database vds set state='ONLINE'; Succeeded. DGMGRL> show database vds Database - vds Role: PRIMARY Intended State: TRANSPORT-ON Instance(s): vds Database Status: SUCCESS
DGMGRL> show database verbose vdssb
adrci
show alert
-- pürfen ob die Archive erfolgreich auch applied wurden oder andere Fehler hier auftauchen
Siehe Support Portal:
Oracle:
Support:
Blogs:
Remove DG Config