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