Oracle Data Guard - Conceitos e Arquitetura | GPO (Grupo de Profissionais Oracle)

Oracle Data Guard – Conceitos e Arquitetura

Introdução

Operações de negócio eficientes, Alta qualidade de serviços prestados, conformidade com regras e aplicações em TI e informações corporativas com alto nível de segurança são cenários ideais para cumprimento de um ambiente de alta disponibilidade e segurança de dados. Não é nenhuma surpresa que alta disponibilidde e segurança de dados estão entre as maiores prioridades de empresas hoje em dia.

As solucões para Disaster & Recover (DR) mais conhecidas atualmente são: Backup e Recover para unidades de Mídia / Fita, Log Shipping e replicação remota de informações em Storage. Infelizmente todas as soluções acima não suportam uma recuperação e proteção de dados (RPO – Recovery in Point) ou recuperação em tempo específico (RTO – Data Availability).

Em contra-partida o Oracle Data Guard suporta muitos cenários para soluções de alta disponibilidade. O Oracle Data Guard é suportado apenas na versão Enterprise e provê gerenciamento, moniotramento e automação para criar e gerenciar um ou mais Bancos de Dados Standby que protegem o ambiente contra falhas, desastres, erros e corrupções de dados. Pode ser utilizado como Alta Disponibilidade ou ambiente de recuperação de desastres e é uma ferramenta que pode trabalhar de forma ideal juntamente com o Oracle Real Application Clusters.

Em um momento em que todas as áreas de negócio tem como foco a redução de custos e despesas o Oracle Data Guard é uma forma de retorno de investimento uma vez que pode ser utilizado para execução de queries em ambiente paralelo, relatórios, backups, testes e atualizações ou outras manutenções no ambiente de Banco de Dados, bem como proteção contra desastres.

Planejamento – DRP e BCP

Descrição

Prover meios para garantir a continuidade e a recuperação das operações de negócio quando ocorre um desastre. Planejamento é chave.

Coisas ruins e inesperadas acontecem

Catástrofes naturais (furacão, enchentes, terremotos, incêncios, tempestades);
Atentados terroristas;
Acidentes (aéreos, etc);
Problemas de infra-estrutura (falta de energia elétrica, telefonia, etc);
Ataques de hackers;
etc;

BCP – Business Continuity Plan

Manter as operações funcionando após um desastre

Em outro local, ou com outras ferramentas / processos.

Exemplo

Numa empresa de entregas, que opera com caminhões. BCP se preocupa em manter as entregas em dia, mesmo que um caminhão quebre. Mantendo caminhões e motoristas reserva, rotas alternativas, etc

DRP – Disaster Recovery Plan

Recuperar às operações normais após um desastre

Corrigir, consertar, reparar os problemas.

Exemplo

Numa empresa de entregas, que opera com caminhões. DRP se preocupa em consertar os caminhões quebrados que saíram de operação.

Desenvolvendo um Plano de DRP

Suporte para o desenvolvimento do plano

Suporte GERENCIAL é essencial;
O plano consome tempo;
Não tem retorno tangível imediato;
Para ter sucesso, é necessário comprometimento dos tomadores de decisão;
Definição do time é importante – envolvimento de todas as áreas;

Definição do escopo

Quais riscos serão abrangidos;
Pressões políticas internas podem mudar o escopo;

Identificar Vulnerabilidades

Determinar os impactos – quantitativo e qualitativo
Quantitativos:
Perda de receita;
Aumento de despesas;
Penalidades por violações de leis;
Qualitativos:
Perda de Vantagens competitivas;
Perda de mercado;
Perda de reputação e prestígio;

Definição de Criticidade

Quais os sistemas ou áreas com maior prioridade;
Definir os impactos em cada uma delas;

Identificar as pessoas-chave

Quem deve ser envolvido e agir no momento crítico;

Estabelecer o limite máximo de “downtime” aceitável

Definir os recursos necessários

Máquinas, equipamentos, infra-estrutura, etc;

Análise dos danos

Especialistas devem ser chamados para verificar os danos e a segurança;

Segurança das pessoas

Deve ser sempre a maior prioridade;

Notificações

Notificar todas as pessoas envolvidas sobre o desastre e orientações conforme o caso;

Backup

Efetuados regularmente;
Armazenados externamente;
Planejamento para recuperação (tempo, esforço);

Comunicações

Logística e Suprimentos

Documentação

Preparação para respostas emergenciais

Equipes devem estar preparadas para todos os cenários possíveis;
Todas as respostas devem estar documentadas para a equipe saber o que fazer;
Respostas divididas em dois grupos: Salvamento e Recuperação;

Notificação

Deve haver plano para comunicar aos funcionários quais as facilidades indisponíveis;
Exemplo: ao ligar para a empresa, mensagem explicando a situação;

Manter a segurança física

Evitar vandalismo, invasões, saques;

Testar o plano

Medir tempos de restauração;
Medir performance das principais aplicações;
Aprender com os problemas;
Anotar e implementar as correções necessárias;
Documentar o resultado;

Soluções Oracle para DRP

Backup e Recuperação

Estratégias, técnicas e ferramentas Oracle para Backup e Recuperação do Banco de Dados;
Com segurança;
Sem perdas;
Rápida;

Replicação de Dados

Dados são distribuídos entre bancos de dados;
O que é alterado em um, é replicado para o outro(s);
Altamente configurável:
Master – master, Master – slave
Definição dos dados que serão replicados
Implementada através de Views Materializadas, Oracle Streams, Advanced Replication,

Oracle Golden Gate

Oracle Data-Guard (Standby Database)

Principal solução Oracle especialmente desenvolvida para lidar com desastres;
Mantém um (ou vários) banco de dados sincronizados com o principal;
Dados alterados no site principal são enviados e aplicados rapidamente no site standby;
Preparado para ser utilizado em caso de falha no site principal;

Proteção dos Dados

Data Guard é capaz validar dados corrompidos antes de aplicá-los no DR.
Data Guard oferece zero perda de dados.

Disponibilidade do sistema

Data Guard é capaz de realizar o failover automático ao identificar um problema.
Data Guard pode minimizar o downtime de um upgrade ou em uma manutenção.

Utilização do sistema

Data Guard utiliza menos recursos de rede na transmissão de redo.
Data Guard permite a utilização do DR para relatórios (lógico e físico 11g) e backups.

Oracle Data Guard – Visão Geral

O Oracle Data Guard gerencia, monitora e automatiza o processo de infraestrutura de Bancos de Dados standby, afim de proteger o Oracle Database contra falhas, desastres, erros e corrupção de dados.

Existem 2 (dois) tipos de StandBy Database:

Físico (Physical StandBy Database): Utiliza repliação via Redo e aplica bloco a bloco uma cópia exata

do ambiente de produção;

Lógico (Logical StandBy Database): Utiliza repliação via SQL e contém a mesma informação lógica

do ambiente de produção, porém a estrutura física dos dados pode ser diferente;

Visão Geral da Solução

Solução Oracle para proteção de dados;
Automatiza a criação e manutenção de um ou mais cópias sincronizadas do banco de dados de produção;
Segurança contra falhas, erros, desastres e corrupção de dados;
Mantém até 9 ambientes standby (10gR2);
Mantém até 30 ambientes standby (11gR2);
Servidor de contingência pode estar situado à kilometros;
Incluso na versão DB Enterprise Edition;
Usar o standby para pesquisas, relatórios, teste ou backups;
Replica do banco de dados primário;
Quando o banco primário é modificado, as mudanças são propagadas para o (possivelmente remoto) banco standby;
O banco primário está aberto e ativo. O banco standby ou está em recovery ou em read-only;
Se alguma coisa de errado acontecer com o primário, o standby pode assumir a responsabilidade;

Como o Data Guard Funciona – Arquitetura

A configuração do Data Guard inclui um ambiente de Produção, refrenciado como “Primary Database” e um ambiente de StandBy, referenciado como StandBy Database. Ambos se conectam via TCP/IP usando os serviços de Rede do Oracle (Oracle Net Services). Não existem restrições de local onde cada ambiente se encontra, desde que ambos possam se comunicar. O Ambiente Standby é criado através de backup do Ambiente Produtivo. O Data Guard sincroniza automaticamente o Banco de Dados Primário com todos os seus respectivos Bancos de Dados Standby através de aplicação de Redo Logs ou instruções SQL (Logical Standby).

Data Guard Transport Services

Quando um usuário realiza um COMMIT em uma transação no Banco de Dados, o Oracle escreve as alterações em um arquivo de redo log local. O Data Guard transfere as alterações do Redo Log local do Primary Database para o StandBy Database tanto de maneira Síncrona como Assíncrona. No caso do Oracle 11gR2 os Redo Logs podem ser transferidos com compressão, utilizando o Oracle Advanced Compression.

Transporte de Redo Síncrono (SYNC)

Nesta configuração o Primary Database irá aguardar a confirmação do StandBy Database que o Redo foi descarregado em disco antes de efetivamente realizar o COMMIT, garantindo proteção contra perda de dados. A performance no Primary Database está ligada diretamente ao tempo de envio do Redo Log para o Standby Database (Tempo de Rede).

Na versão 11gR2, o Oracle Dataguard foi melhorado para realizar as transferências de Redo Log para o ambiente Standby de forma paralela, com o I/O de Redo Log do Primary Database otimizando assim o tempo de consumo de rede e I/O de Redo Log no ambiente. Isso permite que a distância geográfica entre o Primary Database e o StandBy Database seja maior. Em ambientes com baixa latência de rede esta configuração reduz o tempo de consumo de rede utilizado pela configuração de transporte SYNC.

Transporte de Redo Assíncrono (ASYNC)

Evita problemas de performance no Primary Database uma vez que não aguarda resposta do Standby Database sobre o recebimento e aplicação do Redo Log. Na versão 11gR2 ocorreram melhorias neste processo, diminuindo o impacto no Primary Database uma vez que que o as alterações ocorridas são transferidas diretamente do Log Buffer (ao invés do Online Redo Log File) para o Standby Database. Este processo diminui o consumo de rede entre os ambientes aumento o throughput do sistema.

De qualquer forma o benefício da configuração ASYNC é acompanhado por uma pequena possibilidade de perda de dados no Standby Database, uma vez que não existem garantidas que os Redo Logs foram aplicados.

Serviços de Aplicação de Alterações do Data Guard (Apply Services)

Este é chamado de “Apply Services” e tem como principal responsabilidade ler e validar Redo Logs (Standby Redo Log File) do Primary Database e aplicar os mesmos no Standby Database usando a configuração de “Redo Apply” (Standby Físico) ou “SQL Apply” (Standby Lógico).

É importante observar que os serviços de aplicação são totalemente independentes. A performance do Standby Database não tem impacto algum sobre o transporte de Redo Logs do Primary Database, esta isolação é bastante importante.

A configuração dos serviços de transporte é essencial para determinação da Performance do Primary Database, consumo de rede, I/O de Redo Logs no Primary e Standby Databases e também garantia ou não de perda de dados. (Data Loss).

Redo Apply – Standby Físico

O Standby Físico, aplica Redo Logs recebidos do ambiente Primary utilizando o “Managed Recovery Process (MRP)”. O Processo MRP é executado em paralelo a fim de otimizar ao máximo a performance e tempo de aplicação de Redo Logs.

Na versão 11gR2, o Data Guard atinge performance de processos de Recovery de até 50MB/Segundo para Bancos de Dados OLTP e mais de 100MB/segundo através de “Direct Path Load” (Este no caso do Exadata).

A configuração de “Redo Apply” é simples, rápida e mais confiável maneira de manter uma cópia exata e sincronizada do Primary Database.

Aspectos:

Fisicamente idêntico ao banco de dados principal;
Enquanto o banco principal está trabalhando, o standby pode estar em dois modos:
Modo de recuperação – logs de alterações gerados no banco principal são enviados e aplicados no standby, bloco a bloco;
Aberto somente para leituras – usado para consultas;
Estruturas em disco idênticas;
Cada bloco de dados do banco standby é exatamente igual ao do banco principal;

SQL Apply – Standby Lógico

O Standby Lógico possui a mesma estrutura lógica do Primary Database, porém a estrutura física pode ser diferente.

O Standby Lógico transforma redo logs recebidos do Primary Database em instruções SQL, e aplica estas instruções no Banco de Dados aberto em modo Read Only. Existem algumas restrições em operações DDL e DML que podem ser encontradas na documentação oficial.

10gR2 (http://docs.oracle.com/cd/B19306_01/server.102/b14239/concepts.htm)

11gR2 (http://docs.oracle.com/cd/E11882_01/server.112/e25608/log_apply.htm#i1027052)

Aspectos:

Logicamente idêntico ao banco principal, porém pode ser fisicamente diferente;
Os logs gerados no banco principal são aplicados como comandos SQL no standby;
Está disponível em modo somente leitura enquanto os logs são aplicados;
As tabelas podem ter índices diferentes e características físicas diferentes do Primary Database;
Mantém a consistência lógica dos dados, para manter as características de standby;

Resolução Automática de Sincronização

Em casos onde o Primary e o Standby Database se desconectam (devido a Falhas de rede ou erros no Servidor Standby), e dependendo do modo de proteção configurado, o Primary Database irá continuar normalmente as operações e irá acumular Redo Logs que não podem ser enviados ao Standby até que uma nova conexão seja estabelecida.

Enquanto estiver nesta condição, o Data Guard irá continuamente monitorar o Standby até que a conexão seja re-estabelecida e os Redo Logs sejam automaticamente aplicados no Standby Database. Nenhuma ação administrativa é necessária, uma vez que os archives logs do Primary Database serão enviados e aplicados no Standby Database.

Caso ocorra um longo tempo de indisponibilidade do Standby, onde não existirão mais os archives necessários para sincronismo do Banco de Dados, pode-se utilizar um backup incremental via RMAN para sincronizar o Standby.

Validação de Dados

Uma das grandes vantagens do Oracle Data Guard é capacidade de validação dos Redo Logs antes da aplicação no Standby Database. Somente são aplicados os Redos recebidos do Primary depois de uma validação e garantia de que não existam blocos corrompidos ou algum tipo de inconsistência de dados.

No caso do Oracle Dataguard 11gR2, os redos são extraídos diretamente da memória (SGA) assim evitando qualquer tipo de corrupção de dados, e somente então enviados para o Standby.

Para o caso de Standby Físico (Physical Standby) o Oracle utiliza o parâmetro DB_LOST_WRITE_PROTECT (Apenas para versão 11g). Este parâmetro evita problemas de gravação em disco que foram confirmadas para o Oracle, porém não ocorreram efetivamente em disco.

Modos de Proteção

Máxima Proteção (Maximum Protection)

Altíssimo nível de proteção de dados;
Configuração: LGWR SYNC;
Proteção a cada transação;
Só libera transação após o redo ser aplicado em ambos os sites;
Se ocorrer algum problema com o site standby, o ambiente produtivo é parado;
Possibilidade de sincronismo com dois sites distintos;

Máxima Disponibilidade (Maximum Availability)

Proteção a cada transação;
Configuração: LGWR SYNC;
Só libera transação após o redo ser aplicado em ambos os sites;
Se ocorrer algum problema com o site standby, o ambiente produtivo continua em funcionamento;
Quando o ambiente standby retorna, a sincronização é feita de forma automática.;
Pré requisito para Failover automático (Fast-start failover);

Máxima Performance (Maximum Performance)

Alto nível de performance;
Configuração: LGWR ASYNC, ou ARCH;
Mínimo impacto ao ambiente de produção;
Utilizado para aplicações que toleram perda de dados;

Oracle Data Guard Broker

Gerenciando a configuração do Data Guard

As configurações do Data Guard (Primary e Standby) podem ser gerenciadas via SQL Plus*. O Oracle Dataguard oferece a ferramenta “Data Guard Broker”, que automatiza e centraliza o gerenciamento, manutenção e criação de configurações para o Data Guard. Esta ferramenta pode ser acessada via Enterprise Manager ou via linha de comando com a ferramenta “DGMGRL”.

Através do Enterprise Manager Grid Control pode-se administrar facilmente as configurações do Data Guard, utilizando o console de Alta Disponibilidade.

O Enterprise Manager Grid Control ainda mantém dados históricos de disponibilidade do Data Guard e permite configuração de Thresholds e alertas.

Aspectos Oracle Data Guard Broker:

Integrado ao banco de dados Oracle e ao Enterprise Manager;
Permite monitoramento unificado de todos os sites Standby;
Agiliza manutenções (criação, switch entre Standby e Primary, etc);

Oracle Data Guard - Conceitos e Arquitetura

Gerenciamento de Diretivas (Role Management Services)

Este serviço permite mudar a “Role” de um Banco de Dados Primary para Standby e Vice-Versa.

Um “Switchover” pode-ser utilizado para executar manutenções programadas, Atualizações, entre outras. Independentemente da configuração de transporte dos Redos, uma operação de “Switchover” tem sempre ZERO de perda de dados (Data Loss).

Um “Failover” converte o Standby Database para Primary, devido a algum problema inesperado com o Primary Database. Uma operação de “Failover” não necessita que o Standby seja re-iniciado para assumir a Role de Primary. Uma vez que os dados e arquivos do Primary permaneçam intactos, o Primary Database Original pode ser re-configurado para assumir de volta sua Role de Primary, utilizando a feature de “Flashback Database”, assim o mesmo não precisará ser restaurado de um Backup anterior.

Aspectos:

Switchover

Mudanças planejadas;
Não é requerida recriação do database;
Utilizado para manutenções de hardware, sistema operacional, Banco de Dados, etc;

Failover

Alteração automática;
Falhas não planejadas com o Primary Database;
Primary pode ser recuperado com Flashback Database;

Fast-Start Failover

Permite a sincronização e troca de Roles dos bancos (Primary e Standby) automaticamente em eventos de perda do ambiente Primary, sem necessária intervenção manual, de forma transparente chegando ao mais alto nível de disponibilidade do Data Guard.

A tecnologia de alta disponibilidade e proteção de dados da Oracle (através do Observer) executará o “Failover”automático na presença dos eventos abaixo:

Datafile Offine (erros IO);
Controlfile corrompido;
Dicionário corrompido;
Logfile inacessível (erros IO);
Problemas de archives;
Lista cadastrada de erros ORA-;

Proteção Automática contra Falhas

Falha detectada pelo Serviço OBSERVER;
Falha confirmada no Standby;

Failover automático para Standby

Failover exeutado automaticamente pelo Observer;
Standby Database assume role de Primary Database;

Re-Sincronização Automática

O Serviço OBSERVER automaticamente re-sincroniza o Primary com falhas para Standby;

Recuperação automática de Blocos

Detecta e recupera automaticamente possíveis blocos corrompidos;
Transparente para usuários e aplicações;
Disponível apenas na versão 11gR2;

Alta Disponibilidade – Downtime Reduzido

Alguns exemplos:

Standby Físico	Standby Lógico

• Atualizações de Database	• Atualizações de Database
• Aplicações de Patchs primeiro em ambiente Standby	• Alterações dno Database
• Movimentação Física de Servidores	• Exemplos: ASSM, initrans, blocksize …
• Atualizações Gerais	• Alterações em índices
• Migrações de 32bit para 64bit	• Implementações de Advanced Compression (11.2)
• Migrações de SO (Windos -> Linux)	• Migração para Secure Files (11.2)
• Migrações de SO (AIX 64 bit -> Solaris SPARC)	• Migrações para Exadata
• Single instance para RAC
• Migrações para ASM	Note: Veja a Nota no My Oracle Support 413484.1 para maiores detalhes
• Testes de Novas Features
• Migrações para Exadata
• Manutenções de Sistema