{"id":185,"date":"2014-12-12T23:17:51","date_gmt":"2014-12-13T02:17:51","guid":{"rendered":"http:\/\/www.fernandosimon.com\/blog\/?p=185"},"modified":"2015-01-25T22:58:03","modified_gmt":"2015-01-26T01:58:03","slug":"oracle-e-maa-artigo-ix-failover-automatico","status":"publish","type":"post","link":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/","title":{"rendered":"Oracle e MAA \u2013 Artigo IX \u2013 Failover Autom\u00e1tico"},"content":{"rendered":"

Neste pen\u00faltimo da s\u00e9rie sobre MAA com Oracle RAC 11GR2 vou falar um pouco sobre como ocorre o failover autom\u00e1tico em caso de falha do primary. Vou demonstrar que basicamente voc\u00ea n\u00e3o faz nada, todo o trabalho \u201csujo\u201d ser\u00e1 pelo pr\u00f3prio Oracle.<\/p>\n

NONO ARTIGO<\/strong><\/p>\n

Este artigo ir\u00e1 mostrar como o MAA resolve de forma autom\u00e1tica todos os pontos de um failover. Claro que para isso voc\u00ea tem que ter tudo devidamente configurado e operacional. Voc\u00ea vai precisar de um Observer configurado e o Fast-Start Failover habilitado (como demonstrado aqui<\/a>) bem como um Broker operacional (veja aqui<\/a>). Se voc\u00ea leu os artigos anteriores voc\u00ea j\u00e1 tem tudo isso configurado e n\u00e3o ir\u00e1 se preocupar com mais nada.<\/p>\n

AMBIENTE<\/strong><\/p>\n

At\u00e9 o momento voc\u00ea tem um banco de dados primary (maa<\/em>) e um banco de dados standby (maastb<\/em>) sincronizados em Maximum Availability (com Real-Time no envio de redo). Al\u00e9m disso o Fast-Start Failover est\u00e1 habilitado.<\/p>\n

J\u00e1 aviso que o artigo pode ser extenso devido aos logs, tentarei suprimir as informa\u00e7\u00f5es que n\u00e3o s\u00e3o necess\u00e1rias. Mas mesmo assim recomendo a leitura para compreender tudo o que ocorre.<\/p>\n

<\/p>\n

FAILOVER AUTOM\u00c1TICO<\/strong><\/p>\n

Neste artigo voc\u00ea vai ver que os comandos executados ser\u00e3o exclusivamente para monitoramento das atividades, tudo o que voc\u00ea precisava fazer j\u00e1 foi feito. O que acontecer\u00e1 abaixo \u00e9 uma simula\u00e7\u00e3o do que voc\u00ea veria em um ambiente real, voc\u00ea n\u00e3o vai querer que ocorra isso no seu ambiente de produ\u00e7\u00e3o, n\u00e3o \u00e9? Mas se voc\u00ea chegou at\u00e9 aqui j\u00e1 tem configurado um ambiente com MAA e Oracle RAC e isso j\u00e1 denota a import\u00e2ncia do ambiente e que deseja estar protegido das adversidades.<\/p>\n

Como um failover autom\u00e1tico n\u00e3o acontece \u201cnaturalmente\u201d na vida real, vamos simular com um abort em todas as inst\u00e2ncias do primary:<\/p>\n

[oracle@rac11pri01 ~]$ srvctl stop database -d maa -o abort\r\n<\/pre>\n
Note que o log do Observer j\u00e1 detectou isso:<\/p>\n
[W000 07\/28 21:57:00.35] Observer started.\r\n\r\n23:43:15.41 Monday, July 28, 2014\r\nInitiating Fast-Start Failover to database \"maastb\"...\r\nPerforming failover NOW, please wait...\r\nFailover succeeded, new primary is \"maastb\"\r\n23:45:11.19 Monday, July 28, 2014\r\n<\/pre>\n
Como visto acima, em 3 minutos ocorreu o failover completo do ambiente, o banco maastb passou a responder como novo primary. Claro que esse tempo depender\u00e1 do tamanho de sua base de dados mas vamos ver como tudo isso aconteceu \u201cde verdade\u201d.<\/p>\n
No log do Broker (da inst\u00e2ncia maastb01) temos informa\u00e7\u00f5es mais interessantes, veja abaixo:<\/p>\n
07\/29\/2014 02:23:36\r\nFast-Start Failover cannot proceed because: \"standby has connectivity to the primary\"<\/strong>\r\n07\/29\/2014 02:23:38\r\nFAILOVER TO maastb<\/strong>\r\n07\/29\/2014 02:23:39\r\nBeginning failover to database maastb\r\nNotifying Oracle Clusterware to teardown database for FAILOVER\r\n07\/29\/2014 02:24:20\r\nDMON: Old primary \"maa\" needs reinstatement<\/strong>\r\n07\/29\/2014 02:25:07\r\nProtection mode set to MAXIMUM AVAILABILITY\r\n07\/29\/2014 02:25:27\r\nDeferring associated archivelog destinations of sites permanently disabled due to Failover\r\nNotifying Oracle Clusterware to buildup primary database after FAILOVER\r\nData Guard notifying Oracle Clusterware to start services and other instances change\r\n07\/29\/2014 02:25:30\r\nPosting DB_DOWN alert ...\r\n\t\t... with reason Data Guard Fast-Start Failover - Primary Disconnected\r\n07\/29\/2014 02:25:32\r\nCommand FAILOVER TO maastb completed\r\n07\/29\/2014 02:25:35\r\nData Guard Broker Status Summary:\r\n  Type                        Name                             Severity  Status\r\n  Configuration               dgrac                             Warning  ORA-16608\r\n  Primary Database            maastb                            Warning  ORA-16817\r\n  Physical Standby Database   maa                                 Error  ORA-16661\r\n07\/29\/2014 02:26:34\r\nData Guard Broker Status Summary:\r\n  Type                        Name                             Severity  Status\r\n  Configuration               dgrac                             Warning  ORA-16608\r\n  Primary Database            maastb                            Warning  ORA-16817\r\n  Physical Standby Database   maa                                 Error  ORA-16661\r\n<\/pre>\n
Deixei em negrito algumas informa\u00e7\u00f5es, mas observe que que o antigo primary precisar\u00e1 sofrer o reinstate assim que foi iniciado (j\u00e1 que ocorreu um failover) e que existem mensagens de erro informando que n\u00e3o h\u00e1\u00a0nenhum destino para manter a disponibilidade desejada.<\/p>\n
Mas existem locais que podem nos dar mais detalhes do que ocorreu (dos passos) e isso est\u00e1 no alertlog da antiga standby. No log abaixo eu suprimi os erros de TNS entre as bases, mas deixei em negrito pontos importantes.<\/p>\n
[root@rac11stb01 ~]# tail -f \/u01\/app\/oracle\/diag\/rdbms\/maastb\/maastb1\/trace\/alert_maastb1.log\r\nTue Jul 29 02:22:36 2014\r\nRFS[15]: Possible network disconnect with primary database\r\nTue Jul 29 02:22:36 2014\r\nRFS[13]: Possible network disconnect with primary database\r\nTue Jul 29 02:22:36 2014\r\nRFS[18]: Possible network disconnect with primary database\r\nTue Jul 29 02:22:37 2014\r\nRFS[19]: Possible network disconnect with primary database\r\nTue Jul 29 02:22:37 2014\r\nRFS[17]: Possible network disconnect with primary database\r\nTue Jul 29 02:23:37 2014\r\nAttempting Fast-Start Failover because the threshold of 60 seconds has elapsed.<\/strong>\r\nTue Jul 29 02:23:39 2014\r\nData Guard Broker: Beginning failover\r\nTue Jul 29 02:23:44 2014\r\nALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL<\/strong>\r\nTue Jul 29 02:23:45 2014\r\nMRP0: Background Media Recovery cancelled with status 16037\r\nErrors in file \/u01\/app\/oracle\/diag\/rdbms\/maastb\/maastb1\/trace\/maastb1_pr00_3786.trc:\r\nORA-16037: user requested cancel of managed recovery operation\r\nTue Jul 29 02:23:45 2014\r\nManaged Standby Recovery not using Real Time Apply\r\nRecovery interrupted!\r\nRecovered data files to a consistent state at change 19932270\r\nTue Jul 29 02:23:49 2014\r\nMRP0: Background Media Recovery process shutdown (maastb1)\r\nManaged Standby Recovery Canceled (maastb1)\r\nCompleted: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL\r\nALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE<\/strong>\r\nAttempt to do a Terminal Recovery (maastb1)\r\nMedia Recovery Start: Managed Standby Recovery (maastb1)\r\n started logmerger process\r\nTue Jul 29 02:23:55 2014\r\nManaged Standby Recovery not using Real Time Apply\r\nTue Jul 29 02:23:57 2014\r\nParallel Media Recovery started with 2 slaves\r\nTue Jul 29 02:24:00 2014\r\nBegin: Standby Redo Logfile archival\r\nEnd: Standby Redo Logfile archival\r\nTerminal Recovery timestamp is '07\/29\/2014 02:24:00'\r\nTerminal Recovery: applying standby redo logs.\r\nTerminal Recovery: thread 1 seq# 1181 redo required\r\nTerminal Recovery:\r\nRecovery of Online Redo Log: Thread 1 Group 6 Seq 1181 Reading mem 0\r\n  Mem# 0: +DG01\/maastb\/onlinelog\/group_6.267.844716079\r\n  Mem# 1: +FRA\/maastb\/onlinelog\/group_6.604.844716081\r\nIdentified End-Of-Redo (failover) for thread 1 sequence 1181 at SCN 0xffff.ffffffff\r\nTerminal Recovery: thread 2 seq# 1395 redo required\r\nTerminal Recovery:\r\nRecovery of Online Redo Log: Thread 2 Group 9 Seq 1395 Reading mem 0\r\n  Mem# 0: +DG01\/maastb\/onlinelog\/group_9.260.844716095\r\n  Mem# 1: +FRA\/maastb\/onlinelog\/group_9.591.844716097\r\nIdentified End-Of-Redo (failover) for thread 2 sequence 1395 at SCN 0xffff.ffffffff\r\nIncomplete Recovery applied until change 19932272 time 07\/29\/2014 05:42:13\r\nMedia Recovery Complete (maastb1)\r\nTerminal Recovery: successful completion\r\nTue Jul 29 02:24:02 2014\r\nARC0: Archiving not possible: error count exceeded\r\nTue Jul 29 02:24:03 2014\r\nARC3: Archiving not possible: error count exceeded\r\nForcing ARSCN to IRSCN for TR 0:19932272\r\nAttempt to set limbo arscn 0:19932272 irscn 0:19932272\r\nResetting standby activation ID 728027883 (0x2b64d2eb)\r\nARCH: Archival stopped, error occurred. Will continue retrying\r\nORACLE Instance maastb1 - Archival Error\r\nORA-16014: log 6 sequence# 1181 not archived, no available destinations\r\nORA-00312: online log 6 thread 1: '+DG01\/maastb\/onlinelog\/group_6.267.844716079'\r\nORA-00312: online log 6 thread 1: '+FRA\/maastb\/onlinelog\/group_6.604.844716081'\r\nCompleted: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE\r\nALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WAIT WITH SESSION SHUTDOWN\r\nALTER DATABASE SWITCHOVER TO PRIMARY (maastb1)<\/strong>\r\nMaximum wait for role transition is 15 minutes.\r\nBackup controlfile written to trace file \/u01\/app\/oracle\/diag\/rdbms\/maastb\/maastb1\/trace\/maastb1_rsm0_3741.trc\r\nTue Jul 29 02:24:08 2014\r\nStandby terminal recovery start SCN: 19932270\r\nRESETLOGS after incomplete recovery UNTIL CHANGE 19932272<\/strong>\r\nOnline log +DG01\/maastb\/onlinelog\/group_1.257.844716051: Thread 1 Group 1 was previously cleared\r\nOnline log +FRA\/maastb\/onlinelog\/group_1.568.844716053: Thread 1 Group 1 was previously cleared\r\nOnline log +DG01\/maastb\/onlinelog\/group_2.268.844716057: Thread 1 Group 2 was previously cleared\r\nOnline log +FRA\/maastb\/onlinelog\/group_2.564.844716059: Thread 1 Group 2 was previously cleared\r\nOnline log +DG01\/maastb\/onlinelog\/group_3.269.844716063: Thread 2 Group 3 was previously cleared\r\nOnline log +FRA\/maastb\/onlinelog\/group_3.562.844716065: Thread 2 Group 3 was previously cleared\r\nOnline log +DG01\/maastb\/onlinelog\/group_4.270.844716067: Thread 2 Group 4 was previously cleared\r\nOnline log +FRA\/maastb\/onlinelog\/group_4.559.844716071: Thread 2 Group 4 was previously cleared\r\nStandby became primary SCN: 19932269\r\nTue Jul 29 02:24:12 2014\r\nSetting recovery target incarnation to 4\r\nSwitchover: Complete - Database mounted as primary\r\nCompleted: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WAIT WITH SESSION SHUTDOWN\r\nTue Jul 29 02:24:20 2014\r\nALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY\r\nCompleted: ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY\r\nALTER DATABASE OPEN<\/strong>\r\nData Guard Broker initializing...\r\nThis instance was first to open\r\nPicked broadcast on commit scheme to generate SCNs\r\nTue Jul 29 02:24:21 2014\r\nAssigning activation ID 732752315 (0x2bace9bb)\r\nLGWR: Primary database is in MAXIMUM AVAILABILITY mode\r\nDestination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED<\/strong>\r\nLGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR\r\nThread 1 advanced to log sequence 2 (thread open)\r\nTue Jul 29 02:24:22 2014\r\nARC3: Becoming the 'no SRL' ARCH\r\nTue Jul 29 02:24:22 2014\r\nARC0: Becoming the 'no SRL' ARCH\r\nThread 1 opened at log sequence 2\r\n  Current log# 2 seq# 2 mem# 0: +DG01\/maastb\/onlinelog\/group_2.268.844716057\r\n  Current log# 2 seq# 2 mem# 1: +FRA\/maastb\/onlinelog\/group_2.564.844716059\r\nSuccessful open of redo thread 1\r\nMTTR advisory is disabled because FAST_START_MTTR_TARGET is not set\r\nTue Jul 29 02:24:23 2014\r\nSMON: enabling cache recovery\r\nTue Jul 29 02:24:23 2014\r\n...\r\n...\r\n...\r\nTNS-12564: TNS:connection refused\r\n\tns secondary err code: 0\r\n\tnt main err code: 0\r\n\tnt secondary err code: 0\r\n\tnt OS err code: 0\r\nError 12514 received logging on to the standby\r\nPING[ARC2]: Heartbeat failed to connect to standby 'maa'. Error is 12514.\r\nInstance recovery: looking for dead threads\r\nInstance recovery: lock domain invalid but no dead threads\r\nTue Jul 29 02:24:30 2014\r\nFSFP started with pid=40, OS id=9787\r\nTue Jul 29 02:24:34 2014\r\nminact-scn: Inst 1 is a slave inc#:4 mmon proc-id:3596 status:0x2\r\nminact-scn status: grec-scn:0x0000.00000000 gmin-scn:0x0000.00000000 gcalc-scn:0x0000.00000000\r\nTue Jul 29 02:24:37 2014\r\n[3741] Successfully onlined Undo Tablespace 2.\r\nUndo initialization finished serial:0 start:8127994 end:8132374 diff:4380 (43 seconds)\r\nVerifying file header compatibility for 11g tablespace encryption..\r\nVerifying 11g file header compatibility for tablespace encryption completed\r\nTue Jul 29 02:24:37 2014\r\nSMON: enabling tx recovery\r\nDatabase Characterset is WE8MSWIN1252\r\nTue Jul 29 02:24:48 2014\r\nNo Resource Manager plan active\r\nStarting background process GTX0\r\nTue Jul 29 02:24:57 2014\r\nGTX0 started with pid=41, OS id=9799\r\nStarting background process RCBG\r\nTue Jul 29 02:24:57 2014\r\nRCBG started with pid=45, OS id=9802\r\nreplication_dependency_tracking turned off (no async multimaster replication found)\r\nTue Jul 29 02:24:59 2014\r\nStarting background process QMNC\r\nTue Jul 29 02:24:59 2014\r\nQMNC started with pid=46, OS id=9804\r\nCompleted: ALTER DATABASE OPEN\r\nALTER SYSTEM SET log_archive_trace=0 SCOPE=BOTH SID='maastb1';\r\nALTER SYSTEM SET log_archive_format='arch_%t_%s_%r.arc' SCOPE=SPFILE SID='maastb1';\r\nTue Jul 29 02:25:18 2014\r\n...\r\n...\r\n...\r\nTNS-12564: TNS:connection refused\r\n\tns secondary err code: 0\r\n\tnt main err code: 0\r\n\tnt secondary err code: 0\r\n\tnt OS err code: 0\r\nError 12514 received logging on to the standby\r\nPING[ARC2]: Heartbeat failed to connect to standby 'maa'. Error is 12514.\r\nTue Jul 29 02:25:20 2014\r\nALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH SID='*';\r\nTue Jul 29 02:25:20 2014\r\nSetting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter\r\nTue Jul 29 02:25:20 2014\r\nStarting background process VKRM\r\nTue Jul 29 02:25:20 2014\r\nVKRM started with pid=49, OS id=9823\r\nTue Jul 29 02:25:22 2014\r\nStarting background process CJQ0\r\nTue Jul 29 02:25:22 2014\r\nCJQ0 started with pid=58, OS id=9838\r\nALTER SYSTEM SET archive_lag_target=0 SCOPE=BOTH SID='*';\r\nALTER SYSTEM SET log_archive_max_processes=4 SCOPE=BOTH SID='*';\r\nALTER SYSTEM SET log_archive_min_succeed_dest=1 SCOPE=BOTH SID='*';\r\nALTER SYSTEM SET db_file_name_convert='+DATA\/maa','+DG01\/maastb','+FRA\/maa','+FRA\/maastb' SCOPE=SPFILE;\r\nALTER SYSTEM SET log_file_name_convert='+DATA\/maa','+DG01\/maastb','+FRA\/maa','+FRA\/maastb' SCOPE=SPFILE;\r\nSetting Resource Manager plan SCHEDULER[0x3189]:DEFAULT_MAINTENANCE_PLAN via scheduler window\r\nSetting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter\r\nTue Jul 29 02:25:27 2014\r\nStarting background process SMCO\r\nTue Jul 29 02:25:27 2014\r\nSMCO started with pid=56, OS id=9845\r\nTue Jul 29 02:25:28 2014\r\nALTER SYSTEM SET log_archive_dest_state_2='RESET' SCOPE=BOTH;\r\nTue Jul 29 02:25:28 2014\r\nActive Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring issue, you may consider increasing ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 4194304 bytes. Both ASH size and the total number of emergency flushes since instance startup can be monitored by running the following query:\r\n select total_size,awr_flush_emergency_count from v$ash_info;\r\nFailover succeeded. Primary database is now maastb.\r\n<\/pre>\n
Observe que no come\u00e7o do alertlog temos informa\u00e7\u00f5es que o primary pode estar indispon\u00edvel e ap\u00f3s 60 segundos (que defini quando configurei o Fast-Start Faiolver) o failover autom\u00e1tico iniciou. Depois disso tivemos o cancelamento da aplica\u00e7\u00e3o dos redo\u2019s por parte do standby. Um pouco mais abaixo tivemos o switchover da base para primary e a informa\u00e7\u00e3o de qual o SCN utilizado como ponto de virada (RESETLOGS after incomplete recovery UNTIL CHANGE 19932272<\/em>). Ap\u00f3s isso tivemos a abertura da base em modo OPEN e que o destino archive_dest 2 est\u00e1 dessincronizado (isso \u00e9 normal j\u00e1 que o antigo primary est\u00e1 fora).<\/p>\n
No Broker temos a configura\u00e7\u00e3o demonstrada abaixo, observe que o banco maastb j\u00e1 aparece listado como primary e o banco maa est\u00e1 com erro. Al\u00e9m disso o Fast-Start Failover est\u00e1 ativo e tamb\u00e9m que o antigo primary deve sofrer resinstate ao ser iniciado.<\/p>\n
[oracle@rac11stb01 ~]$ dgmgrl\r\nDGMGRL for Linux: Version 11.2.0.3.0 - 64bit Production\r\n\r\nCopyright (c) 2000, 2009, Oracle. All rights reserved.\r\n\r\nWelcome to DGMGRL, type \"help\" for information.\r\nDGMGRL> connect sys@maastb\r\nPassword:\r\nConnected.\r\nDGMGRL> SHOW CONFIGURATION VERBOSE;\r\n\r\nConfiguration - dgrac\r\n\r\n  Protection Mode: MaxAvailability\r\n  Databases:\r\n\tmaastb - Primary database\r\n\t  Warning: ORA-16817: unsynchronized fast-start failover configuration\r\n\r\n\tmaa    - (*) Physical standby database (disabled)\r\n\t  ORA-16661: the standby database needs to be reinstated\r\n\r\n  (*) Fast-Start Failover target\r\n\r\n  Properties:\r\n\tFastStartFailoverThreshold      = '60'\r\n\tOperationTimeout                = '30'\r\n\tFastStartFailoverLagLimit       = '30'\r\n\tCommunicationTimeout            = '180'\r\n\tFastStartFailoverAutoReinstate  = 'TRUE'\r\n\tFastStartFailoverPmyShutdown    = 'TRUE'\r\n\tBystandersFollowRoleChange      = 'ALL'\r\n\r\nFast-Start Failover: ENABLED\r\n\r\n  Threshold:        60 seconds\r\n  Target:           maa\r\n  Observer:         sbdobs\r\n  Lag Limit:        30 seconds (not in use)\r\n  Shutdown Primary: TRUE\r\n  Auto-reinstate:   TRUE\r\n\r\nConfiguration Status:\r\nWARNING\r\n\r\nDGMGRL>\r\nDGMGRL> SHOW DATABASE maa;\r\n\r\nDatabase - maa\r\n\r\n  Role:            PHYSICAL STANDBY\r\n  Intended State:  APPLY-ON\r\n  Transport Lag:   (unknown)\r\n  Apply Lag:       (unknown)\r\n  Real Time Query: OFF\r\n  Instance(s):\r\n\tmaa1\r\n\tmaa2\r\n\r\nDatabase Status:\r\nORA-16661: the standby database needs to be reinstated\r\n\r\nDGMGRL> SHOW DATABASE maastb;\r\n\r\nDatabase - maastb\r\n\r\n  Role:            PRIMARY\r\n  Intended State:  TRANSPORT-ON\r\n  Instance(s):\r\n\tmaastb1\r\n\tmaastb2\r\n\r\n  Database Warning(s):\r\n\tORA-16817: unsynchronized fast-start failover configuration\r\n\r\nDatabase Status:\r\nWARNING\r\n\r\nDGMGRL>\r\n<\/pre>\n
Como j\u00e1 aconteceu em artigos anteriores, o CRS precisa de um ajuste manual para que o novo primary sempre inicie em modo OPEN:<\/p>\n
[oracle@rac11stb01 ~]$ srvctl config database -d maastb -v\r\nDatabase unique name: maastb\r\nDatabase name:\r\nOracle home: \/u01\/app\/oracle\/product\/11.2.0.3\/db_1\r\nOracle user: oracle\r\nSpfile:\r\nDomain:\r\nStart options: mount\r\nStop options: immediate\r\nDatabase role: PRIMARY\r\nManagement policy: AUTOMATIC\r\nServer pools: maastb\r\nDatabase instances: maastb1,maastb2\r\nDisk Groups: DG01,FRA\r\nMount point paths:\r\nServices:\r\nType: RAC\r\nDatabase is administrator managed\r\n[oracle@rac11stb01 ~]$ srvctl modify database -d maastb -s OPEN\r\n[oracle@rac11stb01 ~]$ srvctl config database -d maastb -v\r\nDatabase unique name: maastb\r\nDatabase name:\r\nOracle home: \/u01\/app\/oracle\/product\/11.2.0.3\/db_1\r\nOracle user: oracle\r\nSpfile:\r\nDomain:\r\nStart options: open\r\nStop options: immediate\r\nDatabase role: PRIMARY\r\nManagement policy: AUTOMATIC\r\nServer pools: maastb\r\nDatabase instances: maastb1,maastb2\r\nDisk Groups: DG01,FRA\r\nMount point paths:\r\nServices:\r\nType: RAC\r\nDatabase is administrator managed\r\n[oracle@rac11stb01 ~]$\r\n<\/pre>\n
RELIGANDO O BANCO<\/strong><\/p>\n
Voc\u00ea deve ter notado acima que o antigo primary ainda n\u00e3o foi religado, se voc\u00ea o iniciar\u00a0agora ele ir\u00e1 sofrer o reinstate e voltar\u00e1 como novo standby. De qualquer forma recomendo que antes de ligar o antigo primary verificar o motivo da queda, n\u00e3o adianta ter um ambiente standby que n\u00e3o \u00e9 confi\u00e1vel. Muitas vezes \u00e9 imposs\u00edvel religar o antigo primary e neste caso voc\u00ea precisa remover ele do Broker e adicionar um novo standby.<\/p>\n
Supondo que voc\u00ea consiga religar o antigo primary e deixar ele est\u00e1vel ver\u00e1 algo parecido com o alertlog abaixo. \u00c9 um log com muita informa\u00e7\u00e3o: o banco tentar\u00e1 abrir em modo OPEN e o DataGuard ir\u00e1 informar que ele n\u00e3o \u00e9 mais o novo primary. O banco sofrer\u00e1 flashback para o SCN detectado como ponto de recover e ser\u00e1 convertido em physical standby. Por fim um restart do banco e defini\u00e7\u00e3o deste como standby juntamente com a sincroniza\u00e7\u00e3o dos archives com o primary. Tudo isso est\u00e1 em negrito no log abaixo.<\/p>\n
[root@rac11pri01 ~]# tail -f \/u01\/app\/oracle\/diag\/rdbms\/maa\/maa1\/trace\/alert_maa\r\n  Current log# 1 seq# 1181 mem# 1: +FRA\/maa\/onlinelog\/group_1.286.843488555\r\nTue Jul 29 04:30:00 2014\r\nArchived Log entry 5432 added for thread 1 sequence 1180 ID 0x2b64d2eb dest 1:\r\nTue Jul 29 05:42:12 2014\r\nShutting down instance (abort)<\/strong>\r\nLicense high water mark = 7\r\nUSER (ospid: 3606): terminating the instance\r\nInstance terminated by USER, pid = 3606\r\nTue Jul 29 05:42:17 2014\r\nInstance shutdown complete\r\nTue Jul 29 06:16:58 2014\r\nStarting ORACLE instance (normal)\r\n****************** Large Pages Information *****************\r\n\r\nTotal Shared Global Region in Large Pages = 0 KB (0%)\r\n\r\nLarge Pages used by this instance: 0 (0 KB)\r\nLarge Pages unused system wide = 0 (0 KB) (alloc incr 4096 KB)\r\nLarge Pages configured system wide = 0 (0 KB)\r\nLarge Page size = 2048 KB\r\n\r\nRECOMMENDATION:\r\n  Total Shared Global Region size is 1026 MB. For optimal performance,\r\n  prior to the next instance restart increase the number\r\n  of unused Large Pages by atleast 513 2048 KB Large Pages (1026 MB)\r\n  system wide to get 100% of the Shared\r\n  Global Region allocated with Large pages\r\n***********************************************************\r\nLICENSE_MAX_SESSION = 0\r\nLICENSE_SESSIONS_WARNING = 0\r\nPrivate Interface 'eth2:1' configured from GPnP for use as a private interconnect.\r\n  [name='eth2:1', type=1, ip=169.254.187.5, mac=00-0c-29-8c-91-79, net=169.254.0.0\/16, mask=255.255.0.0, use=haip:cluster_interconnect\/62]\r\nPublic Interface 'eth0' configured from GPnP for use as a public interface.\r\n  [name='eth0', type=1, ip=10.17.42.10, mac=00-0c-29-8c-91-65, net=10.17.42.0\/26, mask=255.255.255.192, use=public\/1]\r\nPublic Interface 'eth0:2' configured from GPnP for use as a public interface.\r\n  [name='eth0:2', type=1, ip=10.17.42.22, mac=00-0c-29-8c-91-65, net=10.17.42.0\/26, mask=255.255.255.192, use=public\/1]\r\nPublic Interface 'eth0:4' configured from GPnP for use as a public interface.\r\n  [name='eth0:4', type=1, ip=10.17.42.17, mac=00-0c-29-8c-91-65, net=10.17.42.0\/26, mask=255.255.255.192, use=public\/1]\r\nPublic Interface 'eth0:5' configured from GPnP for use as a public interface.\r\n  [name='eth0:5', type=1, ip=10.17.42.14, mac=00-0c-29-8c-91-65, net=10.17.42.0\/26, mask=255.255.255.192, use=public\/1]\r\nPicked latch-free SCN scheme 3\r\nAutotune of undo retention is turned on.\r\nLICENSE_MAX_USERS = 0\r\nSYS auditing is disabled\r\nStarting up:\r\nOracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production\r\nWith the Partitioning and Real Application Clusters options.\r\nORACLE_HOME = \/u01\/app\/oracle\/product\/11.2.0.3\/db_1\r\nSystem name:    Linux\r\nNode name:      rac11pri01.tjsc.jus.br\r\nRelease:        2.6.39-400.17.1.el6uek.x86_64\r\nVersion:        #1 SMP Fri Feb 22 18:16:18 PST 2013\r\nMachine:        x86_64\r\nVM name:        VMWare Version: 6\r\nUsing parameter settings in server-side pfile \/u01\/app\/oracle\/product\/11.2.0.3\/db_1\/dbs\/initmaa1.ora\r\nSystem parameters with non-default values:\r\n  processes                = 150\r\n  spfile                   = \"+DATA\/maa\/spfilemaa.ora\"\r\n  sga_target               = 1G\r\n  control_files            = \"+DATA\/maa\/controlfile\/current.273.843488553\"\r\n  control_files            = \"+FRA\/maa\/controlfile\/current.256.843488553\"\r\n  db_file_name_convert     = \"+DG01\/maastb\"\r\n  db_file_name_convert     = \"+DATA\/maa\"\r\n  db_file_name_convert     = \"+FRA\/maastb\"\r\n  db_file_name_convert     = \"+FRA\/maa\"\r\n  log_file_name_convert    = \"+DG01\/maastb\"\r\n  log_file_name_convert    = \"+DATA\/maa\"\r\n  log_file_name_convert    = \"+FRA\/maastb\"\r\n  log_file_name_convert    = \"+FRA\/maa\"\r\n  db_block_size            = 8192\r\n  compatible               = \"11.2.0.0.0\"\r\n  log_archive_dest_1       = \"LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=maa\"\r\n  log_archive_dest_2       = \"SERVICE=maastb SYNC AFFIRM LGWR VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=maastb\"\r\n  log_archive_dest_state_2 = \"ENABLE\"\r\n  log_archive_min_succeed_dest= 1\r\n  fal_server               = \"maastb\"\r\n  log_archive_trace        = 0\r\n  log_archive_config       = \"DG_CONFIG=(maa,maastb)\"\r\n  log_archive_format       = \"arch_%t_%s_%r.arc\"\r\n  log_archive_max_processes= 4\r\n  archive_lag_target       = 0\r\n  cluster_database         = TRUE\r\n  db_create_file_dest      = \"+DATA\"\r\n  db_recovery_file_dest    = \"+FRA\"\r\n  db_recovery_file_dest_size= 10G\r\n  standby_file_management  = \"AUTO\"\r\n  thread                   = 1\r\n  undo_tablespace          = \"UNDOTBS1\"\r\n  instance_number          = 1\r\n  remote_login_passwordfile= \"EXCLUSIVE\"\r\n  db_domain                = \"\"\r\n  remote_listener          = \"rac11pri-scan.tjsc.jus.br:1521\"\r\n  audit_file_dest          = \"\/u01\/app\/oracle\/admin\/maa\/adump\"\r\n  audit_trail              = \"DB\"\r\n  db_name                  = \"maa\"\r\n  db_unique_name           = \"maa\"\r\n  open_cursors             = 300\r\n  pga_aggregate_target     = 256M\r\n  dg_broker_start          = TRUE\r\n  dg_broker_config_file1   = \"+DATA\/maa\/dr1maa.dat\"\r\n  dg_broker_config_file2   = \"+FRA\/maa\/dr2maa.dat\"\r\n  diagnostic_dest          = \"\/u01\/app\/oracle\"\r\nCluster communication is configured to use the following interface(s) for this instance\r\n  169.254.187.5\r\ncluster interconnect IPC version:Oracle UDP\/IP (generic)\r\nIPC Vendor 1 proto 2\r\nTue Jul 29 06:17:06 2014\r\nPMON started with pid=2, OS id=7421\r\nTue Jul 29 06:17:06 2014\r\nPSP0 started with pid=3, OS id=7423\r\nTue Jul 29 06:17:08 2014\r\nVKTM started with pid=4, OS id=7425 at elevated priority\r\nVKTM running at (1)millisec precision with DBRM quantum (100)ms\r\nTue Jul 29 06:17:08 2014\r\nGEN0 started with pid=5, OS id=7430\r\nTue Jul 29 06:17:08 2014\r\nDIAG started with pid=6, OS id=7432\r\nTue Jul 29 06:17:08 2014\r\nDBRM started with pid=7, OS id=7434\r\nTue Jul 29 06:17:08 2014\r\nPING started with pid=8, OS id=7436\r\nTue Jul 29 06:17:08 2014\r\nACMS started with pid=9, OS id=7438\r\nTue Jul 29 06:17:08 2014\r\nDIA0 started with pid=10, OS id=7440\r\nTue Jul 29 06:17:08 2014\r\nLMON started with pid=11, OS id=7442\r\nTue Jul 29 06:17:08 2014\r\nLMD0 started with pid=12, OS id=7444\r\n* Load Monitor used for high load check\r\n* New Low - High Load Threshold Range = [1920 - 2560]\r\nTue Jul 29 06:17:08 2014\r\nLMS0 started with pid=13, OS id=7446 at elevated priority\r\nTue Jul 29 06:17:08 2014\r\nRMS0 started with pid=14, OS id=7450\r\nTue Jul 29 06:17:08 2014\r\nLMHB started with pid=15, OS id=7452\r\nTue Jul 29 06:17:08 2014\r\nMMAN started with pid=16, OS id=7454\r\nTue Jul 29 06:17:08 2014\r\nDBW0 started with pid=17, OS id=7456\r\nTue Jul 29 06:17:09 2014\r\nLGWR started with pid=18, OS id=7458\r\nTue Jul 29 06:17:09 2014\r\nCKPT started with pid=19, OS id=7460\r\nTue Jul 29 06:17:09 2014\r\nSMON started with pid=20, OS id=7462\r\nTue Jul 29 06:17:09 2014\r\nRECO started with pid=21, OS id=7464\r\nTue Jul 29 06:17:09 2014\r\nRBAL started with pid=22, OS id=7466\r\nTue Jul 29 06:17:09 2014\r\nASMB started with pid=23, OS id=7468\r\nTue Jul 29 06:17:09 2014\r\nMMON started with pid=24, OS id=7470\r\nTue Jul 29 06:17:09 2014\r\nMMNL started with pid=25, OS id=7474\r\nNOTE: initiating MARK startup\r\nStarting background process MARK\r\nTue Jul 29 06:17:09 2014\r\nMARK started with pid=26, OS id=7476\r\nlmon registered with NM - instance number 1 (internal mem no 0)\r\nNOTE: MARK has subscribed\r\nReconfiguration started (old inc 0, new inc 2)\r\nList of instances:\r\n 1 (myinst: 1)\r\n Global Resource Directory frozen\r\n* allocate domain 0, invalid = TRUE\r\n Communication channels reestablished\r\n Master broadcasted resource hash value bitmaps\r\n Non-local Process blocks cleaned out\r\n LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived\r\n Set master node info\r\n Submitted all remote-enqueue requests\r\n Dwn-cvts replayed, VALBLKs dubious\r\n All grantable enqueues granted\r\n Post SMON to start 1st pass IR\r\n Submitted all GCS remote-cache requests\r\n Post SMON to start 1st pass IR\r\n Fix write in gcs resources\r\nReconfiguration complete\r\nTue Jul 29 06:17:11 2014\r\nLCK0 started with pid=28, OS id=7482\r\nTue Jul 29 06:17:11 2014\r\nStarting background process RSMN\r\nTue Jul 29 06:17:11 2014\r\nRSMN started with pid=29, OS id=7484\r\nError: can not register my instance state - 4\r\nORACLE_BASE not set in environment. It is recommended\r\nthat ORACLE_BASE be set in the environment\r\nReusing ORACLE_BASE from an earlier startup = \/u01\/app\/oracle\r\nTue Jul 29 06:17:12 2014\r\nDMON started with pid=30, OS id=7486\r\nReconfiguration started (old inc 2, new inc 4)\r\nList of instances:\r\n 1 2 (myinst: 1)\r\n Global Resource Directory frozen\r\n Communication channels reestablished\r\n Master broadcasted resource hash value bitmaps\r\n Non-local Process blocks cleaned out\r\n LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived\r\n Set master node info\r\n Submitted all remote-enqueue requests\r\n Dwn-cvts replayed, VALBLKs dubious\r\n All grantable enqueues granted\r\n Post SMON to start 1st pass IR\r\n Submitted all GCS remote-cache requests\r\n Post SMON to start 1st pass IR\r\n Fix write in gcs resources\r\nReconfiguration complete\r\nTue Jul 29 06:17:13 2014\r\nALTER SYSTEM SET local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=10.17.42.14)(PORT=1521))))' SCOPE=MEMORY SID='maa1';\r\nALTER DATABASE MOUNT \/* db agent *\/\/* {1:18282:220} *\/\r\nThis instance was first to mount\r\nNOTE: Loaded library: \/opt\/oracle\/extapi\/64\/asm\/orcl\/1\/libasm.so\r\nNOTE: Loaded library: System\r\nSUCCESS: diskgroup DATA was mounted\r\nNOTE: dependency between database maa and diskgroup resource ora.DATA.dg is established\r\nSUCCESS: diskgroup FRA was mounted\r\nNOTE: dependency between database maa and diskgroup resource ora.FRA.dg is established\r\nTue Jul 29 06:17:18 2014\r\nNSS2 started with pid=33, OS id=7506\r\nSuccessful mount of redo thread 1, with mount id 732690857\r\nAllocated 3981120 bytes in shared pool for flashback generation buffer\r\nStarting background process RVWR\r\nTue Jul 29 06:17:18 2014\r\nRVWR started with pid=34, OS id=7508\r\nDatabase mounted in Shared Mode (CLUSTER_DATABASE=TRUE)\r\nLost write protection disabled\r\nCompleted: ALTER DATABASE MOUNT \/* db agent *\/\/* {1:18282:220} *\/\r\nALTER DATABASE OPEN \/* db agent *\/\/* {1:18282:220} *\/\r\nData Guard Broker initializing...\r\nData Guard Broker initialization complete\r\nData Guard: verifying database primary role...\r\nTue Jul 29 06:17:25 2014\r\nStarting Data Guard Broker (DMON)\r\n<\/strong>Tue Jul 29 06:17:25 2014\r\nINSV started with pid=36, OS id=7514\r\nTue Jul 29 06:17:29 2014\r\nNSV1 started with pid=37, OS id=7516\r\nTue Jul 29 06:17:37 2014\r\nData Guard: version check completed\r\nData Guard determines a failover has occurred - this is no longer a primary database\r\nORA-16649 signalled during: ALTER DATABASE OPEN \/* db agent *\/\/* {1:18282:220} *\/...<\/strong>\r\nTue Jul 29 06:17:52 2014\r\nReconfiguration started (old inc 4, new inc 6)\r\nList of instances:\r\n 1 (myinst: 1)\r\n Global Resource Directory frozen\r\n * dead instance detected - domain 0 invalid = TRUE\r\n Communication channels reestablished\r\n Master broadcasted resource hash value bitmaps\r\n Non-local Process blocks cleaned out\r\nTue Jul 29 06:17:52 2014\r\n LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived\r\n Set master node info\r\n Submitted all remote-enqueue requests\r\n Dwn-cvts replayed, VALBLKs dubious\r\n All grantable enqueues granted\r\n Post SMON to start 1st pass IR\r\n Submitted all GCS remote-cache requests\r\n Post SMON to start 1st pass IR\r\n Fix write in gcs resources\r\nReconfiguration complete\r\nTue Jul 29 06:17:59 2014\r\nNSV1 started with pid=39, OS id=7566\r\nTue Jul 29 06:18:07 2014\r\nRSM0 started with pid=40, OS id=7570\r\nTue Jul 29 06:18:11 2014\r\nUsing STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST\r\nRFS[1]: Assigned to RFS process 7573\r\nRFS[1]: Database mount ID mismatch [0x2bace9bb:0x2babf9a9] (732752315:732690857)\r\nFLASHBACK DATABASE TO SCN 19932269<\/strong>\r\nTue Jul 29 06:18:13 2014\r\nRFS[2]: Assigned to RFS process 7577\r\nRFS[2]: Database mount ID mismatch [0x2bace9bb:0x2babf9a9] (732752315:732690857)\r\nFlashback Restore Start\r\nFlashback Restore Complete\r\nFlashback Media Recovery Start\r\n started logmerger process<\/strong>\r\nTue Jul 29 06:18:18 2014\r\nParallel Media Recovery started with 2 slaves\r\nTue Jul 29 06:18:18 2014\r\nRecovery of Online Redo Log: Thread 1 Group 1 Seq 1181 Reading mem 0\r\n  Mem# 0: +DATA\/maa\/onlinelog\/group_1.272.843488553\r\n  Mem# 1: +FRA\/maa\/onlinelog\/group_1.286.843488555\r\nRecovery of Online Redo Log: Thread 2 Group 3 Seq 1394 Reading mem 0\r\n  Mem# 0: +DATA\/maa\/onlinelog\/group_3.257.843489101\r\n  Mem# 1: +FRA\/maa\/onlinelog\/group_3.284.843489101\r\nRecovery of Online Redo Log: Thread 2 Group 4 Seq 1395 Reading mem 0\r\n  Mem# 0: +DATA\/maa\/onlinelog\/group_4.262.843489103\r\n  Mem# 1: +FRA\/maa\/onlinelog\/group_4.283.843489103\r\nIncomplete Recovery applied until change 19932270 time 07\/29\/2014 05:42:12\r\nFlashback Media Recovery Complete\r\nCompleted: FLASHBACK DATABASE TO SCN 19932269\r\nalter database convert to physical standby\r\nALTER DATABASE CONVERT TO PHYSICAL STANDBY (maa1)<\/strong>\r\nFlush standby redo logfile failed:1649\r\nClearing standby activation ID 728027883 (0x2b64d2eb)\r\nThe primary database controlfile was created using the\r\n'MAXLOGFILES 192' clause.\r\nThere is space for up to 188 standby redo logfiles\r\nUse the following SQL commands on the standby database to create\r\nstandby redo logfiles that match the primary database:\r\nALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;\r\nALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;\r\nALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;\r\nALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;\r\nALTER DATABASE ADD STANDBY LOGFILE 'srl5.f' SIZE 52428800;\r\nWaiting for all non-current ORLs to be archived...\r\nAll non-current ORLs have been archived.\r\nClearing online redo logfile 1 +DATA\/maa\/onlinelog\/group_1.272.843488553\r\nClearing online log 1 of thread 1 sequence number 1181\r\nClearing online redo logfile 1 complete\r\nClearing online redo logfile 2 +DATA\/maa\/onlinelog\/group_2.271.843488555\r\nClearing online log 2 of thread 1 sequence number 1180\r\nClearing online redo logfile 2 complete\r\nClearing online redo logfile 3 +DATA\/maa\/onlinelog\/group_3.257.843489101\r\nClearing online log 3 of thread 2 sequence number 1394\r\nClearing online redo logfile 3 complete\r\nClearing online redo logfile 4 +DATA\/maa\/onlinelog\/group_4.262.843489103\r\nClearing online log 4 of thread 2 sequence number 1395\r\nClearing online redo logfile 4 complete\r\nCompleted: alter database convert to physical standby\r\nTue Jul 29 06:18:29 2014\r\nShutting down instance (immediate)\r\nShutting down instance: further logons disabled\r\nStopping background process MMNL\r\nStopping background process MMON\r\nLicense high water mark = 6\r\nalter database CLOSE NORMAL\r\nORA-1109 signalled during: alter database CLOSE NORMAL...\r\nalter database DISMOUNT\r\nShutting down archive processes\r\nArchiving is disabled\r\nTue Jul 29 06:18:33 2014\r\nNOTE: Deferred communication with ASM instance\r\nNOTE: deferred map free for map id 5\r\nTue Jul 29 06:18:33 2014\r\nNOTE: Deferred communication with ASM instance\r\nNOTE: deferred map free for map id 150\r\nTue Jul 29 06:18:34 2014\r\nNOTE: Deferred communication with ASM instance\r\nNOTE: deferred map free for map id 2\r\nCompleted: alter database DISMOUNT\r\nARCH: Archival disabled due to shutdown: 1089\r\nShutting down archive processes\r\nArchiving is disabled\r\nShutting down Data Guard Broker processes\r\nTue Jul 29 06:18:35 2014\r\nNOTE: Deferred communication with ASM instance\r\nTue Jul 29 06:18:36 2014\r\nCompleted: Data Guard Broker shutdown\r\nNOTE: force a map free for map id 2\r\nTue Jul 29 06:18:38 2014\r\nStopping background process VKTM\r\nARCH: Archival disabled due to shutdown: 1089\r\nShutting down archive processes\r\nArchiving is disabled\r\nTue Jul 29 06:18:38 2014\r\nNOTE: Shutting down MARK background process\r\nNOTE: force a map free for map id 192\r\nNOTE: force a map free for map id 190\r\nNOTE: force a map free for map id 188\r\nNOTE: force a map free for map id 186\r\nNOTE: force a map free for map id 184\r\nNOTE: force a map free for map id 182\r\nNOTE: force a map free for map id 143\r\nNOTE: force a map free for map id 191\r\nNOTE: force a map free for map id 189\r\nNOTE: force a map free for map id 187\r\nNOTE: force a map free for map id 185\r\nNOTE: force a map free for map id 183\r\nNOTE: force a map free for map id 181\r\nNOTE: force a map free for map id 142\r\nTue Jul 29 06:18:41 2014\r\nfreeing rdom 0\r\nTue Jul 29 06:18:43 2014\r\nInstance shutdown complete\r\nTue Jul 29 06:18:44 2014\r\nStarting ORACLE instance (normal)\r\n****************** Large Pages Information *****************\r\n\r\nTotal Shared Global Region in Large Pages = 0 KB (0%)\r\n\r\nLarge Pages used by this instance: 0 (0 KB)\r\nLarge Pages unused system wide = 0 (0 KB) (alloc incr 4096 KB)\r\nLarge Pages configured system wide = 0 (0 KB)\r\nLarge Page size = 2048 KB\r\n\r\nRECOMMENDATION:\r\n  Total Shared Global Region size is 1026 MB. For optimal performance,\r\n  prior to the next instance restart increase the number\r\n  of unused Large Pages by atleast 513 2048 KB Large Pages (1026 MB)\r\n  system wide to get 100% of the Shared\r\n  Global Region allocated with Large pages\r\n***********************************************************\r\nLICENSE_MAX_SESSION = 0\r\nLICENSE_SESSIONS_WARNING = 0\r\nPrivate Interface 'eth2:1' configured from GPnP for use as a private interconnect.\r\n  [name='eth2:1', type=1, ip=169.254.187.5, mac=00-0c-29-8c-91-79, net=169.254.0.0\/16, mask=255.255.0.0, use=haip:cluster_interconnect\/62]\r\nPublic Interface 'eth0' configured from GPnP for use as a public interface.\r\n  [name='eth0', type=1, ip=10.17.42.10, mac=00-0c-29-8c-91-65, net=10.17.42.0\/26, mask=255.255.255.192, use=public\/1]\r\nPublic Interface 'eth0:2' configured from GPnP for use as a public interface.\r\n  [name='eth0:2', type=1, ip=10.17.42.22, mac=00-0c-29-8c-91-65, net=10.17.42.0\/26, mask=255.255.255.192, use=public\/1]\r\nPublic Interface 'eth0:4' configured from GPnP for use as a public interface.\r\n  [name='eth0:4', type=1, ip=10.17.42.17, mac=00-0c-29-8c-91-65, net=10.17.42.0\/26, mask=255.255.255.192, use=public\/1]\r\nPublic Interface 'eth0:5' configured from GPnP for use as a public interface.\r\n  [name='eth0:5', type=1, ip=10.17.42.14, mac=00-0c-29-8c-91-65, net=10.17.42.0\/26, mask=255.255.255.192, use=public\/1]\r\nPicked latch-free SCN scheme 3\r\nAutotune of undo retention is turned on.\r\nLICENSE_MAX_USERS = 0\r\nSYS auditing is disabled\r\nStarting up:\r\nOracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production\r\nWith the Partitioning and Real Application Clusters options.\r\nORACLE_HOME = \/u01\/app\/oracle\/product\/11.2.0.3\/db_1\r\nSystem name:    Linux\r\nNode name:      rac11pri01.tjsc.jus.br\r\nRelease:        2.6.39-400.17.1.el6uek.x86_64\r\nVersion:        #1 SMP Fri Feb 22 18:16:18 PST 2013\r\nMachine:        x86_64\r\nVM name:        VMWare Version: 6\r\nUsing parameter settings in server-side pfile \/u01\/app\/oracle\/product\/11.2.0.3\/db_1\/dbs\/initmaa1.ora\r\nSystem parameters with non-default values:\r\n  processes                = 150\r\n  spfile                   = \"+DATA\/maa\/spfilemaa.ora\"\r\n  sga_target               = 1G\r\n  control_files            = \"+DATA\/maa\/controlfile\/current.273.843488553\"\r\n  control_files            = \"+FRA\/maa\/controlfile\/current.256.843488553\"\r\n  db_file_name_convert     = \"+DG01\/maastb\"\r\n  db_file_name_convert     = \"+DATA\/maa\"\r\n  db_file_name_convert     = \"+FRA\/maastb\"\r\n  db_file_name_convert     = \"+FRA\/maa\"\r\n  log_file_name_convert    = \"+DG01\/maastb\"\r\n  log_file_name_convert    = \"+DATA\/maa\"\r\n  log_file_name_convert    = \"+FRA\/maastb\"\r\n  log_file_name_convert    = \"+FRA\/maa\"\r\n  db_block_size            = 8192\r\n  compatible               = \"11.2.0.0.0\"\r\n  log_archive_dest_1       = \"LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=maa\"\r\n  log_archive_dest_2       = \"SERVICE=maastb SYNC AFFIRM LGWR VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=maastb\"\r\n  log_archive_dest_state_2 = \"ENABLE\"\r\n  log_archive_min_succeed_dest= 1\r\n  fal_server               = \"maastb\"\r\n  log_archive_trace        = 0\r\n  log_archive_config       = \"DG_CONFIG=(maa,maastb)\"\r\n  log_archive_format       = \"arch_%t_%s_%r.arc\"\r\n  log_archive_max_processes= 4\r\n  archive_lag_target       = 0\r\n  cluster_database         = TRUE\r\n  db_create_file_dest      = \"+DATA\"\r\n  db_recovery_file_dest    = \"+FRA\"\r\n  db_recovery_file_dest_size= 10G\r\n  standby_file_management  = \"AUTO\"\r\n  thread                   = 1\r\n  undo_tablespace          = \"UNDOTBS1\"\r\n  instance_number          = 1\r\n  remote_login_passwordfile= \"EXCLUSIVE\"\r\n  db_domain                = \"\"\r\n  remote_listener          = \"rac11pri-scan.tjsc.jus.br:1521\"\r\n  audit_file_dest          = \"\/u01\/app\/oracle\/admin\/maa\/adump\"\r\n  audit_trail              = \"DB\"\r\n  db_name                  = \"maa\"\r\n  db_unique_name           = \"maa\"\r\n  open_cursors             = 300\r\n  pga_aggregate_target     = 256M\r\n  dg_broker_start          = TRUE\r\n  dg_broker_config_file1   = \"+DATA\/maa\/dr1maa.dat\"\r\n  dg_broker_config_file2   = \"+FRA\/maa\/dr2maa.dat\"\r\n  diagnostic_dest          = \"\/u01\/app\/oracle\"\r\nCluster communication is configured to use the following interface(s) for this instance\r\n  169.254.187.5\r\ncluster interconnect IPC version:Oracle UDP\/IP (generic)\r\nIPC Vendor 1 proto 2\r\nTue Jul 29 06:18:47 2014\r\nPMON started with pid=2, OS id=7618\r\nTue Jul 29 06:18:47 2014\r\nPSP0 started with pid=3, OS id=7620\r\nTue Jul 29 06:18:48 2014\r\nVKTM started with pid=4, OS id=7622 at elevated priority\r\nVKTM running at (1)millisec precision with DBRM quantum (100)ms\r\nTue Jul 29 06:18:48 2014\r\nGEN0 started with pid=5, OS id=7626\r\nTue Jul 29 06:18:48 2014\r\nDIAG started with pid=6, OS id=7628\r\nTue Jul 29 06:18:48 2014\r\nDBRM started with pid=7, OS id=7630\r\nTue Jul 29 06:18:48 2014\r\nPING started with pid=8, OS id=7632\r\nTue Jul 29 06:18:48 2014\r\nACMS started with pid=9, OS id=7634\r\nTue Jul 29 06:18:49 2014\r\nDIA0 started with pid=10, OS id=7636\r\nTue Jul 29 06:18:49 2014\r\nLMON started with pid=11, OS id=7638\r\nTue Jul 29 06:18:49 2014\r\nLMD0 started with pid=12, OS id=7640\r\nTue Jul 29 06:18:49 2014\r\nLMS0 started with pid=13, OS id=7642 at elevated priority\r\nTue Jul 29 06:18:49 2014\r\nRMS0 started with pid=14, OS id=7646\r\nTue Jul 29 06:18:49 2014\r\nLMHB started with pid=15, OS id=7648\r\nTue Jul 29 06:18:49 2014\r\nMMAN started with pid=16, OS id=7650\r\n* Load Monitor used for high load check\r\n* New Low - High Load Threshold Range = [1920 - 2560]\r\nTue Jul 29 06:18:49 2014\r\nDBW0 started with pid=17, OS id=7652\r\nTue Jul 29 06:18:49 2014\r\nLGWR started with pid=18, OS id=7654\r\nTue Jul 29 06:18:50 2014\r\nCKPT started with pid=19, OS id=7656\r\nTue Jul 29 06:18:50 2014\r\nSMON started with pid=20, OS id=7658\r\nTue Jul 29 06:18:50 2014\r\nRECO started with pid=21, OS id=7660\r\nTue Jul 29 06:18:50 2014\r\nRBAL started with pid=22, OS id=7662\r\nTue Jul 29 06:18:50 2014\r\nASMB started with pid=23, OS id=7664\r\nTue Jul 29 06:18:50 2014\r\nMMON started with pid=24, OS id=7666\r\nTue Jul 29 06:18:50 2014\r\nMMNL started with pid=25, OS id=7670\r\nlmon registered with NM - instance number 1 (internal mem no 0)\r\nNOTE: initiating MARK startup\r\nStarting background process MARK\r\nTue Jul 29 06:18:50 2014\r\nMARK started with pid=26, OS id=7672\r\nNOTE: MARK has subscribed\r\nReconfiguration started (old inc 0, new inc 2)\r\nList of instances:\r\n 1 (myinst: 1)\r\n Global Resource Directory frozen\r\n* allocate domain 0, invalid = TRUE\r\n Communication channels reestablished\r\n Master broadcasted resource hash value bitmaps\r\n Non-local Process blocks cleaned out\r\n LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived\r\n Set master node info\r\n Submitted all remote-enqueue requests\r\n Dwn-cvts replayed, VALBLKs dubious\r\n All grantable enqueues granted\r\n Post SMON to start 1st pass IR\r\n Submitted all GCS remote-cache requests\r\n Post SMON to start 1st pass IR\r\n Fix write in gcs resources\r\nReconfiguration complete\r\nTue Jul 29 06:18:50 2014\r\nLCK0 started with pid=28, OS id=7678\r\nStarting background process RSMN\r\nTue Jul 29 06:18:51 2014\r\nRSMN started with pid=29, OS id=7680\r\nORACLE_BASE from environment = \/u01\/app\/oracle\r\nTue Jul 29 06:18:51 2014\r\nDMON started with pid=30, OS id=7682\r\nTue Jul 29 06:18:51 2014\r\nalter database  mount\r\nThis instance was first to mount\r\nTue Jul 29 06:18:52 2014\r\nALTER SYSTEM SET local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=10.17.42.14)(PORT=1521))))' SCOPE=MEMORY SID='maa1';\r\nNOTE: Loaded library: \/opt\/oracle\/extapi\/64\/asm\/orcl\/1\/libasm.so\r\nNOTE: Loaded library: System\r\nSUCCESS: diskgroup DATA was mounted\r\nSUCCESS: diskgroup FRA was mounted\r\nNOTE: dependency between database maa and diskgroup resource ora.DATA.dg is established\r\nNOTE: dependency between database maa and diskgroup resource ora.FRA.dg is established\r\nTue Jul 29 06:18:58 2014\r\nNSS2 started with pid=33, OS id=7720\r\nARCH: STARTING ARCH PROCESSES\r\nTue Jul 29 06:18:58 2014\r\nARC0 started with pid=34, OS id=7722\r\nARC0: Archival started\r\nARCH: STARTING ARCH PROCESSES COMPLETE\r\nARC0: STARTING ARCH PROCESSES\r\nTue Jul 29 06:18:59 2014\r\nARC1 started with pid=35, OS id=7724\r\nSuccessful mount of redo thread 1, with mount id 732706059\r\nTue Jul 29 06:18:59 2014\r\nARC2 started with pid=36, OS id=7726\r\nAllocated 3981120 bytes in shared pool for flashback generation buffer\r\nTue Jul 29 06:18:59 2014\r\nARC3 started with pid=37, OS id=7728\r\nStarting background process RVWR\r\nARC1: Archival started\r\nARC2: Archival started\r\nARC1: Becoming the 'no FAL' ARCH\r\nARC1: Becoming the 'no SRL' ARCH\r\nARC2: Becoming the heartbeat ARCH\r\nTue Jul 29 06:18:59 2014\r\nRVWR started with pid=38, OS id=7730\r\nPhysical Standby Database mounted.\r\nLost write protection disabled\r\nARC2: Becoming the active heartbeat ARCH\r\nARC2: Becoming the active heartbeat ARCH\r\nARC3: Archival started\r\nARC0: STARTING ARCH PROCESSES COMPLETE\r\nCompleted: alter database  mount\r\nTue Jul 29 06:19:04 2014\r\nStarting Data Guard Broker (DMON)\r\nTue Jul 29 06:19:05 2014\r\nINSV started with pid=40, OS id=7747\r\nTue Jul 29 06:19:11 2014\r\nNSV1 started with pid=41, OS id=7752\r\nTue Jul 29 06:19:16 2014\r\nRSM0 started with pid=43, OS id=7758\r\nTue Jul 29 06:19:21 2014\r\nUsing STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST\r\nPrimary database is in MAXIMUM AVAILABILITY mode<\/strong>\r\nChanging standby controlfile to RESYNCHRONIZATION level\r\nALTER SYSTEM SET log_archive_trace=0 SCOPE=BOTH SID='maa1';\r\nStandby controlfile consistent with primary\r\nALTER SYSTEM SET log_archive_format='arch_%t_%s_%r.arc' SCOPE=SPFILE SID='maa1';\r\nALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH SID='*';\r\nALTER SYSTEM SET archive_lag_target=0 SCOPE=BOTH SID='*';\r\nRFS[1]: Assigned to RFS process 7760\r\nRFS[1]: Selected log 5 for thread 1 sequence 4 dbid 722024964 branch 854159044\r\nALTER SYSTEM SET log_archive_max_processes=4 SCOPE=BOTH SID='*';\r\nALTER SYSTEM SET log_archive_min_succeed_dest=1 SCOPE=BOTH SID='*';\r\nALTER SYSTEM SET db_file_name_convert='+DG01\/maastb','+DATA\/maa','+FRA\/maastb','+FRA\/maa' SCOPE=SPFILE;\r\nALTER SYSTEM SET log_file_name_convert='+DG01\/maastb','+DATA\/maa','+FRA\/maastb','+FRA\/maa' SCOPE=SPFILE;\r\nALTER SYSTEM SET fal_server='maastb' SCOPE=BOTH;\r\nALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  USING CURRENT LOGFILE\r\nAttempt to start background Managed Standby Recovery process (maa1)\r\nTue Jul 29 06:19:23 2014\r\nPrimary database is in MAXIMUM AVAILABILITY mode\r\nStandby controlfile consistent with primary\r\nTue Jul 29 06:19:23 2014\r\nMRP0 started with pid=46, OS id=7764\r\nMRP0: Background Managed Standby Recovery process started (maa1)\r\nStandby controlfile consistent with primary\r\nRFS[2]: Assigned to RFS process 7762\r\nRFS[2]: Selected log 8 for thread 2 sequence 4 dbid 722024964 branch 854159044\r\nTue Jul 29 06:19:25 2014\r\nRFS[3]: Assigned to RFS process 7766\r\nRFS[3]: Selected log 6 for thread 1 sequence 3 dbid 722024964 branch 854159044\r\nTue Jul 29 06:19:25 2014\r\nRFS[4]: Assigned to RFS process 7768\r\nRFS[4]: Selected log 9 for thread 2 sequence 3 dbid 722024964 branch 854159044\r\nRFS[3]: New Archival REDO Branch(resetlogs_id): 854159044  Prior: 847284763\r\nRFS[3]: Archival Activation ID: 0x2bace9bb Current: 0x0\r\nRFS[3]: Effect of primary database OPEN RESETLOGS<\/strong>\r\nRFS[3]: Managed Standby Recovery process is active\r\nRFS[3]: Incarnation entry added for Branch(resetlogs_id): 854159044 (maa1)\r\nTue Jul 29 06:19:25 2014\r\nSetting recovery target incarnation to 4\r\nTue Jul 29 06:19:26 2014\r\nArchived Log entry 5433 added for thread 2 sequence 3 ID 0x2bace9bb dest 1:\r\nTue Jul 29 06:19:26 2014\r\nArchived Log entry 5434 added for thread 1 sequence 3 ID 0x2bace9bb dest 1:\r\nRFS[4]: Opened log for thread 2 sequence 1395 dbid 722024964 branch 847284763\r\nRFS[3]: Opened log for thread 1 sequence 1181 dbid 722024964 branch 847284763\r\nArchived Log entry 5435 added for thread 2 sequence 1395 rlc 847284763 ID 0x2b64d2eb dest 2:\r\n started logmerger process\r\nArchived Log entry 5436 added for thread 1 sequence 1181 rlc 847284763 ID 0x2b64d2eb dest 2:\r\nManaged Standby Recovery starting Real Time Apply<\/strong>\r\nRFS[4]: Opened log for thread 2 sequence 2 dbid 722024964 branch 854159044\r\nTue Jul 29 06:19:29 2014\r\nRFS[5]: Assigned to RFS process 7786\r\nRFS[5]: Opened log for thread 2 sequence 1 dbid 722024964 branch 854159044\r\nRFS[3]: Opened log for thread 1 sequence 1 dbid 722024964 branch 854159044\r\nArchived Log entry 5437 added for thread 2 sequence 2 rlc 854159044 ID 0x2bace9bb dest 2:\r\nArchived Log entry 5438 added for thread 2 sequence 1 rlc 854159044 ID 0x2bace9bb dest 2:\r\nParallel Media Recovery started with 2 slaves\r\nTue Jul 29 06:19:30 2014\r\nMedia Recovery start incarnation depth : 1, target inc# : 4, irscn : 19932272\r\nArchived Log entry 5439 added for thread 1 sequence 1 rlc 854159044 ID 0x2bace9bb dest 2:\r\nWaiting for all non-current ORLs to be archived...\r\nAll non-current ORLs have been archived.\r\nTue Jul 29 06:19:30 2014\r\nRFS[6]: Assigned to RFS process 7788\r\nRFS[6]: Opened log for thread 1 sequence 2 dbid 722024964 branch 854159044\r\nMedia Recovery Log +FRA\/maa\/archivelog\/2014_07_29\/thread_2_seq_1395.2326.854173167\r\nIdentified End-Of-Redo (failover) for thread 2 sequence 1395 at SCN 0x0.1302470<\/strong>\r\nMedia Recovery Log +FRA\/maa\/archivelog\/2014_07_29\/thread_1_seq_1181.2327.854173167\r\nIdentified End-Of-Redo (failover) for thread 1 sequence 1181 at SCN 0x0.1302470<\/strong>\r\nArchived Log entry 5440 added for thread 1 sequence 2 rlc 854159044 ID 0x2bace9bb dest 2:\r\nResetting standby activation ID 728027883 (0x2b64d2eb)\r\nMedia Recovery End-Of-Redo indicator encountered\r\nMedia Recovery Continuing\r\nTue Jul 29 06:19:31 2014\r\nCompleted: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  THROUGH ALL SWITCHOVER DISCONNECT  USING CURRENT LOGFILE<\/strong>\r\nMedia Recovery Log +FRA\/maa\/archivelog\/2014_07_29\/thread_2_seq_1.2329.854173169\r\nMedia Recovery Log +FRA\/maa\/archivelog\/2014_07_29\/thread_1_seq_1.2330.854173169\r\nMedia Recovery Log +FRA\/maa\/archivelog\/2014_07_29\/thread_1_seq_2.2331.854173171\r\nMedia Recovery Log +FRA\/maa\/archivelog\/2014_07_29\/thread_2_seq_2.2328.854173169\r\nMedia Recovery Log +FRA\/maa\/archivelog\/2014_07_29\/thread_2_seq_3.2325.854173167\r\nTue Jul 29 06:19:34 2014\r\nArchived Log entry 5441 added for thread 2 sequence 4 ID 0x2bace9bb dest 1:\r\nTue Jul 29 06:19:34 2014\r\nPrimary database is in MAXIMUM AVAILABILITY mode\r\nStandby controlfile consistent with primary\r\nStandby controlfile consistent with primary\r\nRFS[7]: Assigned to RFS process 7806\r\nRFS[7]: Selected log 8 for thread 2 sequence 5 dbid 722024964 branch 854159044\r\nMedia Recovery Log +FRA\/maa\/archivelog\/2014_07_29\/thread_1_seq_3.2324.854173167\r\nMedia Recovery Waiting for thread 1 sequence 4 (in transit)\r\nRecovery of Online Redo Log: Thread 1 Group 5 Seq 4 Reading mem 0\r\n  Mem# 0: +DATA\/maa\/onlinelog\/group_5.263.843615365\r\n  Mem# 1: +FRA\/maa\/onlinelog\/group_5.289.843615367\r\nMedia Recovery Log +FRA\/maa\/archivelog\/2014_07_29\/thread_2_seq_4.2332.854173175\r\nMedia Recovery Waiting for thread 2 sequence 5 (in transit)\r\nRecovery of Online Redo Log: Thread 2 Group 8 Seq 5 Reading mem 0\r\n  Mem# 0: +DATA\/maa\/onlinelog\/group_8.259.843615383\r\n  Mem# 1: +FRA\/maa\/onlinelog\/group_8.703.843615385\r\nTue Jul 29 06:19:37 2014\r\nArchived Log entry 5442 added for thread 1 sequence 4 ID 0x2bace9bb dest 1:\r\nTue Jul 29 06:19:38 2014\r\nPrimary database is in MAXIMUM AVAILABILITY mode\r\nStandby controlfile consistent with primary\r\nMedia Recovery Waiting for thread 1 sequence 5 (in transit)\r\nStandby controlfile consistent with primary\r\nRFS[8]: Assigned to RFS process 7809\r\nRFS[8]: Selected log 5 for thread 1 sequence 5 dbid 722024964 branch 854159044\r\nRecovery of Online Redo Log: Thread 1 Group 5 Seq 5 Reading mem 0\r\n  Mem# 0: +DATA\/maa\/onlinelog\/group_5.263.843615365\r\n  Mem# 1: +FRA\/maa\/onlinelog\/group_5.289.843615367\r\nTue Jul 29 06:19:46 2014\r\nReconfiguration started (old inc 2, new inc 4)\r\nList of instances:\r\n 1 2 (myinst: 1)\r\n Global Resource Directory frozen\r\n Communication channels reestablished\r\n Master broadcasted resource hash value bitmaps\r\n Non-local Process blocks cleaned out\r\nTue Jul 29 06:19:46 2014\r\n LMS 0: 0 GCS shadows cancelled, 0 closed, 0 Xw survived\r\n Set master node info\r\n Submitted all remote-enqueue requests\r\n Dwn-cvts replayed, VALBLKs dubious\r\n All grantable enqueues granted\r\n Post SMON to start 1st pass IR\r\n Submitted all GCS remote-cache requests\r\n Post SMON to start 1st pass IR\r\n Fix write in gcs resources\r\nReconfiguration complete\r\n<\/pre>\n
No log do Broker ir\u00e1 ver um resumo do est\u00e1 no alertlog. Detec\u00e7\u00e3o que o antigo primary voltou e precisa de reinstate, ap\u00f3s isso o banco maa passa a ser o destino preferencial.<\/p>\n
07\/29\/2014 02:58:18\r\nREINSTATE DATABASE maa\r\nDatabase maa can be reinstated\r\n07\/29\/2014 02:58:50\r\nCommand REINSTATE DATABASE maa completed with warning ORA-16570\r\nData Guard Broker Status Summary:\r\n  Type                        Name                             Severity  Status\r\n  Configuration               dgrac                             Warning  ORA-16608\r\n  Primary Database            maastb                            Warning  ORA-16817\r\n  Physical Standby Database   maa                                 Error  ORA-16661\r\n07\/29\/2014 02:59:31\r\nREINSTATE DATABASE maa\r\nDatabase maa can be reinstated\r\n07\/29\/2014 02:59:53\r\nSuccessfully completed reinstatement of database 0x01001000; removing ReinstateContextArray property\r\n07\/29\/2014 03:00:03\r\nCommand REINSTATE DATABASE maa completed\r\nData Guard Broker Status Summary:\r\n  Type                        Name                             Severity  Status\r\n  Configuration               dgrac                             Warning  ORA-16608\r\n  Primary Database            maastb                            Warning  ORA-16817\r\n  Physical Standby Database   maa                               Warning  ORA-16817\r\nEDIT DATABASE maa SET PROPERTY ActualApplyInstance = maa1\r\n07\/29\/2014 03:00:04\r\nApply Instance for database maa is maa1\r\nCommand EDIT DATABASE maa SET PROPERTY ActualApplyInstance = maa1 completed\r\n<\/pre>\n
Caso estivesse acompanhando o log do Observer veria as mesmas informa\u00e7\u00f5es (de forma mais resumida ainda). Conforme o log abaixo demonstra o banco maa n\u00e3o chega a abrir durante o processo devido ao reinstate.<\/p>\n
Failover succeeded, new primary is \"maastb\"\r\n23:45:11.19  Monday, July 28, 2014\r\n00:17:56.55  Tuesday, July 29, 2014\r\nInitiating reinstatement for database \"maa\"...\r\nReinstating database \"maa\", please wait...\r\nOperation requires shutdown of instance \"maa1\" on database \"maa\"\r\nShutting down instance \"maa1\"...\r\nORA-01109: database not open\r\n\r\nDatabase dismounted.\r\nORACLE instance shut down.\r\nOperation requires startup of instance \"maa1\" on database \"maa\"\r\nStarting instance \"maa1\"...\r\nORACLE instance started.\r\nDatabase mounted.\r\nContinuing to reinstate database \"maa\" ...\r\nReinstatement of database \"maa\" succeeded\r\n00:19:41.47  Tuesday, July 29, 2014\r\n<\/pre>\n
Como sempre, o ajuste necess\u00e1rio do CRS para n\u00e3o abrir o antigo primary em modo OPEN em caso de restart do server:<\/p>\n
[oracle@rac11pri01 ~]$ srvctl config database -d maa -v\r\nDatabase unique name: maa\r\nDatabase name: maa\r\nOracle home: \/u01\/app\/oracle\/product\/11.2.0.3\/db_1\r\nOracle user: oracle\r\nSpfile: +DATA\/maa\/spfilemaa.ora\r\nDomain:\r\nStart options: open\r\nStop options: immediate\r\nDatabase role: PHYSICAL_STANDBY\r\nManagement policy: AUTOMATIC\r\nServer pools: maa\r\nDatabase instances: maa1,maa2\r\nDisk Groups: DATA,FRA\r\nMount point paths:\r\nServices:\r\nType: RAC\r\nDatabase is administrator managed\r\n[oracle@rac11pri01 ~]$ srvctl modify database -d maa -s MOUNT\r\n[oracle@rac11pri01 ~]$ srvctl config database -d maa -v\r\nDatabase unique name: maa\r\nDatabase name: maa\r\nOracle home: \/u01\/app\/oracle\/product\/11.2.0.3\/db_1\r\nOracle user: oracle\r\nSpfile: +DATA\/maa\/spfilemaa.ora\r\nDomain:\r\nStart options: mount\r\nStop options: immediate\r\nDatabase role: PHYSICAL_STANDBY\r\nManagement policy: AUTOMATIC\r\nServer pools: maa\r\nDatabase instances: maa1,maa2\r\nDisk Groups: DATA,FRA\r\nMount point paths:\r\nServices:\r\nType: RAC\r\nDatabase is administrator managed\r\n[oracle@rac11pri01 ~]$\r\n<\/pre>\n
AMBIENTE FINAL<\/strong><\/p>\n
Chegamos aqui com o ambiente com dois bancos operando em Maximum Availability. O banco primary \u00e9 o maastb e o standby \u00e9 o maa. A troca de papeis ocorreu de forma autom\u00e1tica pois o Fast-Start Failover est\u00e1 ativo com o Observer monitorando tudo.<\/p>\n
Claro que seu ambiente n\u00e3o \u00e9 s\u00f3 isso, voc\u00ea precisar\u00e1 que suas aplica\u00e7\u00f5es e TNS estejam preparadas para chavear as conex\u00f5es para o novo primary. N\u00e3o \u00e9 o escopo aqui, mas \u00e9 um ponto importante a ser verificado.<\/p>\n
PROXIMO ARTIGO<\/strong><\/p>\n
No pr\u00f3ximo artigo falarei do que temos de mudan\u00e7a para o DataGuard do Oracle 12c. Al\u00e9m disso um resumo dos dez artigos para que voc\u00ea possa ter um guia do que pode ser feito para configurar MAA com oracle RAC.<\/p>\n","protected":false},"excerpt":{"rendered":"
Neste pen\u00faltimo da s\u00e9rie sobre MAA com Oracle RAC 11GR2 vou falar um pouco sobre como ocorre o failover autom\u00e1tico em caso de falha do primary. Vou demonstrar que basicamente voc\u00ea n\u00e3o faz nada, todo o trabalho \u201csujo\u201d ser\u00e1 pelo pr\u00f3prio Oracle. NONO ARTIGO Este artigo ir\u00e1 mostrar como o MAA resolve de forma autom\u00e1tica […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[30,41,29,47,53,5],"tags":[],"class_list":["post-185","post","type-post","status-publish","format-standard","hentry","category-banco-de-dados","category-data-guard","category-database","category-failover","category-fast-start-failover","category-oracle"],"yoast_head":"\nOracle e MAA \u2013 Artigo IX \u2013 Failover Autom\u00e1tico<\/title>\n<meta name=\"description\" content=\"Analisando um Failover autom\u00e1tico em um ambiente com Fast-Start Faiolver para Oracle com Maximum Availability Architecture (MAA), Data Guard (DG) e RAC.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Oracle e MAA \u2013 Artigo IX \u2013 Failover Autom\u00e1tico\" \/>\n<meta property=\"og:description\" content=\"Analisando um Failover autom\u00e1tico em um ambiente com Fast-Start Faiolver para Oracle com Maximum Availability Architecture (MAA), Data Guard (DG) e RAC.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/\" \/>\n<meta property=\"og:site_name\" content=\"Fernando Simon\" \/>\n<meta property=\"article:published_time\" content=\"2014-12-13T02:17:51+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2015-01-26T01:58:03+00:00\" \/>\n<meta name=\"author\" content=\"Simon\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Simon\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"36 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/\"},\"author\":{\"name\":\"Simon\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\"},\"headline\":\"Oracle e MAA \u2013 Artigo IX \u2013 Failover Autom\u00e1tico\",\"datePublished\":\"2014-12-13T02:17:51+00:00\",\"dateModified\":\"2015-01-26T01:58:03+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/\"},\"wordCount\":1041,\"commentCount\":0,\"articleSection\":[\"Banco de Dados\",\"Data Guard\",\"Database\",\"Failover\",\"Fast-Start Failover\",\"Oracle\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/\",\"url\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/\",\"name\":\"Oracle e MAA \u2013 Artigo IX \u2013 Failover Autom\u00e1tico\",\"isPartOf\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#website\"},\"datePublished\":\"2014-12-13T02:17:51+00:00\",\"dateModified\":\"2015-01-26T01:58:03+00:00\",\"author\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\"},\"description\":\"Analisando um Failover autom\u00e1tico em um ambiente com Fast-Start Faiolver para Oracle com Maximum Availability Architecture (MAA), Data Guard (DG) e RAC.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.fernandosimon.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Oracle e MAA \u2013 Artigo IX \u2013 Failover Autom\u00e1tico\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#website\",\"url\":\"https:\/\/www.fernandosimon.com\/blog\/\",\"name\":\"Fernando Simon\",\"description\":\"Have you hugged your backup today?\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.fernandosimon.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\",\"name\":\"Simon\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g\",\"caption\":\"Simon\"},\"sameAs\":[\"http:\/\/www.fernandosimon.com\"],\"url\":\"https:\/\/www.fernandosimon.com\/blog\/author\/simon\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Oracle e MAA \u2013 Artigo IX \u2013 Failover Autom\u00e1tico","description":"Analisando um Failover autom\u00e1tico em um ambiente com Fast-Start Faiolver para Oracle com Maximum Availability Architecture (MAA), Data Guard (DG) e RAC.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/","og_locale":"en_US","og_type":"article","og_title":"Oracle e MAA \u2013 Artigo IX \u2013 Failover Autom\u00e1tico","og_description":"Analisando um Failover autom\u00e1tico em um ambiente com Fast-Start Faiolver para Oracle com Maximum Availability Architecture (MAA), Data Guard (DG) e RAC.","og_url":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/","og_site_name":"Fernando Simon","article_published_time":"2014-12-13T02:17:51+00:00","article_modified_time":"2015-01-26T01:58:03+00:00","author":"Simon","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Simon","Est. reading time":"36 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/#article","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/"},"author":{"name":"Simon","@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"headline":"Oracle e MAA \u2013 Artigo IX \u2013 Failover Autom\u00e1tico","datePublished":"2014-12-13T02:17:51+00:00","dateModified":"2015-01-26T01:58:03+00:00","mainEntityOfPage":{"@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/"},"wordCount":1041,"commentCount":0,"articleSection":["Banco de Dados","Data Guard","Database","Failover","Fast-Start Failover","Oracle"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/","url":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/","name":"Oracle e MAA \u2013 Artigo IX \u2013 Failover Autom\u00e1tico","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#website"},"datePublished":"2014-12-13T02:17:51+00:00","dateModified":"2015-01-26T01:58:03+00:00","author":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"description":"Analisando um Failover autom\u00e1tico em um ambiente com Fast-Start Faiolver para Oracle com Maximum Availability Architecture (MAA), Data Guard (DG) e RAC.","breadcrumb":{"@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ix-failover-automatico\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.fernandosimon.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Oracle e MAA \u2013 Artigo IX \u2013 Failover Autom\u00e1tico"}]},{"@type":"WebSite","@id":"https:\/\/www.fernandosimon.com\/blog\/#website","url":"https:\/\/www.fernandosimon.com\/blog\/","name":"Fernando Simon","description":"Have you hugged your backup today?","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.fernandosimon.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9","name":"Simon","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g","caption":"Simon"},"sameAs":["http:\/\/www.fernandosimon.com"],"url":"https:\/\/www.fernandosimon.com\/blog\/author\/simon\/"}]}},"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p5ofTp-2Z","_links":{"self":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/185","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/comments?post=185"}],"version-history":[{"count":0,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/185\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/media?parent=185"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/categories?post=185"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/tags?post=185"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}