Revisado por Junior Palomino
Introdução
O Oracle Dataguard, que faz parte do MAA (Max Availability Architecture) é um produto utilizado em larga escala, por diversas empresas, ao redor do mundo. Sua principal funcionalidade é manter uma cópia atualizada do banco de dados primário em um site secundário, na maioria dos casos.
Com a introdução do Active Dataguard no Oracle 11g o produto ganhou novas funcionalidades, permitindo que os usuários utilizem o banco de dados de standby para geração de reports, levou o produto que já era bom a um nível ainda melhor. Ao poder gerar reports com o banco de dados aberto em modo read only with apply, é retirado muita carga do banco de dados de primário.
Com o Oracle 19c, foi introduzido um recurso que permite que DML feito no standby seja redirecionado para o banco de dados primário e depois seja enviado via archivelog para o standby, note que não é recomendado direcionar cargas intensas de modificações no standby database para redirecionar ao banco primário.
Benefícios de usar a nova funcionalidade
- Simplicidade para criação ou recriação
As vezes, por algumas falhas como GAP de archivelogs ou alguma reconfiguração, se faz necessário recriar o standby database, e no Oracle 18c é possível, de maneira bem simples, recriar o standby database com um único comando via RMAN.
- Melhor controle do processo
Temos um acompanhamento mais específico como veremos na simulação abaixo, quando falamos de recuperação em caso de falhas ou reconfiguração.
Cenário
- Primary database: orclcdb
- Standby database: orclstb
O banco de dados de standby e primário estão sendo gerenciados pelo Dataguard broker (DGMGRL), que nos auxilia na administração de um ambiente Dataguard, simplificando operações como switchover e diversos outras operações. Para maiores informações, consulte o manual https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/index.html
Verificação do Dataguard
Usando a interface de linha de comando do Oracle Dataguard Broker, emitimos o comando show configuration para mostrar as configurações dos bancos de dados protegidos, no nosso caso, os bancos são orclcdb, o primário e o orclstb que é o nosso standby que irei recriar em seguida após ocasionar uma falha, removendo alguns datafiles do mesmo.
Note, que pela imagem abaixo, não temos problemas e no caso de uma falha do banco primário, o banco de dados de standby poderia ser utilizado como banco primário fazendo um switchover manual, sem maiores problemas. Note que é possível automatizar essa operação, configurando Fast-Start Failover
Gerando problemas no standby
Na imagem abaixo, podemos verificar os datafiles do meu banco de dados de standby, onde iremos causar danos e reconstruir o mesmo a partir do comando recover standby database from service. A listagem abaixo, mostra todos os datafiles do banco de dados em questão (orclstb)
Agora, iremos remover o datafile principal do banco de dados de standby, /u01/app/oracle/oradata/ORCLSTB/system01.dbf
Como esperado, após removermos um datafile, propositalmente o nosso ambiente apresenta problemas, vejam:
Desabilitando o apply no banco de dados de standby
Antes de iniciar o recover do standby database, precisamos parar o sincronismo de archivelogs que estão sendo enviados do banco primário, para isso, usamos o comando abaixo para editar o state do database, ou então, vai se deparar com o erro:
starting media recovery
media recovery failed
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 01/19/2020 11:16:26
RMAN-03015: error occurred in stored script Memory Script
RMAN-11003: failure during parse/execution of SQL statement: alter database recover
if needed standby start
ORA-01153: an incompatible media recovery is active
Após pararmos o recover, basta se logar no RMAN e emitir o comando recover standby database from service, como veremos a seguir:
[oracle@ora19c ~]$ rman target=sys/oracle@orclstb
Recovery Manager: Release 19.0.0.0.0 - Production on Sun Jan 19 11:27:59 2020
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCLCDB (DBID=2780785463, not open)
RMAN> recover standby database from service orclcdb;
Starting recover at 19-JAN-20
using target database control file instead of recovery catalog
Oracle instance started
Total System Global Area 1895823376 bytes
Fixed Size 9136144 bytes
Variable Size 436207616 bytes
Database Buffers 1442840576 bytes
Redo Buffers 7639040 bytes
contents of Memory Script:
{
restore standby controlfile from service 'orclcdb';
alter database mount standby database;
}
executing Memory Script
Starting restore at 19-JAN-20
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=39 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service orclcdb
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
output file name=/u01/app/oracle/oradata/ORCLSTB/control01.ctl
output file name=/u01/app/oracle/fast_recovery_area/ORCLSTB/control02.ctl
Finished restore at 19-JAN-20
released channel: ORA_DISK_1
Statement processed
contents of Memory Script:
{
set newname for datafile 1 to
"/u01/app/oracle/oradata/ORCLSTB/system01.dbf";
restore from service 'orclcdb' datafile
1;
catalog datafilecopy "/u01/app/oracle/oradata/ORCLSTB/system01.dbf";
switch datafile all;
}
executing Memory Script
executing command: SET NEWNAME
Starting restore at 19-JAN-20
Starting implicit crosscheck backup at 19-JAN-20
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=49 device type=DISK
Crosschecked 3 objects
Finished implicit crosscheck backup at 19-JAN-20
Starting implicit crosscheck copy at 19-JAN-20
using channel ORA_DISK_1
Crosschecked 2 objects
Finished implicit crosscheck copy at 19-JAN-20
searching for all files in the recovery area
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_25_gyq4g4hz_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_26_gyq5km3v_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_27_gyq64bom_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_28_gyq64n7f_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_29_gyq64zy8_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_30_gyq6vxg5_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_32_gyq6vzrv_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_31_gyq6vzs6_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_33_gyq84b59_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_34_gyq88dll_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_35_gyq9rvx9_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_36_gyqcf807_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_37_gyqcfsk1_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_38_gyqcg4l3_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_39_gyqckh4o_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_41_gyqckkfk_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_40_gyqckkg6_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_42_gyqcpsko_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_07/
o1_mf_1_43_gyqdchj7_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_08/
o1_mf_1_44_gyso1jwz_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_08/
o1_mf_1_45_gytopnjo_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2019_12_08/
o1_mf_1_46_gytowb7h_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/
o1_mf_1_47_h1gstntb_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/
o1_mf_1_48_h1gtcgd0_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/
o1_mf_1_49_h1gv3wqn_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/
o1_mf_1_50_h1gv8rbs_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_09/
o1_mf_1_51_h1gvo2x8_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_16/
o1_mf_1_52_h21lqfd2_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_16/
o1_mf_1_53_h21m7fwt_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/archivelog/2020_01_19/
o1_mf_1_54_h28w8y78_.arc
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/autobackup/2019_12_07/
o1_mf_s_1026372241_gyq6h263_.bkp
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/autobackup/2019_12_07/
o1_mf_s_1026373077_gyq7r09k_.bkp
File Name: /u01/app/oracle/fast_recovery_area/ORCLSTB/autobackup/2019_12_07/
o1_mf_s_1026378166_gyqd9fxy_.bkp
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service orclcdb
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/ORCLSTB/system01.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
Finished restore at 19-JAN-20
cataloged datafile copy
datafile copy file name=/u01/app/oracle/oradata/ORCLSTB/system01.dbf RECID=5 STAMP=1030102136
datafile 1 switched to datafile copy
input datafile copy RECID=5 STAMP=1030102136 file name=/u01/app/oracle/oradata/ORCLSTB/
system01.dbf
contents of Memory Script:
{
recover database from service 'orclcdb';
}
executing Memory Script
Starting recover at 19-JAN-20
using channel ORA_DISK_1
skipping datafile 1; already restored to SCN 4595092
skipping datafile 3; already restored to SCN 4594570
skipping datafile 5; already restored to SCN 2163739
skipping datafile 6; already restored to SCN 2163739
skipping datafile 7; already restored to SCN 4594577
skipping datafile 8; already restored to SCN 2163739
skipping datafile 9; already restored to SCN 4594580
skipping datafile 10; already restored to SCN 4594582
skipping datafile 12; already restored to SCN 4594588
skipping datafile 13; already restored to SCN 4594593
skipping datafile 14; already restored to SCN 4594596
skipping datafile 15; already restored to SCN 4594598
skipping datafile 19; already restored to SCN 4594600
skipping datafile 20; already restored to SCN 4594604
skipping datafile 21; already restored to SCN 4594611
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 19-JAN-20
Finished recover at 19-JAN-20
RMAN> Como podemos ver, como uma única linha do RMAN, foi possível recuperar o meu banco de dados de standby, se os danos fossem outros, o resultado final seria o mesmo que obtivemos nesse exemplo, banco de dados restaurado e pronto para ser sincronizado novamente.
Então, pela interface do DGMGRL, ativamos o sincronismo novamente conforme vemos abaixo:
Para validar, se tudo ocorreu bem, vamos realizer um switchover para trocar os papéis dos bancos de dados fazendo com que o banco primário vire standby e vice versa. Como podemos ver na imagem abaixo, sem problemas para realizar o switchover:
Agora o meu banco de dados orclstb, originalmente standby database, agora passou a ser meu banco de dados primário, com todos os pdbs abertos para uso.
Todos os nossos PDBs estão abertos e como podemos ver, a instance com db_unique_name = orclstb agora está com a ROLE (papel) PRIMARY.
Conclusão:A Oracle sempre está evoluindo e o produto sempre agregando novas funcionalidades, temos que concordar que essa funcionalidade salva um bom tempo de trabalho para os DBAs e ainda simplifica demais a criação de um standby database. Fica mais um lembrete que está funcionalidade pode ser usada de forma bi-direcional quando você transforma seu standby database em primary database você pode usar a mesma funcionalidade no seu novo standby database.
Rodrigo Mufalani é um Oracle ACE member e Oracle Certified Master (OCM) com 15 anos de experiência, começou com o Oracle 8i, mas teve a oportunidade de dar suporte a Oracle 7.3.4 em diante. É especialista em banco de dados Oracle com foco principal em Engineered Systems, Performance & Tuning e RAC. Ele é fundador e presidente e também palestrante do Luxembourg Oracle User Group. É palestrante em eventos de Oracle como: OTN LAD TOUR e OTN EMEA TOUR e outros. Atualmente trabalha como Principal DB Architect na eProseed Europe. Foi o terceiro Oracle ACE a ser nomeado no Brasil. Twitter @mufalani / blog Mufalani.worpress.com
Y V Ravi Kumar é um Oracle ACE e Oracle Certified Master (OCM) com 18 anos de experiência em instituições financeiras, serviços financeiros e seguros (BFSI) e atuou em diversos papeis como Senior Database Architect e Production DBA. Ele também é OCP em Oracle 8i, 9i, 10g, 11g & 12c e Certificado em Golden Gate, RAC, Performance Tuning& Oracle Exadata. Ele continua motivando muitos DBAs e ajudando a Oracle Community publicando suas dicas /ideias/sugestões/soluções em seu blog. Ele escreveu 40+ artigos OTN sobre Oracle Exadata, Oracle RAC e Oracle GoldenGate para a OTN em Espanhol, OTN em Português e OTN em inglês e 19 artigos para a TOAD World, 2 Artigos para o UKOUG, 3 Artigos para OTech Magazine e 2 Artigos para a Redgate. Ele é membro do AllIndia Oracle UserGroup (AIOUG) e frequente Oracle speaker in @NYOUG, @OTN, AIOUG, Sangam e IOUG. Ele desenha, projeta e implementa Core Banking System (CBS) Databases para o Central Banks em dois países – India e Mahe, Seychelles. Ele é Co-Founder do OraWorld (www.oraworld.com). Leia mais sobre o seu perfil na LaserSoft.
André Luiz Dutra Ontalba é um Oracle ACE member, formado em Ciências da Computação, é especialista em Banco de Dados Oracle com sólidos conhecimentos em Engineered Systems, Performance & Tuning, RAC, Oracle Cloud e Oracle ERP's System; Trabalha com Oracle há 17 anos, certificado OCP Oracle 11/12g/Cloud e conta com mais de 27 outras certificações em produtos da Oracle. Atualmente trabalha como Senior Database Architect na Sogeti Luxembourg uma empresa da Capgemini Group. André é Oracle ACE Member, também é fundador do Grupo de Usuários Oracle de Luxemburgo (LUXOUG). Articulista para o OTN, GPO (Grupo de Usuários Oracle Brasil) e LUXOUG. Twitter @aontalba / blog www.dbadutra.com
Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.