High Avaiability Architeture with Oracle Data Guard Broker

115 visualizações

Publicada em

Overview sobre Oracle Data Guard, e, vantagens na utilização da ferramenta DGMGRL (Oracle Data Guard Broker).

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
115
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
3
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

High Avaiability Architeture with Oracle Data Guard Broker

  1. 1. High Availability Architecture with Oracle Data Guard Broker
  2. 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. 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. 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.
  5. 5. Arquitetura Data Guard
  6. 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. 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. 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. 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. 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”;

×