Konfiguration Dataguard für Oracle 11.2 · [1] , [email protected] CL ambertz onsulting Konfiguration Dataguard für Oracle 11.2.02

________________________________________________________________

[1] http://www.lambertz-consulting.de, [email protected]

CambertzLonsulting

Konfiguration Dataguard für Oracle 11.2.02

Inhalt

Was will dieses Dokument zeigen ........................................................................................................... 2

Die Systemumgebung .............................................................................................................................. 2

LISTENER anpassen .................................................................................................................................. 2

Service in den Datenbanken prüfen ........................................................................................................ 6

DGMGRL .................................................................................................................................................. 7

Standby Redo Logs .................................................................................................................................. 9

DATAGUARD Konfiguration prüfen: ...................................................................................................... 10

SwitchOver ausführen ........................................................................................................................... 12

Primär -> Standby .............................................................................................................................. 14

Standby -> Primär .............................................................................................................................. 16

Transparent Application Failover (TAF) ................................................................................................. 17

Test der Standby DB als Primärdatenbank ............................................................................................ 19

LISTENER.ORA Vorlage .......................................................................................................................... 21

Primärdatenbank ............................................................................................................................... 21

Standbydatenbank ............................................................................................................................ 22

TNSNAMES.ORA Vorlage ....................................................................................................................... 23

Probleme erkennen ............................................................................................................................... 25

DGMGRL ............................................................................................................................................ 26

Was, wenn der SwitchOver schief geht ................................................................................................. 27

________________________________________________________________


CambertzLonsulting

Was will dieses Dokument zeigen Wer schon einmal einen "SWITCH OVER" durchgeführt hat, weiß, daß die meisten Dataguard Konfigurationen, wie man sie zu hauf im Netz findet, nicht nur von einander abgeschrieben scheinen, sondern oft nicht funktionieren oder wenn sie funktionieren - warum.

Schlimmer noch, wenn wegen einer fehlerhaften Konfiguration der angeforderte "SWITCH OVER" abbricht und sich die Datenbanken in einem offensichtlichen "Schwebezustand" befinden, muß man wissen, wie man die Ordnung wieder herstellen kann.

Aus dem Grund wird hier nicht beschrieben, wie eine StandBy Datenbank mit RMAN aufgebaut, sondern wie eine erfolgreiche Dataguard Konfiguration erstellt wird und der Dataguard genutzt wird.

Die Systemumgebung Eine zwei Knoten RAC Datenbank als Primärsystem mit einer Single Instanz als Standby Datenbank:

RAC DB: DB11R2 Knoten 1: DB11R21 Knoten 2: DB11R22

Standby Datenbank: DB11R2SB

OS: Centos 5.5

LISTENER anpassen Für eine mit dem DBCA erstellte Oracle 11.2.0.2 Datenbank sind folgen Einträge in der Listener.ora eingetragen:

LISTENER= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=IPC) (KEY=LISTENER) ) ) ) # line added by Agent LISTENER_SCAN1= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=IPC) (KEY=LISTENER_SCAN1) )

________________________________________________________________


CambertzLonsulting

) ) # line added by Agent ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN1=ON # line added by Agent ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON # line added by Agent

D. h., sobald eine Datenbank gestartet ist meldet sie sich beim Listener an (das geschieht mit ALTER SYSTEM REGISTER) und der startet den entsprechenden Service dazu. Vorher ist der Service nicht existent.

Ein solcher Service kann allerdings erzeugt werden, ohne daß die Datenbank gestartet ist. Dazu werden SID_LIST_xxx Einträge in der Listener.ora zu den Datenbanken vorgenommen. Der Listener startet dann diesen Service unabhängig von der Datenbank.

Man erkennt solche Service am Status "UNKNOWN" (lsnrctl status).

Service "DB11R21.VM" has 1 instance(s). Instance "DB11R21", status UNKNOWN, has 1 handler(s) for this service...

Wenn die Datenbank dazu schon hochgefahren wurde, existieren zu dem selben Service zwei Instanz Angaben. Eine "UNKNOWN" (diese stammt von der SID_LIST_xxx Eintrag) und ein Status "READY" (der wurde durch die Datenbank erzeugt)

Das ist von besonderem Interesse, wenn ein SwitchOver erfolgen soll (für einen FailOver ist das weniger von Bedeutung, weil für den Fall davon ausgegangen werden kann, daß die Standby Datenbank gestartet ist)

Der Dataguard Broker rebootet während eins SwitchOver die Datenbanken. Dazu meldet er sich über den Listener an. Zum ShutDown ist dies immer möglich. Ohne einen existierenden Service ist ein Startup jedoch nicht automatisch möglich. Nur aus dem Grund sind SID_LIST_xxxx Anpassungen an der Listener.ora erforderlich.

Ob die SID_LIST_xxx Erweiterungen dem LISTENER oder dem LISTENER_SCAN1 zugeordnet werden ist wahrscheinlich unerheblich. In folgenden Beispiel wurden die Erweiterungen für den LISTENER eingetragen.

Die listener.ora der ersten RAC Instanz verfügt dann über folgende Einträge (entsprechend wurde der zweite Knoten angepasst und auch die Standby Datebank):

[grid@olinux1 admin]$ cat listener.ora SID_LIST_LISTENER = (SID_LIST = (SID_DESC =

________________________________________________________________


CambertzLonsulting

(SID_NAME = DB11R21) (ORACLE_HOME = /opt/oracle/product/11.2/db_1 ) (GLOBAL_DBNAME = DB11R21.VM) ) (SID_DESC = (SID_NAME = DB11R21) (ORACLE_HOME = /opt/oracle/product/11.2/db_1 ) (GLOBAL_DBNAME = DB11R2_DGMGRL.VM) ) ) LISTENER= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=IPC) (KEY=LISTENER) ) ) ) # line added by Agent LISTENER_SCAN1= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=IPC) (KEY=LISTENER_SCAN1) ) ) ) # line added by Agent ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN1=ON # line added by Agent ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON # line added by Agent

Mit "lsnrctl relad" werden die Änderungen aktiviert. Jetzt zeigt sich für eine Status Anfrage das gewünschte Bild:

[grid@olinux1 ~]$ lsnrctl status LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 18-FEB-2011 15:36:49 Copyright (c) 1991, 2010, Oracle. All rights reserved.

________________________________________________________________


CambertzLonsulting

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER))) STATUS of the LISTENER ------------------------ Alias LISTENER Version TNSLSNR for Linux: Version 11.2.0.2.0 - Production Start Date 18-FEB-2011 14:46:38 Uptime 0 days 0 hr. 50 min. 10 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /u01/app/11.2.0/grid/network/admin/listener.ora Listener Log File /u01/app/grid/diag/tnslsnr/olinux1/listener/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.123.10)(PORT=1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.123.11)(PORT=1521))) Services Summary... Service "+ASM" has 1 instance(s). Instance "+ASM1", status READY, has 1 handler(s) for this service... Service "DB11R2.VM" has 1 instance(s). Instance "DB11R21", status READY, has 1 handler(s) for this service... Service "DB11R21.VM" has 1 instance(s). Instance "DB11R21", status UNKNOWN, has 1 handler(s) for this service... Service "DB11R2XDB.VM" has 1 instance(s). Instance "DB11R21", status READY, has 1 handler(s) for this service... Service "DB11R2_DGB.VM" has 1 instance(s). Instance "DB11R21", status READY, has 1 handler(s) for this service... Service "DB11R2_DGMGRL.VM" has 2 instance(s). Instance "DB11R21", status UNKNOWN, has 1 handler(s) for this service... Instance "DB11R21", status READY, has 1 handler(s) for this service... The command completed successfully [grid@olinux1 ~]$

Hier noch einmal deutlich:

Durch den SID_LIST_xxx Eintrag Instance "DB11R21", status UNKNOWN, has 1 handler(s) for this service...

Durch die Datenbank erzeugt Instance "DB11R21", status READY, has 1 handler(s) for this service...

________________________________________________________________


CambertzLonsulting

Service in den Datenbanken prüfen Nun kennt der Listener die Service, wie sie in der tnsnames.ora eingetragen sind. Aber fühlt sich die Datenbank auch angesprochen, wenn der Listener diesen Service abruft? Dazu muß der Service in der Datebank bekannt sein.

SQL> show parameter service NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ service_names string DB11R2.VM SQL>

Das ist hier nicht der Fall. Es fehlt der Eintrag für den Dataguard. Mit ALTER SYSTEM wird der Servicename eingetragen, auf die sie reagieren soll.

Die Primärdatenbank:

SQL> ALTER SYSTEM SET service_name=' DB11R2.VM', 'DB11R2_DGMGRL.VM' scope=both sid='*';

Wichtig ist hier, daß der schob existierende Eintrag mit angegeben wird !!

Die Standby Datenbank:

SQL> show parameter service NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ service_names string DB11R2.VM

Obwohl es sich um die Standby Datenbank handelt, ist der Service Name der Gleiche wie auf der Primär Datenbank - das ist wichtig!!

Den zweiten Service wie schon bei der primären Datendank eintragen:

SQL> ALTER SYSTEM SET service_name=' DB11R2.VM', 'DB11R2SB_DGMGRL.VM' scope=both sid='*';

________________________________________________________________


CambertzLonsulting

DGMGRL Die Einstellungen zum Dataguard werden in ein oder mehreren Dateien gespeichert. Als Speicherort bietet sich für einen RAC auf ASM der ASM an.

In einem Filesystem werden korrupte Konfig Dateien selten erkannt. Nur die drXORACLE_SID.log Datei des DataGuard weist auf den Fehler ausdrücklich hin.

Wo die Config Datein speichert werden, kann aus der Datenbank ermittelt werden:

SQL> show parameter dg_broker_config

NAME TYPE VALUE

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

dg_broker_config_file1 string +DATA/db11r2/dr1db11r2.dat

dg_broker_config_file2 string +DATA/db11r2/dr2DB11R2.dat

SQL>

SQL> ALTER SYSTEM SET dg_broker_config_file1='+DATA/db11r2/dr1db11r2.dat';

SQL> ALTER SYSTEM SET dg_broker_config_file2='+DATA/db11r2/dr2db11r2.dat';

Nur noch wenige Einstellungen sind direkt in der Datenbank mit "ALTER SYSTEM..." vorzunehmen. Einstellungen, die nicht automatisch vom DataGuard Broker vorgenommen werden, können mit dem EDIT Befehl im DGMGRL geändert werden. ALTER SSYSTEM Einträge werden ggf. durch den DataGuard Broker überschrieben

Keine direkten Eingriffe in die Datenbank Konfiguration der Standby via "ALTER..". Alle grundsätzlich erforderlichen Einstellungen nimmt der DataGuard Broker vor. Fehlende Einstellungen per EDIT aus dem dgmgrl vornehmen.

Der DGMGRL sollte gerade zur Beauskunftung mit Bedacht eingesetzt werden. So kann es passieren, daß die Abfrage auf der Standby Datenbank "show database 'mystb" vom Status SUCCESS ist, wogegen die gleiche Anfrage auf der Primärdatenbank mit Fehlern ausgewiesen wird. Sicherheit bekommt man immer aus den Log Dateien.

Immer die Alert.log datei der Datenbanken und die Logfiles des Dataguard Brokers auf Fehler prüfen. Diese sind im Regelfall zu finden:

________________________________________________________________


CambertzLonsulting

$ORACLE_BASE/diag/rdbms/${ORACLE_UNQNAME}/${ORACLE_SID}/trace/drc${ORACLE_SID}.log

$ORACLE_BASE/diag/rdbms/${ORACLE_UNQNAME}/${ORACLE_SID}/trace/dalert${ORACLE_SID}.log

Nun die einzelnen Konfigurationen:

# dgmgrl DGMGRL> connect sys/manager@db11r2 DGMGRL> create configuration 'DG_DB11R2' as primary database is 'DB11R2' connect identifier is DB11R2; DGMGRL> add database 'DB11R2SB' as connect identifier is DB11R2SB maintained as physical; DGMGRL> edit database 'DB11R2' set property 'StandbyFileManagement'='AUTO'; DGMGRL> edit database 'DB11R2SB' set property 'StandbyFileManagement'='AUTO'; DGMGRL> edit database 'DB11R2' set property 'MaxConnections'='4'; DGMGRL> edit database 'DB11R2SB' set property 'MaxConnections'='4'; DGMGRL> edit database 'DB11R2' set property 'LogArchiveMaxProcesses'='5'; DGMGRL> edit database 'DB11R2SB' set property 'LogArchiveMaxProcesses'='5'; DGMGRL> edit database 'DB11R2' set property 'StandbyArchiveLocation' = '+DATA'; DGMGRL> edit database 'DB11R2SB' set property 'StandbyArchiveLocation' = '/opt/oracle/oradata/DB11R2/archivelog/standby'; DGMGRL> enable configuration; Folgende Einstellungen sind für die Modus " MaxAvailability" oder "MaxProtection" erforderlich: DGMGRL> edit database 'DB11R2' set property 'LogXptMode'='SYNC'; DGMGRL> edit database 'DB11R2SB' set property 'LogXptMode'='SYNC'; DGMGRL> edit database 'DB11R2' set property 'NetTimeout'=10; DGMGRL> edit database 'DB11R2SB' set property 'NetTimeout'=10; DGMGRL> edit configuration set protection mode as MaxAvailability; !! Dazu müssen aber die Standby Redologs angelegt sein !!

________________________________________________________________


CambertzLonsulting

Standby Redo Logs Redologs werden benötigt, für den Modus " MAXIMUM AVAILABILITY " oder "MAX PROTECTION", weil der LogWriter für die Datenübetragung auf die Standby zuständig.

Für dem Modus "MAXIMUM PERFORMANCE" kann auf die Standby Redos verzichtet werden, da der Archiver der Transport der Archive Redo Logs steuert.

Um die richtige Anzahl und Größe der Standby Redologs erstellen zu können, gilt zu prüfen, wie viele und in welcher Größe die Primär Datenbank Redo's nutzt.

SQL> l 1 SELECT l.thread#, 2 l.SEQUENCE# Redo, 3 l.group# grp, 4 ROUND( l.BYTES/1024/1024 ) SizeM, 5 l.ARCHIVED ARCHIVED, 6 l.STATUS LogStat, 7 lf.TYPE lftype, 8 lf.MEMBER filename 9 FROM GV$log l, 10 v$logfile lf 11 WHERE lf.GROUP# = l.GROUP# 12 AND IS_RECOVERY_DEST_FILE='YES' 13* ORDER BY l.SEQUENCE# SQL> /

THREAD# Redo Nr Group Size M Archived Log Status Type FileName ---------- ------- ------ ------- -------- ---------- -------- -------------------------------------------------- 2 432 3 50 YES INACTIVE ONLINE +DATA/db11r2/onlinelog/group_3.269.736978013 2 432 3 50 YES INACTIVE ONLINE +DATA/db11r2/onlinelog/group_3.269.736978013 2 433 4 50 NO CURRENT ONLINE +DATA/db11r2/onlinelog/group_4.271.736978019 2 433 4 50 NO CURRENT ONLINE +DATA/db11r2/onlinelog/group_4.271.736978019 1 569 2 50 YES INACTIVE ONLINE +DATA/db11r2/onlinelog/group_2.261.736972737 1 569 2 50 YES INACTIVE ONLINE +DATA/db11r2/onlinelog/group_2.261.736972737

________________________________________________________________


CambertzLonsulting

1 570 1 50 NO CURRENT ONLINE +DATA/db11r2/onlinelog/group_1.259.736972731 1 570 1 50 NO CURRENT ONLINE +DATA/db11r2/onlinelog/group_1.259.736972731 8 rows selected. SQL>

Entsprechend der Vorgabe von Oracle werden jeweils fünf (einer mehr als aktive Redo Logs im Einsatz sind) RedoLogs für jedem RAC Knoten erzeugt:

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 50M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 50M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 50M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 50M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 50M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 50M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 50M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 50M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 50M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 50M;

Auch auf der Standby Datenbank sind diese Redos anzulegen. Wenn die Datenbank bereits im Recovery Mode ist, muß dieser abschaltet werden (z.B. durch das Stoppen des Dataguard Broker) für die Zeit der Redo Erstellung.

DATAGUARD Konfiguration prüfen: DGMGRL> show configuration; Configuration - DG_DB11R2 Protection Mode: MaxAvailability Databases: DB11R2SB - Primary database DB11R2 - Physical standby database Fast-Start Failover: DISABLED

________________________________________________________________


CambertzLonsulting

Configuration Status: SUCCESS Mehr Details bekommt man mit der Angabe Verbose:

DGMGRL>

DGMGRL> show database verbose 'DB11R2SB'; Database - DB11R2SB Role: PHYSICAL STANDBY Intended State: OFFLINE Transport Lag: (unknown) <-- Hier muß ein Wert stehen Apply Lag: (unknown) <-- Hier muß ein Wert stehen Real Time Query: OFF Instance(s): DB11R2 Properties: DGConnectIdentifier = 'db11r2sb' ObserverConnectIdentifier = '' LogXptMode = 'SYNC' DelayMins = '0' Binding = 'OPTIONAL' MaxFailure = '0' MaxConnections = '4' ReopenSecs = '300' NetTimeout = '10' RedoCompression = 'DISABLE' LogShipping = 'ON' PreferredApplyInstance = '' ApplyInstanceTimeout = '0' ApplyParallel = 'AUTO' StandbyFileManagement = 'AUTO' ArchiveLagTarget = '0' LogArchiveMaxProcesses = '5' LogArchiveMinSucceedDest = '1' DbFileNameConvert = '+DATA/db11r2, /opt/oracle/oradata/DB11R2' LogFileNameConvert = '+DATA/db11r2, /opt/oracle/oradata/DB11R2'

________________________________________________________________


CambertzLonsulting

FastStartFailoverTarget = '' InconsistentProperties = '(monitor)' InconsistentLogXptProps = '(monitor)' SendQEntries = '(monitor)' LogXptStatus = '(monitor)' RecvQEntries = '(monitor)' SidName = 'DB11R2' StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=olinux3.vm)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=DB11R2SB_DGMGRL.VM)(INSTANCE_NAME=DB11R2)(SERVER=DEDICATED)))' StandbyArchiveLocation = '/opt/oracle/oradata/DB11R2/archivelog/standby' AlternateLocation = '' LogArchiveTrace = '0' LogArchiveFormat = '%t_%s_%r.dbf' TopWaitEvents = '(monitor)' Database Status: DISABLED DGMGRL>

Mit der Verbose Anzeige erklärt sich nun auch, wer den neuen Service DB11R2SB_DGMGRL.VM nutzt, der über die Listener Konfiguration erstellt wurde.

"Transport Lag" und "Apply Lag" sind abzuwarten

SwitchOver ausführen Bevor ein SwitchOver eingeleitet wird, ist erst der Zustand des Standby Systems zu prüfen.

DGMGRL> show configuration; Configuration - DG_DB11R2 Protection Mode: MaxAvailability Databases: DB11R2 - Primary database DB11R2SB - Physical standby database (disabled) Fast-Start Failover: DISABLED

________________________________________________________________


CambertzLonsulting

Configuration Status: SUCCESS Hier war die Standby Datenbank zwar online aber nicht "enabled" und die letzten Transaktionen der Primärdatenbank waren nicht an die Standby Datenbank übertragen worden. Das wurde nachgeholt mit: DGMGRL> enable database 'DB11R2SB' Enabled. DGMGRL> show configuration; Configuration - DG_DB11R2 Protection Mode: MaxAvailability Databases: DB11R2 - Primary database DB11R2SB - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS DGMGRL>

Sicherheitshalber erfolgt die Prüfung, ob beide Datenbanken ordnungsgemäß arbeiten in den Datenbanken selbst:

Standby Datenbank:

SQL> SELECT database_role, protection_mode, protection_level, flashback_on, SWITCHOVER#, ACTIVATION# FROM v$database; 2 3 4 5 6 7 DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL FLASHBACK_ON

________________________________________________________________


CambertzLonsulting

---------------- -------------------- -------------------- ------------------ PHYSICAL STANDBY MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY YES

Primär Datenbank:

SQL> SELECT database_role, protection_mode, protection_level, flashback_on, SWITCHOVER#, ACTIVATION# FROM v$database; 2 3 4 5 6 7 DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL FLASHBACK_ON ---------------- -------------------- -------------------- ------------------ PRIMARY MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY YES

Wird für den Protetion_level= RESYNCHRONIZATION angezeigt, steht die Verbindung zwischen den Datenbanken nicht un eine SwitchOver sollte nicht vorgenommen werden.

Primär -> Standby Alle Datenbanken arbeiten wie erwartet und der SwitchOver kann erfolgen.

DGMGRL> switchover to 'DB11R2SB' Performing switchover NOW, please wait... New primary database "DB11R2SB" is opening... Operation requires shutdown of instance "DB11R21" on database "DB11R2" Shutting down instance "DB11R21"... ORACLE instance shut down. Operation requires startup of instance "DB11R21" on database "DB11R2" Starting instance "DB11R21"... ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance ORACLE instance started. Database mounted. Switchover succeeded, new primary is "DB11R2SB" DGMGRL>

DGMGRL> show database verbose 'DB11R2'

________________________________________________________________


CambertzLonsulting

Database - DB11R2 Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 0 seconds Apply Lag: 0 seconds Real Time Query: OFF Instance(s): DB11R21 (apply instance) DB11R22 Properties: DGConnectIdentifier = 'db11r2' ObserverConnectIdentifier = '' LogXptMode = 'SYNC' DelayMins = '0' Binding = 'optional' MaxFailure = '0' MaxConnections = '4' ReopenSecs = '300' NetTimeout = '10' RedoCompression = 'DISABLE' LogShipping = 'ON' PreferredApplyInstance = '' ApplyInstanceTimeout = '0' ApplyParallel = 'AUTO' StandbyFileManagement = 'AUTO' ArchiveLagTarget = '0' LogArchiveMaxProcesses = '5' LogArchiveMinSucceedDest = '1' DbFileNameConvert = '' LogFileNameConvert = '' FastStartFailoverTarget = '' InconsistentProperties = '(monitor)' InconsistentLogXptProps = '(monitor)' SendQEntries = '(monitor)' LogXptStatus = '(monitor)' RecvQEntries = '(monitor)' SidName(*) StaticConnectIdentifier(*) StandbyArchiveLocation(*)

________________________________________________________________


CambertzLonsulting

AlternateLocation(*) LogArchiveTrace(*) LogArchiveFormat(*) TopWaitEvents(*) (*) - Please check specific instance for the property value Database Status: SUCCESS DGMGRL>

Nur eine Instanz des RAC Clusters ist für das Redo Apply zuständig - DB11R21 (apply instance)

Standby -> Primär Nun kann wieder zurück geschwenkt werden:

DGMGRL> switchover to 'DB11R2'; Performing switchover NOW, please wait... New primary database "DB11R2" is opening... Operation requires shutdown of instance "DB11R2" on database "DB11R2SB" Shutting down instance "DB11R2"... ORACLE instance shut down. Operation requires startup of instance "DB11R2" on database "DB11R2SB" Starting instance "DB11R2"... Unable to connect to database ORA-12521: TNS:listener does not currently know of instance requested in connect descriptor Failed. Warning: You are no longer connected to ORACLE. Please complete the following steps to finish switchover: start up and mount instance "DB11R2" of database "DB11R2SB" DGMGRL>

An der Stelle ist ein Fehler aufgetreten, der schnell und einfach korrigiert werden kann, wenn die DB händisch gestartet wird. Dann zeigt sich nach einer Zeit das gewünschte Bild:

________________________________________________________________


CambertzLonsulting

DGMGRL> show configuration; Configuration - DG_DB11R2 Protection Mode: MaxAvailability Databases: DB11R2SB - Primary database DB11R2 - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS DGMGRL>

Due Fehlerursache war ein falscher Listener Eintrag auf der Standby Seite. Irrtümlich wurde die SID für die Stanby Datenbank eingetragen:

(SID_DESC = (GLOBAL_DBNAME = DB11R2SB_DGMGRL.VM) (ORACLE_HOME=/opt/oracle/product/11.2/db_1) (SID_NAME = DB11R2SB) )

anstatt:

(SID_DESC = (GLOBAL_DBNAME = DB11R2SB_DGMGRL.VM) (ORACLE_HOME=/opt/oracle/product/11.2/db_1) (SID_NAME = DB11R2) )

Transparent Application Failover (TAF) In der Literatur gerne verwendet soll ein Startup Trigger in die Standby und Primärdatenbank eingetragen werden um Service zu starten /stoppen. Dies ist nicht erforderlich, wenn, wie schon erwähnt, auf beiden DB Systemen ein Service mit gleichem Namen existiert:

________________________________________________________________


CambertzLonsulting

Primärdatenbank: SQL > show parameter service NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ service_names string DB11R2.VM, DB11R2_DGMGRL.VM Standby Datenbank: SQL - Primaer> show parameter service NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ service_names string DB11R2.VM, DB11R2SB_DGMGRL.VM

Der entsprechende TAF Connect Eintrag in der tnsnames.ora, welcher die Connects steuert:

DB11R2_TAF = (DESCRIPTION = (ADDRESS_LIST= (load_balance=off) (FAILOVER=ON) (ADDRESS = (PROTOCOL = TCP) (HOST = olinux.vm) (PORT = 1521) ) (ADDRESS = (PROTOCOL = TCP) (HOST = olinux3.vm) (PORT = 1521) ) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DB11R2.VM) (FAILOVER_MODE= (TYPE=SESSION) (METHOD=BASIC) (RETRIES=180) (DELAY=5)

________________________________________________________________


CambertzLonsulting

) ) )

Alle Verbindungen von Clients gegen die Datenbank sollten über TAF erfolgen, weil hier der FailOver Connect gewährleistet ist.

Test der Standby DB als Primärdatenbank Nun ist klar, daß ein SwitchOver fehlerfrei arbeitet. Wie verhält sich aber die Datenbank? Dazu wird erneut ein SwitchOver eingeleitet und die Standby ist anschließend die primäre Datenbank: DGMGRL> switchover to 'DB11R2SB' Performing switchover NOW, please wait... New primary database "DB11R2SB" is opening... Operation requires shutdown of instance "DB11R21" on database "DB11R2" Shutting down instance "DB11R21"... ORACLE instance shut down. Operation requires startup of instance "DB11R21" on database "DB11R2" Starting instance "DB11R21"... ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance ORACLE instance started. Database mounted. Switchover succeeded, new primary is "DB11R2SB" DGMGRL>

Damit ein Connect nicht auf die gemountete Datebank erfolgt (das kann TAF nicht unterscheiden), wird der RAC, der jetzt Standby ist, runter gefahren. Mit SQLPLUS wird eine TAF Verbindung hergestellt: [oracle@olinux3 ~]$ sqlplus system/manager@db11r2_taf SQL*Plus: Release 11.2.0.2.0 Production on Fri Feb 18 15:05:50 2011 Copyright (c) 1982, 2010, Oracle. All rights reserved.

________________________________________________________________


CambertzLonsulting

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production With the Partitioning and Real Application Testing options SQL> shpw parameter db_unique NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_unique_name string DB11R2SB SQL> create table lctest (id number(3), tex varchar2(60)); Table created. Nun wird der RAC wieder hochgefahren (was unbedeutend für den Test ist, weil keine neuen Verbindungen über den Listener ausfgebaut werden müssen) und der SwitchOver wieder rückgängig gemacht mit: DGMGRL> switchover to 'DB11R2SB'

In SQLPLUS besteht weiter die zuvor hergestellte Verbindung in die Datenbank. Es wurde kein ReConnect vorgenommen.

SQL> select * from dual; select * from dual * ERROR at line 1: ORA-25408: can not safely replay call

Diese Meldung sagt nur aus, daß der Schwenk noch nicht abgeschlossen ist. Einen Moment später:

SQL> select * from dual; D - X SQL> show parameter db_unique

________________________________________________________________


CambertzLonsulting

NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_unique_name string DB11R2 SQL> SQL> desc lctest Name Null? Type ----------------------------------------- -------- ---------------------------- ID NUMBER(3) TEX VARCHAR2(60) SQL>

Ohne daß die SQLPLUS Session beendet wurde (weder vom Anwender noch von Oracle) wurde die Datenbank Verbindung gewechselt und die Änderungen, welche auf der Standby Datenbank vorgenommen wurden, sind auf der Primärdatenbank gelandet. So wünscht man sich letztlich auch ein FailOver ;)

LISTENER.ORA Vorlage

Primärdatenbank SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = DB11R21) (ORACLE_HOME = /opt/oracle/product/11.2/db_1 ) (GLOBAL_DBNAME = DB11R21.VM) ) (SID_DESC = (SID_NAME = DB11R21) (ORACLE_HOME = /opt/oracle/product/11.2/db_1 ) (GLOBAL_DBNAME = DB11R2_DGMGRL.VM) ) ) LISTENER=

________________________________________________________________


CambertzLonsulting

(DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=IPC) (KEY=LISTENER) ) ) ) # line added by Agent LISTENER_SCAN1= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=IPC) (KEY=LISTENER_SCAN1) ) ) ) # line added by Agent ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN1=ON # line added by Agent ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON # line added by Agent

Standbydatenbank # listener.ora Network Configuration File: /opt/oracle/product/11.2/db_1/network/admin/listener.ora # Generated by Oracle configuration tools. LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = olinux3.vm)(PORT = 1521)) (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) ) ) SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = DB11R2SB_DGMGRL.VM) (ORACLE_HOME=/opt/oracle/product/11.2/db_1) (SID_NAME = DB11R2) ) (SID_DESC =

________________________________________________________________


CambertzLonsulting

(GLOBAL_DBNAME = DB11R2SB.VM) (ORACLE_HOME=/opt/oracle/product/11.2/db_1) (SID_NAME = DB11R2) ) ) ADR_BASE_LISTENER = /opt/oracle ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON

TNSNAMES.ORA Vorlage +ASM1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = olinux1.vm)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = +ASM) ) ) asm11g = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = olinux1.vm)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = +ASM) ) ) DB11R21 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = olinux1.vm) (PORT = 1521) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DB11R21.VM) # (UR=A)

________________________________________________________________


CambertzLonsulting

) ) DB11R22 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = olinux2.vm) (PORT = 1521) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DB11R22.VM) # (UR=A) ) ) DB11R2 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = olinux.vm) (PORT = 1521) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DB11R2.VM) # (UR=A) ) ) DB11R2_TAF = (DESCRIPTION = (ADDRESS_LIST= (load_balance=off) (FAILOVER=ON) (ADDRESS = (PROTOCOL = TCP) (HOST = olinux.vm) (PORT = 1521) )

________________________________________________________________


CambertzLonsulting

(ADDRESS = (PROTOCOL = TCP) (HOST = olinux3.vm) (PORT = 1521) ) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = DB11R2.VM) (FAILOVER_MODE= (TYPE=SESSION) (METHOD=BASIC) (RETRIES=180) (DELAY=5) ) ) ) DB11R2SB = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = olinux3.vm) (PORT = 1521) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME=DB11R2SB.VM) ) )

Probleme erkennen Bei der Anzahl an Datenbanken, die ein Oracle DBA heute im Regelfall zu betreuen hat, kann er sich nicht mehr um die Alert.log Dateien einzelner Datenbanken kümmern und ist angewiesen auf Tools wie "NAGIOS", die die Überwachung übernehmen.

Meldungen wie die folgenden gehen aber oft verloren, weil sie nicht mit dem typischen "ORA-" beginnen, oder nicht im Alert.log eingetragen werden sondern in der drSID.log Datei des DataGuard.

________________________________________________________________


CambertzLonsulting

Es ist somit zwingend erforderlich, auch die Log Datei des Dataguard Broker auf Fehler zu überwachen.

Beispiel :

Error 1034 received logging on to the standby

PING[ARC2]: Heartbeat failed to connect to standby 'db11r2sb'. Error is 1034.

Das ein Fehler vorliegt kann man in der Datenbank auch erkennen, wenn auch nicht die Fehlerursache: SQL> SELECT database_role, protection_mode, protection_level FROM v$database; DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL ---------------- -------------------- -------------------- PRIMARY MAXIMUM AVAILABILITY RESYNCHRONIZATION Und so sollte die Ausgabe aussehen, wenn alles fehlerfrei arbeitet: DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL ---------------- -------------------- -------------------- PRIMARY MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY

DGMGRL DGMGRL> show configuration

Configuration - DG_DB11R2

Protection Mode: MaxAvailability

Databases:

DB11R2 - Primary database

DB11R2SB - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

________________________________________________________________


CambertzLonsulting

DGMGRL>

Der Dataguard Manager behauptet, daß alles fehlerfrei arbeitet. Das Logfile drcXXX.log zeigt aber etwas anderes:

RSM0: HEALTH CHECK ERROR: ORA-16737: the redo transport service for standby database "DB11R2SB" has an error

Nur wenn der HEALTHCHECK erfolgreich war, ist das System ohne Fehler. Das sieht so aus:

2011-02-11 20:00:03.316 00001000 1653045540 DMON: start task execution: client healthcheck

2011-02-11 20:00:03.318 INSV: Received message for inter-instance publication

Was, wenn der SwitchOver schief geht Wenn der DGMGRL den SwitchOver abbricht, hat er meist schon Arbeiten an einer oder beiden Datenbank ausgeführt und es liegt ein Schwebezustand vor, weil diese Änderungen nicht zurück genommen werden. Das muß händisch erfolgen.

Als erstes findet man heraus, welche Rolle die jeweilige Datenbank im Moment hat:

SQL> SELECT database_role FROM v$database; DATABASE_ROLE ---------------- PRIMARY

Die Rolle einer Datenbank bekommt man geändert:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY (with session shutdown); Nun muß die Datenbank allerdings einen Shutdown und startup bekommen: Für eine Datenbank ohne CRS: SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; Für einen RAC:

________________________________________________________________


CambertzLonsulting

# srvctl stop database -d db11r2 # srvctl start database -d db11r2 -o mount Die RAC Datenbank hat nun den Primärstatus verloren und ist Standby:

Das geht auch umgekehrt

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY (with session shutdown); Für eine Standby Datenbank ohne CRS: SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP; Für einen RAC: # srvctl stop database -d db11r2sb # srvctl start database -d db11r2sb Die Standby Datenbank hat nun den Primärstatus:

Documents

Konfiguration Dataguard für Oracle 11.2 · [1] , [email protected] CL ambertz onsulting Konfiguration Dataguard für Oracle 11.2.02