Pular para o conteúdo

ORACLE E MAA (Maximum Availability Architecture) – Parte III – Reinstate

ORACLE e MAA – Parte III – Reinstate

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.

Este artigo também foi publicado em meu blog pessoal.

Quão útil foi este post ?

Clique em uma estrela para classificar o post

nota média 4.8 / 5. Contagem de votos: 28

Sem votos ! Seja o primeiro a classificar !

Marcações:

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

plugins premium WordPress