=====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 [[dba:standby_db_per_script|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:
{{ :dba:standby:oracle_standby_overview_v01.png?600 | Oracle DataGuard Konfiguration}}
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|
===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:
{{:dba:standby:oracle_redo_transmission_standby_11g_v01.png?700 |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**
- Primäre DB - Sicherstellen das aktuelles Backup verfügbar ist und Anwendung sauber gestoppt wurde
- 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 [[dba:flashback|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 ('','') 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 => [[dba:connect_password_file_instance_sys_user|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 => [[dba:connect_password_file_instance_sys_user|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===
Siehe dazu auch im Detail => [[dba:db_clone_rman_active_database_online|Eine Oracle Datenbank 11g R2 mit RMAN "DUPLICATE TARGET DATABASE TO xxxx FROM ACTIVE DATABASE unter Linux " klonen]]
==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:
* http://docs.oracle.com/cd/E11882_01/server.112/e40771/toc.htm
Übersicht über die Data Guard Architektur:
{{ :dba:standby:oracle_dataguard_11g_v01.png?600 |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 => :[[dba:start_db_windows|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
* mount_database.ps1 => {{:dba:standby:mount_database_ps1.zip|mount_database.ps1}}
* Service für das Powerschell mit nssm anlegen
* Service muss unter einen Konto laufen, dem die DB gehöhrt, nicht unter system!
* Für das Anlegen des Service siehe (siehe auch [[windows:windows_run_as_service|Programm unter Windows 2008 als Service starten]]
* 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/ und https://www.qualogy.com/techblog/oracle/deleting-archive-log-files-in-a-data-guard-environment#
----
====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 ===
siehe auch => [[dba:taf_sql_connection|Transparent Application Failover konfigurieren]]
Siehe auch:
* http://www.oracle.com/technetwork/database/features/availability/maa-wp-11gr2-client-failover-173305.pdf
=== 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 '';" 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:
-- ======================================================
-- 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:
* http://arjudba.blogspot.de/2011/03/scripts-to-monitor-data-guard.html
* Oracle Support => 11.2 Data Guard Physical Standby Switchover Best Practices using SQL*Plus (Doc ID 1304939.1)
=== 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 ===
* Dokumentation => http://docs.oracle.com/cd/E11882_01/server.112/e40771/sofo.htm#DGBKR390
Netz:
* http://www.databasejournal.com/features/oracle/article.php/3849106/Fast-Start-Failover-in-Oracle-11g-Data-Guard.htm
==== Snapshot Standby Database ====
See:
* 11g Using Snapshot Standby Database. (Doc ID 443720.1)
==== Active Standby ====
siehe => http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/active_standby/index.html
----
==== 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 einschaltenPS 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 wurdenadrci
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 ====
Oracle:
* http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/active_standby/index.html
* http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/aufbau_standby/index.html
* http://www.oracle.com/webfolder/technetwork/de/community/dbadmin/tipps/snapshot_standby/index.html
* http://docs.oracle.com/cd/E11882_01/server.112/e41134/create_ps.htm#SBYDB00200
* http://www.oracle.com/us/solutions/sap/wp-ora4sap-flashback11g-1-303814.pdf
Support:
* Creating a Physical Standby Database (Doc ID 1475344.1)
* Information Center: Oracle Data Guard Physical Standby Database (Doc ID 1395508.2)
Blogs:
* http://maleshg.wordpress.com/2012/02/25/standby-redo-logs/
* http://blog.grid-it.nl/index.php/2011/05/24/how-is-data-guard-maximum-protection-mode-protecting-your-data/
* http://www.ora-solutions.net/papers/Ausfallszenarien_DataGuard_Flashback_10gR2.pdf
* http://allthingsoracle.com/data-guard-physical-standby-database-best-practices-part-i/
* http://allthingsoracle.com/data-guard-physical-standby-database-best-practices-part-ii/
Remove DG Config
* http://www.oracledbasupport.co.uk/how-to-safely-remove-a-data-guard-broker-configuration-under-racnon-rac-setup-2/
* Oracle Support How to remove a Data Guard Configuration from Primary Database (Doc ID 733794.1)