No artigo anterior demonstrei como configurar um DG para que você possa ter MAA no seu ambiente. Foram apresentados os passos para criar um DG entre um banco primary ORACLE RAC e standby também em ORACLE RAC. Até o momento o ambiente não está 100%, ainda não configuramos o DG para utilizar o broker e nem fast-start failover, tudo será manual.

A função básica do DG é proteger quanto a possíveis falhas inesperadas em nosso banco primary. Existem vários tipos de falhas que podem deixar indisponível um banco de dados: hardware, software, estagiário, DBA Senior; inúmeras.

Quando trabalhamos com o Oracle em RAC as falhas que podem deixar o seu ambiente indisponível por completo reduzem, no caso de uma falha de um único nó o outro assume a carga e o banco continua disponível ao usuário. Mas ele não protege para falhas mais complexas. Se o seu storage falhar? Ou se a sua rede apresentar problema e o seu RAC cair?

É nesses cenários que o DG pode ajudar, ele irá proteger seu banco Oracle contra possíveis falhas do seu ambiente primary. Com MAA você teria tudo replicado no outro ambiente e em um ambiente RAC você estará protegido contra falhas de ambos os nós.

SEGUNDO ARTIGO

Neste artigo vamos dar sequência ao anterior e simular um failover no ambiente. Neste artigo você verá os passos e o que fazer para realizar o failover do primary para o seu standby, tudo isso de forma manual.

AMBIENTE

Para recordar, temos um ambiente DG configurado com RAC conforme passos que vimos neste artigo. O DG está operando em MAXIMUM AVAILABILITY e com real-time-apply. Ainda não temos broker configurado e todos os passos necessitam de intervenção manual para a troca de papeis, incluindo a restauração do ambiente.

Para exemplificar a garantias que um DG nos dá, vamos criar uma tabela de controle para verificar se os dados estão salvos. Observe o momento que a tabela foi criada e que recebeu inserts de ambas as instâncias do RAC:

Instância MAA1
    SQL> SELECT instance_name FROM v$instance;

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

    SQL> CREATE TABLE testedg(c1 DECIMAL(3,0), c2 DATE);

    Table created.

    SQL> INSERT INTO testedg VALUES(1, SYSDATE);

    1 row created.

    SQL> commit;

    Commit complete.

    SQL>
    
Instância MAA2
    SQL> SELECT instance_name FROM v$instance;

    INSTANCE_NAME
    ----------------
    maa2

    SQL> INSERT INTO testedg VALUES(2, SYSDATE);

    1 row created.

    SQL> COMMIT;

    Commit complete.

    SQL> SELECT c1, TO_CHAR(c2, 'DD/MM HH24:MI:SS') as momento FROM testedg;

            C1 MOMENTO
    ---------- --------------
             1 13/04 07:00:04
             2 13/04 07:01:11

    SQL> 

FAILOVER

Aqui simularemos uma falha não planejada do primary, o banco de dados ficará indisponível e será chaveado para o banco standby com failover. Mas o que é failover? De forma bem resumida, o failover ocorre quando existe indisponibilidade completa do primary. Isso impede o banco primary de “ser avisado” da troca de papeis.

Antes de pensarmos em fazer o failover ou switchover precisamos saber se ele é necessário ou se podemos fazer sem perder dados. O primeiro ponto a ser avaliado em qualquer ambiente DG é se tanto primary e standby estão sincronizados, se eles não estiverem você provavelmente perderá dados.

Vamos partir do princípio que se você está configurando um ambiente DG é devido a importância do seu banco de dados. Se você está montando um ambiente MAA com DG+RAC a criticidade da informação que você gerencia é muito maior, você quer garantias. Além disso, a disponibilidade necessária para o ambiente está intimamente ligada a importância dos seus dados. Então, você monta um ambiente DG com RAC e não deixa primary e standby sincronizados? Você monta e prepara um standby que não suporta a carga do seu primary em caso de falha?

Primeiro, se o seu ambiente está sincronizado, faça o failover. Caso o seu ambiente não esteja sincronizado nem continue, você VAI perder dados. Se o seu ambiente não está ok, revise ele e o deixe tudo sincronizado, você vai ter noites mais tranquilas e as surpresas serão menores.

Criando a falha

Para iniciar vamos simular uma falha do ambiente, uma falha catastrófica como a perda do storage que derrubou ambas as instâncias do primary. Aqui, o que está nos redo não foi para os archives (como os dados da nossa tabela de teste por exemplo). Como exemplo, um simples abort já dá conta (lembre do RAC – ambos os nós tem que morrer):

[oracle@rac11pri01 ~]$ srvctl stop database -d maa -o abort
[oracle@rac11pri01 ~]$ 

O standby percebeu a falha no standby de forma imediata. Observe no alertlog da standby que está abaixo os horários de recebimento do último archivelog e do momento da falha do primary (faça uma relação com o que está na nossa tabela de controle que criamos previamente):

Sun Apr 13 05:57:45 2014
Media Recovery Waiting for thread 1 sequence 77 (in transit)
Recovery of Online Redo Log: Thread 1 Group 5 Seq 77 Reading mem 0
  Mem# 0: +DG01/maastb/onlinelog/group_5.271.844716073
  Mem# 1: +FRA/maastb/onlinelog/group_5.553.844716075
Sun Apr 13 07:20:08 2014
RFS[4]: Possible network disconnect with primary database
Sun Apr 13 07:20:08 2014
RFS[2]: Possible network disconnect with primary database
Sun Apr 13 07:20:08 2014
RFS[6]: Possible network disconnect with primary database
Sun Apr 13 07:20:08 2014
RFS[10]: Assigned to RFS process 2470
RFS[10]: Possible network disconnect with primary database
Sun Apr 13 07:20:08 2014
RFS[5]: Possible network disconnect with primary database
Sun Apr 13 07:20:08 2014
RFS[9]: Possible network disconnect with primary database
Sun Apr 13 07:20:09 2014
RFS[7]: Possible network disconnect with primary database
Sun Apr 13 07:20:09 2014
RFS[8]: Possible network disconnect with primary database

Com o alertlog observamos que o último archive foi recebido as 05:57:45 e a falha do primary foi detectada pelo standby as 07:20:09. Também identificamos que o standby detectou a falha mas não fez nada ainda. Não estamos com o broker para ele chavear automaticamente, e caso você consiga reativar seu ambiente primary tudo volta ao normal.

Verificando o Standby

Então, no meio da tarde você percebe que o seu RAC primary parou e o standby está esperando você se decidir o que fazer. A primeira coisa que você faz é ver seu standby pode chavear e se tornar primary. Conecte no standby e verifique o modo em que ele está operando:

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

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

SQL> SELECT instance_name FROM gv$instance;

INSTANCE_NAME
----------------
maastb1
maastb2

SQL>

Com isso, você sabe que tem duas instâncias e um banco sincronizado com o primary e que está atuando como PHYSICAL STANDBY. Isso é bom e nos permite continuar com o failover. Se o seu protection_level não está igual ao protection_mode, você tem problemas e não está com primary e standby sincronizados.

Trocando os papeis

Como o primary morreu, o próximo passo que precisamos é parar a sincronização do standby. Como estamos em um failover alguns comandos devem “forçar” paradas ou configurações, precisamos forçar a parada na sincronia entre o primary e standby. Basicamente você conecta no standby e desliga a sincronia:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Database altered.

SQL>

No alert da instancia:
    Sun Apr 13 08:02:42 2014
    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
    Sun Apr 13 08:02:42 2014
    MRP0: Background Media Recovery cancelled with status 16037
    Errors in file /u01/app/oracle/diag/rdbms/maastb/maastb1/trace/maastb1_pr00_2398.trc:
    ORA-16037: user requested cancel of managed recovery operation
    Sun Apr 13 08:02:42 2014
    Managed Standby Recovery not using Real Time Apply
    Recovery interrupted!
    Recovered data files to a consistent state at change 2596057
    Sun Apr 13 08:02:42 2014
    MRP0: Background Media Recovery process shutdown (maastb1)
    Managed Standby Recovery Canceled (maastb1)
    Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL

Observe no alertlog que está acima o aviso de parada da sincronização, inclusive do real-time-apply. O próximo passo é marcar o fim da aplicação de qualquer redo, este comando “marca” e aplica no banco do standby todo e qualquer redo pendente recebido do primary:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

Database altered.

SQL>

No alertlog:
Observe o "enf-of-redo" marcado por failover.    
    Sun Apr 13 08:07:40 2014
    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
    Attempt to do a Terminal Recovery (maastb1)
    Media Recovery Start: Managed Standby Recovery (maastb1)
     started logmerger process
    Sun Apr 13 08:07:40 2014
    Managed Standby Recovery not using Real Time Apply
    Parallel Media Recovery started with 2 slaves
    Sun Apr 13 08:07:42 2014
    Begin: Standby Redo Logfile archival
    End: Standby Redo Logfile archival
    Terminal Recovery timestamp is '04/13/2014 08:07:42'
    Terminal Recovery: applying standby redo logs.
    Terminal Recovery: thread 1 seq# 77 redo required
    Terminal Recovery:
    Recovery of Online Redo Log: Thread 1 Group 5 Seq 77 Reading mem 0
      Mem# 0: +DG01/maastb/onlinelog/group_5.271.844716073
      Mem# 1: +FRA/maastb/onlinelog/group_5.553.844716075
    Identified End-Of-Redo (failover) for thread 1 sequence 77 at SCN 0xffff.ffffffff
    Terminal Recovery: thread 2 seq# 54 redo required
    Terminal Recovery:
    Recovery of Online Redo Log: Thread 2 Group 8 Seq 54 Reading mem 0
      Mem# 0: +DG01/maastb/onlinelog/group_8.261.844716089
      Mem# 1: +FRA/maastb/onlinelog/group_8.611.844716093
    Identified End-Of-Redo (failover) for thread 2 sequence 54 at SCN 0xffff.ffffffff
    Incomplete Recovery applied until change 2596059 time 04/13/2014 13:23:14
    Media Recovery Complete (maastb1)
    Terminal Recovery: successful completion
    Sun Apr 13 08:07:44 2014
    ARC0: Archiving not possible: error count exceeded
    Sun Apr 13 08:07:44 2014
    ARC1: Archiving not possible: error count exceeded
    ARCH: Archival stopped, error occurred. Will continue retrying
    ORACLE Instance maastb1 - Archival Error
    ORA-16014: log 5 sequence# 77 not archived, no available destinations
    ORA-00312: online log 5 thread 1: '+DG01/maastb/onlinelog/group_5.271.844716073'
    ORA-00312: online log 5 thread 1: '+FRA/maastb/onlinelog/group_5.553.844716075'
    Forcing ARSCN to IRSCN for TR 0:2596059
    Attempt to set limbo arscn 0:2596059 irscn 0:2596059
    Resetting standby activation ID 722049028 (0x2b099804)
    Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH

Se você observar com detalhe o que ocorreu no alertlog acima irá notar que foi marcado um “End-Of-Redo” devido a failover nas duas threads recebidas do primary. O End-Of-Redo” marca o momento (SCN) que ocorreu a interrupção na aplicação dos redo’s recebidos da primary, tudo o que ocorrer após este SCN não terá vindo da primary. Ignore os erros de arquivamento listados no alertlog (ele não está conseguindo enviar archives e explicarei porque mais abaixo).

O próximo passo é efetivamente a troca de papeis, o standby passará a ser o primary. Primeiro você pode garantir/verificar se o standby está pronto para o ser primary:

SQL> SELECT switchover_status FROM v$database;

SWITCHOVER_STATUS
--------------------
TO PRIMARY

SQL>

Caso o comando acima retorne que existem sessões você pode forçar o kill destas. Recomenda-se que somente de prosseguimento caso apareça TO PRIMARY. Não de sequência caso o comando acima retorne outro valor.

Para trocar os papeis e fazer o standby assumir como primary execute:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

Database altered.

SQL>

No alert:
    ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
    ALTER DATABASE SWITCHOVER TO PRIMARY (maastb1)
    Maximum wait for role transition is 15 minutes.
    Backup controlfile written to trace file /u01/app/oracle/diag/rdbms/maastb/maastb1/trace/maastb1_ora_31327.trc
    Standby terminal recovery start SCN: 2596057
    RESETLOGS after incomplete recovery UNTIL CHANGE 2596059
    Online log +DG01/maastb/onlinelog/group_1.257.844716051: Thread 1 Group 1 was previously cleared
    Online log +FRA/maastb/onlinelog/group_1.568.844716053: Thread 1 Group 1 was previously cleared
    Online log +DG01/maastb/onlinelog/group_2.268.844716057: Thread 1 Group 2 was previously cleared
    Online log +FRA/maastb/onlinelog/group_2.564.844716059: Thread 1 Group 2 was previously cleared
    Online log +DG01/maastb/onlinelog/group_3.269.844716063: Thread 2 Group 3 was previously cleared
    Online log +FRA/maastb/onlinelog/group_3.562.844716065: Thread 2 Group 3 was previously cleared
    Online log +DG01/maastb/onlinelog/group_4.270.844716067: Thread 2 Group 4 was previously cleared
    Online log +FRA/maastb/onlinelog/group_4.559.844716071: Thread 2 Group 4 was previously cleared
    Standby became primary SCN: 2596056
    Sun Apr 13 08:20:09 2014
    Setting recovery target incarnation to 2
    Switchover: Complete - Database mounted as primary
    Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN

O que tudo isso nos diz (comando e alertlog)? No comando você informou para ele passar a ser o banco primary (SWITCHOVER TO PRIMARY) e qualquer sessão existente será desconectada (SESSION SHUTDOWN). No alertlog temos a informação do SCN aplicado e que os redog do standby foram reiniciados, e para os esotéricos temos uma nova encarnação. Por fim, seu banco foi montado como primary.

Tudo muito bem até agora e pronto para abrir o banco:

SQL> ALTER DATABASE OPEN;

Database altered.

SQL>

No alert:
Observe os erros de TNS para os archives que apontam para a antiga primary
    Sun Apr 13 08:25:05 2014
    ALTER DATABASE OPEN
    This instance was first to open
    Picked broadcast on commit scheme to generate SCNs
    Sun Apr 13 08:25:06 2014
    Assigning activation ID 723258431 (0x2b1c0c3f)
    Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
    Destination LOG_ARCHIVE_DEST_2 no longer supports SYNCHRONIZATION
    Thread 1 advanced to log sequence 2 (thread open)
    Thread 1 opened at log sequence 2
      Current log# 2 seq# 2 mem# 0: +DG01/maastb/onlinelog/group_2.268.844716057
      Current log# 2 seq# 2 mem# 1: +FRA/maastb/onlinelog/group_2.564.844716059
    Successful open of redo thread 1
    MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
    Sun Apr 13 08:25:07 2014
    SMON: enabling cache recovery
    Sun Apr 13 08:25:07 2014
    Archived Log entry 46 added for thread 1 sequence 1 ID 0x2b1c0c3f dest 1:
    Sun Apr 13 08:25:07 2014
    ...
    ...
    ...
    ***********************************************************************

    Fatal NI connect error 12514, connecting to:
     (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rac11pri-scan.tjsc.jus.br)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=maa)(CID=(PROGRAM=oracle)(HOST=rac11stb01.tjsc.jus.br)(USER=oracle))))

      VERSION INFORMATION:
            TNS for Linux: Version 11.2.0.3.0 - Production
            TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.3.0 - Production
      Time: 13-APR-2014 08:25:07
      Tracing not turned on.
      Tns error struct:
        ns main err code: 12564

    TNS-12564: TNS:connection refused
        ns secondary err code: 0
        nt main err code: 0
        nt secondary err code: 0
        nt OS err code: 0
    Error 12514 received logging on to the standby
    PING[ARC2]: Heartbeat failed to connect to standby 'maa'. Error is 12514.
    [31327] Successfully onlined Undo Tablespace 2.
    Undo initialization finished serial:0 start:1288905924 end:1288907124 diff:1200 (12 seconds)
    Dictionary check beginning
    Sun Apr 13 08:25:10 2014
    Errors in file /u01/app/oracle/diag/rdbms/maastb/maastb1/trace/maastb1_dbw0_2288.trc:
    ORA-01186: file 201 failed verification tests
    ORA-01157: cannot identify/lock data file 201 - see DBWR trace file
    ORA-01110: data file 201: '+DG01'
    File 201 not verified due to error ORA-01157
    Dictionary check complete
    Verifying file header compatibility for 11g tablespace encryption..
    Sun Apr 13 08:25:10 2014
    minact-scn: Inst 1 is now the master inc#:4 mmon proc-id:2303 status:0x7
    Verifying 11g file header compatibility for tablespace encryption completedminact-scn status: grec-scn:0x0000.00000000 gmin-scn:0x0000.00000000 gcalc-scn:0x0000.00000000

    minact-scn: Master returning as live inst:2 has inc# mismatch instinc:0 cur:4 errcnt:0SMON: enabling tx recovery

    Re-creating tempfile +DG01 as +DG01/maastb/tempfile/temp.276.844784711
    Database Characterset is WE8MSWIN1252
    No Resource Manager plan active
    Starting background process GTX0
    Sun Apr 13 08:25:14 2014
    GTX0 started with pid=39, OS id=32334
    Starting background process RCBG
    Sun Apr 13 08:25:14 2014
    RCBG started with pid=40, OS id=32336
    replication_dependency_tracking turned off (no async multimaster replication found)
    Starting background process QMNC
    Sun Apr 13 08:25:15 2014
    QMNC started with pid=41, OS id=32338
    LOGSTDBY: Validating controlfile with logical metadata
    LOGSTDBY: Validation complete
    Sun Apr 13 08:25:16 2014
    Completed: ALTER DATABASE OPEN

Peço que observe com calma o alertlog acima, ele nos dá algumas informações interessantes. Primeiro nos diz que o banco está abrindo e que o destino LOG_ARCHIVE_DEST_2 não está sincronizado. Lembram do artigo anterior em que já deixamos tudo pronto para uma eventual troca de papeis? Então, o novo primary está tentando se comunicar com o seu standby (que era o antigo primary) mas não está conseguindo (se você ver logo abaixo tem uma falha de TNS). Mais para baixo ele vai detectar que não tem a tablespace TEMP, ela foi criada e o banco aberto.

Caso queira investigar a falha do LOG_ARCHIVE_DEST_2 basta executar o comando abaixo:

SQL> COL dest_name FORMAT a20
SQL> COL error FORMAT a20
SQL> COL destination FORMAT a10
SQL> SELECT inst_id, dest_name, destination, status, error FROM gv$archive_dest_status WHERE status != 'INACTIVE';

   INST_ID DEST_NAME            DESTINATIO STATUS    ERROR
---------- -------------------- ---------- --------- --------------------
         2 LOG_ARCHIVE_DEST_1              VALID
         2 LOG_ARCHIVE_DEST_2   maa        VALID
         1 LOG_ARCHIVE_DEST_1              VALID
         1 LOG_ARCHIVE_DEST_2   maa        ERROR     ORA-12514:
                                                     TNS:listener does
                                                     not currently know
                                                     of service requested
                                                     in connect
                                                     descriptor


SQL>

Enquanto o antigo primary não volta nós podemos desligar o envio de dados do novo primary para o seu standby. Isso evita um monte de lixo no alertlog:

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

System altered.

SQL>

Ajustando o novo primary

Um detalhe interessante, o Oracle automaticamente após um failover reduz o modo de proteção do seu banco. Assim, ele passa a operar em MAXIMUM PERFORMANCE. Você pode corrigir isso como o seguinte comando:

SQL> SELECT protection_mode, protection_level FROM v$database;

PROTECTION_MODE      PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM PERFORMANCE  MAXIMUM PERFORMANCE

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;

Database altered.

SQL> SELECT protection_mode, protection_level FROM v$database;

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

SQL>

Vamos verificar se tudo foi replicado com sucesso e não perdemos qualquer informação? Na prática você vai fazer diversas validações nos seus dados para garantir isso, aqui vamos usar a nossa tabela de testes. Como você pode ver abaixo, tudo está lá:

SQL> SELECT c1, TO_CHAR(c2, 'DD/MM HH24:MI:SS') as momento FROM testedg;

        C1 MOMENTO
---------- --------------
         1 13/04 07:00:04
         2 13/04 07:01:11

SQL>

CORRIGINDO CRS

Se você seguiu o artigo anterior irá notar que registramos no CRS que esta base é um standby e no caso de um restart do nó ele será aberto em modo mount. Como ocorreu a troca de papeis, precisamos corrigir o CRS. Iremos informar que ela é um banco primary e deve sempre iniciar em open (observe a lista de comandos):

[oracle@rac11stb01 ~]$ srvctl config database -d maastb -v
Database unique name: maastb
Database name:
Oracle home: /u01/app/oracle/product/11.2.0.3/db_1
Oracle user: oracle
Spfile:
Domain:
Start options: mount
Stop options: immediate
Database role: PHYSICAL_STANDBY
Management policy: AUTOMATIC
Server pools: maastb
Database instances: maastb1,maastb2
Disk Groups: DG01,FRA
Mount point paths:
Services:
Type: RAC
Database is administrator managed
[oracle@rac11stb01 ~]$
[oracle@rac11stb01 ~]$    
[oracle@rac11stb01 ~]$ srvctl modify database -d maastb -s OPEN -r PRIMARY
[oracle@rac11stb01 ~]$
[oracle@rac11stb01 ~]$
[oracle@rac11stb01 ~]$ srvctl config database -d maastb -v
Database unique name: maastb
Database name:
Oracle home: /u01/app/oracle/product/11.2.0.3/db_1
Oracle user: oracle
Spfile:
Domain:
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: maastb
Database instances: maastb1,maastb2
Disk Groups: DG01,FRA
Mount point paths:
Services:
Type: RAC
Database is administrator managed
[oracle@rac11stb01 ~]$ 

Como você está em um ambiente RAC você deve abrir as outras instâncias:

SQL> SELECT instance_name, status FROM gv$instance;

INSTANCE_NAME    STATUS
---------------- ------------
maastb1          OPEN
maastb2          MOUNTED

SQL> ALTER DATABASE OPEN;

Database altered.

SQL> SELECT instance_name FROM v$instance;

INSTANCE_NAME
----------------
maastb2

SQL>

BACKUP

Por fim, é imprescindível um backup do seu novo banco primary, será importante caso você precise criar ou recriar o seu standby (antigo primary). Um detalhe que pode poupar um pouco de tempo no futuro, eu não recomendaria fazer um backup e apagar os archive logs (DELETE ALL INPUT), lembre que o novo primary não sincronizou nada com o standby. Assim quando ele voltar ele irá precisar enviar os archives e caso eles não estejam disponível você irá precisar voltar backup. Até se você tentar deletar você receberá um warnig dizendo que eles são necessários.

Uma curiosidade, se você listar as suas cópias de archive irá ver que os últimos oriundos do antigo primary estão marcados como “TERMINAL”

RUN {
    BACKUP FULL FORMAT '/tmp/bkpf-data-D-%d-DBID-%I-T-%T-NB-%s.bkp' DATABASE TAG 'BKP-FULL';
    SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
    BACKUP FORMAT '/tmp/bkpf-arch-D-%d-DBID-%I-T-%T-NB-%s.bkp' ARCHIVELOG ALL TAG 'BKP-FULL-ARCH';
    BACKUP FORMAT '/tmp/bkp-spf-D-%d-DBID-%I-T-%T-NB-%s.bkp' SPFILE TAG 'BKP-FULL-SPFILE';
    BACKUP FORMAT '/tmp/bkp-ctf-D-%d-DBID-%I-T-%T-NB-%s.bkp' CURRENT CONTROLFILE TAG 'BKP-FULL-CONTROL';
}           
   
[oracle@rac11stb01 ~]$ rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Sun Apr 13 09:01:14 2014

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: MAA (DBID=722024964)

RMAN> RUN {
2>     BACKUP FULL FORMAT '/tmp/bkpf-data-D-%d-DBID-%I-T-%T-NB-%s.bkp' DATABASE TAG 'BKP-FULL';
3>     SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
4>     BACKUP FORMAT '/tmp/bkpf-arch-D-%d-DBID-%I-T-%T-NB-%s.bkp' ARCHIVELOG ALL TAG 'BKP-FULL-ARCH';
5>     BACKUP FORMAT '/tmp/bkp-spf-D-%d-DBID-%I-T-%T-NB-%s.bkp' SPFILE TAG 'BKP-FULL-SPFILE';
6>     BACKUP FORMAT '/tmp/bkp-ctf-D-%d-DBID-%I-T-%T-NB-%s.bkp' CURRENT CONTROLFILE TAG 'BKP-FULL-CONTROL';
7> }

Starting backup at 13-APR-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=30 instance=maastb1 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=+DG01/maastb/datafile/system.275.844715965
input datafile file number=00002 name=+DG01/maastb/datafile/sysaux.264.844715965
input datafile file number=00003 name=+DG01/maastb/datafile/undotbs1.263.844715965
input datafile file number=00004 name=+DG01/maastb/datafile/undotbs2.262.844715965
input datafile file number=00005 name=+DG01/maastb/datafile/users.256.844715965
channel ORA_DISK_1: starting piece 1 at 13-APR-14
...
...
...
Starting backup at 13-APR-14
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at 13-APR-14
channel ORA_DISK_1: finished piece 1 at 13-APR-14
piece handle=/tmp/bkp-ctf-D-MAA-DBID-722024964-T-20140413-NB-29.bkp tag=BKP-FULL-CONTROL comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 13-APR-14

RMAN> LIST COPY OF ARCHIVELOG ALL;

List of Archived Log Copies for database with db_unique_name MAASTB
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - ---------
7       1    56      A 12-APR-14
        Name: +FRA/maastb/archivelog/2014_04_12/thread_1_seq_56.391.844718829
...
...
...
45      1    76      A 13-APR-14
        Name: +FRA/maastb/archivelog/2014_04_13/thread_1_seq_76.389.844775859

47      1    77      A 13-APR-14
        Name: +FRA/maastb/archivelog/2014_04_13/thread_1_seq_77.350.844784741 (TERMINAL)

4       2    33      A 12-APR-14
        Name: +FRA/maastb/archivelog/2014_04_12/thread_2_seq_33.398.844717695
...
...
...
43      2    53      A 13-APR-14
        Name: +FRA/maastb/archivelog/2014_04_12/thread_2_seq_53.381.844746645

48      2    54      A 13-APR-14
        Name: +FRA/maastb/archivelog/2014_04_13/thread_2_seq_54.355.844784743 (TERMINAL)

...
...
...
53      2    3       A 13-APR-14
        Name: +FRA/maastb/archivelog/2014_04_13/thread_2_seq_3.300.844786941


RMAN>

AMBIENTE FINAL

Aqui, temos um ambiente em que o banco primary foi chaveado através de failover para seu standby. O failover foi manual e não tivemos qualquer perda de dados devido a forma como o DG estava configurado: MAXIMUM AVAILABILITY e com real-time-apply.

Claro que isso não teria acontecido se primary e standby não estivessem sincronizados. Você já começa errado se o seu ambiente não está sincronizado (você nem deveria começar na realidade). Se você continuar com o ambiente não sincronizado você terá perda de dados, isso é fato.

Lembre-se que aqui tudo foi feito manualmente, em um ambiente MAA DG+RAC você teria o broker configurado (mas isso fica para artigos que virão a seguir). No próximo artigo veremos como fazer o reinstate do antigo primary, vamos fazer ele voltar e se tornar o standby.