ORACLE E MAA (Maximum Availability Architecture) – Parte II
FAILOVER MANUAL
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 databaseCom 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 CANCELObserve 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 FINISHSe 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 SHUTDOWNO 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 OPENPeç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.
Este artigo também foi publicado em meu blog pessoal.
