{"id":151,"date":"2014-04-25T20:18:38","date_gmt":"2014-04-25T23:18:38","guid":{"rendered":"http:\/\/www.fernandosimon.com\/blog\/?p=151"},"modified":"2015-01-25T23:31:35","modified_gmt":"2015-01-26T02:31:35","slug":"oracle-e-maa-artigo-ii-failover","status":"publish","type":"post","link":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/","title":{"rendered":"Oracle e MAA – Artigo II – Failover"},"content":{"rendered":"

No artigo anterior<\/a> demonstrei como configurar um DG para que voc\u00ea possa ter MAA no seu ambiente. Foram apresentados os passos para criar um DG entre um banco primary ORACLE RAC e standby tamb\u00e9m em ORACLE RAC. At\u00e9 o momento o ambiente n\u00e3o est\u00e1 100%, ainda n\u00e3o configuramos o DG para utilizar o broker e nem fast-start failover, tudo ser\u00e1 manual.<\/p>\n

A fun\u00e7\u00e3o b\u00e1sica do DG \u00e9 proteger quanto a poss\u00edveis falhas inesperadas em nosso banco primary. Existem v\u00e1rios tipos de falhas que podem deixar indispon\u00edvel um banco de dados: hardware, software, estagi\u00e1rio, DBA Senior; in\u00fameras.<\/p>\n

Quando trabalhamos com o Oracle em RAC as falhas que podem deixar o seu ambiente indispon\u00edvel por completo reduzem, no caso de uma falha de um \u00fanico n\u00f3 o outro assume a carga e o banco continua dispon\u00edvel ao usu\u00e1rio. Mas ele n\u00e3o protege para falhas mais complexas. Se o seu storage falhar? Ou se a sua rede apresentar problema e o seu RAC cair?<\/p>\n

\u00c9 nesses cen\u00e1rios que o DG pode ajudar, ele ir\u00e1 proteger seu banco Oracle contra poss\u00edveis falhas do seu ambiente primary. Com MAA voc\u00ea teria tudo replicado no outro ambiente e em um ambiente RAC voc\u00ea estar\u00e1 protegido contra falhas de ambos os n\u00f3s.<\/p>\n

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

Neste artigo vamos dar sequ\u00eancia ao anterior e simular um failover no ambiente. Neste artigo voc\u00ea ver\u00e1 os passos e o que fazer para realizar o failover do primary para o seu standby, tudo isso de forma manual.<\/p>\n

<\/p>\n

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

Para recordar, temos um ambiente DG configurado com RAC conforme passos que vimos neste artigo<\/a>. O DG est\u00e1 operando em\u00a0MAXIMUM AVAILABILITY e com real-time-apply. Ainda n\u00e3o temos broker configurado e todos os passos necessitam de interven\u00e7\u00e3o manual para a troca de papeis, incluindo a restaura\u00e7\u00e3o do ambiente.<\/p>\n

Para exemplificar a garantias que um DG nos d\u00e1, vamos criar uma tabela de controle para verificar se os dados est\u00e3o salvos. Observe o momento que a tabela foi criada e que recebeu inserts de ambas as inst\u00e2ncias do RAC:<\/p>\n

Inst\u00e2ncia MAA1\r\n    SQL> SELECT instance_name FROM v$instance;\r\n\r\n    INSTANCE_NAME\r\n    ----------------\r\n    maa1\r\n\r\n    SQL> CREATE TABLE testedg(c1 DECIMAL(3,0), c2 DATE);\r\n\r\n    Table created.\r\n\r\n    SQL> INSERT INTO testedg VALUES(1, SYSDATE);\r\n\r\n    1 row created.\r\n\r\n    SQL> commit;\r\n\r\n    Commit complete.\r\n\r\n    SQL>\r\n    \r\nInst\u00e2ncia MAA2\r\n    SQL> SELECT instance_name FROM v$instance;\r\n\r\n    INSTANCE_NAME\r\n    ----------------\r\n    maa2\r\n\r\n    SQL> INSERT INTO testedg VALUES(2, SYSDATE);\r\n\r\n    1 row created.\r\n\r\n    SQL> COMMIT;\r\n\r\n    Commit complete.\r\n\r\n    SQL> SELECT c1, TO_CHAR(c2, 'DD\/MM HH24:MI:SS') as momento FROM testedg;\r\n\r\n            C1 MOMENTO\r\n    ---------- --------------\r\n             1 13\/04 07:00:04\r\n             2 13\/04 07:01:11\r\n\r\n    SQL> \r\n<\/pre>\n
FAILOVER<\/strong><\/p>\n
Aqui simularemos uma falha n\u00e3o planejada do primary, o banco de dados ficar\u00e1 indispon\u00edvel e ser\u00e1 chaveado para o banco standby com failover. Mas o que \u00e9 failover? De forma bem resumida, o failover ocorre quando existe indisponibilidade completa do primary. Isso impede o banco primary de \u201cser avisado\u201d da troca de papeis.<\/p>\n
Antes de pensarmos em fazer o failover ou switchover precisamos saber se ele \u00e9 necess\u00e1rio ou se podemos fazer sem perder dados. O primeiro ponto a ser avaliado em qualquer ambiente DG \u00e9 se tanto primary e standby est\u00e3o sincronizados, se eles n\u00e3o estiverem voc\u00ea provavelmente perder\u00e1 dados.<\/p>\n
Vamos partir do princ\u00edpio que se voc\u00ea est\u00e1 configurando um ambiente DG \u00e9 devido a import\u00e2ncia do seu banco de dados. Se voc\u00ea est\u00e1 montando um ambiente MAA com DG+RAC a criticidade da informa\u00e7\u00e3o que voc\u00ea gerencia \u00e9 muito maior, voc\u00ea quer garantias. Al\u00e9m disso, a disponibilidade necess\u00e1ria para o ambiente est\u00e1 intimamente ligada a import\u00e2ncia dos seus dados. Ent\u00e3o, voc\u00ea monta um ambiente DG com RAC e n\u00e3o deixa primary e standby sincronizados? Voc\u00ea monta e prepara um standby que n\u00e3o suporta a carga do seu primary em caso de falha?<\/p>\n
Primeiro, se o seu ambiente est\u00e1 sincronizado, fa\u00e7a o failover. Caso o seu ambiente n\u00e3o esteja sincronizado nem continue, voc\u00ea VAI perder dados. Se o seu ambiente n\u00e3o est\u00e1 ok, revise ele e o deixe tudo sincronizado, voc\u00ea vai ter noites mais tranquilas e as surpresas ser\u00e3o menores.<\/p>\n
Criando a falha<\/strong><\/p>\n
Para iniciar vamos simular uma falha do ambiente, uma falha catastr\u00f3fica como a perda do storage que derrubou ambas as inst\u00e2ncias do primary. Aqui, o que est\u00e1 nos redo n\u00e3o foi para os archives (como os dados da nossa tabela de teste por exemplo). Como exemplo, um simples abort j\u00e1 d\u00e1 conta (lembre do RAC \u2013 ambos os n\u00f3s tem que morrer):<\/p>\n
[oracle@rac11pri01 ~]$ srvctl stop database -d maa -o abort\r\n[oracle@rac11pri01 ~]$ \r\n<\/pre>\n
O standby percebeu a falha no standby de forma imediata. Observe no alertlog da standby que est\u00e1 abaixo os hor\u00e1rios de recebimento do \u00faltimo archivelog e do momento da falha do primary (fa\u00e7a uma rela\u00e7\u00e3o com o que est\u00e1 na nossa tabela de controle que criamos previamente):<\/p>\n
Sun Apr 13 05:57:45 2014\r\nMedia Recovery Waiting for thread 1 sequence 77 (in transit)\r\nRecovery of Online Redo Log: Thread 1 Group 5 Seq 77 Reading mem 0\r\n  Mem# 0: +DG01\/maastb\/onlinelog\/group_5.271.844716073\r\n  Mem# 1: +FRA\/maastb\/onlinelog\/group_5.553.844716075\r\nSun Apr 13 07:20:08 2014\r\nRFS[4]: Possible network disconnect with primary database\r\nSun Apr 13 07:20:08 2014\r\nRFS[2]: Possible network disconnect with primary database\r\nSun Apr 13 07:20:08 2014\r\nRFS[6]: Possible network disconnect with primary database\r\nSun Apr 13 07:20:08 2014\r\nRFS[10]: Assigned to RFS process 2470\r\nRFS[10]: Possible network disconnect with primary database\r\nSun Apr 13 07:20:08 2014\r\nRFS[5]: Possible network disconnect with primary database\r\nSun Apr 13 07:20:08 2014\r\nRFS[9]: Possible network disconnect with primary database\r\nSun Apr 13 07:20:09 2014\r\nRFS[7]: Possible network disconnect with primary database\r\nSun Apr 13 07:20:09 2014\r\nRFS[8]: Possible network disconnect with primary database\r\n<\/pre>\n
Com o alertlog observamos que o \u00faltimo archive foi recebido as 05:57:45 e a falha do primary foi detectada pelo standby as 07:20:09. Tamb\u00e9m identificamos que o standby detectou a falha mas n\u00e3o fez nada ainda. N\u00e3o estamos com o broker para ele chavear automaticamente, e caso voc\u00ea consiga reativar seu ambiente primary tudo volta ao normal.<\/p>\n
Verificando o Standby<\/strong><\/p>\n
Ent\u00e3o, no meio da tarde voc\u00ea percebe que o seu RAC primary parou e o standby est\u00e1 esperando voc\u00ea se decidir o que fazer. A primeira coisa que voc\u00ea faz \u00e9 ver seu standby pode chavear e se tornar primary. Conecte no standby e verifique o modo em que ele est\u00e1 operando:<\/p>\n
SQL> SELECT protection_mode, protection_level, database_role FROM v$database;\r\n\r\nPROTECTION_MODE      PROTECTION_LEVEL     DATABASE_ROLE\r\n-------------------- -------------------- ----------------\r\nMAXIMUM AVAILABILITY MAXIMUM AVAILABILITY PHYSICAL STANDBY\r\n\r\nSQL> SELECT instance_name FROM gv$instance;\r\n\r\nINSTANCE_NAME\r\n----------------\r\nmaastb1\r\nmaastb2\r\n\r\nSQL>\r\n<\/pre>\n
Com isso, voc\u00ea sabe que tem duas inst\u00e2ncias e um banco sincronizado com o primary e que est\u00e1 atuando como PHYSICAL STANDBY. Isso \u00e9 bom e nos permite continuar com o failover. Se o seu protection_level n\u00e3o est\u00e1 igual ao protection_mode, voc\u00ea tem problemas e n\u00e3o est\u00e1 com primary e standby sincronizados.<\/p>\n
Trocando os papeis<\/strong><\/p>\n
Como o primary morreu, o pr\u00f3ximo passo que precisamos \u00e9 parar a sincroniza\u00e7\u00e3o do standby. Como estamos em um failover alguns comandos devem \u201cfor\u00e7ar\u201d paradas ou configura\u00e7\u00f5es, precisamos for\u00e7ar a parada na sincronia entre o primary e standby. Basicamente voc\u00ea conecta no standby e desliga a sincronia:<\/p>\n
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;\r\n\r\nDatabase altered.\r\n\r\nSQL>\r\n\r\nNo alert da instancia:\r\n    Sun Apr 13 08:02:42 2014\r\n    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL\r\n    Sun Apr 13 08:02:42 2014\r\n    MRP0: Background Media Recovery cancelled with status 16037\r\n    Errors in file \/u01\/app\/oracle\/diag\/rdbms\/maastb\/maastb1\/trace\/maastb1_pr00_2398.trc:\r\n    ORA-16037: user requested cancel of managed recovery operation\r\n    Sun Apr 13 08:02:42 2014\r\n    Managed Standby Recovery not using Real Time Apply\r\n    Recovery interrupted!\r\n    Recovered data files to a consistent state at change 2596057\r\n    Sun Apr 13 08:02:42 2014\r\n    MRP0: Background Media Recovery process shutdown (maastb1)\r\n    Managed Standby Recovery Canceled (maastb1)\r\n    Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL\r\n<\/pre>\n
Observe no alertlog que est\u00e1 acima o aviso de parada da sincroniza\u00e7\u00e3o, inclusive do real-time-apply. O pr\u00f3ximo passo \u00e9 marcar o fim da aplica\u00e7\u00e3o de qualquer redo, este comando \u201cmarca\u201d e aplica no banco do standby todo e qualquer redo pendente recebido do primary:<\/p>\n
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;\r\n\r\nDatabase altered.\r\n\r\nSQL>\r\n\r\nNo alertlog:\r\nObserve o \"enf-of-redo\" marcado por failover.    \r\n    Sun Apr 13 08:07:40 2014\r\n    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH\r\n    Attempt to do a Terminal Recovery (maastb1)\r\n    Media Recovery Start: Managed Standby Recovery (maastb1)\r\n     started logmerger process\r\n    Sun Apr 13 08:07:40 2014\r\n    Managed Standby Recovery not using Real Time Apply\r\n    Parallel Media Recovery started with 2 slaves\r\n    Sun Apr 13 08:07:42 2014\r\n    Begin: Standby Redo Logfile archival\r\n    End: Standby Redo Logfile archival\r\n    Terminal Recovery timestamp is '04\/13\/2014 08:07:42'\r\n    Terminal Recovery: applying standby redo logs.\r\n    Terminal Recovery: thread 1 seq# 77 redo required\r\n    Terminal Recovery:\r\n    Recovery of Online Redo Log: Thread 1 Group 5 Seq 77 Reading mem 0\r\n      Mem# 0: +DG01\/maastb\/onlinelog\/group_5.271.844716073\r\n      Mem# 1: +FRA\/maastb\/onlinelog\/group_5.553.844716075\r\n    Identified End-Of-Redo (failover) for thread 1 sequence 77 at SCN 0xffff.ffffffff<\/strong>\r\n    Terminal Recovery: thread 2 seq# 54 redo required\r\n    Terminal Recovery:\r\n    Recovery of Online Redo Log: Thread 2 Group 8 Seq 54 Reading mem 0\r\n      Mem# 0: +DG01\/maastb\/onlinelog\/group_8.261.844716089\r\n      Mem# 1: +FRA\/maastb\/onlinelog\/group_8.611.844716093\r\n    Identified End-Of-Redo (failover) for thread 2 sequence 54 at SCN 0xffff.ffffffff<\/strong>\r\n    Incomplete Recovery applied until change 2596059 time 04\/13\/2014 13:23:14\r\n    Media Recovery Complete (maastb1)\r\n    Terminal Recovery: successful completion\r\n    Sun Apr 13 08:07:44 2014\r\n    ARC0: Archiving not possible: error count exceeded\r\n    Sun Apr 13 08:07:44 2014\r\n    ARC1: Archiving not possible: error count exceeded\r\n    ARCH: Archival stopped, error occurred. Will continue retrying\r\n    ORACLE Instance maastb1 - Archival Error\r\n    ORA-16014: log 5 sequence# 77 not archived, no available destinations\r\n    ORA-00312: online log 5 thread 1: '+DG01\/maastb\/onlinelog\/group_5.271.844716073'\r\n    ORA-00312: online log 5 thread 1: '+FRA\/maastb\/onlinelog\/group_5.553.844716075'\r\n    Forcing ARSCN to IRSCN for TR 0:2596059\r\n    Attempt to set limbo arscn 0:2596059 irscn 0:2596059\r\n    Resetting standby activation ID 722049028 (0x2b099804)\r\n    Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH\r\n<\/pre>\n
Se voc\u00ea observar com detalhe o que ocorreu no alertlog acima ir\u00e1 notar que foi marcado um \u201cEnd-Of-Redo\u201d devido a failover nas duas threads recebidas do primary. O End-Of-Redo\u201d marca o momento (SCN) que ocorreu a interrup\u00e7\u00e3o na aplica\u00e7\u00e3o dos redo\u2019s recebidos da primary, tudo o que ocorrer ap\u00f3s este SCN n\u00e3o ter\u00e1 vindo da primary. Ignore os erros de arquivamento listados no alertlog (ele n\u00e3o est\u00e1 conseguindo enviar archives e explicarei porque mais abaixo).<\/p>\n
O pr\u00f3ximo passo \u00e9 efetivamente a troca de papeis, o standby passar\u00e1 a ser o primary. Primeiro voc\u00ea pode garantir\/verificar se o standby est\u00e1 pronto para o ser primary:<\/p>\n
SQL> SELECT switchover_status FROM v$database;\r\n\r\nSWITCHOVER_STATUS\r\n--------------------\r\nTO PRIMARY\r\n\r\nSQL>\r\n<\/pre>\n
Caso o comando acima retorne que existem sess\u00f5es voc\u00ea pode for\u00e7ar o kill destas. Recomenda-se que somente de prosseguimento caso apare\u00e7a TO PRIMARY. N\u00e3o de sequ\u00eancia caso o comando acima retorne outro valor.<\/p>\n
Para trocar os papeis e fazer o standby assumir como primary execute:<\/p>\n
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;\r\n\r\nDatabase altered.\r\n\r\nSQL>\r\n\r\nNo alert:\r\n    ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN\r\n    ALTER DATABASE SWITCHOVER TO PRIMARY (maastb1)\r\n    Maximum wait for role transition is 15 minutes.\r\n    Backup controlfile written to trace file \/u01\/app\/oracle\/diag\/rdbms\/maastb\/maastb1\/trace\/maastb1_ora_31327.trc\r\n    Standby terminal recovery start SCN: 2596057\r\n    RESETLOGS after incomplete recovery UNTIL CHANGE 2596059\r\n    Online log +DG01\/maastb\/onlinelog\/group_1.257.844716051: Thread 1 Group 1 was previously cleared\r\n    Online log +FRA\/maastb\/onlinelog\/group_1.568.844716053: Thread 1 Group 1 was previously cleared\r\n    Online log +DG01\/maastb\/onlinelog\/group_2.268.844716057: Thread 1 Group 2 was previously cleared\r\n    Online log +FRA\/maastb\/onlinelog\/group_2.564.844716059: Thread 1 Group 2 was previously cleared\r\n    Online log +DG01\/maastb\/onlinelog\/group_3.269.844716063: Thread 2 Group 3 was previously cleared\r\n    Online log +FRA\/maastb\/onlinelog\/group_3.562.844716065: Thread 2 Group 3 was previously cleared\r\n    Online log +DG01\/maastb\/onlinelog\/group_4.270.844716067: Thread 2 Group 4 was previously cleared\r\n    Online log +FRA\/maastb\/onlinelog\/group_4.559.844716071: Thread 2 Group 4 was previously cleared\r\n    Standby became primary SCN: 2596056<\/strong>\r\n    Sun Apr 13 08:20:09 2014\r\n    Setting recovery target incarnation to 2\r\n    Switchover: Complete - Database mounted as primary\r\n    Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN\r\n<\/pre>\n
O que tudo isso nos diz (comando e alertlog)? No comando voc\u00ea informou para ele passar a ser o banco primary (SWITCHOVER TO PRIMARY<\/strong>) e qualquer sess\u00e3o existente ser\u00e1 desconectada (SESSION SHUTDOWN<\/strong>). No alertlog temos a informa\u00e7\u00e3o do SCN aplicado e que os redog do standby foram reiniciados, e para os esot\u00e9ricos temos uma nova encarna\u00e7\u00e3o. Por fim, seu banco foi montado como primary.<\/p>\n
Tudo muito bem at\u00e9 agora e pronto para abrir o banco:<\/p>\n
SQL> ALTER DATABASE OPEN;\r\n\r\nDatabase altered.\r\n\r\nSQL>\r\n\r\nNo alert:\r\nObserve os erros de TNS para os archives que apontam para a antiga primary\r\n    Sun Apr 13 08:25:05 2014\r\n    ALTER DATABASE OPEN\r\n    This instance was first to open\r\n    Picked broadcast on commit scheme to generate SCNs\r\n    Sun Apr 13 08:25:06 2014\r\n    Assigning activation ID 723258431 (0x2b1c0c3f)\r\n    Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED\r\n    Destination LOG_ARCHIVE_DEST_2 no longer supports SYNCHRONIZATION\r\n    Thread 1 advanced to log sequence 2 (thread open)\r\n    Thread 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\n    Successful open of redo thread 1\r\n    MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set\r\n    Sun Apr 13 08:25:07 2014\r\n    SMON: enabling cache recovery\r\n    Sun Apr 13 08:25:07 2014\r\n    Archived Log entry 46 added for thread 1 sequence 1 ID 0x2b1c0c3f dest 1:\r\n    Sun Apr 13 08:25:07 2014\r\n    ...\r\n    ...\r\n    ...\r\n    ***********************************************************************\r\n\r\n    Fatal NI connect error 12514, connecting to:\r\n     (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rac11pri-scan.tjsc.jus.br)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=maa)(CID=(PROGRAM=oracle)(HOST=rac11stb01.tjsc.jus.br)(USER=oracle))))\r\n\r\n      VERSION INFORMATION:\r\n            TNS for Linux: Version 11.2.0.3.0 - Production\r\n            TCP\/IP NT Protocol Adapter for Linux: Version 11.2.0.3.0 - Production\r\n      Time: 13-APR-2014 08:25:07\r\n      Tracing not turned on.\r\n      Tns error struct:\r\n        ns main err code: 12564\r\n\r\n    TNS-12564: TNS:connection refused\r\n        ns secondary err code: 0\r\n        nt main err code: 0\r\n        nt secondary err code: 0\r\n        nt OS err code: 0\r\n    Error 12514 received logging on to the standby\r\n    PING[ARC2]: Heartbeat failed to connect to standby 'maa'. Error is 12514.\r\n    [31327] Successfully onlined Undo Tablespace 2.\r\n    Undo initialization finished serial:0 start:1288905924 end:1288907124 diff:1200 (12 seconds)\r\n    Dictionary check beginning\r\n    Sun Apr 13 08:25:10 2014\r\n    Errors in file \/u01\/app\/oracle\/diag\/rdbms\/maastb\/maastb1\/trace\/maastb1_dbw0_2288.trc:\r\n    ORA-01186: file 201 failed verification tests\r\n    ORA-01157: cannot identify\/lock data file 201 - see DBWR trace file\r\n    ORA-01110: data file 201: '+DG01'\r\n    File 201 not verified due to error ORA-01157\r\n    Dictionary check complete\r\n    Verifying file header compatibility for 11g tablespace encryption..\r\n    Sun Apr 13 08:25:10 2014\r\n    minact-scn: Inst 1 is now the master inc#:4 mmon proc-id:2303 status:0x7\r\n    Verifying 11g file header compatibility for tablespace encryption completedminact-scn status: grec-scn:0x0000.00000000 gmin-scn:0x0000.00000000 gcalc-scn:0x0000.00000000\r\n\r\n    minact-scn: Master returning as live inst:2 has inc# mismatch instinc:0 cur:4 errcnt:0SMON: enabling tx recovery\r\n\r\n    Re-creating tempfile +DG01 as +DG01\/maastb\/tempfile\/temp.276.844784711\r\n    Database Characterset is WE8MSWIN1252\r\n    No Resource Manager plan active\r\n    Starting background process GTX0\r\n    Sun Apr 13 08:25:14 2014\r\n    GTX0 started with pid=39, OS id=32334\r\n    Starting background process RCBG\r\n    Sun Apr 13 08:25:14 2014\r\n    RCBG started with pid=40, OS id=32336\r\n    replication_dependency_tracking turned off (no async multimaster replication found)\r\n    Starting background process QMNC\r\n    Sun Apr 13 08:25:15 2014\r\n    QMNC started with pid=41, OS id=32338\r\n    LOGSTDBY: Validating controlfile with logical metadata\r\n    LOGSTDBY: Validation complete\r\n    Sun Apr 13 08:25:16 2014\r\n    Completed: ALTER DATABASE OPEN\r\n<\/pre>\n
Pe\u00e7o que observe com calma o alertlog acima, ele nos d\u00e1 algumas informa\u00e7\u00f5es interessantes. Primeiro nos diz que o banco est\u00e1 abrindo e que o destino LOG_ARCHIVE_DEST_2 n\u00e3o est\u00e1 sincronizado. Lembram do artigo anterior em que j\u00e1 deixamos tudo pronto para uma eventual troca de papeis? Ent\u00e3o, o novo primary est\u00e1 tentando se comunicar com o seu standby (que era o antigo primary) mas n\u00e3o est\u00e1 conseguindo (se voc\u00ea ver logo abaixo tem uma falha de TNS). Mais para baixo ele vai detectar que n\u00e3o tem a tablespace TEMP, ela foi criada e o banco aberto.<\/p>\n
Caso queira investigar a falha do LOG_ARCHIVE_DEST_2 basta executar o comando abaixo:<\/p>\n
SQL> COL dest_name FORMAT a20\r\nSQL> COL error FORMAT a20\r\nSQL> COL destination FORMAT a10\r\nSQL> SELECT inst_id, dest_name, destination, status, error FROM gv$archive_dest_status WHERE status != 'INACTIVE';\r\n\r\n   INST_ID DEST_NAME            DESTINATIO STATUS    ERROR\r\n---------- -------------------- ---------- --------- --------------------\r\n         2 LOG_ARCHIVE_DEST_1              VALID\r\n         2 LOG_ARCHIVE_DEST_2   maa        VALID\r\n         1 LOG_ARCHIVE_DEST_1              VALID\r\n         1 LOG_ARCHIVE_DEST_2   maa        ERROR     ORA-12514:\r\n                                                     TNS:listener does\r\n                                                     not currently know\r\n                                                     of service requested\r\n                                                     in connect\r\n                                                     descriptor\r\n\r\n\r\nSQL>\r\n<\/pre>\n
Enquanto o antigo primary n\u00e3o volta n\u00f3s podemos desligar o envio de dados do novo primary para o seu standby. Isso evita um monte de lixo no alertlog:<\/p>\n
SQL> ALTER SYSTEM SET log_archive_dest_state_2 = 'DEFER' SCOPE = BOTH SID = '*';\r\n\r\nSystem altered.\r\n\r\nSQL>\r\n<\/pre>\n
Ajustando o novo primary<\/strong><\/p>\n
Um detalhe interessante, o Oracle automaticamente ap\u00f3s um failover reduz o modo de prote\u00e7\u00e3o do seu banco. Assim, ele passa a operar em MAXIMUM PERFORMANCE. Voc\u00ea pode corrigir isso como o seguinte comando:<\/p>\n
SQL> SELECT protection_mode, protection_level FROM v$database;\r\n\r\nPROTECTION_MODE      PROTECTION_LEVEL\r\n-------------------- --------------------\r\nMAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE\r\n\r\nSQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;\r\n\r\nDatabase altered.\r\n\r\nSQL> SELECT protection_mode, protection_level FROM v$database;\r\n\r\nPROTECTION_MODE      PROTECTION_LEVEL\r\n-------------------- --------------------\r\nMAXIMUM AVAILABILITY RESYNCHRONIZATION\r\n\r\nSQL>\r\n<\/pre>\n
Vamos verificar se tudo foi replicado com sucesso e n\u00e3o perdemos qualquer informa\u00e7\u00e3o? Na pr\u00e1tica voc\u00ea vai fazer diversas valida\u00e7\u00f5es nos seus dados para garantir isso, aqui vamos usar a nossa tabela de testes. Como voc\u00ea pode ver abaixo, tudo est\u00e1 l\u00e1:<\/p>\n
SQL> SELECT c1, TO_CHAR(c2, 'DD\/MM HH24:MI:SS') as momento FROM testedg;\r\n\r\n        C1 MOMENTO\r\n---------- --------------\r\n         1 13\/04 07:00:04\r\n         2 13\/04 07:01:11\r\n\r\nSQL>\r\n<\/pre>\n
CORRIGINDO CRS<\/strong><\/p>\n
Se voc\u00ea seguiu o artigo anterior ir\u00e1 notar que registramos no CRS que esta base \u00e9 um standby e no caso de um restart do n\u00f3 ele ser\u00e1 aberto em modo mount. Como ocorreu a troca de papeis, precisamos corrigir o CRS. Iremos informar que ela \u00e9 um banco primary e deve sempre iniciar em open (observe a lista de comandos):<\/p>\n
[oracle@rac11stb01 ~]$ srvctl config database -d maastb -v<\/strong>\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<\/strong>\r\nStop options: immediate\r\nDatabase role: PHYSICAL_STANDBY<\/strong>\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[oracle@rac11stb01 ~]$    \r\n[oracle@rac11stb01 ~]$ srvctl modify database -d maastb -s OPEN -r PRIMARY<\/strong>\r\n[oracle@rac11stb01 ~]$\r\n[oracle@rac11stb01 ~]$\r\n[oracle@rac11stb01 ~]$ srvctl config database -d maastb -v<\/strong>\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<\/strong>\r\nStop options: immediate\r\nDatabase role: PRIMARY<\/strong>\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
Como voc\u00ea est\u00e1 em um ambiente RAC voc\u00ea deve abrir as outras inst\u00e2ncias:<\/p>\n
SQL> SELECT instance_name, status FROM gv$instance;\r\n\r\nINSTANCE_NAME    STATUS\r\n---------------- ------------\r\nmaastb1          OPEN\r\nmaastb2          MOUNTED\r\n\r\nSQL> ALTER DATABASE OPEN;\r\n\r\nDatabase altered.\r\n\r\nSQL> SELECT instance_name FROM v$instance;\r\n\r\nINSTANCE_NAME\r\n----------------\r\nmaastb2\r\n\r\nSQL>\r\n<\/pre>\n
BACKUP<\/strong><\/p>\n
Por fim, \u00e9 imprescind\u00edvel um backup do seu novo banco primary, ser\u00e1 importante caso voc\u00ea precise criar ou recriar o seu standby (antigo primary). Um detalhe que pode poupar um pouco de tempo no futuro, eu n\u00e3o recomendaria fazer um backup e apagar os archive logs (DELETE ALL INPUT), lembre que o novo primary n\u00e3o sincronizou nada com o standby. Assim quando ele voltar ele ir\u00e1 precisar enviar os archives e caso eles n\u00e3o estejam dispon\u00edvel voc\u00ea ir\u00e1 precisar voltar backup. At\u00e9 se voc\u00ea tentar deletar voc\u00ea receber\u00e1 um warnig dizendo que eles s\u00e3o necess\u00e1rios.<\/p>\n
Uma curiosidade, se voc\u00ea listar as suas c\u00f3pias de archive ir\u00e1 ver que os \u00faltimos oriundos do antigo primary est\u00e3o marcados como \u201cTERMINAL\u201d<\/p>\n
RUN {\r\n    BACKUP FULL FORMAT '\/tmp\/bkpf-data-D-%d-DBID-%I-T-%T-NB-%s.bkp' DATABASE TAG 'BKP-FULL';\r\n    SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';\r\n    BACKUP FORMAT '\/tmp\/bkpf-arch-D-%d-DBID-%I-T-%T-NB-%s.bkp' ARCHIVELOG ALL TAG 'BKP-FULL-ARCH';\r\n    BACKUP FORMAT '\/tmp\/bkp-spf-D-%d-DBID-%I-T-%T-NB-%s.bkp' SPFILE TAG 'BKP-FULL-SPFILE';\r\n    BACKUP FORMAT '\/tmp\/bkp-ctf-D-%d-DBID-%I-T-%T-NB-%s.bkp' CURRENT CONTROLFILE TAG 'BKP-FULL-CONTROL';\r\n}           \r\n   \r\n[oracle@rac11stb01 ~]$ rman target \/\r\n\r\nRecovery Manager: Release 11.2.0.3.0 - Production on Sun Apr 13 09:01:14 2014\r\n\r\nCopyright (c) 1982, 2011, Oracle and\/or its affiliates.  All rights reserved.\r\n\r\nconnected to target database: MAA (DBID=722024964)\r\n\r\nRMAN> RUN {\r\n2>     BACKUP FULL FORMAT '\/tmp\/bkpf-data-D-%d-DBID-%I-T-%T-NB-%s.bkp' DATABASE TAG 'BKP-FULL';\r\n3>     SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';\r\n4>     BACKUP FORMAT '\/tmp\/bkpf-arch-D-%d-DBID-%I-T-%T-NB-%s.bkp' ARCHIVELOG ALL TAG 'BKP-FULL-ARCH';\r\n5>     BACKUP FORMAT '\/tmp\/bkp-spf-D-%d-DBID-%I-T-%T-NB-%s.bkp' SPFILE TAG 'BKP-FULL-SPFILE';\r\n6>     BACKUP FORMAT '\/tmp\/bkp-ctf-D-%d-DBID-%I-T-%T-NB-%s.bkp' CURRENT CONTROLFILE TAG 'BKP-FULL-CONTROL';\r\n7> }\r\n\r\nStarting backup at 13-APR-14\r\nusing target database control file instead of recovery catalog\r\nallocated channel: ORA_DISK_1\r\nchannel ORA_DISK_1: SID=30 instance=maastb1 device type=DISK\r\nchannel ORA_DISK_1: starting full datafile backup set\r\nchannel ORA_DISK_1: specifying datafile(s) in backup set\r\ninput datafile file number=00001 name=+DG01\/maastb\/datafile\/system.275.844715965\r\ninput datafile file number=00002 name=+DG01\/maastb\/datafile\/sysaux.264.844715965\r\ninput datafile file number=00003 name=+DG01\/maastb\/datafile\/undotbs1.263.844715965\r\ninput datafile file number=00004 name=+DG01\/maastb\/datafile\/undotbs2.262.844715965\r\ninput datafile file number=00005 name=+DG01\/maastb\/datafile\/users.256.844715965\r\nchannel ORA_DISK_1: starting piece 1 at 13-APR-14\r\n...\r\n...\r\n...\r\nStarting backup at 13-APR-14\r\nusing channel ORA_DISK_1\r\nchannel ORA_DISK_1: starting full datafile backup set\r\nchannel ORA_DISK_1: specifying datafile(s) in backup set\r\nincluding current control file in backup set\r\nchannel ORA_DISK_1: starting piece 1 at 13-APR-14\r\nchannel ORA_DISK_1: finished piece 1 at 13-APR-14\r\npiece handle=\/tmp\/bkp-ctf-D-MAA-DBID-722024964-T-20140413-NB-29.bkp tag=BKP-FULL-CONTROL comment=NONE\r\nchannel ORA_DISK_1: backup set complete, elapsed time: 00:00:01\r\nFinished backup at 13-APR-14\r\n\r\nRMAN> LIST COPY OF ARCHIVELOG ALL;\r\n\r\nList of Archived Log Copies for database with db_unique_name MAASTB\r\n=====================================================================\r\n\r\nKey     Thrd Seq     S Low Time\r\n------- ---- ------- - ---------\r\n7       1    56      A 12-APR-14\r\n        Name: +FRA\/maastb\/archivelog\/2014_04_12\/thread_1_seq_56.391.844718829\r\n...\r\n...\r\n...\r\n45      1    76      A 13-APR-14\r\n        Name: +FRA\/maastb\/archivelog\/2014_04_13\/thread_1_seq_76.389.844775859\r\n\r\n47      1    77      A 13-APR-14\r\n        Name: +FRA\/maastb\/archivelog\/2014_04_13\/thread_1_seq_77.350.844784741 (TERMINAL)\r\n\r\n4       2    33      A 12-APR-14\r\n        Name: +FRA\/maastb\/archivelog\/2014_04_12\/thread_2_seq_33.398.844717695\r\n...\r\n...\r\n...\r\n43      2    53      A 13-APR-14\r\n        Name: +FRA\/maastb\/archivelog\/2014_04_12\/thread_2_seq_53.381.844746645\r\n\r\n48      2    54      A 13-APR-14\r\n        Name: +FRA\/maastb\/archivelog\/2014_04_13\/thread_2_seq_54.355.844784743 (TERMINAL)\r\n\r\n...\r\n...\r\n...\r\n53      2    3       A 13-APR-14\r\n        Name: +FRA\/maastb\/archivelog\/2014_04_13\/thread_2_seq_3.300.844786941\r\n\r\n\r\nRMAN>\r\n<\/pre>\n
AMBIENTE FINAL<\/strong><\/p>\n
Aqui, temos um ambiente em que o banco primary foi chaveado atrav\u00e9s de failover para seu standby. O failover foi manual e n\u00e3o tivemos qualquer perda de dados devido a forma como o DG estava configurado: MAXIMUM AVAILABILITY e com real-time-apply.<\/p>\n
Claro que isso n\u00e3o teria acontecido se primary e standby n\u00e3o estivessem sincronizados. Voc\u00ea j\u00e1 come\u00e7a errado se o seu ambiente n\u00e3o est\u00e1 sincronizado (voc\u00ea nem deveria come\u00e7ar na realidade). Se voc\u00ea continuar com o ambiente n\u00e3o sincronizado voc\u00ea ter\u00e1 perda de dados, isso \u00e9 fato.<\/p>\n
Lembre-se que aqui tudo foi feito manualmente, em um ambiente MAA DG+RAC voc\u00ea teria o broker configurado (mas isso fica para artigos que vir\u00e3o a seguir). No pr\u00f3ximo artigo veremos como fazer o reinstate do antigo primary, vamos fazer ele voltar e se tornar o standby.<\/p>\n","protected":false},"excerpt":{"rendered":"
No artigo anterior demonstrei como configurar um DG para que voc\u00ea possa ter MAA no seu ambiente. Foram apresentados os passos para criar um DG entre um banco primary ORACLE RAC e standby tamb\u00e9m em ORACLE RAC. At\u00e9 o momento o ambiente n\u00e3o est\u00e1 100%, ainda n\u00e3o configuramos o DG para utilizar o broker e […]<\/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":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[30,41,29,47,5,42],"tags":[],"class_list":["post-151","post","type-post","status-publish","format-standard","hentry","category-banco-de-dados","category-data-guard","category-database","category-failover","category-oracle","category-rac"],"yoast_head":"\nOracle e MAA - Artigo II - Failover Manual<\/title>\n<meta name=\"description\" content=\"Fazendo o Failover manual em um ambiente Oracle com Maximum Availability Architecture (MAA), Data Guard (DG) e RAC. Dicas, detalhes e truques.\" \/>\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-ii-failover\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Oracle e MAA - Artigo II - Failover Manual\" \/>\n<meta property=\"og:description\" content=\"Fazendo o Failover manual em um ambiente Oracle com Maximum Availability Architecture (MAA), Data Guard (DG) e RAC. Dicas, detalhes e truques.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/\" \/>\n<meta property=\"og:site_name\" content=\"Fernando Simon\" \/>\n<meta property=\"article:published_time\" content=\"2014-04-25T23:18:38+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2015-01-26T02:31:35+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=\"19 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-ii-failover\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/\"},\"author\":{\"name\":\"Simon\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\"},\"headline\":\"Oracle e MAA – Artigo II – Failover\",\"datePublished\":\"2014-04-25T23:18:38+00:00\",\"dateModified\":\"2015-01-26T02:31:35+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/\"},\"wordCount\":1825,\"commentCount\":7,\"articleSection\":[\"Banco de Dados\",\"Data Guard\",\"Database\",\"Failover\",\"Oracle\",\"RAC\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/\",\"url\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/\",\"name\":\"Oracle e MAA - Artigo II - Failover Manual\",\"isPartOf\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#website\"},\"datePublished\":\"2014-04-25T23:18:38+00:00\",\"dateModified\":\"2015-01-26T02:31:35+00:00\",\"author\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\"},\"description\":\"Fazendo o Failover manual em um ambiente Oracle com Maximum Availability Architecture (MAA), Data Guard (DG) e RAC. Dicas, detalhes e truques.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.fernandosimon.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Oracle e MAA – Artigo II – Failover\"}]},{\"@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 - Artigo II - Failover Manual","description":"Fazendo o Failover manual em um ambiente Oracle com Maximum Availability Architecture (MAA), Data Guard (DG) e RAC. Dicas, detalhes e truques.","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-ii-failover\/","og_locale":"en_US","og_type":"article","og_title":"Oracle e MAA - Artigo II - Failover Manual","og_description":"Fazendo o Failover manual em um ambiente Oracle com Maximum Availability Architecture (MAA), Data Guard (DG) e RAC. Dicas, detalhes e truques.","og_url":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/","og_site_name":"Fernando Simon","article_published_time":"2014-04-25T23:18:38+00:00","article_modified_time":"2015-01-26T02:31:35+00:00","author":"Simon","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Simon","Est. reading time":"19 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/#article","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/"},"author":{"name":"Simon","@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"headline":"Oracle e MAA – Artigo II – Failover","datePublished":"2014-04-25T23:18:38+00:00","dateModified":"2015-01-26T02:31:35+00:00","mainEntityOfPage":{"@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/"},"wordCount":1825,"commentCount":7,"articleSection":["Banco de Dados","Data Guard","Database","Failover","Oracle","RAC"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/","url":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/","name":"Oracle e MAA - Artigo II - Failover Manual","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#website"},"datePublished":"2014-04-25T23:18:38+00:00","dateModified":"2015-01-26T02:31:35+00:00","author":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"description":"Fazendo o Failover manual em um ambiente Oracle com Maximum Availability Architecture (MAA), Data Guard (DG) e RAC. Dicas, detalhes e truques.","breadcrumb":{"@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-ii-failover\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.fernandosimon.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Oracle e MAA – Artigo II – Failover"}]},{"@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-2r","_links":{"self":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/151","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=151"}],"version-history":[{"count":0,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/151\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/media?parent=151"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/categories?post=151"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/tags?post=151"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}