Benutzer-Werkzeuge

Webseiten-Werkzeuge


dba:oracle_dataguard_standby_datenbank

Oracle 11g / 12c - Eine Standby Datenbank mit Oracle Data Guard aufsetzen – pflegen und überwachen

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:

 Oracle DataGuard Konfiguration

Aufbau der Umgebung:

KonfigurationNameWert
Software InstallationOracle HomeD:\oracle\product\11.2.0\dbhome_1
Oracle BaseD:\oracle\product\11.2.0\dbhome_1
Primäre DatenbankSIDVDS
Standby DatenbankSIDVDSSB
Primäre Servershadb01
Standby Servershadb02

Die drei Modi einer Standby Umgebung

  • Maximum Protection - Primary und Standby sind IMMER synchron
    • LGWR schreibt in Redo Log und muss warten, bis der LNSn das OK gibt, dass die Daten erfolgreich bis in den Standby Redologs der Standby DB übertragen werden konnten
    • ⇒ Wird die Standby dB gestoppt, wird damit auch automatisch die Primary DB heruntergefahren
  • Maximum Availability - Primary und Standby sind IMMER synchron, aber eine nicht verfügbare Standby hat keine Auswirkung auf die Primary Datenbank
    • LGWR schreibt in Redo Log und muss warten bis der LNSn das OK gibt, dass die Daten erfolgreich bis in den Standby Redologs der Standby DB übertrage werden konnten
    • ⇒ Wird ABER die Standby gestoppt, führt das NICHT zu einem Fehler in der Primary DB, sondern die Logs werden später wieder von der Standby DB nach gearbeitet
  • Maximum Performance - Primary und Standby sind müssen nicht immer synchron zueinander sein
    • LNSn liest aus dem Redo Logs die geänderten Daten und überträgt die Daten sofort, aber der LGWR muss nicht auf den erfolgreichen Versandt der Daten warten
    • ⇒ Wird die Standby gestoppt, führt das nicht zu einem Fehler in der Primary DB sondern die Logs werden später nach gearbeitet
    • ⇒ Fällt aber die Primary DB aus, können die letzten Einträge in den Online Redo Logs verloren gegangen sein

Übersicht über die beteiligten Prozesse:

11g Oracle Standby Asynchronous Redo Transmission


Aufbau - Generelle Übersicht über die notwenigen Schritte beim Aufbau der Standby Umgebung

Vorbereitung der Primären Datenbank:

  • Primary DB - Aktivieren von des Archive log , Flashback Log und Force Logging Modus
  • Primary DB - Standby Redo Logs anlegen
  • Primary Listener - Listener Konfiguration anpassen - Anmeldung muss remote auch bei gestoppter DB möglich sein

Vorbereitung der Standby Datenbank:

  • Standby DB - Oracle Software mit möglichst gleicher Dateistruktur und Version + Patch Level Stand installieren
  • Standby DB Listener - Oracle Listener einrichten- Anmeldung muss remote auch bei gestoppter DB möglich sein
  • Standby DB - Oracle Verzeichnisstruktur für Standby DB anlegen
  • Standby DB - Init.ora + Password File vorbereiten
  • Standby DB - Windows Service anlegen um DB in „nomount“ Modus starten zu können

SQL*Net Verbindung in alle Richtungen zu 100% prüfen

  • Primary Datenbank ⇒ Standby DB – Standby DB muss sich remote starten und stoppen lassen!
  • Standby DB ⇒ Primary Datenbank – Primary DB muss sich remote starten und stoppen lassen!

Klonen der Primaren Datenbank auf den neuen Standby Server mit RMAN Duplicate

  • Primary Datenbank - Einen Klone der Datenbank über das Netzwerk anlegen

Data Guard Broker einrichten

  • Primäre DB - DG Brocker einrichten
  • Standby DB - DB Brocker einrichten
  • Standby DB - Flashback aktivieren
  • Primare DB - Einrichten der Data Guard Brocker Konfiguration und Aktiveren des Log Shippings

Test der Umgebung

  1. Primäre DB - Sicherstellen das aktuelles Backup verfügbar ist und Anwendung sauber gestoppt wurde
  2. Primäre DB - Umschalten in den verschiedenen Modi durchführen

Der Aufbau der Standby Umgebung im Detail Schritt für Schritt

Vorbereitung der Primären Datenbank

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 ).

Primary DB- Aktivieren von Archivelog , Flashback Log und Force Logging

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.

Primary DB - Standby Redo Logs anlegen

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:

  • Maximum Protection
  • Maximum Availability
  • Maximum Performance

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:

  • Warning: ORA-16809: multiple warnings detected for the database
  • ORA-16789: standby redo logs not configured
Primary Listener - Listener Konfiguration anpassen

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

Vier Tnsname Einträge anlegen

  • VDS ⇒ über die SID an der VDS anmelden
  • VDSSB ⇒ über die SID an der VDSSB anmelden
  • DG_VDS ⇒ über den Service VDS_DGMGRL anmelden
  • DG_VDSSB ⇒ über den Service VDSSB_DGMGRL anmelden
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!

Vorbereitung der Standby Datenbank:

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!

Standby DB - Oracle Software mit möglichst gleicher Dateistruktur installieren

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!

Standby DB Listener - Oracle Listener einrichten - Anmeldung muss Remote auch bei gestoppter DB möglich sein

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!

Standby DB - Oracle Verzeichnisstruktur für Standby DB anlegen

Die gleiche Verzeichnisstruktur wie auf dem Primären Knoten ist zwar nicht notwendig vorgeschrieben, erleichtert aber die Wartung durch Standardisierung.

Standby DB - Init.ora + Password File vorbereiten

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.

Keinen SPFILE verwenden! Dieser wird später von Dublicate Befehl vom RMAN erzeugt - evlt. SPFILES für diese Instance entfernen!
Standby DB - Windows Service anlegen um DB in nomount Modus starten zu können

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

SQL*Net Verbindung in alle Richtungen 100% prüfen

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.

In einer RAC Umgebung daran denken, das die SQL*Net Einstellungen aus dem Cluster Home gelesen werden! Am einfachsten die gleichen Konfigurationen im Datenbank Home und im Cluster Home verwenden!
Primary Datenbank => Standby DB - DB muss sich remote starten und stoppen lassen
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“

Standby DB => Primary Datenbank - DB muss sich remote starten und stoppen lassen

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

Klone der Primaren Datenbank auf den neuen Standby Server mit RMAN Duplicate

Primary Datenbank - Eine Clone der Datenbank über das Netzwerk anlegen

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;
Standby File Management

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='*';

Data Guard Broker einrichten

Siehe auch die Oracle Dokumentation:

Übersicht über die Data Guard Architektur:

Data Guard Architektur Oracle 11g

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.

Primäre DB - DG Brocker einrichten
sqlplus sys@vds AS sysdba
 
sql> ALTER system SET dg_broker_start=TRUE scope=BOTH sid='*';
sql> exit
Standby DB - DB Brocker einrichten
sqlplus sys@vdssb AS sysdba
 
sql> ALTER system SET dg_broker_start=TRUE scope=BOTH sid='*';
sql> exit
Standby DB - Flashback aktivieren
sqlplus sys@vdssb AS sysdba
 
sql> ALTER DATABASE flashback ON;
sql> exit
Primare DB - Einrichten der Data Guard Brocker Konfiguration und Aktiveren des Log Shippings

Ü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';
Achtung! Das Setzen des Mode, zum Beispiel auf „ maxprotection“ kann zu einem Neustart der primären Instance führen!

Standby DB starten und stoppen

Manuell

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.

Auto Start der Standby DB prüfen / einstellen

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:

  • Powershell Script anlegen, mit einer kleinen Verzögerung die Instance im Mount Modus starten
  • Service für das Powerschell mit nssm anlegen
  • Als Abhängig zum Oracle Dienst setzen
    C:\Windows\System32\sc.exe config "ORACLE_MOUNT" depend= "OracleServiceGPI"

    (auf das Leerzeichen nach dem = achten!!)


Archive Log Handling

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/


Test der Umgebung mit verschiedenen Fail-Over Szenarien

Test 1 -Umschalten der Rollen zwischen den Datenbanken

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
 
 

Test 2 -Archive Lag

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
 
 

Client für das Failover einrichten

Fehler Szenarien überwachen und bearbeiten

Im ersten Schritt die Konfiguration der Umgebung prüfen!

Datenbank Eigenschaften und Status der Instance abfragen

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:

  • Status ist TRANSPORT-ON state (Nicht TRANSPORT-OFF!!)
  • Eigenschaft „LogXptStatus“ prüfen ⇒ Fehlermeldung beachten
  • Eigenschaft „StaticConnectIdentifer“ prüfen, muss der gültige TNS String sein!

Standby DB

  • Status „Intended State:“ ist APPLY-ON (Nicht im APPLY-OFF !!)
  • Transport Lag ⇒ Sollte kein größeres Lag sichtbar sein
  • Apply Lag ⇒ Sollte kein größeres Lag sichtbar sein
  • Eigenschaft „LogShipping“ auf der Standby ist ON
  • Eigenschaft „DelayMins“ sollte nicht zu hoch gesetzt sein
  • Eigenschaft „StaticConnectIdentifer“ prüfen, muss der gültige TNS String sein!
Umgebung per SQL Überwachen

Per SQL Script die Standby DB Umgebung abfragen:

standby_status.sql
-- ======================================================
-- 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:

Umgebung mit dgmgrl überwachen

Eigenschaften setzen:

dgmgrl
EDIT DATABASE sbo SET PROPERTY TransportDisconnectedThreshold='120'; 
EDIT DATABASE sbo SET PROPERTY TransportLagThreshold='4'; 

Lokal abfragen:

dgmgrl "/" "show database verbose vds"

Das Netz zur Standby fällt aus

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

Prüfen ab welcher SCN die Datenbank zu einer Primären DB wurde

Ü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;

Fast Start Failover einrichten

Es soll automatisch bei einem Ausfall ein Rollenwechsel stattfinden.

Fast Start Failover konfigurieren und den Data Guard Observer kontrollieren

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"

Doku

Snapshot Standby Database

See:

  • 11g Using Snapshot Standby Database. (Doc ID 443720.1)

Active Standby

DB Umgebung patchen

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)“

Genereller Ablauf

  • Primär - In der primären Datenbank das Log Shipping ausschalten
  • Standby - Standby DB herunterfahren
  • Standby - Patch für die RDBMS binaries durchführen
  • Standby - Listener und DB wieder starten
  • Primär - Primäre DB herunterfahren
  • Primär - Patch für die RDBMS binaries durchführen
  • Primär - Backup bei Bedarf anpassen -darauf achten, das die archivierten Redo Logs bis zum Abschluss aller Arbeiten auf der Platte verbleiben
  • Primär - Patch für die Datenbank durchführen
  • Standby - Standby DB status überprüfen
  • Primär - In der primären Datenbank das Log Shipping wieder einschalten
  • Standby - Redo Apply bei Bedarf starten / prüfen - die Patch Änderungen in der DB werden damit nachgefahren
  • Standby - Prüfen ob die Patche auch alle erfolgreich übertragen wurden
  • Primär - Backup bei Bedarf bzgl. Archivelog handling wieder anpassen
Beispiel

Beispiel für den Oracle Critical Patch Update Advisory - April 2017 ⇒ Patch 25632533: WINDOWS DB BUNDLE PATCH 12.1.0.2.170418

  • Download p25632533_121020_MSWIN-x86-64.zip
  • Download OPatch Patch 6880880 p6880880_121010_MSWIN-x86-64.zip
  • Entpacken auf beiden DB Servern
  • Primär - In der primären Datenbank das Log Shipping ausschalten
    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
  • Standby - Standby DB herunterfahren
    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
  • Standby - Patch für die RDBMS binaries durchführen
    • Alle Oracle Dienste stoppen, mit sysinternal Tools prüfen das keine Libraries mehr aktiv sind!
    • OPatch Verzeichnis mit neuen Verzeichnis Opatch aus 6880880 p6880880_121010_MSWIN-x86-64.zip Patch überschreiben/ersetzen
    • DB Patch auspacken in einer administrativen Session einspielen
      # 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.
  • Standby - Listener und DB wieder starten
  • Primär - Primäre DB herunterfahren
  • Primär - Patch für die RDBMS binaries durchführen
    • Alle Oracle Dienste stoppen, mit sysinternal Tools prüfen das keine Libraries mehr aktiv sind!
    • OPatch Verzeichnis mit neuen Verzeichnis Opatch aus 6880880 p6880880_121010_MSWIN-x86-64.zip Patch überschreiben/ersetzen
    • DB Patch auspacken in einer administrativen Session einspielen
      # 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.
  • Primär - Listener und Datenbank wieder starten
  • Primär - Backup bei Bedarf anpassen -darauf achten, das die archivierten Redo Logs bis zum Abschluss aller Arbeiten auf der Platte verbleiben
  • Primär - Patch für die Datenbank durchführen
    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;
  • Standby - Standby DB status überprüfen
  • Primär - In der primären Datenbank das Log Shipping wieder einschalten
    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
  • Standby - Redo Apply bei Bedarf starten / prüfen - die Patch Änderungen in der DB werden damit nachgefahren
    DGMGRL> show database verbose vdssb
  • Standby - Prüfen ob die Patche auch alle erfolgreich übertragen wurden
    adrci
    show alert
    --  pürfen ob die Archive erfolgreich auch applied wurden oder andere Fehler hier auftauchen
  • Primär - Backup bei Bedarf bzgl. Archivelog handling wieder anpassen

SSL Verschlüsselung Dataguard

Siehe Support Portal:

  • How To Enable SSL Encryption For Data Guard Redo Transport? (Doc ID 1143443.1)

Quellen

Cookies helfen bei der Bereitstellung von Inhalten. Durch die Nutzung dieser Seiten erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Rechner gespeichert werden. Weitere Information
"Autor: Gunther Pipperr"
dba/oracle_dataguard_standby_datenbank.txt · Zuletzt geändert: 2018/03/10 09:25 von Gunther Pippèrr