Oracle e MAA – Artigo III – Reinstate

2 Replies

Após fazer o failover no artigo anterior você precisa recuperar o seu ambiente, presiamos fazer o reinstate do antigo primary. De forma resumida o resintate é recuperar o banco para que assuma a nova função.

No mundo real as falhas que podem deixar seu ambiente primary fora e forçar o failover para o standby são diversas. Muitas vezes perde-se o ambiente por completo e precisamos recriar o primary, quando acontece isso a solução é 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ê perdeu completamente o antigo primary não há o que fazer, você precisará recriar ele através de um backup do novo primary.

TERCEIRO ARTIGO

Neste artigo irei demonstrar como fazer o reinstate manual do antigo primary. Além disso, também demonstrarei como adicionar este banco como standby ao ambiente para que possamos a ter um ambiente MAA. Como este artigo é uma sequência dos anteriores eu recomendo a leitura dos anteriores para ficar familiarizado, não é obrigatório mas pode ajudar.

AMBIENTE

Neste artigo temos um banco primary rodando em Oracle RAC que sofreu uma falha e sofreu failover para seu standby que também roda em Oracle RAC. Com isso o antigo standby foi elevado a função de primary, e esta troca de papeis ocorreu sem qualquer perda de dados.

Aqui, o antigo primary foi recuperado e está novamente operacional. Como estamos em um ambiente Oracle RAC automaticamente ao servidor ligar o CRS irá iniciar o banco, recomendo que todas as suas instâncias paradas.

Lembra-se que até o momento não temos o Broker habilitado no ambiente. Tudo o que fizemos até agora foi manual, configuração, failover e agora o reinstate.

REINSTATE

O reinstate é um procedimento simples, mas para isso você tem que ter seguido alguns passos. No primeiro artigo fui categórico ao afirmar que habilitar o flashback do banco de dados traria benefícios, e é aqui que veremos isso. Se você tiver o flashback habilitado com um simples comando você deixa tudo pronto, caso contrário se prepare e tenha backup do banco de dados – você precisaria.

SCN

A primeira coisa a fazer é identificar qual foi SCN em que o standby se tornou primary, o comando abaixo mostra como fazer isso:

SQL> SELECT instance_name FROM v$instance;

INSTANCE_NAME
----------------
maastb1

SQL> SELECT standby_became_primary_scn FROM v$database;

STANDBY_BECAME_PRIMARY_SCN
--------------------------
                   2596056

SQL>

Se você notar e comparar com o artigo anterior verá que o SCN foi o mesmo que apareceu no alertlog do standby quando ele se tornou primary. Este SCN é fundamental para fazer o resintate do antigo primary, com ele fazemos o flashback do banco. Volto ao ponto da importância do flashback, com um único comando você volta o banco sem precisar de qualquer restore de backup.

Antigo Primary

Depois de verificar o scn nós precisamos iniciar um instância do antigo primary. Não se preocupe se quando você ligou o servidor o seu antigo primary entrou em modo open. Desta forma, iniciamos uma única instância em modo mount:

SQL> STARTUP MOUNT;
ORACLE instance started.

Total System Global Area 1068937216 bytes
Fixed Size                  2235208 bytes
Variable Size             511706296 bytes
Database Buffers          549453824 bytes
Redo Buffers                5541888 bytes
Database mounted.
SQL> SELECT instance_name FROM v$instance;

INSTANCE_NAME
----------------
maa1

SQL>

Um detalhe interessante, se você fizer um select para saber a role do banco ele ainda acredita que é um banco primary. Observe:

SQL> SELECT database_role FROM v$database;

DATABASE_ROLE
----------------
PRIMARY

SQL>

Flashback

Até o momento nós temos o scn que o houve a troca de papeis, um banco standby que se tornou primary. Além disso, temos o antigo primary que foi aberto em modo mount em uma única instância, confuso?

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:

SQL> FLASHBACK DATABASE TO SCN 2596056;

Flashback complete.

SQL>

Convert to Standby

Como você viu acima este banco ainda acredita que é o banco primary, nós precisamos alterar isso. O procedimento é simples e deixa o banco pronto para se tornar o standby, observe:

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Database altered.

SQL>

No alert da antiga primary:
    Flashback Media Recovery Complete
    Completed: FLASHBACK DATABASE TO SCN 2596056
    Sun Apr 13 11:12:38 2014
    ALTER DATABASE CONVERT TO PHYSICAL STANDBY
    ALTER DATABASE CONVERT TO PHYSICAL STANDBY (maa1)
    Flush standby redo logfile failed:1649
    Clearing standby activation ID 722049028 (0x2b099804)
    The primary database controlfile was created using the
    'MAXLOGFILES 192' clause.
    There is space for up to 188 standby redo logfiles
    Use the following SQL commands on the standby database to create
    standby redo logfiles that match the primary database:
    ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl5.f' SIZE 52428800;
    Shutting down archive processes
    Archiving is disabled
    Completed: ALTER DATABASE CONVERT TO PHYSICAL STANDBY
    Sun Apr 13 11:12:44 2014
    SUCCESS: diskgroup FRA was dismounted
    SUCCESS: diskgroup DATA was dismounted
    NOTE: Database dismounted; ASMB process exiting
    Stopping background process RBAL
    Stopping background process MARK
    Sun Apr 13 11:12:46 2014
    NOTE: Shutting down MARK background process

Deixei em negrito no alertlog acima, mas se você notar no irá ver que o banco agora passou a ser o standby. Depois, você eu recomendo fazer um shutdown e um startup mount do novo standby:

SQL> SHUTDOWN IMMEDIATE;
ORA-01507: database not mounted


ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area 1068937216 bytes
Fixed Size                  2235208 bytes
Variable Size             511706296 bytes
Database Buffers          549453824 bytes
Redo Buffers                5541888 bytes
Database mounted.
SQL>

Observe no resultado do comando acima que a informação de que o banco não estava montado (mas iniciamos o processo com o banco em estado mount!?). Não se preocupe, o processo de conversão para standby fez isso.

Standby redo log files

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:

SQL> COL member FORMAT a50
SQL> SELECT group#, type, member FROM v$logfile;

    GROUP# TYPE    MEMBER
---------- ------- --------------------------------------------------
         1 ONLINE  +DATA/maa/onlinelog/group_1.272.843488553
         1 ONLINE  +FRA/maa/onlinelog/group_1.286.843488555
         2 ONLINE  +DATA/maa/onlinelog/group_2.271.843488555
         2 ONLINE  +FRA/maa/onlinelog/group_2.285.843488555
         3 ONLINE  +DATA/maa/onlinelog/group_3.257.843489101
         3 ONLINE  +FRA/maa/onlinelog/group_3.284.843489101
         4 ONLINE  +DATA/maa/onlinelog/group_4.262.843489103
         4 ONLINE  +FRA/maa/onlinelog/group_4.283.843489103
         5 STANDBY +DATA/maa/onlinelog/group_5.263.843615365
         5 STANDBY +FRA/maa/onlinelog/group_5.289.843615367
         6 STANDBY +DATA/maa/onlinelog/group_6.261.843615373

    GROUP# TYPE    MEMBER
---------- ------- --------------------------------------------------
         6 STANDBY +FRA/maa/onlinelog/group_6.670.843615373
         7 STANDBY +DATA/maa/onlinelog/group_7.260.843615379
         7 STANDBY +FRA/maa/onlinelog/group_7.263.843615379
         8 STANDBY +DATA/maa/onlinelog/group_8.259.843615383
         8 STANDBY +FRA/maa/onlinelog/group_8.703.843615385
         9 STANDBY +DATA/maa/onlinelog/group_9.256.843615389
         9 STANDBY +FRA/maa/onlinelog/group_9.504.843615389
        10 STANDBY +DATA/maa/onlinelog/group_10.274.843615393
        10 STANDBY +FRA/maa/onlinelog/group_10.496.843615393

20 rows selected.

SQL>

Você deve estar se perguntando o porquê disso, mas explico. Quando fizemos o convert acima para physical standby apareceu no alerlog informação referentes a adição de standby logfiles. Como destaquei no primeiro artigo, eles são importantes e não custa nada averiguar algumas informações antes de prosseguir. Aqui, tudo permaneceu correto, aço o seu fique/esteja errado após o reinstate, basta remover e adicionar novos.

log_archive_dest_state_XX

No artigo anterior você viu que que deixamos desligado o envio de redo do primary para o standby. Fizemos isso até que o novo standby estivesse disponível, como agora ele está nós podemos ir na primary e religar o envio.

SQL> ALTER SYSTEM SET log_archive_dest_state_2 = 'ENABLE' SCOPE = BOTH SID = '*';

System altered.

SQL>

No alert da standby:
    [oracle@rac11pri01 ~]$ tail -f /u01/app/oracle/diag/rdbms/maa/maa1/trace/alert_maa1.log
    ARC2: Becoming the active heartbeat ARCH
    ARC2: Becoming the active heartbeat ARCH
    ARC3: Archival started
    ARC0: STARTING ARCH PROCESSES COMPLETE
    Completed: ALTER DATABASE   MOUNT
    Sun Apr 13 11:32:40 2014
    db_recovery_file_dest_size of 10240 MB is 11.88% used. This is a
    user-specified limit on the amount of space that will be used by this
    database for recovery-related files, and does not reflect the amount of
    space available in the underlying filesystem or ASM diskgroup.
    Sun Apr 13 11:40:14 2014
    Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
    Sun Apr 13 11:40:16 2014
    RFS[1]: Assigned to RFS process 9651
    RFS[1]: Opened log for thread 1 sequence 77 dbid 722024964 branch 843466948
    Archived Log entry 192 added for thread 1 sequence 77 rlc 843466948 ID 0x2b099804 dest 2:
    Sun Apr 13 11:40:19 2014
    Primary database is in MAXIMUM AVAILABILITY mode
    Changing standby controlfile to RESYNCHRONIZATION level
    Standby controlfile consistent with primary
    RFS[2]: Assigned to RFS process 9655
    RFS[2]: Selected log 5 for thread 1 sequence 6 dbid 722024964 branch 844762805
    Sun Apr 13 11:40:22 2014
    RFS[3]: Assigned to RFS process 9666
    RFS[3]: Opened log for thread 1 sequence 2 dbid 722024964 branch 844762805
    Sun Apr 13 11:40:22 2014
    RFS[4]: Assigned to RFS process 9664
    RFS[4]: Opened log for thread 1 sequence 1 dbid 722024964 branch 844762805
    RFS[3]: New Archival REDO Branch(resetlogs_id): 844762805  Prior: 843466948
    RFS[3]: Archival Activation ID: 0x2b1c0c3f Current: 0x0
    RFS[3]: Effect of primary database OPEN RESETLOGS
    RFS[3]: Incarnation entry added for Branch(resetlogs_id): 844762805 (maa1)
    Sun Apr 13 11:40:23 2014
    Setting recovery target incarnation to 2
    ...
    ...
    ...
    Changing standby controlfile to MAXIMUM AVAILABILITY level
    RFS[2]: Selected log 5 for thread 1 sequence 9 dbid 722024964 branch 844762805
    Archived Log entry 208 added for thread 1 sequence 8 ID 0x2b1c0c3f dest 1:
    Sun Apr 13 12:24:26 2014
    Standby controlfile consistent with primary
    RFS[1]: Selected log 9 for thread 2 sequence 9 dbid 722024964 branch 844762805
    Sun Apr 13 12:24:26 2014
    Archived Log entry 209 added for thread 2 sequence 8 ID 0x2b1c0c3f dest 1:

Vamos analisar com calma o alertlog acima. Se você notar, no mesmo momento em que executamos comando na primary, o alertlog da standby já detectou que o recebimento destes arquivos já que a base precisava de RESYNCRONIZATION.

Se estivéssemos olhando o alertlog da primary iríamos ver as informações de início de envio de archivelogs para a standby. Observe no alertlog acima que os archives estão sendo recebido e que a primary se “tornou primary” devido a um OPEN RESETLOGS. Os redo começam a ser enviados para o standby e os bancos ficam em MAXIMUM AVAILABILITY, observe o resultado do select na primary:

SQL> SELECT database_role FROM v$database;

DATABASE_ROLE
----------------
PRIMARY

SQL>

PROTECTION_MODE      PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY

SQL>

Database Recover

Isso não quer dizer que tudo está correto, os archives do primary foram recebidos pelo standby mas ainda não foram aplicados. Além do mais, você 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:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

Database altered.

SQL>

No alert da standby:
    Sun Apr 13 12:31:35 2014
    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
    Attempt to start background Managed Standby Recovery process (maa1)
    Sun Apr 13 12:31:35 2014
    MRP0 started with pid=48, OS id=11062
    MRP0: Background Managed Standby Recovery process started (maa1)
     started logmerger process
    Sun Apr 13 12:31:41 2014
    Managed Standby Recovery starting Real Time Apply
    Parallel Media Recovery started with 2 slaves
    Sun Apr 13 12:31:41 2014
    Media Recovery start incarnation depth : 1, target inc# : 2, irscn : 2596059
    Waiting for all non-current ORLs to be archived...
    All non-current ORLs have been archived.
    Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
    Clearing online redo logfile 1 +DATA/maa/onlinelog/group_1.272.843488553
    Clearing online log 1 of thread 1 sequence number 9
    Clearing online redo logfile 1 complete
    Clearing online redo logfile 2 +DATA/maa/onlinelog/group_2.271.843488555
    Clearing online log 2 of thread 1 sequence number 9
    Clearing online redo logfile 2 complete
    Clearing online redo logfile 3 +DATA/maa/onlinelog/group_3.257.843489101
    Clearing online log 3 of thread 2 sequence number 53
    Clearing online redo logfile 3 complete
    Clearing online redo logfile 4 +DATA/maa/onlinelog/group_4.262.843489103
    Clearing online log 4 of thread 2 sequence number 54
    Sun Apr 13 12:31:46 2014
    Clearing online redo logfile 4 complete
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_54.585.844799057
    Identified End-Of-Redo (failover) for thread 2 sequence 54 at SCN 0x0.279cdb
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_77.557.844796415
    Identified End-Of-Redo (failover) for thread 1 sequence 77 at SCN 0x0.279cdb
    Resetting standby activation ID 722049028 (0x2b099804)
    Media Recovery End-Of-Redo indicator encountered
    Media Recovery Continuing
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_1.573.844799061
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_1.582.844796423
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_2.560.844796423
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_3.568.844796425
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_2.564.844799061
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_3.578.844799061
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_4.491.844796425
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_4.581.844799061
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_5.580.844796425
    Sun Apr 13 12:31:52 2014
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_6.587.844799057
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_5.598.844799061
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_6.596.844799061
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_7.579.844799057
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_7.591.844799057
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_2_seq_8.595.844799067
    Media Recovery Log +FRA/maa/archivelog/2014_04_13/thread_1_seq_8.593.844799065
    Media Recovery Waiting for thread 1 sequence 9 (in transit)
    Recovery of Online Redo Log: Thread 1 Group 5 Seq 9 Reading mem 0
      Mem# 0: +DATA/maa/onlinelog/group_5.263.843615365
      Mem# 1: +FRA/maa/onlinelog/group_5.289.843615367
    Media Recovery Waiting for thread 2 sequence 9 (in transit)
    Recovery of Online Redo Log: Thread 2 Group 9 Seq 9 Reading mem 0
      Mem# 0: +DATA/maa/onlinelog/group_9.256.843615389
      Mem# 1: +FRA/maa/onlinelog/group_9.504.843615389

No alertlog da standby temos algumas informações 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 “End-Of-Redo” nas duas threads de redo e aplicou os archives recebidos previamente. Observe que os redologs fora reiniciados (ele é standby e não necessita deles agora).

CRS

Para finalizar, ajuste o CRS do novo standby, assim ele ficará correto irá iniciar tudo corretamente (inicie as outras instâncias do standby se desejar).

[oracle@rac11pri01 ~]$ srvctl config database -d maa -v
Database unique name: maa
Database name: maa
Oracle home: /u01/app/oracle/product/11.2.0.3/db_1
Oracle user: oracle
Spfile: +DATA/maa/spfilemaa.ora
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: maa
Database instances: maa1,maa2
Disk Groups: DATA,FRA
Mount point paths:
Services:
Type: RAC
Database is administrator managed
[oracle@rac11pri01 ~]$
[oracle@rac11pri01 ~]$
[oracle@rac11pri01 ~]$ srvctl modify database -d maa -s MOUNT -r PHYSICAL_STANDBY
[oracle@rac11pri01 ~]$
[oracle@rac11pri01 ~]$
[oracle@rac11pri01 ~]$ srvctl config database -d maa -v
Database unique name: maa
Database name: maa
Oracle home: /u01/app/oracle/product/11.2.0.3/db_1
Oracle user: oracle
Spfile: +DATA/maa/spfilemaa.ora
Domain:
Start options: mount
Stop options: immediate
Database role: PHYSICAL_STANDBY
Management policy: AUTOMATIC
Server pools: maa
Database instances: maa1,maa2
Disk Groups: DATA,FRA
Mount point paths:
Services:
Type: RAC
Database is administrator managed
[oracle@rac11pri01 ~]$

Acima modificamos a antiga primary no crs e deixamos ela como standby e que somente inicie ela em modo mount.

AMBIENTE FINAL

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ém disso, fizemos com que o antigo primary passase a agir como o novo standby. Observe abaixo:

Na primary:
    SQL> SELECT protection_mode, protection_level, database_role FROM v$database;

    PROTECTION_MODE      PROTECTION_LEVEL     DATABASE_ROLE
    -------------------- -------------------- ----------------
    MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY PRIMARY

    SQL>

Na standby:
    SQL> SELECT protection_mode, protection_level, database_role FROM v$database;

    PROTECTION_MODE      PROTECTION_LEVEL     DATABASE_ROLE
    -------------------- -------------------- ----------------
    MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY PHYSICAL STANDBY

    SQL>

Pronto, agora você fez um reinstate do antigo primary e tornou ele o banco standby. Acredito que você percebeu como fica mais fácil quando trabalhamos com FLASHBACK, não precisamos voltar nenhum backup e tudo foi mais rápido. Claro que isso só pode ocorrer pois o seu antigo primary voltou sem perder dados. Caso você 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óximo artigo vamos ver como fazer o swicthover manual dos bancos.

2 thoughts on “Oracle e MAA – Artigo III – Reinstate”

  1. Pingback: Oracle e MAA - Artigo V - Switchover Broker | Have you hugged your backup today?

  2. Pingback: Oracle e MAA - Artigo IV - Switchover Manual

Leave a Reply

Your email address will not be published. Required fields are marked *