Gunther Oracle APEX und Datenbank Wiki

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
=====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:
<code sql>

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

</code>

Falls die Datenbank noch nicht so wie gewünscht parametrisiert ist, die DB stoppen, im Mount Status die Wert setzen und wieder starten:

<code sql>
sqlplus / as sysdba

shutdown immediate

startup mount

alter database archivelog;
alter database flashback on;
alter database force logging;
alter database open;

</code>

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 ('<file_dest_1>','<file_dest_2>') size xxxM"

<code sql>

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

</code>


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:
<code>
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
</code>


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

<code>
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)
    )
  )
</code>
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 
<code>
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

</code>

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:
<code sql>

sqlplus / as sysdba

sql>create pfile='d:\initVDSSB.ora' from spfile;

</code>

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:

<code>

#Namen anpassen
*.db_name='VDSSB'

#Unique name mit aufnehme
DB_UNIQUE_NAME=VDS

</code>
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.


<note tip>Keinen SPFILE verwenden! Dieser wird später von Dublicate Befehl vom RMAN erzeugt - evlt. SPFILES für diese Instance entfernen! </note>



==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:
<code cmd> 

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.

</code> 

! 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!

<code sql>

sqlplus / as sysdba

sql>startup nomount

</code>


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

<note>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!</note>

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

<code>

tnsping vdssb

sqlplus sys@vdssb as sysdba
sql>shutdown immediate
sql>exit

sqlplus sys@vdssb as sysdba
sql>startup nomount
sql>exit

</code>

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.

<code>

tnsping vds

sqlplus sys@vds as sysdba
sql>shutdown immediate
sql>exit

sqlplus sys@vds as sysdba
sql>startup
sql>exit

</code>

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

<code sql>

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;
</code>


Fehler:

<code bash>
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
</code>


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:
<code>
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;
</code>


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

<code sql>

sqlplus sys@vdssb AS sysdba

SQL>show parameter standby_file_management
SQL>alter system set  standby_file_management=AUTO scope=both sid='*';

</code>




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

<code sql>
sqlplus sys@vds as sysdba

sql> alter system set dg_broker_start=true scope=both sid='*';
sql> exit

</code>


==Standby DB - DB Brocker einrichten==

<code sql>
sqlplus sys@vdssb as sysdba

sql> alter system set dg_broker_start=true scope=both sid='*';
sql> exit

</code>

==Standby DB - Flashback aktivieren==


<code sql>
sqlplus sys@vdssb as sysdba

sql> alter database flashback on;
sql> exit

</code>


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

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



</code>


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
<code>
#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';

</code>

<note important>Achtung! Das Setzen des Mode, zum Beispiel auf " maxprotection" kann zu einem Neustart der primären Instance führen! </note>



----

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

<code sql>
dgmgrl

DGMGRL> connect sys@dg_vdssb
Password:
Connected.

DGMGRL> startup mount
ORACLE instance started.
Database mounted.

</code>

<fc #800000>!Daran denken nur bis zum Mount Modus zu starten!</fc>


DB stoppen:

<code sql>
dgmgrl

DGMGRL> connect sys@dg_vdssb
Password:
Connected.

DGMGRL> shutdown immediate
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.

</code>


=== 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:
<code cmd>
oradim -edit -sid VDSSB -startmode manual
</code>


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 <code cmd>
C:\Windows\System32\sc.exe config "ORACLE_MOUNT" depend= "OracleServiceGPI"
</code> (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:
<code sql>
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY BACKED UP 1 TIMES TO DISK;
</code>


RMAN Setting setzen auf der Standby:
<code sql>
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
</code>


Überwachen mit:

<code sql>
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
/
</code>

Falls keine Archivelogs als reclaimable angebeben werden, trigger mit:
<code sql>
RMAN> sql "begin dbms_backup_restore.refreshagedfiles; end;";
</code>

Bzw. in 12c mit <code sql>
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
</code>

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:
<code bash>

dgmgrl

connect sys@DG_VDS

switchover to VDSSB

</code>

Von der produktiven VDSSB DB auf dem knoten 2 wieder auf die ursprüngliche Datenbank VDS auf Knoten 1 umschalten:

<code bash>

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

  
</code>
=== Test 2 -Archive Lag  ===

Um ein Lag zu simulieren, schalten wir den Apply der Logs ab:
<code bash>

dgmgrl

connect sys@DG_VDSSB

edit database vdssb set state=apply-off;

show database vdssb;

</code>

Alert Log Eintrag prüfen:
<code>
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
...

</code>

Primary DB create some test data:
<code sql>
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.
</code>

SQL auf der Standby DB:
<code sql>
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
		   
 </code>

 
Wieder einschalten:
<code bash>

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
  
  
</code>

=== 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 '<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:

<code sql 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
/

----------------------------------------

</code>

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:

<code sql>
dgmgrl
EDIT DATABASE sbo SET PROPERTY TransportDisconnectedThreshold='120'; 
EDIT DATABASE sbo SET PROPERTY TransportLagThreshold='4'; 
</code>


Lokal abfragen:
<code sql>
dgmgrl "/" "show database verbose vds"
</code>
  
  
=== Das Netz zur Standby fällt aus ===


Primäre DB läuft weiter, wenn im Status Max Performance Mode.

Transport abgeschaltet:

<code bash>

connect sys@dg_vds

edit database vds set state=transport-off;

show database verbose 'vds';

Database - vds

  Role:            PRIMARY
  Intended State:  TRANSPORT-OFF


</code>

Auf die Spalte Status = DEFERRED auf der Primary DB achten!!

<code sql>

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
</code>
=== 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:
<code sql>

select STANDBY_BECAME_PRIMARY_SCN from V$DATABASE;

</code>


==== 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:
<code bash>
SHOW FAST_START FAILOVER;
</code>

Fast Start konfigurieren und aktivieren:
<code bash>

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

</code>



Einstellungen überpürfen:
<code bash>
DGMGRL>show configuration verbose;

..
 Observer:        shadb01
..

</code>

Ist der Observer nicht gestartet(Wert none) dann Observer mit Logfile starten:
(nur ein Observer kann pro Umgebung gestartet werden!)
<code bash>

# starten mit einem Logfile:

dgmgrl -logfile d:\temp\dg_observer.log "sys/oracle@DG_VDS" "start observer"

</code>




=== 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 <code powershell>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
</code>
  * Standby - Standby DB herunterfahren <code powershell>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
</code>		
  * 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 <code powershell># 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.

</code>
  * 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 <code powershell># 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.

</code>	 
  * 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 <code powershell>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;


</code>

  * Standby - Standby DB status überprüfen
  * Primär  - In der primären Datenbank das Log Shipping wieder einschalten<code bash>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
</code>
  * Standby - Redo Apply bei Bedarf starten / prüfen - die Patch Änderungen in der DB werden damit nachgefahren <code bash>DGMGRL> show database verbose vdssb</code>
  * Standby - Prüfen ob die Patche auch alle erfolgreich übertragen wurden<code bash>adrci
show alert
--  pürfen ob die Archive erfolgreich auch applied wurden oder andere Fehler hier auftauchen
</code>
  * 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)