Dicas para configurar o Oracle Data Guard Standby físico

ARTIGO REVISADO EM 31/5/24

Olá pessoal,

     No post de hoje quero compartilhar com vocês algumas dicas simples, mas que considero importantes para quem tem um ambiente de "Disaster Recovery" com Data Guard e um Banco de Dados Standby físico.

     Antes de iniciar o artigo, caso você queira aprender conceitos básicos sobre o Data Guard e como implementar um Data Guard com Standby Físico, sugiro a leitura dos artigos abaixo:

        - Conceitos básicos do Oracle Data Guard;

        - Implementando um Data Guard com Standby Físico,

     Agora vamos ao que interessa. Considerando que você já tem um ambiente Data Guard com Standby Físico, seguem abaixo 2 dicas para você configurar melhor o seu ambiente:

1- EVITANDO QUE ARCHIVES SEJAM APAGADOS ANTES DELES SEREM APLICADOS NO BD STANDBY:

É muito comum que criemos nos servidores de produção uma área de armazenamento isolada para os archives, e que configuremos algum job para limpar (apagar) os archives dessa área de tempos em tempos, evitando que ela "estoure" e congele o Banco de Dados. Na empresa em que trabalho, configuramos a limpeza através de um script que é executado de hora em hora no RMAN, fazendo um backup dos archives e em seguida apagando-os, como no exemplo abaixo:

$ rman target /
RMAN> backup archivelog all delete all input;

É importante ressaltar que archives que ainda não foram aplicados no BD Standby não podem ser apagados, portanto para evitar que isso ocorra, execute o comando abaixo no RMAN, conectando-se no BD de Produção (e também no catálogo do RMAN, caso você tenha um), para permitir que os archives sejam apagados somente após eles serem aplicados no BD Standby:

$ rman target /

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

 

Obs.: Execute o mesmo comando também no BD Standby.

2- CONFIGURANDO O DATA BROKER PARA OCORRER O STARTUP AUTOMÁTICO:

No artigo Configurando o Data Broker no Data Guard falo sobre alguns benefícios de você configurar o Data Broker no seu ambiente Data Guard, mas quero falar aqui sobre outro benefício que não foi citado lá. Na empresa em que trabalho temos ambientes de produção single instance que são gerenciados pelo Oracle Grid Infrastructure. Antes de termos o Grid Infrastructure (GI) instalado, a gente tinha que criar um serviço no Linux para chamar os famosos scripts dbshut e dbstart, para que os serviços do Oracle fossem "shutados" e "startados" automaticamente, porém, em ambientes com Data Guard, era necessário criar scripts customizados para verificar o papel do banco de dados e fazer o startup apropriado dos BDs Primário e Standby. Depois que implementamos o GI não precisamos de mais nada disso para que o shutdown/startup ocorra automaticamente, porém no caso do BD Standby, caso você não tenha o Data Broker configurado, ele não será startado automaticamente, portanto, essa é mais uma vantagem de ter o Data Broker configurado.

Desse modo, lembre-se também de configurar no GI o BD para ele abrir no modo mount e no papel de standby físico, como no exemplo abaixo para adicioná-lo: 

$ srvctl add database -d nomebd -s mount -r PHYSICAL_STANDBY -oraclehome diretorio

ou como no exemplo abaixo para modificá-lo (caso ele já esteja registrado no GI):

$ srvctl modify database -d nomebd -s mount -r PHYSICAL_STANDBY

Por hoje é só, espero que as dicas lhe sejam úteis!
Se tiver alguma dúvida deixe um comentário nesse post que eu lhe responderei o mais breve possível.

[]s