Entendendo Dataguard (Physical Standby Database): Arquitetura do Dataguard (Parte I)

Por Carlos Henrique Yakithi Furushima
Postado em Abril 2015

Revisado por Marcelo Pivovar - Solution Architect

Este artigo traz uma discussão completa sobre Oracle Data Guard - Physical Standby Database, divido em seis (6) partes, abordado as principais perspectivas teórica e pratica (implementação).

O Oracle Data Guard é uma solução alta disponibilidade (High Availability) para banco de dados Oracle, que provê um conjunto abrangente de serviços como criar, manter, gerenciar e monitorar um ou mais banco de dados standby permitindo que um bancos de dados Oracle de produção sobreviva a desastres e corrupção dados. O Data Guard é um dos vários componentes existentes no software Oracle database enterprise edition (Oracle 9i e superior).

O que é banco de dados standby (Standby Database)?
É uma cópia transaccionalmente consistente do banco de dados de produção (primary database), cujo objetivo é ser um "reserva" imediato em caso de desastre, o banco de dados standby (Standby Database) está em recover na sua maior parte do tempo, sendo alimentado por "redo data" (dados oriundo do redo log) oriundos do standby redo log file (real-time apply) ou archivelog file.

Funcionamento

Arquitetura do Dataguard


Em banco de dados standby (Standby Database) físico, a replicação é feita bit-a-bit, ou seja, uma cópia exata do banco de dados produtivo (primary database), o que significa que os rownum e rowids das tabelas permanecerão os mesmos em ambos os ambientes.

Geração, transmissão e aplicação de entradas de redo
Conforme abordado anteriormente, a base da replicação do banco de dados standby (Standby Database) são os dados de redo (redo data), originados na instance do banco de dados produtivo (primary database), cujo componente é o "Redo Log Buffer", o processo background LGWR (Log Writer) é responsável por escrever as entradas de redo (redo data) para área permanente (disco), com isso, o "redo log file" é o destino desta operação de escrita, o também processo background ARCn está encarregado em arquivar de forma off-line um redo log file (criar um réplica de um redo log file que não será sobrescrevido), o destino de criação desde arquivo off-line é descrito no parâmetro de instancia log_archive_dest_1.

O parâmetro de instancia log_archive_dest_1 referência o destino local dos archives gerados, já o parâmetro de instancia log_archive_dest_2 referência o destino remoto das entradas de redo log (redo data), ou seja, o banco de dados standby (Standby Database), o envio pode ser feito de forma síncrona pelo processo background LGWR ou assíncrona pelo processo background LNS (LNS - LGWR network server process é um extensão do processo log writer utilizado pelo Data Guard). Independentemente da forma de envio, o destino é o processo background RFS localizado no banco de dados standby (Standby Database).

O processo background RFS é uma espécie de canal das entradas de redo para um "standby redo log file", o processo background ARCn arquivará um "standby redo log file" que deve ser aplicado no banco de dados standby (Standby Database) pelo processo background MRP, cujo intuito é sincronizar o banco de dados standby (Standby Database) em relação ao banco de dados produtivo (primary database). Em caso de aplicação em tempo real (Real-Time Apply), o archivelog gerado não é utilizado no processo de sincronização (processo de sincronização = aplicação de entradas de redo), uma vez que as entradas de redo localizadas no "standby redo log file" são diretamente aplicadas no banco de dados standby (Standby Database).


Arquitetura do Dataguard


Resolução automática de redo gap
Em caso de redo gap no banco de dados standby (Standby Database), o data guard é capaz de buscar automaticamente o archivelog faltante, por meio de requisições ao FAL Server (FAL Server = Primary Database). FAL é a capacidade do Data Guard de detectar e buscar archivelog para satisfazer a relação de sincronismo entre banco de dados produtivo (primary database) e banco de dados standby (Standby Database), essa propriedade é usada somente em Standby Database Físico (Physical standby database), assim caso ocorra “redo missing” ou corrupção do archivelog é possível buscar em um FAL Server, o mecanismo também é conhecido como "reactive gap resolution". O processo MRP do standby database usando o parâmetro FAL_SERVER (parâmetro FAL_SERVER deve possui uma entrada na lista TNS) requisita o archivelog necessário para resolver o GAP. É importante ressaltar que o parâmetro FAL_CLIENT está depreciado desde Oracle Database 11g R2.

MRP detecta um situação de redo gap, uma vez que não haja mais comunicação entre os processos background ARCn do banco de dados produtivo (primary database) e RFS do banco de dados standby (Standby Database), ou seja, o processo background ARCn do banco de dados produtivo (primary database), executa um ping contínuo em direção ao banco de dados standby (Standby Database), afim de verificar, se a comunicação entre os databases (primário e standby) foi reestabelecida.

Em caso de reestabelecimento da conectividade entre os databases (primário e standby), o mecanismo de resolução do gap, utilizará o FAL Server para requisitar os archivelogs gerados no intervalo de tempo onde ocorreu a indisponibilidade. O processo ARCn determina qual foi o último archivelog file aplicado, essa verificação é feita a partir do standby controlfile via processo background RFS (RFS process do standby database), finalizado esta verificação é enviado os archivelogs necessários para resolver o gap, para que a posição sequencial dos logs tendam a igualdade entre os databases (primário e standby). Posteriormente o processo background LGWR/LNS voltará a enviar as entradas de redo localizada no redo log buffer (SGA) do banco de dados produtivo (primary database) para o Standby Redo Logs.


...Brevemente a próxima parte deste artigo...



Carlos H. Y. Furushima é um especialista em banco de dados relacional, trabalhando como consultor de TI, atuando principalmente como o Oracle Database Administrator (DBA Oracle). Tem uma vasta experiência e conhecimento em "Performance, diagnosticand tuning", "High Availability", "Backup & Recovery" e "Exadata". Ele também está entusiasmado com sistema operacional Linux/Unix, onde contribui com o desenvolvimento do código do kernel Linux em parceria com a comunidade "GNU Linux", com criação e revisão de novas funcionalidades, melhorias e correções de bugs. Recentemente, Furushima divide seu tempo com consultoria especializada em banco de dados Oracle e estudos sobre "Oracle Internals", com o objetivo de descobrir e entender os benefícios do bancos de dados Oracle em plataforma Linux/Unix.

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.