{"id":154,"date":"2014-05-11T11:09:23","date_gmt":"2014-05-11T14:09:23","guid":{"rendered":"http:\/\/www.fernandosimon.com\/blog\/?p=154"},"modified":"2015-01-25T23:29:44","modified_gmt":"2015-01-26T02:29:44","slug":"oracle-e-maa-artigo-iv-switchover","status":"publish","type":"post","link":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iv-switchover\/","title":{"rendered":"Oracle e MAA \u2013 Artigo IV \u2013 Switchover"},"content":{"rendered":"

Seguindo a ordem dos artigos o pr\u00f3ximo passo \u00e9 realizar o switchover entre primary e standby. Se voc\u00ea seguiu os artigos at\u00e9 aqui, j\u00e1 realizou um failover manual<\/a> e um reinstate<\/a> do seu ambiente. O switchover pode ser realizado sem que ocorra um failover, ele \u00e9 uma opera\u00e7\u00e3o leg\u00edtima de um Data Guard. Os passos deste artigo podem ser realizados em um ambiente que n\u00e3o sofreu nenhuma falha at\u00e9 o momento.<\/p>\n

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

Neste quarto artigo vamos realizar o switchover manual do ambiente, mostrarei os passos envolvidos e mais alguns detalhes. Citei acima que esse \u00e9 uma sequ\u00eancia dos anteriores, mas os passos s\u00e3o os mesmos para um ambiente que necessita de um switchover sem que antes tenha ocorrido um failover.<\/p>\n

<\/p>\n

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

Neste artigo temos um banco Oracle RAC maastb<\/strong> atuando como primary e um banco Oracle RAC maa<\/strong> atuando como standby. A troca pr\u00e9via de papeis foi realizada devido a um failover, ap\u00f3s o antigo primary sofreu o reinstate e voltou como standby do novo primary.<\/p>\n

SWITCHOVER<\/strong><\/p>\n

O switchover difere do failover pois tanto o primary quanto o standy est\u00e3o ativos durante a execu\u00e7\u00e3o. Assim, voc\u00ea n\u00e3o precisa fazer o reinstate de nenhum deles.<\/p>\n

Novamente, ainda n\u00e3o temos o Broker configurado e todos os comandos ser\u00e3o manuais. Os passos para ambos, failover ou switchover, come\u00e7am da mesma forma: garantia de sincroniza\u00e7\u00e3o. Volto ao mesmo conceito que falei no caso do failover, voc\u00ea tem um ambiente cr\u00edtico que utiliza DG e n\u00e3o mant\u00e9m o ambiente rodando e sincronizado em sua plenitude?<\/p>\n

Sincronia<\/strong><\/p>\n

Como temos o banco primary dispon\u00edvel no switchover, \u00e9 mais f\u00e1cil verificar se ele est\u00e1 sincronizado com o standby. Para isso execute:<\/p>\n

SQL> SELECT database_role FROM v$database;\r\n\r\nDATABASE_ROLE\r\n----------------\r\nPHYSICAL STANDBY\r\n\r\nSQL> SELECT instance_name, status FROM gv$instance;\r\n\r\nINSTANCE_NAME    STATUS\r\n---------------- ------------\r\nmaa1             MOUNTED\r\nmaa2             MOUNTED\r\n\r\nSQL>\r\n<\/pre>\n
Se voc\u00ea quiser, pode verificar se est\u00e1 tudo correto com o seu Oracle RAC standby (deveria estar j\u00e1 que o anterior j\u00e1 retornou com sucesso):<\/p>\n
SQL> SELECT database_role FROM v$database;\r\n\r\nDATABASE_ROLE\r\n----------------\r\nPRIMARY\r\n\r\nSQL> 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 PRIMARY\r\n\r\nSQL>\r\n<\/pre>\n
Os comandos acima j\u00e1 nos mostraram que est\u00e1 tudo correto com o envio e recebimento dos archives entre primary e standby. Se voc\u00ea quiser verificar qualquer erro ou GAP na troca de archives execute:<\/p>\n
SQL> COL error FORMAT a10\r\nSQL> COL destination FORMAT a20\r\nSQL> COL dest_name FORMAT a20\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            DESTINATION          STATUS    ERROR\r\n---------- -------------------- -------------------- --------- ----------\r\n         1 LOG_ARCHIVE_DEST_1                        VALID\r\n         1 LOG_ARCHIVE_DEST_2   maa                  VALID\r\n         2 LOG_ARCHIVE_DEST_1                        VALID\r\n         2 LOG_ARCHIVE_DEST_2   maa                  VALID\r\n\r\nSQL> SELECT * FROM gv$archive_gap;\r\n\r\nno rows selected\r\n\r\nSQL>\r\n<\/pre>\n
Controle<\/strong><\/p>\n
Como n\u00e3o temos qualquer erro podemos seguir e realizar o swicthover. Para ilustrar que n\u00e3o perderemos qualquer informa\u00e7\u00e3o durante o switchover vamos voltar a nossa tabela de teste de sincronia que criamos no artigo do failover. Vamos limpar, inserir alguns dados e verificar se ap\u00f3s o switchover nenhuma informa\u00e7\u00e3o foi perdida (isso \u00e9 um teste e voc\u00ea n\u00e3o precisa fazer em seu ambiente de produ\u00e7\u00e3o):<\/p>\n
SQL> select instance_name FROM v$instance;\r\n\r\nINSTANCE_NAME\r\n----------------\r\nmaastb1\r\n\r\nSQL> DELETE FROM testedg;\r\n\r\n2 rows deleted.\r\n\r\nSQL> INSERT INTO testedg VALUES(5, sysdate);\r\n\r\n1 row created.\r\n\r\nSQL> COMMIT;\r\n\r\nCommit complete.\r\n\r\nSQL> SELECT c1, TO_CHAR(c2, 'DD\/MM HH24:MI:SS') AS momento FROM testedg;\r\n\r\n        C1 MOMENTO\r\n---------- --------------\r\n         5 13\/04 13:38:10\r\n\r\nSQL>\r\n<\/pre>\n
Oracle RAC e ORA-01105<\/strong><\/p>\n
Oracle RAC \u00e9 legal, ainda mais quanto temos um DataGuard e trabalhamos com MAA, mas as vezes complica a vida de um DBA. O detalhe \u00e9 que como estamos em ambiente Oracle RAC voc\u00ea n\u00e3o pode fazer swicthover se mais de uma inst\u00e2ncia do primary estiver online. Caso voc\u00ea tente fazer isso receber\u00e1 o belo de um erro \u201cORA-01105: mount is incompatible with mounts by other instances<\/em><\/strong>\u201d. Para resolver tal erro, basta deixar somente uma inst\u00e2ncia online do primary (lembre-se que aqui a maastb est\u00e1 atuando como primary):<\/p>\n
[oracle@rac11stb01 ~]$ srvctl status database -d maastb\r\nInstance maastb1 is running on node rac11stb01\r\nInstance maastb2 is running on node rac11stb02\r\n[oracle@rac11stb01 ~]$    \r\n[oracle@rac11stb01 ~]$ srvctl stop instance -d maastb -i maastb2 -o immediate\r\n[oracle@rac11stb01 ~]$\r\n<\/pre>\n
TO STANDBY<\/strong><\/p>\n
Prosseguindo com o switchover precisamos fazer a troca de papeis. Recomendo desconectar qualquer conex\u00e3o com o seu banco primary antes de prosseguir, voc\u00ea pode fazer sem isso mas finalizar qualquer conex\u00e3o deixa tudo mais r\u00e1pido.<\/p>\n
Antes do switchover, verifique ser voc\u00ea o seu banco primary ir\u00e1 aceitar a troca. Com o comando abaixo voc\u00ea faz isso, garante que nenhuma conex\u00e3o est\u00e1 ativa e poder\u00e1 prosseguir com a troca:<\/p>\n
SQL> SELECT switchover_status FROM v$database;\r\n\r\nSWITCHOVER_STATUS\r\n--------------------\r\nTO STANDBY\r\n\r\nSQL>\r\n<\/pre>\n
Depois de verificar que pode ocorrer a troca, basta execut\u00e1-la:<\/p>\n
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;<\/strong>\r\n\r\nDatabase altered.\r\n\r\nSQL>\r\n\r\nNo alert da primary:\r\n    Sun Apr 13 13:40:07 2014\r\n    ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN\r\n    ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id: 10087] (maastb1)\r\n    Sun Apr 13 13:40:08 2014\r\n    LGWR: Standby redo logfile selected to archive thread 1 sequence 20\r\n    LGWR: Standby redo logfile selected for thread 1 sequence 20 for destination LOG_ARCHIVE_DEST_2\r\n    Thread 1 advanced to log sequence 20 (LGWR switch)\r\n      Current log# 2 seq# 20 mem# 0: +DG01\/maastb\/onlinelog\/group_2.268.844716057\r\n      Current log# 2 seq# 20 mem# 1: +FRA\/maastb\/onlinelog\/group_2.564.844716059\r\n    Stopping background process QMNC\r\n    Sun Apr 13 13:40:08 2014\r\n    Stopping background process CJQ0\r\n    Sun Apr 13 13:40:08 2014\r\n    Archived Log entry 119 added for thread 1 sequence 19 ID 0x2b1c0c3f dest 1:\r\n    CLOSE: killing server sessions.\r\n    Active process 1004 user 'oracle' program 'oracle@rac11stb01.tjsc.jus.br (TNS V1-V3)'\r\n    Active process 9850 user 'oracle' program 'oracle@rac11stb01.tjsc.jus.br (W000)'\r\n    Active process 9850 user 'oracle' program 'oracle@rac11stb01.tjsc.jus.br (W000)'\r\n    ...\r\n    ...\r\n    ...\r\n    Active process 1004 user 'oracle' program 'oracle@rac11stb01.tjsc.jus.br (TNS V1-V3)'\r\n    Active process 9850 user 'oracle' program 'oracle@rac11stb01.tjsc.jus.br (W000)'\r\n    Active process 1013 user 'oracle' program 'oracle@rac11stb01.tjsc.jus.br (TNS V1-V3)'\r\n    CLOSE: all sessions shutdown successfully.<\/strong>\r\n    Waiting for all non-current ORLs to be archived...\r\n    All non-current ORLs have been archived.\r\n    Waiting for all FAL entries to be archived...\r\n    All FAL entries have been archived.\r\n    Waiting for potential Physical Standby switchover target to become synchronized...\r\n    Active, synchronized Physical Standby switchover target has been identified\r\n    Switchover End-Of-Redo Log thread 1 sequence 20 has been fixed<\/strong>\r\n    Switchover: Primary highest seen SCN set to 0x0.0x28a6d8\r\n    ARCH: Noswitch archival of thread 1, sequence 20\r\n    ARCH: End-Of-Redo Branch archival of thread 1 sequence 20\r\n    ARCH: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2\r\n    ARCH: Standby redo logfile selected for thread 1 sequence 20 for destination LOG_ARCHIVE_DEST_2\r\n    Archived Log entry 120 added for thread 1 sequence 20 ID 0x2b1c0c3f dest 1:\r\n    ARCH: Archiving is disabled due to current logfile archival\r\n    Primary will check for some target standby to have received alls redo\r\n    Final check for a synchronized target standby. Check will be made once.\r\n    LOG_ARCHIVE_DEST_2 is a potential Physical Standby switchover target\r\n    Active, synchronized target has been identified\r\n    Target has also received all redo<\/strong>\r\n    Backup controlfile written to trace file \/u01\/app\/oracle\/diag\/rdbms\/maastb\/maastb1\/trace\/maastb1_ora_10087.trc\r\n    Clearing standby activation ID 723258431 (0x2b1c0c3f)\r\n    The primary database controlfile was created using the\r\n    'MAXLOGFILES 192' clause.\r\n    There is space for up to 188 standby redo logfiles\r\n    Use the following SQL commands on the standby database to create\r\n    standby redo logfiles that match the primary database:\r\n    ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;\r\n    ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;\r\n    ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;\r\n    ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;\r\n    ALTER DATABASE ADD STANDBY LOGFILE 'srl5.f' SIZE 52428800;\r\n    Archivelog for thread 1 sequence 20 required for standby recovery\r\n    Switchover: Primary controlfile converted to standby controlfile succesfully.\r\n    Switchover: Complete - Database shutdown required\r\n    Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN\r\n\r\nNo alert da standby:\r\n    [oracle@rac11pri01 dbs]$ tail -f \/u01\/app\/oracle\/diag\/rdbms\/maa\/maa1\/trace\/alert_maa1.log\r\n    Sun Apr 13 13:41:02 2014\r\n    Standby controlfile consistent with primary\r\n    RFS[2]: Selected log 5 for thread 1 sequence 19 dbid 722024964 branch 844762805\r\n    Sun Apr 13 13:41:02 2014\r\n    Archived Log entry 227 added for thread 1 sequence 18 ID 0x2b1c0c3f dest 1:\r\n    Sun Apr 13 13:41:02 2014\r\n    Media Recovery Waiting for thread 1 sequence 19 (in transit)\r\n    Recovery of Online Redo Log: Thread 1 Group 5 Seq 19 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\n    Sun Apr 13 13:43:14 2014\r\n    RFS[2]: Selected log 6 for thread 1 sequence 20 dbid 722024964 branch 844762805\r\n    Sun Apr 13 13:43:14 2014\r\n    Archived Log entry 228 added for thread 1 sequence 19 ID 0x2b1c0c3f dest 1:\r\n    Sun Apr 13 13:43:14 2014\r\n    Media Recovery Waiting for thread 1 sequence 20 (in transit)\r\n    Recovery of Online Redo Log: Thread 1 Group 6 Seq 20 Reading mem 0\r\n      Mem# 0: +DATA\/maa\/onlinelog\/group_6.261.843615373\r\n      Mem# 1: +FRA\/maa\/onlinelog\/group_6.670.843615373\r\n    RFS[2]: Possible network disconnect with primary database\r\n    Sun Apr 13 13:43:19 2014\r\n    RFS[8]: Assigned to RFS process 12838\r\n    RFS[8]: Selected log 6 for thread 1 sequence 20 dbid 722024964 branch 844762805\r\n    Resetting standby activation ID 723258431 (0x2b1c0c3f)\r\n    Sun Apr 13 13:43:20 2014\r\n    Archived Log entry 229 added for thread 1 sequence 20 ID 0x2b1c0c3f dest 1:\r\n    Media Recovery Waiting for thread 1 sequence 21\r\n<\/pre>\n
Analisando o comando e o log acima temos que o banco sofre commit de todas as transa\u00e7\u00f5es (COMMIT), foi trocado de papel para ser standby (SWITCHOVER TO PHYSICAL STANDBY) e finalizou toda e qualquer conex\u00e3o existente (WITH SESSION SHUTDOWN). Observe no alertlog do banco primary que ele verificou (duas vezes) se o standby estava apto e recebeu tudo o que devia (Active, synchronized Physical Standby switchover target has been identified). Tamb\u00e9m observe no alertlog que novamente temos um \u201cEnf-Of-Redo\u201d e o kill de todos os processo conectados.<\/p>\n
Uma informa\u00e7\u00e3o importante est\u00e1 no alertlog, \u00e9 necess\u00e1rio fazer o shutdown da antiga primary. Assim, um abort resolve (n\u00e3o se preocupe, os redo ser\u00e3o limpos automaticamente):<\/p>\n
SQL> shutdown abort;\r\nORACLE instance shut down.\r\nSQL> STARTUP MOUNT;\r\nORACLE instance started.\r\n\r\nTotal System Global Area 1068937216 bytes\r\nFixed Size                  2235208 bytes\r\nVariable Size             343934136 bytes\r\nDatabase Buffers          717225984 bytes\r\nRedo Buffers                5541888 bytes\r\nDatabase mounted.\r\nSQL>\r\n<\/pre>\n
SWITCHOVER TO PRIMARY<\/strong><\/p>\n
Entramos em um momento critico e sem volta, neste momento voc\u00ea n\u00e3o tem nenhum banco primary. O antigo primary j\u00e1 acredita que ser\u00e1 standby e o novo primary ainda acha que \u00e9 standby. Claro que os comandos executados at\u00e9 aqui garantem a sincronia entre os bancos, mas \u00e9 sempre bom tomar cuidado.<\/p>\n
At\u00e9 aqui j\u00e1 verificamos e garantimos que est\u00e1 tudo sincronizado e que voc\u00ea est\u00e1 sem primary. Al\u00e9m disso, j\u00e1 garantimos que a antiga primary est\u00e1 em modo mount para evitar que ao abrir o novo primary apare\u00e7am erros de tns e n\u00e3o consiga sincronizar os redo.<\/p>\n
Agora precisamos fazer a standby se tornar a primary. Isso \u00e9 simples e realizado com um \u00fanico comando:<\/p>\n
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;<\/strong>\r\n\r\nDatabase altered.\r\n\r\nSQL>\r\n\r\nNo alert da antiga standby:\r\n    Sun Apr 13 13:56:37 2014\r\n    ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN<\/strong>\r\n    ALTER DATABASE SWITCHOVER TO PRIMARY (maa1)\r\n    Maximum wait for role transition is 15 minutes.\r\n    Switchover: Media recovery is still active\r\n    Role Change: Canceling MRP - no more redo to apply\r\n    Sun Apr 13 13:56:38 2014\r\n    MRP0: Background Media Recovery cancelled with status 16037\r\n    Errors in file \/u01\/app\/oracle\/diag\/rdbms\/maa\/maa1\/trace\/maa1_pr00_11067.trc:\r\n    ORA-16037: user requested cancel of managed recovery operation\r\n    Sun Apr 13 13:56:38 2014\r\n    Managed Standby Recovery not using Real Time Apply<\/strong>\r\n    Recovery interrupted!<\/strong>\r\n    Sun Apr 13 13:56:40 2014\r\n    MRP0: Background Media Recovery process shutdown (maa1)\r\n    Role Change: Canceled MRP\r\n    Backup controlfile written to trace file \/u01\/app\/oracle\/diag\/rdbms\/maa\/maa1\/trace\/maa1_ora_11497.trc\r\n    SwitchOver after complete recovery through change 2664152\r\n    Online log +DATA\/maa\/onlinelog\/group_1.272.843488553: Thread 1 Group 1 was previously cleared\r\n    Online log +FRA\/maa\/onlinelog\/group_1.286.843488555: Thread 1 Group 1 was previously cleared\r\n    Online log +DATA\/maa\/onlinelog\/group_2.271.843488555: Thread 1 Group 2 was previously cleared\r\n    Online log +FRA\/maa\/onlinelog\/group_2.285.843488555: Thread 1 Group 2 was previously cleared\r\n    Online log +DATA\/maa\/onlinelog\/group_3.257.843489101: Thread 2 Group 3 was previously cleared\r\n    Online log +FRA\/maa\/onlinelog\/group_3.284.843489101: Thread 2 Group 3 was previously cleared\r\n    Online log +DATA\/maa\/onlinelog\/group_4.262.843489103: Thread 2 Group 4 was previously cleared\r\n    Online log +FRA\/maa\/onlinelog\/group_4.283.843489103: Thread 2 Group 4 was previously cleared\r\n    Standby became primary SCN: 2664150\r\n    Switchover: Complete - Database mounted as primary\r\n    Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN\r\n<\/strong><\/pre>\n
Como pode ser visto no alertlog acima o comando executou com sucesso. O banco standby passou agora a ser o primary (SWITCHOVER TO PRIMARY e Standby became primary), basta abrir o banco agora:<\/p>\n
SQL> ALTER DATABASE OPEN;\r\n\r\nDatabase altered.\r\n\r\nSQL>\r\n\r\nObserve que ele j\u00e1 detectou que o dest_2 estava dessincronizado e j\u00e1 enviou os dados para ele, voc\u00ea poderia ter deixado ele em modo DEFER caso n\u00e3o quisesse essa sincronia:<\/strong>\r\nNo alert da nova primary temos:\r\n    Sun Apr 13 13:59:13 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 13:59:13 2014\r\n    Assigning activation ID 723321957 (0x2b1d0465)\r\n    LGWR: Primary database is in MAXIMUM AVAILABILITY mode\r\n    Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED<\/strong>\r\n    LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR\r\n    Thread 1 advanced to log sequence 22 (thread open)\r\n    Sun Apr 13 13:59:13 2014\r\n    ARC1: Becoming the 'no SRL' ARCH\r\n    Thread 1 opened at log sequence 22\r\n      Current log# 2 seq# 22 mem# 0: +DATA\/maa\/onlinelog\/group_2.271.843488555\r\n      Current log# 2 seq# 22 mem# 1: +FRA\/maa\/onlinelog\/group_2.285.843488555\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 13:59:13 2014\r\n    SMON: enabling cache recovery\r\n    Instance recovery: looking for dead threads\r\n    Instance recovery: lock domain invalid but no dead threads\r\n    Sun Apr 13 13:59:13 2014\r\n    Archived Log entry 230 added for thread 1 sequence 21 ID 0x2b1d0465 dest 1:\r\n    [11497] Successfully onlined Undo Tablespace 2.\r\n    Undo initialization finished serial:0 start:1374323914 end:1374324594 diff:680 (6 seconds)\r\n    Dictionary check beginning\r\n    Dictionary check complete\r\n    Verifying file header compatibility for 11g tablespace encryption..\r\n    Verifying 11g file header compatibility for tablespace encryption completed\r\n    SMON: enabling tx recovery\r\n    Database Characterset is WE8MSWIN1252\r\n    No Resource Manager plan active\r\n    ******************************************************************\r\n    LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2\r\n    ******************************************************************\r\n    LGWR: Standby redo logfile selected to archive thread 1 sequence 23\r\n    LGWR: Standby redo logfile selected for thread 1 sequence 23 for destination LOG_ARCHIVE_DEST_2\r\n    Thread 1 advanced to log sequence 23 (LGWR switch)\r\n      Current log# 1 seq# 23 mem# 0: +DATA\/maa\/onlinelog\/group_1.272.843488553\r\n      Current log# 1 seq# 23 mem# 1: +FRA\/maa\/onlinelog\/group_1.286.843488555\r\n    Sun Apr 13 13:59:17 2014\r\n    minact-scn: Inst 1 is now the master inc#:4 mmon proc-id:10227 status:0x7\r\n    minact-scn status: grec-scn:0x0000.00000000 gmin-scn:0x0000.00000000 gcalc-scn:0x0000.00000000\r\n    minact-scn: Master returning as live inst:2 has inc# mismatch instinc:0 cur:4 errcnt:0\r\n    Starting background process GTX0\r\n    Sun Apr 13 13:59:17 2014\r\n    GTX0 started with pid=39, OS id=13185\r\n    Starting background process RCBG\r\n    Archived Log entry 232 added for thread 1 sequence 22 ID 0x2b1d0465 dest 1:\r\n    Sun Apr 13 13:59:17 2014\r\n    RCBG started with pid=40, OS id=13187\r\n    replication_dependency_tracking turned off (no async multimaster replication found)\r\n    ARC3: Standby redo logfile selected for thread 1 sequence 22 for destination LOG_ARCHIVE_DEST_2\r\n    Starting background process QMNC\r\n    Sun Apr 13 13:59:18 2014\r\n    QMNC started with pid=41, OS id=13189\r\n    LOGSTDBY: Validating controlfile with logical metadata\r\n    LOGSTDBY: Validation complete\r\n    Completed: ALTER DATABASE OPEN<\/strong>\r\n    Thread 1 cannot allocate new log, sequence 24\r\n    Checkpoint not complete\r\n      Current log# 1 seq# 23 mem# 0: +DATA\/maa\/onlinelog\/group_1.272.843488553\r\n      Current log# 1 seq# 23 mem# 1: +FRA\/maa\/onlinelog\/group_1.286.843488555\r\n    Sun Apr 13 13:59:23 2014\r\n    Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED<\/strong>\r\n    LGWR: Standby redo logfile selected to archive thread 1 sequence 24\r\n    LGWR: Standby redo logfile selected for thread 1 sequence 24 for destination LOG_ARCHIVE_DEST_2\r\n    Thread 1 advanced to log sequence 24 (LGWR switch)\r\n      Current log# 2 seq# 24 mem# 0: +DATA\/maa\/onlinelog\/group_2.271.843488555\r\n      Current log# 2 seq# 24 mem# 1: +FRA\/maa\/onlinelog\/group_2.285.843488555\r\n    Sun Apr 13 13:59:24 2014\r\n    ARC3: STARTING ARCH PROCESSES\r\n    Sun Apr 13 13:59:24 2014\r\n    ARC4 started with pid=44, OS id=13213\r\n    ARC4: Archival started\r\n    ARC3: STARTING ARCH PROCESSES COMPLETE\r\n    Archived Log entry 235 added for thread 1 sequence 23 ID 0x2b1d0465 dest 1:\r\n    Sun Apr 13 13:59:27 2014\r\n    Starting background process CJQ0\r\n    Sun Apr 13 13:59:27 2014\r\n    CJQ0 started with pid=45, OS id=13226     \r\n<\/pre>\n
Lembra que eu disse para deixar a antiga primary ligada? Se voc\u00ea observar no alertlog acima ir\u00e1 ver que a nova primary j\u00e1 detectou que a standby precisa de sincronia e j\u00e1 come\u00e7ou a enviar os redo. Observe que a standby detectou isso, recebeu e aplicou os redo:<\/p>\n
No alert da antiga primary e atual standby:\r\n    Sun Apr 13 13:52:18 2014\r\n    ARC2: Becoming the active heartbeat ARCH\r\n    ARC2: Becoming the active heartbeat ARCH\r\n    Sun Apr 13 13:56:07 2014\r\n    Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST\r\n    Sun Apr 13 13:56:08 2014\r\n    RFS[1]: Assigned to RFS process 10590\r\n    RFS[1]: Opened log for thread 1 sequence 21 dbid 722024964 branch 844762805\r\n    Archived Log entry 122 added for thread 1 sequence 21 rlc 844762805 ID 0x2b1d0465 dest 2:\r\n    Sun Apr 13 13:56:10 2014\r\n    Primary database is in MAXIMUM AVAILABILITY mode\r\n    Changing standby controlfile to RESYNCHRONIZATION level\r\n    Standby controlfile consistent with primary\r\n    RFS[2]: Assigned to RFS process 10600\r\n    RFS[2]: Selected log 5 for thread 1 sequence 23 dbid 722024964 branch 844762805\r\n    Sun Apr 13 13:56:11 2014\r\n    RFS[3]: Assigned to RFS process 10602\r\n    RFS[3]: Selected log 6 for thread 1 sequence 22 dbid 722024964 branch 844762805\r\n    Sun Apr 13 13:56:12 2014\r\n    Archived Log entry 123 added for thread 1 sequence 22 ID 0x2b1d0465 dest 1:\r\n    Changing standby controlfile to MAXIMUM AVAILABILITY level\r\n    RFS[2]: Selected log 6 for thread 1 sequence 24 dbid 722024964 branch 844762805\r\n    Sun Apr 13 13:56:18 2014\r\n    Archived Log entry 124 added for thread 1 sequence 23 ID 0x2b1d0465 dest 1:<\/pre>\n
Outras inst\u00e2ncias<\/strong><\/p>\n
Novamente por estarmos e um ambiente Oracle RAC abrimos a outras inst\u00e2ncias do primary (poderia ter feito isso via srvctl, mas escolhi fazer manualmente):<\/p>\n
SQL> SELECT instance_name, status FROM v$instance;\r\n\r\nINSTANCE_NAME    STATUS\r\n---------------- ------------\r\nmaa2             MOUNTED\r\n\r\nSQL> ALTER DATABASE OPEN;\r\n\r\nDatabase altered.\r\n\r\nSQL>\r\n<\/pre>\n
E tamb\u00e9m abrimos a outra inst\u00e2ncia do standby em modo mount:<\/p>\n
[oracle@rac11stb01 ~]$ srvctl start instance -d maastb -i maastb2 -o mount\r\n[oracle@rac11stb01 ~]$\r\n<\/pre>\n
Sincronia 2<\/strong><\/p>\n
Vamos voltar a um ponto que j\u00e1 destaquei em um artigo anterior. Observe que o novo standby recebeu os archives, mas ele n\u00e3o aplicou ainda, nem mesmo o real-time apply est\u00e1 habilitado (se voc\u00ea notou em alguns alertlogs acima isso fica expl\u00edcito \u2013 deixei em negrito). Para \u201ccorrigir\u201d isso basta executar o comando abaixo (em uma das inst\u00e2ncias do standby):<\/p>\n
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;\r\n\r\nDatabase altered.\r\n\r\nSQL>\r\n<\/pre>\n
Depois disso podemos ver como ficou a sincroniza\u00e7\u00e3o entre primary e standby:<\/p>\n
SQL> SELECT name, protection_mode, protection_level, database_role FROM v$database;\r\n\r\nNAME      PROTECTION_MODE      PROTECTION_LEVEL     DATABASE_ROLE\r\n--------- -------------------- -------------------- ----------------\r\nMAA       MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY PRIMARY\r\n\r\nSQL>\r\n<\/pre>\n
Se voc\u00ea notar, ver\u00e1 que tudo est\u00e1 sincronizado e que n\u00e3o precisamos \u201csubir\u201d o modo de prote\u00e7\u00e3o. No failover isso foi necess\u00e1rio, j\u00e1 no swicthover n\u00e3o. Se ambos os bancos \u201cconcordam\u201d com a troca de papeis a garantia e seguran\u00e7a do ambiente \u00e9 mantida no mesmo n\u00edvel.<\/p>\n
Al\u00e9m disso, podemos verificar como est\u00e1 a nossa tabela de teste (mesmo trocando de base ela se manteve correta):<\/p>\n
SQL> SELECT instance_name FROM v$instance;\r\n\r\nINSTANCE_NAME\r\n----------------\r\nmaa1\r\n\r\nSQL> SELECT c1, TO_CHAR(c2, 'DD\/MM HH24:MI:SS') AS momento FROM testedg;\r\n\r\n        C1 MOMENTO\r\n---------- --------------\r\n         5 13\/04 13:38:10\r\n\r\nSQL>\r\n<\/pre>\n
CRS<\/strong><\/p>\n
Novamente o Oracle RAC e seus detalhes (n\u00e3o que isso seja ruim). Para finalizar precisamos arrumar o CRS do novo primary:<\/p>\n
[oracle@rac11pri01 ~]$ srvctl config database -d maa -v<\/strong>\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<\/strong>\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[oracle@rac11pri01 ~]$\r\n[oracle@rac11pri01 ~]$ srvctl modify database -d maa -s OPEN -r PRIMARY<\/strong>\r\n[oracle@rac11pri01 ~]$\r\n[oracle@rac11pri01 ~]$\r\n[oracle@rac11pri01 ~]$ srvctl config database -d maa -v<\/strong>\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: PRIMARY<\/strong>\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
E na nova standby:<\/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: 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[oracle@rac11stb01 ~]$\r\n[oracle@rac11stb01 ~]$ srvctl modify database -d maastb -s MOUNT -r PHYSICAL_STANDBY<\/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: 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<\/pre>\n
AMBIENTE FINAL<\/strong><\/p>\n
Bom, acredito que tenha ficado claro que o swicthover foi realizado com sucesso. Os papeis foram trocados entre primary e standby sem perder qualquer dado. No fim n\u00e3o esque\u00e7a de fazer um backup do seu ambiente.<\/p>\n
No pr\u00f3ximo artigo vamos ver como configurar o Broker, para que serve e onde pode nos ajudar.<\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
Seguindo a ordem dos artigos o pr\u00f3ximo passo \u00e9 realizar o switchover entre primary e standby. Se voc\u00ea seguiu os artigos at\u00e9 aqui, j\u00e1 realizou um failover manual e um reinstate do seu ambiente. O switchover pode ser realizado sem que ocorra um failover, ele \u00e9 uma opera\u00e7\u00e3o leg\u00edtima de um Data Guard. Os passos […]<\/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_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},"jetpack_post_was_ever_published":false},"categories":[40,30,41,29,5,42,49],"tags":[],"class_list":["post-154","post","type-post","status-publish","format-standard","hentry","category-40","category-banco-de-dados","category-data-guard","category-database","category-oracle","category-rac","category-switchover"],"yoast_head":"\nOracle e MAA - Artigo IV - Switchover Manual<\/title>\n<meta name=\"description\" content=\"Fazendo o switchover 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-iv-switchover\/\" \/>\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 IV - Switchover Manual\" \/>\n<meta property=\"og:description\" content=\"Fazendo o switchover 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-iv-switchover\/\" \/>\n<meta property=\"og:site_name\" content=\"Fernando Simon\" \/>\n<meta property=\"article:published_time\" content=\"2014-05-11T14:09:23+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2015-01-26T02:29:44+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=\"18 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-iv-switchover\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/oracle-e-maa-artigo-iv-switchover\\\/\"},\"author\":{\"name\":\"Simon\",\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/#\\\/schema\\\/person\\\/386da956604bca0d5be5dd52210c1dd9\"},\"headline\":\"Oracle e MAA \u2013 Artigo IV \u2013 Switchover\",\"datePublished\":\"2014-05-11T14:09:23+00:00\",\"dateModified\":\"2015-01-26T02:29:44+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/oracle-e-maa-artigo-iv-switchover\\\/\"},\"wordCount\":1201,\"commentCount\":3,\"articleSection\":[\"600\",\"Banco de Dados\",\"Data Guard\",\"Database\",\"Oracle\",\"RAC\",\"Switchover\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/oracle-e-maa-artigo-iv-switchover\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/oracle-e-maa-artigo-iv-switchover\\\/\",\"url\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/oracle-e-maa-artigo-iv-switchover\\\/\",\"name\":\"Oracle e MAA - Artigo IV - Switchover Manual\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/#website\"},\"datePublished\":\"2014-05-11T14:09:23+00:00\",\"dateModified\":\"2015-01-26T02:29:44+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/#\\\/schema\\\/person\\\/386da956604bca0d5be5dd52210c1dd9\"},\"description\":\"Fazendo o switchover 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-iv-switchover\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/oracle-e-maa-artigo-iv-switchover\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/oracle-e-maa-artigo-iv-switchover\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Oracle e MAA \u2013 Artigo IV \u2013 Switchover\"}]},{\"@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:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g\",\"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 IV - Switchover Manual","description":"Fazendo o switchover 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-iv-switchover\/","og_locale":"en_US","og_type":"article","og_title":"Oracle e MAA - Artigo IV - Switchover Manual","og_description":"Fazendo o switchover 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-iv-switchover\/","og_site_name":"Fernando Simon","article_published_time":"2014-05-11T14:09:23+00:00","article_modified_time":"2015-01-26T02:29:44+00:00","author":"Simon","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Simon","Est. reading time":"18 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iv-switchover\/#article","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iv-switchover\/"},"author":{"name":"Simon","@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"headline":"Oracle e MAA \u2013 Artigo IV \u2013 Switchover","datePublished":"2014-05-11T14:09:23+00:00","dateModified":"2015-01-26T02:29:44+00:00","mainEntityOfPage":{"@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iv-switchover\/"},"wordCount":1201,"commentCount":3,"articleSection":["600","Banco de Dados","Data Guard","Database","Oracle","RAC","Switchover"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iv-switchover\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iv-switchover\/","url":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iv-switchover\/","name":"Oracle e MAA - Artigo IV - Switchover Manual","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#website"},"datePublished":"2014-05-11T14:09:23+00:00","dateModified":"2015-01-26T02:29:44+00:00","author":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"description":"Fazendo o switchover 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-iv-switchover\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iv-switchover\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iv-switchover\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.fernandosimon.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Oracle e MAA \u2013 Artigo IV \u2013 Switchover"}]},{"@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:\/\/secure.gravatar.com\/avatar\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g","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-2u","_links":{"self":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/154","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=154"}],"version-history":[{"count":0,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/154\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/media?parent=154"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/categories?post=154"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/tags?post=154"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}