ORACLE E MAA (Maximum Availability Architecture) – Parte 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
----------------
PRIMARY
SQL> SELECT protection_mode, protection_level, database_role FROM v$database;
PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE
-------------------- -------------------- ----------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY PRIMARY
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
----------------
PHYSICAL STANDBY
SQL> SELECT instance_name, status FROM gv$instance;
INSTANCE_NAME STATUS
---------------- ------------
maa1 MOUNTED
maa2 MOUNTED
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 21Analisando 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 SHUTDOWNComo 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=13226Lembra 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.
Este artigo também foi publicado em meu blog pessoal.
