Oracle e MAA – Artigo IV – Switchover

Seguindo a ordem dos artigos o próximo passo é realizar o switchover entre primary e standby. Se você seguiu os artigos até aqui, já realizou um failover manual e um reinstate do seu ambiente. O switchover pode ser realizado sem que ocorra um failover, ele é uma operação legítima de um Data Guard. Os passos deste artigo podem ser realizados em um ambiente que não sofreu nenhuma falha até o momento.

QUARTO ARTIGO

Neste quarto artigo vamos realizar o switchover manual do ambiente, mostrarei os passos envolvidos e mais alguns detalhes. Citei acima que esse é uma sequência dos anteriores, mas os passos são os mesmos para um ambiente que necessita de um switchover sem que antes tenha ocorrido um failover.

AMBIENTE

Neste artigo temos um banco Oracle RAC maastb atuando como primary e um banco Oracle RAC maa atuando como standby. A troca prévia de papeis foi realizada devido a um failover, após o antigo primary sofreu o reinstate e voltou como standby do novo primary.

SWITCHOVER

O switchover difere do failover pois tanto o primary quanto o standy estão ativos durante a execução. Assim, você não precisa fazer o reinstate de nenhum deles.

Novamente, ainda não temos o Broker configurado e todos os comandos serão manuais. Os passos para ambos, failover ou switchover, começam da mesma forma: garantia de sincronização. Volto ao mesmo conceito que falei no caso do failover, você tem um ambiente crítico que utiliza DG e não mantém o ambiente rodando e sincronizado em sua plenitude?

Sincronia

Como temos o banco primary disponível no switchover, é mais fácil verificar se ele está sincronizado com o standby. Para isso execute:

SQL> SELECT database_role FROM v$database;

DATABASE_ROLE
----------------
PHYSICAL STANDBY

SQL> SELECT instance_name, status FROM gv$instance;

INSTANCE_NAME    STATUS
---------------- ------------
maa1             MOUNTED
maa2             MOUNTED

SQL>

Se você quiser, pode verificar se está tudo correto com o seu Oracle RAC standby (deveria estar já que o anterior já retornou com sucesso):

SQL> SELECT database_role FROM v$database;

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

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

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

SQL>

Os comandos acima já nos mostraram que está tudo correto com o envio e recebimento dos archives entre primary e standby. Se você quiser verificar qualquer erro ou GAP na troca de archives execute:

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

   INST_ID DEST_NAME            DESTINATION          STATUS    ERROR
---------- -------------------- -------------------- --------- ----------
         1 LOG_ARCHIVE_DEST_1                        VALID
         1 LOG_ARCHIVE_DEST_2   maa                  VALID
         2 LOG_ARCHIVE_DEST_1                        VALID
         2 LOG_ARCHIVE_DEST_2   maa                  VALID

SQL> SELECT * FROM gv$archive_gap;

no rows selected

SQL>

Controle

Como não temos qualquer erro podemos seguir e realizar o swicthover. Para ilustrar que não perderemos qualquer informação durante o switchover vamos voltar a nossa tabela de teste de sincronia que criamos no artigo do failover. Vamos limpar, inserir alguns dados e verificar se após o switchover nenhuma informação foi perdida (isso é um teste e você não precisa fazer em seu ambiente de produção):

SQL> select instance_name FROM v$instance;

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

SQL> DELETE FROM testedg;

2 rows deleted.

SQL> INSERT INTO testedg VALUES(5, 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
---------- --------------
         5 13/04 13:38:10

SQL>

Oracle RAC e ORA-01105

Oracle RAC é legal, ainda mais quanto temos um DataGuard e trabalhamos com MAA, mas as vezes complica a vida de um DBA. O detalhe é que como estamos em ambiente Oracle RAC você não pode fazer swicthover se mais de uma instância do primary estiver online. Caso você tente fazer isso receberá o belo de um erro “ORA-01105: mount is incompatible with mounts by other instances”. Para resolver tal erro, basta deixar somente uma instância online do primary (lembre-se que aqui a maastb está atuando como primary):

[oracle@rac11stb01 ~]$ srvctl status database -d maastb
Instance maastb1 is running on node rac11stb01
Instance maastb2 is running on node rac11stb02
[oracle@rac11stb01 ~]$    
[oracle@rac11stb01 ~]$ srvctl stop instance -d maastb -i maastb2 -o immediate
[oracle@rac11stb01 ~]$

TO STANDBY

Prosseguindo com o switchover precisamos fazer a troca de papeis. Recomendo desconectar qualquer conexão com o seu banco primary antes de prosseguir, você pode fazer sem isso mas finalizar qualquer conexão deixa tudo mais rápido.

Antes do switchover, verifique ser você o seu banco primary irá aceitar a troca. Com o comando abaixo você faz isso, garante que nenhuma conexão está ativa e poderá prosseguir com a troca:

SQL> SELECT switchover_status FROM v$database;

SWITCHOVER_STATUS
--------------------
TO STANDBY

SQL>

Depois de verificar que pode ocorrer a troca, basta executá-la:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

Database altered.

SQL>

No alert da primary:
    Sun Apr 13 13:40:07 2014
    ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN
    ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id: 10087] (maastb1)
    Sun Apr 13 13:40:08 2014
    LGWR: Standby redo logfile selected to archive thread 1 sequence 20
    LGWR: Standby redo logfile selected for thread 1 sequence 20 for destination LOG_ARCHIVE_DEST_2
    Thread 1 advanced to log sequence 20 (LGWR switch)
      Current log# 2 seq# 20 mem# 0: +DG01/maastb/onlinelog/group_2.268.844716057
      Current log# 2 seq# 20 mem# 1: +FRA/maastb/onlinelog/group_2.564.844716059
    Stopping background process QMNC
    Sun Apr 13 13:40:08 2014
    Stopping background process CJQ0
    Sun Apr 13 13:40:08 2014
    Archived Log entry 119 added for thread 1 sequence 19 ID 0x2b1c0c3f dest 1:
    CLOSE: killing server sessions.
    Active process 1004 user 'oracle' program 'oracle@rac11stb01.tjsc.jus.br (TNS V1-V3)'
    Active process 9850 user 'oracle' program 'oracle@rac11stb01.tjsc.jus.br (W000)'
    Active process 9850 user 'oracle' program 'oracle@rac11stb01.tjsc.jus.br (W000)'
    ...
    ...
    ...
    Active process 1004 user 'oracle' program 'oracle@rac11stb01.tjsc.jus.br (TNS V1-V3)'
    Active process 9850 user 'oracle' program 'oracle@rac11stb01.tjsc.jus.br (W000)'
    Active process 1013 user 'oracle' program 'oracle@rac11stb01.tjsc.jus.br (TNS V1-V3)'
    CLOSE: all sessions shutdown successfully.
    Waiting for all non-current ORLs to be archived...
    All non-current ORLs have been archived.
    Waiting for all FAL entries to be archived...
    All FAL entries have been archived.
    Waiting for potential Physical Standby switchover target to become synchronized...
    Active, synchronized Physical Standby switchover target has been identified
    Switchover End-Of-Redo Log thread 1 sequence 20 has been fixed
    Switchover: Primary highest seen SCN set to 0x0.0x28a6d8
    ARCH: Noswitch archival of thread 1, sequence 20
    ARCH: End-Of-Redo Branch archival of thread 1 sequence 20
    ARCH: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
    ARCH: Standby redo logfile selected for thread 1 sequence 20 for destination LOG_ARCHIVE_DEST_2
    Archived Log entry 120 added for thread 1 sequence 20 ID 0x2b1c0c3f dest 1:
    ARCH: Archiving is disabled due to current logfile archival
    Primary will check for some target standby to have received alls redo
    Final check for a synchronized target standby. Check will be made once.
    LOG_ARCHIVE_DEST_2 is a potential Physical Standby switchover target
    Active, synchronized target has been identified
    Target has also received all redo
    Backup controlfile written to trace file /u01/app/oracle/diag/rdbms/maastb/maastb1/trace/maastb1_ora_10087.trc
    Clearing standby activation ID 723258431 (0x2b1c0c3f)
    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;
    Archivelog for thread 1 sequence 20 required for standby recovery
    Switchover: Primary controlfile converted to standby controlfile succesfully.
    Switchover: Complete - Database shutdown required
    Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN

No alert da standby:
    [oracle@rac11pri01 dbs]$ tail -f /u01/app/oracle/diag/rdbms/maa/maa1/trace/alert_maa1.log
    Sun Apr 13 13:41:02 2014
    Standby controlfile consistent with primary
    RFS[2]: Selected log 5 for thread 1 sequence 19 dbid 722024964 branch 844762805
    Sun Apr 13 13:41:02 2014
    Archived Log entry 227 added for thread 1 sequence 18 ID 0x2b1c0c3f dest 1:
    Sun Apr 13 13:41:02 2014
    Media Recovery Waiting for thread 1 sequence 19 (in transit)
    Recovery of Online Redo Log: Thread 1 Group 5 Seq 19 Reading mem 0
      Mem# 0: +DATA/maa/onlinelog/group_5.263.843615365
      Mem# 1: +FRA/maa/onlinelog/group_5.289.843615367
    Sun Apr 13 13:43:14 2014
    RFS[2]: Selected log 6 for thread 1 sequence 20 dbid 722024964 branch 844762805
    Sun Apr 13 13:43:14 2014
    Archived Log entry 228 added for thread 1 sequence 19 ID 0x2b1c0c3f dest 1:
    Sun Apr 13 13:43:14 2014
    Media Recovery Waiting for thread 1 sequence 20 (in transit)
    Recovery of Online Redo Log: Thread 1 Group 6 Seq 20 Reading mem 0
      Mem# 0: +DATA/maa/onlinelog/group_6.261.843615373
      Mem# 1: +FRA/maa/onlinelog/group_6.670.843615373
    RFS[2]: Possible network disconnect with primary database
    Sun Apr 13 13:43:19 2014
    RFS[8]: Assigned to RFS process 12838
    RFS[8]: Selected log 6 for thread 1 sequence 20 dbid 722024964 branch 844762805
    Resetting standby activation ID 723258431 (0x2b1c0c3f)
    Sun Apr 13 13:43:20 2014
    Archived Log entry 229 added for thread 1 sequence 20 ID 0x2b1c0c3f dest 1:
    Media Recovery Waiting for thread 1 sequence 21

Analisando o comando e o log acima temos que o banco sofre commit de todas as transações (COMMIT), foi trocado de papel para ser standby (SWITCHOVER TO PHYSICAL STANDBY) e finalizou toda e qualquer conexão existente (WITH SESSION SHUTDOWN). Observe no alertlog do banco primary que ele verificou (duas vezes) se o standby estava apto e recebeu tudo o que devia (Active, synchronized Physical Standby switchover target has been identified). Também observe no alertlog que novamente temos um “Enf-Of-Redo” e o kill de todos os processo conectados.

Uma informação importante está no alertlog, é necessário fazer o shutdown da antiga primary. Assim, um abort resolve (não se preocupe, os redo serão limpos automaticamente):

SQL> shutdown abort;
ORACLE instance shut down.
SQL> STARTUP MOUNT;
ORACLE instance started.

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

SWITCHOVER TO PRIMARY

Entramos em um momento critico e sem volta, neste momento você não tem nenhum banco primary. O antigo primary já acredita que será standby e o novo primary ainda acha que é standby. Claro que os comandos executados até aqui garantem a sincronia entre os bancos, mas é sempre bom tomar cuidado.

Até aqui já verificamos e garantimos que está tudo sincronizado e que você está sem primary. Além disso, já garantimos que a antiga primary está em modo mount para evitar que ao abrir o novo primary apareçam erros de tns e não consiga sincronizar os redo.

Agora precisamos fazer a standby se tornar a primary. Isso é simples e realizado com um único comando:

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

Database altered.

SQL>

No alert da antiga standby:
    Sun Apr 13 13:56:37 2014
    ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN
    ALTER DATABASE SWITCHOVER TO PRIMARY (maa1)
    Maximum wait for role transition is 15 minutes.
    Switchover: Media recovery is still active
    Role Change: Canceling MRP - no more redo to apply
    Sun Apr 13 13:56:38 2014
    MRP0: Background Media Recovery cancelled with status 16037
    Errors in file /u01/app/oracle/diag/rdbms/maa/maa1/trace/maa1_pr00_11067.trc:
    ORA-16037: user requested cancel of managed recovery operation
    Sun Apr 13 13:56:38 2014
    Managed Standby Recovery not using Real Time Apply
    Recovery interrupted!
    Sun Apr 13 13:56:40 2014
    MRP0: Background Media Recovery process shutdown (maa1)
    Role Change: Canceled MRP
    Backup controlfile written to trace file /u01/app/oracle/diag/rdbms/maa/maa1/trace/maa1_ora_11497.trc
    SwitchOver after complete recovery through change 2664152
    Online log +DATA/maa/onlinelog/group_1.272.843488553: Thread 1 Group 1 was previously cleared
    Online log +FRA/maa/onlinelog/group_1.286.843488555: Thread 1 Group 1 was previously cleared
    Online log +DATA/maa/onlinelog/group_2.271.843488555: Thread 1 Group 2 was previously cleared
    Online log +FRA/maa/onlinelog/group_2.285.843488555: Thread 1 Group 2 was previously cleared
    Online log +DATA/maa/onlinelog/group_3.257.843489101: Thread 2 Group 3 was previously cleared
    Online log +FRA/maa/onlinelog/group_3.284.843489101: Thread 2 Group 3 was previously cleared
    Online log +DATA/maa/onlinelog/group_4.262.843489103: Thread 2 Group 4 was previously cleared
    Online log +FRA/maa/onlinelog/group_4.283.843489103: Thread 2 Group 4 was previously cleared
    Standby became primary SCN: 2664150
    Switchover: Complete - Database mounted as primary
    Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN

Como pode ser visto no alertlog acima o comando executou com sucesso. O banco standby passou agora a ser o primary (SWITCHOVER TO PRIMARY e Standby became primary), basta abrir o banco agora:

SQL> ALTER DATABASE OPEN;

Database altered.

SQL>

Observe que ele já detectou que o dest_2 estava dessincronizado e já enviou os dados para ele, você poderia ter deixado ele em modo DEFER caso não quisesse essa sincronia:
No alert da nova primary temos:
    Sun Apr 13 13:59:13 2014
    ALTER DATABASE OPEN
    This instance was first to open
    Picked broadcast on commit scheme to generate SCNs
    Sun Apr 13 13:59:13 2014
    Assigning activation ID 723321957 (0x2b1d0465)
    LGWR: Primary database is in MAXIMUM AVAILABILITY mode
    Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
    LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
    Thread 1 advanced to log sequence 22 (thread open)
    Sun Apr 13 13:59:13 2014
    ARC1: Becoming the 'no SRL' ARCH
    Thread 1 opened at log sequence 22
      Current log# 2 seq# 22 mem# 0: +DATA/maa/onlinelog/group_2.271.843488555
      Current log# 2 seq# 22 mem# 1: +FRA/maa/onlinelog/group_2.285.843488555
    Successful open of redo thread 1
    MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
    Sun Apr 13 13:59:13 2014
    SMON: enabling cache recovery
    Instance recovery: looking for dead threads
    Instance recovery: lock domain invalid but no dead threads
    Sun Apr 13 13:59:13 2014
    Archived Log entry 230 added for thread 1 sequence 21 ID 0x2b1d0465 dest 1:
    [11497] Successfully onlined Undo Tablespace 2.
    Undo initialization finished serial:0 start:1374323914 end:1374324594 diff:680 (6 seconds)
    Dictionary check beginning
    Dictionary check complete
    Verifying file header compatibility for 11g tablespace encryption..
    Verifying 11g file header compatibility for tablespace encryption completed
    SMON: enabling tx recovery
    Database Characterset is WE8MSWIN1252
    No Resource Manager plan active
    ******************************************************************
    LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
    ******************************************************************
    LGWR: Standby redo logfile selected to archive thread 1 sequence 23
    LGWR: Standby redo logfile selected for thread 1 sequence 23 for destination LOG_ARCHIVE_DEST_2
    Thread 1 advanced to log sequence 23 (LGWR switch)
      Current log# 1 seq# 23 mem# 0: +DATA/maa/onlinelog/group_1.272.843488553
      Current log# 1 seq# 23 mem# 1: +FRA/maa/onlinelog/group_1.286.843488555
    Sun Apr 13 13:59:17 2014
    minact-scn: Inst 1 is now the master inc#:4 mmon proc-id:10227 status:0x7
    minact-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:0
    Starting background process GTX0
    Sun Apr 13 13:59:17 2014
    GTX0 started with pid=39, OS id=13185
    Starting background process RCBG
    Archived Log entry 232 added for thread 1 sequence 22 ID 0x2b1d0465 dest 1:
    Sun Apr 13 13:59:17 2014
    RCBG started with pid=40, OS id=13187
    replication_dependency_tracking turned off (no async multimaster replication found)
    ARC3: Standby redo logfile selected for thread 1 sequence 22 for destination LOG_ARCHIVE_DEST_2
    Starting background process QMNC
    Sun Apr 13 13:59:18 2014
    QMNC started with pid=41, OS id=13189
    LOGSTDBY: Validating controlfile with logical metadata
    LOGSTDBY: Validation complete
    Completed: ALTER DATABASE OPEN
    Thread 1 cannot allocate new log, sequence 24
    Checkpoint not complete
      Current log# 1 seq# 23 mem# 0: +DATA/maa/onlinelog/group_1.272.843488553
      Current log# 1 seq# 23 mem# 1: +FRA/maa/onlinelog/group_1.286.843488555
    Sun Apr 13 13:59:23 2014
    Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
    LGWR: Standby redo logfile selected to archive thread 1 sequence 24
    LGWR: Standby redo logfile selected for thread 1 sequence 24 for destination LOG_ARCHIVE_DEST_2
    Thread 1 advanced to log sequence 24 (LGWR switch)
      Current log# 2 seq# 24 mem# 0: +DATA/maa/onlinelog/group_2.271.843488555
      Current log# 2 seq# 24 mem# 1: +FRA/maa/onlinelog/group_2.285.843488555
    Sun Apr 13 13:59:24 2014
    ARC3: STARTING ARCH PROCESSES
    Sun Apr 13 13:59:24 2014
    ARC4 started with pid=44, OS id=13213
    ARC4: Archival started
    ARC3: STARTING ARCH PROCESSES COMPLETE
    Archived Log entry 235 added for thread 1 sequence 23 ID 0x2b1d0465 dest 1:
    Sun Apr 13 13:59:27 2014
    Starting background process CJQ0
    Sun Apr 13 13:59:27 2014
    CJQ0 started with pid=45, OS id=13226     

Lembra que eu disse para deixar a antiga primary ligada? Se você observar no alertlog acima irá ver que a nova primary já detectou que a standby precisa de sincronia e já começou a enviar os redo. Observe que a standby detectou isso, recebeu e aplicou os redo:

No alert da antiga primary e atual standby:
    Sun Apr 13 13:52:18 2014
    ARC2: Becoming the active heartbeat ARCH
    ARC2: Becoming the active heartbeat ARCH
    Sun Apr 13 13:56:07 2014
    Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
    Sun Apr 13 13:56:08 2014
    RFS[1]: Assigned to RFS process 10590
    RFS[1]: Opened log for thread 1 sequence 21 dbid 722024964 branch 844762805
    Archived Log entry 122 added for thread 1 sequence 21 rlc 844762805 ID 0x2b1d0465 dest 2:
    Sun Apr 13 13:56:10 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 10600
    RFS[2]: Selected log 5 for thread 1 sequence 23 dbid 722024964 branch 844762805
    Sun Apr 13 13:56:11 2014
    RFS[3]: Assigned to RFS process 10602
    RFS[3]: Selected log 6 for thread 1 sequence 22 dbid 722024964 branch 844762805
    Sun Apr 13 13:56:12 2014
    Archived Log entry 123 added for thread 1 sequence 22 ID 0x2b1d0465 dest 1:
    Changing standby controlfile to MAXIMUM AVAILABILITY level
    RFS[2]: Selected log 6 for thread 1 sequence 24 dbid 722024964 branch 844762805
    Sun Apr 13 13:56:18 2014
    Archived Log entry 124 added for thread 1 sequence 23 ID 0x2b1d0465 dest 1:

Outras instâncias

Novamente por estarmos e um ambiente Oracle RAC abrimos a outras instâncias do primary (poderia ter feito isso via srvctl, mas escolhi fazer manualmente):

SQL> SELECT instance_name, status FROM v$instance;

INSTANCE_NAME    STATUS
---------------- ------------
maa2             MOUNTED

SQL> ALTER DATABASE OPEN;

Database altered.

SQL>

E também abrimos a outra instância do standby em modo mount:

[oracle@rac11stb01 ~]$ srvctl start instance -d maastb -i maastb2 -o mount
[oracle@rac11stb01 ~]$

Sincronia 2

Vamos voltar a um ponto que já destaquei em um artigo anterior. Observe que o novo standby recebeu os archives, mas ele não aplicou ainda, nem mesmo o real-time apply está habilitado (se você notou em alguns alertlogs acima isso fica explícito – deixei em negrito). Para “corrigir” isso basta executar o comando abaixo (em uma das instâncias do standby):

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

Database altered.

SQL>

Depois disso podemos ver como ficou a sincronização entre primary e standby:

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

NAME      PROTECTION_MODE      PROTECTION_LEVEL     DATABASE_ROLE
--------- -------------------- -------------------- ----------------
MAA       MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY PRIMARY

SQL>

Se você notar, verá que tudo está sincronizado e que não precisamos “subir” o modo de proteção. No failover isso foi necessário, já no swicthover não. Se ambos os bancos “concordam” com a troca de papeis a garantia e segurança do ambiente é mantida no mesmo nível.

Além disso, podemos verificar como está a nossa tabela de teste (mesmo trocando de base ela se manteve correta):

SQL> SELECT instance_name FROM v$instance;

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

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

        C1 MOMENTO
---------- --------------
         5 13/04 13:38:10

SQL>

CRS

Novamente o Oracle RAC e seus detalhes (não que isso seja ruim). Para finalizar precisamos arrumar o CRS do novo primary:

[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 ~]$
[oracle@rac11pri01 ~]$
[oracle@rac11pri01 ~]$ srvctl modify database -d maa -s OPEN -r PRIMARY
[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: 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 ~]$

E na nova standby:

[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 ~]$
[oracle@rac11stb01 ~]$
[oracle@rac11stb01 ~]$ srvctl modify database -d maastb -s MOUNT -r PHYSICAL_STANDBY
[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: 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 ~]$

AMBIENTE FINAL

Bom, acredito que tenha ficado claro que o swicthover foi realizado com sucesso. Os papeis foram trocados entre primary e standby sem perder qualquer dado. No fim não esqueça de fazer um backup do seu ambiente.

No próximo artigo vamos ver como configurar o Broker, para que serve e onde pode nos ajudar.

 

3 Responses to Oracle e MAA – Artigo IV – Switchover

  1. Pingback: Oracle e MAA – Artigo VIII – Fast-Start Failover | Have you hugged your backup today?

  2. Pingback: Oracle e MAA – Artigo VII – Switchover Broker

  3. Pingback: Oracle e MAA - Artigo V - Broker

Leave a Reply

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