Konfiguration Dataguard für Oracle 11.2.02 - Lambertz
Werbung
CL ________________________________________________________________ ambertz onsulting 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 [1] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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) ) [2] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting ) ) # 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 = [3] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting (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. [4] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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... [5] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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='*'; [6] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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: [7] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting $ORACLE_BASE/diag/rdbms/${ORACLE_UNQNAME}/${ORACLE_SID}/trace/d rc${ORACLE_SID}.log $ORACLE_BASE/diag/rdbms/${ORACLE_UNQNAME}/${ORACLE_SID}/trace/d alert${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 '+DATA'; 'StandbyArchiveLocation' = 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> DGMGRL> DGMGRL> DGMGRL> edit edit edit edit database database database database 'DB11R2' set property 'LogXptMode'='SYNC'; 'DB11R2SB' set property 'LogXptMode'='SYNC'; 'DB11R2' set property 'NetTimeout'=10; 'DB11R2SB' set property 'NetTimeout'=10; DGMGRL> edit configuration set protection mode as MaxAvailability; !! Dazu müssen aber die Standby Redologs angelegt sein !! [8] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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 [9] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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> SQL> SQL> SQL> SQL> ALTER ALTER ALTER ALTER ALTER DATABASE DATABASE DATABASE DATABASE DATABASE ADD ADD ADD ADD ADD STANDBY STANDBY STANDBY STANDBY STANDBY LOGFILE LOGFILE LOGFILE LOGFILE LOGFILE THREAD THREAD THREAD THREAD THREAD 1 1 1 1 1 SIZE SIZE SIZE SIZE SIZE 50M; 50M; 50M; 50M; 50M; SQL> SQL> SQL> SQL> SQL> ALTER ALTER ALTER ALTER ALTER DATABASE DATABASE DATABASE DATABASE DATABASE ADD ADD ADD ADD ADD STANDBY STANDBY STANDBY STANDBY STANDBY LOGFILE LOGFILE LOGFILE LOGFILE LOGFILE THREAD THREAD THREAD THREAD THREAD 2 2 2 2 2 SIZE SIZE SIZE SIZE SIZE 50M; 50M; 50M; 50M; 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 [10] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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) Apply Lag: (unknown) Real Time Query: OFF Instance(s): DB11R2 <-- Hier muß ein Wert stehen <-- Hier muß ein Wert stehen 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' [11] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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=(SE RVICE_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 [12] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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 [13] PROTECTION_LEVEL FLASHBACK_ON http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting ---------------- -------------------- -------------------- -----------------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' [14] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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(*) [15] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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: [16] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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: [17] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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) [18] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting ) ) ) 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. [19] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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 [20] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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= [21] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting (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 = [22] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting (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) [23] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting ) ) 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) ) [24] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting (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. [25] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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 [26] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting 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: [27] http://www.lambertz-consulting.de, [email protected] CL ________________________________________________________________ ambertz onsulting # 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: [28] http://www.lambertz-consulting.de, [email protected]
