2. Oracle Data Guard Overview
• Oracle Data Guard é uma solução da Oracle de proteção e disponibilidade de
dados (ou Disaster and Recovery), que nasceu no Oracle 7 (ainda sem a
automação que existe hoje), teve sua primeira distribuição formal no Oracle 9i, e
que, teve uma grande evolução no Oracle 10G.
• O grande objetivo do Oracle Data Guard é garantir alta disponibilidade, proteção
de dados e recuperação de desastres para dados empresariais. O Data Guard
oferece um conjunto abrangente de serviços como criar, manter, gerenciar e
monitorar um ou mais bancos de dados standby para permitir que os bancos de
dados de produção do Oracle sobrevivam à catástrofes e corrupções de dados. O
Data Guard mantém esses bancos de dados standby como cópias transacionais
consistentes do banco de dados primário . Se o banco de dados primário se tornar
indisponível por causa de uma interrupção, planejada ou não , o Data Guard pode
mudar qualquer banco de dados standby para o papel de produção, minimizando
assim o tempo de inatividade associado à interrupção. O Data Guard pode ser
usado juntamente com estratégias de backup/recovery tradicionais , arquiteturas
em cluster e, também, com o recurso Flashback Database para fornecer um alto
nível de proteção e disponibilidade de dados. O Oracle Data Guard funciona
apenas na versão Enterprise Edition doOracle Database.
• Atualmente existem soluções de espelhamento remoto "não-Oracle" que
permitem replicar os dados de um modo semelhante ao Data Guard, porém com
algumas desvantagens. Em geral, elas consomem 7 vezes mais volume de dados
na rede, fazem 27 vezes mais operações de I/O na rede, e muitas vezes quando
ocorre alguma falha física no BD de produção, essa falha acaba sendo replicada
para a(s) cópia(s). O Data Guard possui configurações que evitam este problema.
3. Tipos de bancos de dados Standby
• Para termos um ambiente de banco de dados com Oracle Data Guard é necessário pelo
menos:
• 1 Banco de dados primário;
• 1 Banco de dados standby;
• O banco de dados standby pode ser de 3 tipos:
• Físico: Cópia exata do banco de Produção (bloco por bloco), onde os dados são replicados através de
aplicação de redo logs. Este é o tipo de cópia mais utilizada para uma solução de Disaster and Recover.
• Lógico: cópia atualizável do banco de Produção, onde os dados são replicados através de instruções
SQL. Possui algumas limitações, tais como não replicar índices OracleText e Oracle Spatial. É
normalmente utilizada quando há a necessidade de se criar um novo BD, que além de ser uma cópia
"quase idêntica" do BD de produção, possibilite gerar relatórios e até mesmo atualizar dados, visando
não sobrecarregar o BD Primário.
• Snapshot: cópia temporária (existente no 11G ou superior) que recebe, mas não aplica as atualizações
de redo logs. Normalmente é gerada a partir de uma cópia Física para permitir temporariamente
consultar dados e até mesmo alterá-los (para testes), que posteriormente são descartados quando o
sincronismo com o banco de dados primário for refeito.
4. Modos de proteção Oracle Data Guard:
• Máxima Performance: Configuração onde a aplicação de redo logs é assíncrona, ou seja,
os dados de redo são aplicados no banco Primário e depois replicados para o banco
Standby, em modo assíncrono, sem comprometer a performance do banco Primário. Nesta
configuração há o risco de perda de dados no banco standby.
• Máxima Proteção: Configuração onde a aplicação de redo logs é síncrona, ou seja, os
dados de redo são aplicados no banco Primário e replicados para o banco Standby em uma
mesma transação. Essa configuração garante que ambos estejam sempre iguais, mas pode
comprometer a performance do banco Primário, e pior que isso, se o banco Standby não
for replicado em um determinado tempo (configurável), o banco Primário poderá sofrer um
shutdown automático para impedir qualquer alteração no banco e garantir que ambos
continuem iguais ou sincronizados.
• Máxima Disponibilidade:Configuração onde a replicação de redo logs é síncrona até que o
momento em que alguma indisponibilidade de comunicação com o banco Standby ocorra.
Se ocorrer, a replicação passa a ser assíncrona e o banco Primário não sofre um shutdown
automático. Essa configuração é um misto de Máxima Proteção com Máxima Performance.
6. Database Role Switches
• Um banco de dados Oracle opera em uma das duas funções: primário ou standby. O Oracle Data Guard
ajuda a mudar o papel de um banco de dados usando um switchover ou um failover:
• O Switchover é uma inversão de papéis entre o banco de dados principal e um dos seus bancos de dados
standby. O switchover garante que não hajam perdas de dados. Isso geralmente é feito para a manutenção
programada do sistema primário. Durante o switchover, o banco de dados principal transiciona para um
papel de espera, e o banco de dados standby transiciona para o papel principal.
• O Failover é quando o banco de dados primário (todas as instâncias de um banco de dados principal em
RAC) falha e um dos bancos de dados standby é transferido para assumir o papel principal. Failover é
realizada apenas em caso de uma falha catastrófica do banco de dados primário, e não há nenhuma
possibilidade de recuperar o banco de dados principal em tempo hábil. Failover podem ou não resultar na
perda de dados, dependendo do modo de proteção em vigor no momento da falha.
• O Reinstate é o processo no qual o banco de dados principal que sofreu desastre é reintegrado ao
ambiente se tornando agora um standby, esse processo se torna relativamente simples quando o banco de
dados está com flashback ativado, uma vez que é possível voltar o banco ao ultimo SCN antes do desastre.
Sem a feature habilitada é necessário aplicar um recover com um backup incremental a partir do SCN em
que o banco estava no momento do desastre, ou, até mesmo recriar o banco todo através do processo de
duplicate database.
7. Oracle Data Guard Broker Overview
O Oracle Data Guard Broker é um framework que automatiza e centraliza a criação, manutenção e monitoramento de
configurações do Data Guard. A lista a seguir descreve algumas das operações que o Broker automatiza e simplifica:
• Cria e gerencia as configurações do Data Guard que incorporam um banco de dados principal, um novo ou existente (física ou
lógica) do banco de dados standby, redo transport services, e log apply services, onde qualquer um dos bancos de dados podem
ser Oracle Real Application Clusters (Oracle RAC).
• Adiciona um novo ou existente bancos de dados standby (física ou lógico, RAC ou Single Instance) para uma configuração Data
Guard em vigor, para um total de um banco de dados primário, e de 1 a 30 bancos de dados standby na mesma configuração.
• Gerenciando o modo de proteção para a configuração do broker.
• Executa switchover ou failover com um único comando para iniciar e controlar as complexas mudanças de papel (primary x
standby) em todas as bases de dados da configuração.
• Configura para o failover ocorrer automaticamente após a perda do banco de dados principal, aumentando a disponibilidade
sem intervenção manual.
• Monitora o status de toda a configuração, capturando informações de diagnóstico, reportando estatísticas, como a taxa de
aplicação de redo (Redo Apply) e a taxa de geração de redo (Redo Generation Rate), e, detectar problemas rapidamente com
monitoramento centralizado, testes e ferramentas de desempenho.
• Você pode executar todas as operações de gestão local ou remotamente através das interfaces “easy-to-use” do Broker: as
páginas de gerenciamento do Data Guard do Oracle Enterprise Manager, que é a interface gráfica para o usuário do Broker
(GUI), e a interface de linha de comando do Data Guard chamado DGMGRL .
8. Diferenças para FAILOVER
(em caso de queda do primary)
Sem Broker
• ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
• ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
• ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION
SHUTDOWN;
• ALTER DATABASE OPEN;
• Por padrão o Oracle reduz o modo de proteção do banco, caso estivéssemos
utilizando outro modo de proteção que não fosse "maximum performance" seria
necessário alterar:
• ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;
• ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;
Com Broker
• FAILOVERTO “Nome do Banco”;
9. Diferenças para Reinstate
(Com Flashback Database ativo)
Sem Broker
• SELECT standby_became_primary_scn FROM v$database; (no standby)
• STARTUP MOUNT;
• FLASHBACK DATABASE TO SCN 00000000;
• ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
• ALTER SYSTEM SET log_archive_dest_state_2 = 'ENABLE' SCOPE = BOTH
SID = '*';
• ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING
CURRENT LOGFILE DISCONNECT;
Com Broker
• REINSTATE DATABASE “Nome do Banco”;
10. Diferenças para Switchover
Sem Broker
• ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH
SESSION SHUTDOWN; (no primary)
• SHUTDOWN ABORT;
• STARTUP MOUNT;
• ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION
SHUTDOWN; (no standby)
• ALTER DATABASE OPEN; (Novo Primary)
• ALTER DATABASE OPEN; (Novo Standby)
• ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT
LOGFILE DISCONNECT;
Com Broker
• SWITCHOVERTO “Nome do Banco”;