{"id":152,"date":"2014-05-02T22:38:59","date_gmt":"2014-05-03T01:38:59","guid":{"rendered":"http:\/\/www.fernandosimon.com\/blog\/?p=152"},"modified":"2015-01-25T23:30:48","modified_gmt":"2015-01-26T02:30:48","slug":"oracle-e-maa-artigo-iii-reinstate","status":"publish","type":"post","link":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/","title":{"rendered":"Oracle e MAA – Artigo III – Reinstate"},"content":{"rendered":"

Ap\u00f3s fazer o failover no artigo anterior<\/a> voc\u00ea precisa recuperar o seu ambiente, presiamos fazer o reinstate do antigo primary. De forma resumida o resintate \u00e9 recuperar o banco para que assuma a nova fun\u00e7\u00e3o.<\/p>\n

No mundo real as falhas que podem deixar seu ambiente primary fora e for\u00e7ar o failover para o standby s\u00e3o diversas. Muitas vezes perde-se o ambiente por completo e precisamos recriar o primary, quando acontece isso a solu\u00e7\u00e3o \u00e9 recriar o ambiente e adicionar o banco ao DG. Aqui, o antigo primary teve a sua falha corrigida e ele foi religado. Se no caso voc\u00ea perdeu completamente o antigo primary n\u00e3o h\u00e1 o que fazer, voc\u00ea precisar\u00e1 recriar ele atrav\u00e9s de um backup do novo primary.<\/p>\n

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

Neste artigo irei demonstrar como fazer o reinstate manual do antigo primary. Al\u00e9m disso, tamb\u00e9m demonstrarei como adicionar este banco como standby ao ambiente para que possamos a ter um ambiente MAA. Como este artigo \u00e9 uma sequ\u00eancia dos anteriores eu recomendo a leitura dos anteriores para ficar familiarizado, n\u00e3o \u00e9 obrigat\u00f3rio mas pode ajudar.<\/p>\n

<\/p>\n

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

Neste artigo temos um banco primary rodando em Oracle RAC que sofreu uma falha e sofreu failover para seu standby que tamb\u00e9m roda em Oracle RAC. Com isso o antigo standby foi elevado a fun\u00e7\u00e3o de primary, e esta troca de papeis ocorreu sem qualquer perda de dados.<\/p>\n

Aqui, o antigo primary foi recuperado e est\u00e1 novamente operacional. Como estamos em um ambiente Oracle RAC automaticamente ao servidor ligar o CRS ir\u00e1 iniciar o banco, recomendo que todas as suas inst\u00e2ncias paradas.<\/p>\n

Lembra-se que at\u00e9 o momento n\u00e3o temos o Broker habilitado no ambiente. Tudo o que fizemos at\u00e9 agora foi manual, configura\u00e7\u00e3o, failover e agora o reinstate.<\/p>\n

REINSTATE<\/strong><\/p>\n

O reinstate \u00e9 um procedimento simples, mas para isso voc\u00ea tem que ter seguido alguns passos. No primeiro artigo<\/a> fui categ\u00f3rico ao afirmar que habilitar o flashback do banco de dados traria benef\u00edcios, e \u00e9 aqui que veremos isso. Se voc\u00ea tiver o flashback habilitado com um simples comando voc\u00ea deixa tudo pronto, caso contr\u00e1rio se prepare e tenha backup do banco de dados \u2013 voc\u00ea precisaria.<\/p>\n

SCN<\/strong><\/p>\n

A primeira coisa a fazer \u00e9 identificar qual foi SCN em que o standby se tornou primary, o comando abaixo mostra como fazer isso:<\/p>\n

SQL> SELECT instance_name FROM v$instance;\r\n\r\nINSTANCE_NAME\r\n----------------\r\nmaastb1\r\n\r\nSQL> SELECT standby_became_primary_scn FROM v$database;\r\n\r\nSTANDBY_BECAME_PRIMARY_SCN\r\n--------------------------\r\n                   2596056\r\n\r\nSQL>\r\n<\/pre>\n
Se voc\u00ea notar e comparar com o artigo anterior ver\u00e1 que o SCN foi o mesmo que apareceu no alertlog do standby quando ele se tornou primary. Este SCN \u00e9 fundamental para fazer o resintate do antigo primary, com ele fazemos o flashback do banco. Volto ao ponto da import\u00e2ncia do flashback, com um \u00fanico comando voc\u00ea volta o banco sem precisar de qualquer restore de backup.<\/p>\n
Antigo Primary<\/strong><\/p>\n
Depois de verificar o scn n\u00f3s precisamos iniciar um inst\u00e2ncia do antigo primary. N\u00e3o se preocupe se quando voc\u00ea ligou o servidor o seu antigo primary entrou em modo open. Desta forma, iniciamos uma \u00fanica inst\u00e2ncia em modo mount:<\/p>\n
SQL> STARTUP MOUNT;\r\nORACLE instance started.\r\n\r\nTotal System Global Area 1068937216 bytes\r\nFixed Size                  2235208 bytes\r\nVariable Size             511706296 bytes\r\nDatabase Buffers          549453824 bytes\r\nRedo Buffers                5541888 bytes\r\nDatabase mounted.\r\nSQL> SELECT instance_name FROM v$instance;\r\n\r\nINSTANCE_NAME\r\n----------------\r\nmaa1\r\n\r\nSQL> \r\n<\/pre>\n
Um detalhe interessante, se voc\u00ea fizer um select para saber a role do banco ele ainda acredita que \u00e9 um banco primary. Observe:<\/p>\n
SQL> SELECT database_role FROM v$database;\r\n\r\nDATABASE_ROLE\r\n----------------\r\nPRIMARY\r\n\r\nSQL>\r\n<\/pre>\n
Flashback<\/strong><\/p>\n
At\u00e9 o momento n\u00f3s temos o scn que o houve a troca de papeis, um banco standby que se tornou primary. Al\u00e9m disso, temos o antigo primary que foi aberto em modo mount em uma \u00fanica inst\u00e2ncia, confuso?<\/p>\n
Agora, com o SCN que foi resgatado acima podemos fazer o flashback do antigo primary para ele. Com um simples comando iremos deixar o antigo primary pronto para se tornar o novo standby. Observe:<\/p>\n
SQL> FLASHBACK DATABASE TO SCN 2596056;\r\n\r\nFlashback complete.\r\n\r\nSQL>\r\n<\/pre>\n
Convert to Standby<\/strong><\/p>\n
Como voc\u00ea viu acima este banco ainda acredita que \u00e9 o banco primary, n\u00f3s precisamos alterar isso. O procedimento \u00e9 simples e deixa o banco pronto para se tornar o standby, observe:<\/p>\n
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;\r\n\r\nDatabase altered.\r\n\r\nSQL>\r\n\r\nNo alert da antiga primary:\r\n    Flashback Media Recovery Complete\r\n    Completed: FLASHBACK DATABASE TO SCN 2596056<\/strong>\r\n    Sun Apr 13 11:12:38 2014\r\n    ALTER DATABASE CONVERT TO PHYSICAL STANDBY\r\n    ALTER DATABASE CONVERT TO PHYSICAL STANDBY (maa1)<\/strong>\r\n    Flush standby redo logfile failed:1649\r\n    Clearing standby activation ID 722049028 (0x2b099804)\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    Shutting down archive processes\r\n    Archiving is disabled\r\n    Completed: ALTER DATABASE CONVERT TO PHYSICAL STANDBY<\/strong>\r\n    Sun Apr 13 11:12:44 2014\r\n    SUCCESS: diskgroup FRA was dismounted\r\n    SUCCESS: diskgroup DATA was dismounted\r\n    NOTE: Database dismounted; ASMB process exiting\r\n    Stopping background process RBAL\r\n    Stopping background process MARK\r\n    Sun Apr 13 11:12:46 2014\r\n    NOTE: Shutting down MARK background process\r\n<\/pre>\n
Deixei em negrito no alertlog acima, mas se voc\u00ea notar no ir\u00e1 ver que o banco agora passou a ser o standby. Depois, voc\u00ea eu recomendo fazer um shutdown e um startup mount do novo standby:<\/p>\n
SQL> SHUTDOWN IMMEDIATE;\r\nORA-01507: database not mounted\r\n\r\n\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             511706296 bytes\r\nDatabase Buffers          549453824 bytes\r\nRedo Buffers                5541888 bytes\r\nDatabase mounted.\r\nSQL>\r\n<\/pre>\n
Observe no resultado do comando acima que a informa\u00e7\u00e3o de que o banco n\u00e3o estava montado (mas iniciamos o processo com o banco em estado mount!?). N\u00e3o se preocupe, o processo de convers\u00e3o para standby fez isso.<\/p>\n
Standby redo log files<\/strong><\/p>\n
Agora temos um banco primary e um banco standby pronto para receber o dados\/archives do primary. Antes disso vamos dar uma olhada nos standby redo logs:<\/p>\n
SQL> COL member FORMAT a50\r\nSQL> SELECT group#, type, member FROM v$logfile;\r\n\r\n    GROUP# TYPE    MEMBER\r\n---------- ------- --------------------------------------------------\r\n         1 ONLINE  +DATA\/maa\/onlinelog\/group_1.272.843488553\r\n         1 ONLINE  +FRA\/maa\/onlinelog\/group_1.286.843488555\r\n         2 ONLINE  +DATA\/maa\/onlinelog\/group_2.271.843488555\r\n         2 ONLINE  +FRA\/maa\/onlinelog\/group_2.285.843488555\r\n         3 ONLINE  +DATA\/maa\/onlinelog\/group_3.257.843489101\r\n         3 ONLINE  +FRA\/maa\/onlinelog\/group_3.284.843489101\r\n         4 ONLINE  +DATA\/maa\/onlinelog\/group_4.262.843489103\r\n         4 ONLINE  +FRA\/maa\/onlinelog\/group_4.283.843489103\r\n         5 STANDBY +DATA\/maa\/onlinelog\/group_5.263.843615365\r\n         5 STANDBY +FRA\/maa\/onlinelog\/group_5.289.843615367\r\n         6 STANDBY +DATA\/maa\/onlinelog\/group_6.261.843615373\r\n\r\n    GROUP# TYPE    MEMBER\r\n---------- ------- --------------------------------------------------\r\n         6 STANDBY +FRA\/maa\/onlinelog\/group_6.670.843615373\r\n         7 STANDBY +DATA\/maa\/onlinelog\/group_7.260.843615379\r\n         7 STANDBY +FRA\/maa\/onlinelog\/group_7.263.843615379\r\n         8 STANDBY +DATA\/maa\/onlinelog\/group_8.259.843615383\r\n         8 STANDBY +FRA\/maa\/onlinelog\/group_8.703.843615385\r\n         9 STANDBY +DATA\/maa\/onlinelog\/group_9.256.843615389\r\n         9 STANDBY +FRA\/maa\/onlinelog\/group_9.504.843615389\r\n        10 STANDBY +DATA\/maa\/onlinelog\/group_10.274.843615393\r\n        10 STANDBY +FRA\/maa\/onlinelog\/group_10.496.843615393\r\n\r\n20 rows selected.\r\n\r\nSQL>\r\n<\/pre>\n
Voc\u00ea deve estar se perguntando o porqu\u00ea disso, mas explico. Quando fizemos o convert acima para physical standby apareceu no alerlog informa\u00e7\u00e3o referentes a adi\u00e7\u00e3o de standby logfiles. Como destaquei no primeiro artigo, eles s\u00e3o importantes e n\u00e3o custa nada averiguar algumas informa\u00e7\u00f5es antes de prosseguir. Aqui, tudo permaneceu correto, a\u00e7o o seu fique\/esteja errado ap\u00f3s o reinstate, basta remover e adicionar novos.<\/p>\n
log_archive_dest_state_XX<\/strong><\/p>\n
No artigo anterior voc\u00ea viu que que deixamos desligado o envio de redo do primary para o standby. Fizemos isso at\u00e9 que o novo standby estivesse dispon\u00edvel, como agora ele est\u00e1 n\u00f3s podemos ir na primary e religar o envio.<\/p>\n
SQL> ALTER SYSTEM SET log_archive_dest_state_2 = 'ENABLE' SCOPE = BOTH SID = '*';<\/strong>\r\n\r\nSystem altered.\r\n\r\nSQL>\r\n\r\nNo alert da standby:<\/strong>\r\n    [oracle@rac11pri01 ~]$ tail -f \/u01\/app\/oracle\/diag\/rdbms\/maa\/maa1\/trace\/alert_maa1.log\r\n    ARC2: Becoming the active heartbeat ARCH\r\n    ARC2: Becoming the active heartbeat ARCH\r\n    ARC3: Archival started\r\n    ARC0: STARTING ARCH PROCESSES COMPLETE\r\n    Completed: ALTER DATABASE   MOUNT\r\n    Sun Apr 13 11:32:40 2014\r\n    db_recovery_file_dest_size of 10240 MB is 11.88% used. This is a\r\n    user-specified limit on the amount of space that will be used by this\r\n    database for recovery-related files, and does not reflect the amount of\r\n    space available in the underlying filesystem or ASM diskgroup.\r\n    Sun Apr 13 11:40:14 2014\r\n    Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST\r\n    Sun Apr 13 11:40:16 2014\r\n    RFS[1]: Assigned to RFS process 9651\r\n    RFS[1]: Opened log for thread 1 sequence 77 dbid 722024964 branch 843466948\r\n    Archived Log entry 192 added for thread 1 sequence 77 rlc 843466948 ID 0x2b099804 dest 2:<\/strong>\r\n    Sun Apr 13 11:40:19 2014\r\n    Primary database is in MAXIMUM AVAILABILITY mode<\/strong>\r\n    Changing standby controlfile to RESYNCHRONIZATION level<\/strong>\r\n    Standby controlfile consistent with primary\r\n    RFS[2]: Assigned to RFS process 9655\r\n    RFS[2]: Selected log 5 for thread 1 sequence 6 dbid 722024964 branch 844762805\r\n    Sun Apr 13 11:40:22 2014\r\n    RFS[3]: Assigned to RFS process 9666\r\n    RFS[3]: Opened log for thread 1 sequence 2 dbid 722024964 branch 844762805\r\n    Sun Apr 13 11:40:22 2014\r\n    RFS[4]: Assigned to RFS process 9664\r\n    RFS[4]: Opened log for thread 1 sequence 1 dbid 722024964 branch 844762805\r\n    RFS[3]: New Archival REDO Branch(resetlogs_id): 844762805  Prior: 843466948\r\n    RFS[3]: Archival Activation ID: 0x2b1c0c3f Current: 0x0\r\n    RFS[3]: Effect of primary database OPEN RESETLOGS<\/strong>\r\n    RFS[3]: Incarnation entry added for Branch(resetlogs_id): 844762805 (maa1)\r\n    Sun Apr 13 11:40:23 2014\r\n    Setting recovery target incarnation to 2\r\n    ...\r\n    ...\r\n    ...\r\n    Changing standby controlfile to MAXIMUM AVAILABILITY level<\/strong>\r\n    RFS[2]: Selected log 5 for thread 1 sequence 9 dbid 722024964 branch 844762805\r\n    Archived Log entry 208 added for thread 1 sequence 8 ID 0x2b1c0c3f dest 1:<\/strong>\r\n    Sun Apr 13 12:24:26 2014\r\n    Standby controlfile consistent with primary\r\n    RFS[1]: Selected log 9 for thread 2 sequence 9 dbid 722024964 branch 844762805\r\n    Sun Apr 13 12:24:26 2014\r\n    Archived Log entry 209 added for thread 2 sequence 8 ID 0x2b1c0c3f dest 1:    \r\n<\/pre>\n
Vamos analisar com calma o alertlog acima. Se voc\u00ea notar, no mesmo momento em que executamos comando na primary, o alertlog da standby j\u00e1 detectou que o recebimento destes arquivos j\u00e1 que a base precisava de RESYNCRONIZATION.<\/p>\n
Se estiv\u00e9ssemos olhando o alertlog da primary ir\u00edamos ver as informa\u00e7\u00f5es de in\u00edcio de envio de archivelogs para a standby. Observe no alertlog acima que os archives est\u00e3o sendo recebido e que a primary se \u201ctornou primary\u201d devido a um OPEN RESETLOGS. Os redo come\u00e7am a ser enviados para o standby e os bancos ficam em MAXIMUM AVAILABILITY, observe o resultado do select na primary:<\/p>\n
SQL> SELECT database_role FROM v$database;\r\n\r\nDATABASE_ROLE\r\n----------------\r\nPRIMARY\r\n\r\nSQL>\r\n\r\nPROTECTION_MODE      PROTECTION_LEVEL\r\n-------------------- --------------------\r\nMAXIMUM AVAILABILITY MAXIMUM AVAILABILITY\r\n\r\nSQL>\r\n<\/pre>\n
Database Recover<\/strong><\/p>\n
Isso n\u00e3o quer dizer que tudo est\u00e1 correto, os archives do primary foram recebidos pelo standby mas ainda n\u00e3o foram aplicados. Al\u00e9m do mais, voc\u00ea ainda precisa religar o real-time apply para que o redo do primary seja aplicado diretamente pelo standby. Corrigimos tudo isso com o comando abaixo na 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\r\nNo alert da standby:\r\n    Sun Apr 13 12:31:35 2014\r\n    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT<\/strong>\r\n    Attempt to start background Managed Standby Recovery process (maa1)\r\n    Sun Apr 13 12:31:35 2014\r\n    MRP0 started with pid=48, OS id=11062\r\n    MRP0: Background Managed Standby Recovery process started (maa1)\r\n     started logmerger process\r\n    Sun Apr 13 12:31:41 2014\r\n    Managed Standby Recovery starting Real Time Apply<\/strong>\r\n    Parallel Media Recovery started with 2 slaves\r\n    Sun Apr 13 12:31:41 2014\r\n    Media Recovery start incarnation depth : 1, target inc# : 2, irscn : 2596059\r\n    Waiting for all non-current ORLs to be archived...\r\n    All non-current ORLs have been archived.\r\n    Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT<\/strong>\r\n    Clearing online redo logfile<\/strong> 1 +DATA\/maa\/onlinelog\/group_1.272.843488553\r\n    Clearing online log 1 of thread 1 sequence number 9\r\n    Clearing online redo logfile 1 complete\r\n    Clearing online redo logfile 2 +DATA\/maa\/onlinelog\/group_2.271.843488555\r\n    Clearing online log 2 of thread 1 sequence number 9\r\n    Clearing online redo logfile 2 complete\r\n    Clearing online redo logfile 3 +DATA\/maa\/onlinelog\/group_3.257.843489101\r\n    Clearing online log 3 of thread 2 sequence number 53\r\n    Clearing online redo logfile 3 complete\r\n    Clearing online redo logfile 4 +DATA\/maa\/onlinelog\/group_4.262.843489103\r\n    Clearing online log 4 of thread 2 sequence number 54\r\n    Sun Apr 13 12:31:46 2014\r\n    Clearing online redo logfile 4 complete\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_2_seq_54.585.844799057\r\n    Identified End-Of-Redo (failover) for thread 2 sequence 54 at SCN 0x0.279cdb<\/strong>\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_1_seq_77.557.844796415\r\n    Identified End-Of-Redo (failover) for thread 1 sequence 77 at SCN 0x0.279cdb<\/strong>\r\n    Resetting standby activation ID 722049028 (0x2b099804)\r\n    Media Recovery End-Of-Redo indicator encountered<\/strong>\r\n    Media Recovery Continuing\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_2_seq_1.573.844799061\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_1_seq_1.582.844796423\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_1_seq_2.560.844796423\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_1_seq_3.568.844796425\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_2_seq_2.564.844799061\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_2_seq_3.578.844799061\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_1_seq_4.491.844796425\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_2_seq_4.581.844799061\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_1_seq_5.580.844796425\r\n    Sun Apr 13 12:31:52 2014\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_1_seq_6.587.844799057\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_2_seq_5.598.844799061\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_2_seq_6.596.844799061\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_1_seq_7.579.844799057\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_2_seq_7.591.844799057\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_2_seq_8.595.844799067\r\n    Media Recovery Log +FRA\/maa\/archivelog\/2014_04_13\/thread_1_seq_8.593.844799065\r\n    Media Recovery Waiting for thread 1 sequence 9 (in transit)\r\n    Recovery of Online Redo Log: Thread 1 Group 5 Seq 9 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    Media Recovery Waiting for thread 2 sequence 9 (in transit)\r\n    Recovery of Online Redo Log: Thread 2 Group 9 Seq 9 Reading mem 0\r\n      Mem# 0: +DATA\/maa\/onlinelog\/group_9.256.843615389\r\n      Mem# 1: +FRA\/maa\/onlinelog\/group_9.504.843615389\r\n<\/pre>\n
No alertlog da standby temos algumas informa\u00e7\u00f5es importantes. Primeiro o banco iniciou o recover (RECOVER) para ser standby (MANAGED STANDBY DATABASE) e com real-time apply (USING CURRENT LOGFILE). No alertlog vimos que ele detectou o \u201cEnd-Of-Redo\u201d nas duas threads de redo e aplicou os archives recebidos previamente. Observe que os redologs fora reiniciados (ele \u00e9 standby e n\u00e3o necessita deles agora).<\/p>\n
CRS<\/strong><\/p>\n
Para finalizar, ajuste o CRS do novo standby, assim ele ficar\u00e1 correto ir\u00e1 iniciar tudo corretamente (inicie as outras inst\u00e2ncias do standby se desejar).<\/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: open<\/strong>\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[oracle@rac11pri01 ~]$\r\n[oracle@rac11pri01 ~]$ srvctl modify database -d maa -s MOUNT -r PHYSICAL_STANDBY<\/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: mount<\/strong>\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<\/pre>\n
Acima modificamos a antiga primary no crs e deixamos ela como standby e que somente inicie ela em modo mount.<\/p>\n
AMBIENTE FINAL<\/strong><\/p>\n
Chegamos ao final com um ambiente onde o antigo primary sofreu o failover para o standby e aqui vimos como fazer o reinstate manual do antigo primary. Al\u00e9m disso, fizemos com que o antigo primary passase a agir como o novo standby. Observe abaixo:<\/p>\n
Na primary:\r\n    SQL> SELECT protection_mode, protection_level, database_role FROM v$database;\r\n\r\n    PROTECTION_MODE      PROTECTION_LEVEL     DATABASE_ROLE\r\n    -------------------- -------------------- ----------------\r\n    MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY PRIMARY\r\n\r\n    SQL>\r\n\r\nNa standby:\r\n    SQL> SELECT protection_mode, protection_level, database_role FROM v$database;\r\n\r\n    PROTECTION_MODE      PROTECTION_LEVEL     DATABASE_ROLE\r\n    -------------------- -------------------- ----------------\r\n    MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY PHYSICAL STANDBY\r\n\r\n    SQL>\r\n<\/pre>\n
Pronto, agora voc\u00ea fez um reinstate do antigo primary e tornou ele o banco standby. Acredito que voc\u00ea percebeu como fica mais f\u00e1cil quando trabalhamos com FLASHBACK, n\u00e3o precisamos voltar nenhum backup e tudo foi mais r\u00e1pido. Claro que isso s\u00f3 pode ocorrer pois o seu antigo primary voltou sem perder dados. Caso voc\u00ea tivesse perdido completamente ele precisaria utilizar um backup para criar o standby, basicamente os mesmos passos do clone que fizemos no primeiro artigo. No pr\u00f3ximo artigo vamos ver como fazer o swicthover manual dos bancos.<\/p>\n","protected":false},"excerpt":{"rendered":"
Ap\u00f3s fazer o failover no artigo anterior voc\u00ea precisa recuperar o seu ambiente, presiamos fazer o reinstate do antigo primary. De forma resumida o resintate \u00e9 recuperar o banco para que assuma a nova fun\u00e7\u00e3o. No mundo real as falhas que podem deixar seu ambiente primary fora e for\u00e7ar o failover para o standby s\u00e3o […]<\/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,48,45],"tags":[],"class_list":["post-152","post","type-post","status-publish","format-standard","hentry","category-banco-de-dados","category-data-guard","category-database","category-failover","category-oracle","category-rac","category-reinstate","category-restore"],"yoast_head":"\nOracle e MAA - Artigo III - Reinstate Manual<\/title>\n<meta name=\"description\" content=\"Fazendo o reinstate manual ap\u00f3s failover 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-iii-reinstate\/\" \/>\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 III - Reinstate Manual\" \/>\n<meta property=\"og:description\" content=\"Fazendo o reinstate manual ap\u00f3s failover 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-iii-reinstate\/\" \/>\n<meta property=\"og:site_name\" content=\"Fernando Simon\" \/>\n<meta property=\"article:published_time\" content=\"2014-05-03T01:38:59+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2015-01-26T02:30:48+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=\"14 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-iii-reinstate\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/\"},\"author\":{\"name\":\"Simon\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\"},\"headline\":\"Oracle e MAA – Artigo III – Reinstate\",\"datePublished\":\"2014-05-03T01:38:59+00:00\",\"dateModified\":\"2015-01-26T02:30:48+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/\"},\"wordCount\":1282,\"commentCount\":2,\"articleSection\":[\"Banco de Dados\",\"Data Guard\",\"Database\",\"Failover\",\"Oracle\",\"RAC\",\"Reinstate\",\"Restore\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/\",\"url\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/\",\"name\":\"Oracle e MAA - Artigo III - Reinstate Manual\",\"isPartOf\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#website\"},\"datePublished\":\"2014-05-03T01:38:59+00:00\",\"dateModified\":\"2015-01-26T02:30:48+00:00\",\"author\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\"},\"description\":\"Fazendo o reinstate manual ap\u00f3s failover 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-iii-reinstate\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.fernandosimon.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Oracle e MAA – Artigo III – Reinstate\"}]},{\"@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 III - Reinstate Manual","description":"Fazendo o reinstate manual ap\u00f3s failover 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-iii-reinstate\/","og_locale":"en_US","og_type":"article","og_title":"Oracle e MAA - Artigo III - Reinstate Manual","og_description":"Fazendo o reinstate manual ap\u00f3s failover 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-iii-reinstate\/","og_site_name":"Fernando Simon","article_published_time":"2014-05-03T01:38:59+00:00","article_modified_time":"2015-01-26T02:30:48+00:00","author":"Simon","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Simon","Est. reading time":"14 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/#article","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/"},"author":{"name":"Simon","@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"headline":"Oracle e MAA – Artigo III – Reinstate","datePublished":"2014-05-03T01:38:59+00:00","dateModified":"2015-01-26T02:30:48+00:00","mainEntityOfPage":{"@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/"},"wordCount":1282,"commentCount":2,"articleSection":["Banco de Dados","Data Guard","Database","Failover","Oracle","RAC","Reinstate","Restore"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/","url":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/","name":"Oracle e MAA - Artigo III - Reinstate Manual","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#website"},"datePublished":"2014-05-03T01:38:59+00:00","dateModified":"2015-01-26T02:30:48+00:00","author":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"description":"Fazendo o reinstate manual ap\u00f3s failover 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-iii-reinstate\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.fernandosimon.com\/blog\/oracle-e-maa-artigo-iii-reinstate\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.fernandosimon.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Oracle e MAA – Artigo III – Reinstate"}]},{"@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-2s","_links":{"self":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/152","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=152"}],"version-history":[{"count":0,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/152\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/media?parent=152"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/categories?post=152"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/tags?post=152"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}