Oracle Data Guard conceitos e arquitetura

14 de maro de 2013 por Victor Armbrust Operaes de negcio eficientes, alta qualidade de servios prestados, conformidade com regras e aplicaes em TI e informaes corporativas com alto nvel de segurana so cenrios ideais para cumprimento de um ambiente de alta disponibilidade e segurana de dados. No nenhuma surpresa que alta disponibilidade e segurana de dados esto entre as maiores prioridades de empresas hoje em dia. As soluces para Disaster & Recover (DR) mais conhecidas atualmente so: Backup e Recover para unidades de Mdia/Fita, Log Shipping e replicao remota de informaes em Storage. Infelizmente, essas solues no suportam uma recuperao e proteo de dados (RPO Recovery in Point) ou recuperao em tempo especfico (RTO Data Availability). Em contra-partida o Oracle Data Guard suporta muitos cenrios para solues de alta disponibilidade. O Oracle Data Guard suportado apenas na verso Enterprise e prov gerenciamento, monitoramento e automao para criar e gerenciar um ou mais Bancos de Dados Standby que protegem o ambiente contra falhas, desastres, erros e corrupes de dados. Pode ser utilizado como Alta Disponibilidade ou ambiente de recuperao de desastres e uma ferramenta que pode trabalhar de forma ideal juntamente com o Oracle Real Applications Clusters. Em um momento em que todas as reas de negcio tm como foco a reduo de custos e despesas, o Oracle Data Guard uma forma de retorno de investimento, uma vez que pode ser utilizado para execuo de queries em ambiente paralelo, relatrios, backups, testes e atualizaes ou outras manutenes no ambiente de Banco de Dados, bem como proteo contra desastres.

Planejamento DRP e BCP

Descrio
Prover meios para garantir a continuidade e a recuperao das operaes de negcio quando ocorre um desastre. Planejamento chave.

Coisas ruins e inesperadas acontecem

Catstrofes naturais (furaco, enchentes, terremotos, incncios, tempestades); Atentados terroristas; Acidentes (areos, etc); Problemas de infra-estrutura (falta de energia eltrica, telefonia, etc); Ataques de hackers; etc;

BCP Business Continuity Plan

Manter as operaes funcionando aps um desastre
Em outro local, ou com outras ferramentas / processos. Exemplo: Numa empresa de entregas, que opera com caminhes. BCP se preocupa em manter as entregas em dia, mesmo que um caminho quebre. Mantendo caminhes e motoristas reserva, rotas alternativas, etc

DRP Disaster Recovery Plan

Recuperar as operaes normais aps um desastre
Corrigir, consertar, reparar os problemas. Exemplo: Numa empresa de entregas, que opera com caminhes. DRP se preocupa em consertar os caminhes quebrados que saram de operao.

Desenvolvendo um Plano de DRP

1. Suporte para o desenvolvimento do plano:

Suporte GERENCIAL essencial; O plano consome tempo; No tem retorno tangvel imediato; Para ter sucesso, necessrio comprometimento dos tomadores de deciso; Definio do time importante envolvimento de todas as reas;

2. Definio do escopo:

Quais riscos sero abrangidos; Presses polticas internas podem mudar o escopo;

3. Identificar vulnerabilidades: Determinar os impactos quantitativo e qualitativo: Quantitativos: 1. Perda de receita; 2. Aumento de despesas; 3. Penalidades por violaes de leis; Qualitativos: 1. Perda de Vantagens competitivas; 2. Perda de mercado;

3. Perda de reputao e prestgio; 4. Definio de criticidade:

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

5. Identificar as pessoas-chave:

Quem deve ser envolvido e agir no momento crtico;

6. Estabelecer o limite mximo de downtime aceitvel 7. Definir os recursos necessrios:

Mquinas, equipamentos, infra-estrutura, etc;

8. Anlise dos danos:

Especialistas devem ser chamados para verificar os danos e a segurana;

9. Segurana das pessoas:

Deve ser sempre a maior prioridade;

10. Notificaes:

Notificar todas as pessoas envolvidas sobre o desastre e orientaes conforme o caso;

11. Backup:

Efetuados regularmente; Armazenados externamente; Planejamento para recuperao (tempo, esforo);

12. Comunicaes; 13. Logstica e Suprimentos; 14. Documentao;

Preparao para respostas emergenciais - Equipes devem estar preparadas para todos os cenrios possveis; - Todas as respostas devem estar documentadas para a equipe saber o que fazer;

- Respostas divididas em dois grupos: Salvamento e Recuperao;

Notificao - Deve haver plano para comunicar aos funcionrios quais as facilidades indisponveis; Exemplo: ao ligar para a empresa, mensagem explicando a situao;

Manter a segurana fsica - Evitar vandalismo, invases, saques;

Testar o plano - Medir tempos de restaurao; - Medir performance das principais aplicaes; - Aprender com os problemas; - Anotar e implementar as correes necessrias; - Documentar o resultado;

Solues Oracle para DRP

Backup e Recuperao - Estratgias, tcnicas e ferramentas Oracle para Backup e Recuperao do Banco de Dados; - Com segurana; - Sem perdas; - Rpida; Replicao de Dados - Dados so distribudos entre bancos de dados; - O que alterado em um, replicado para o outro(s);

- Altamente configurvel: - Master master, Master slave - Definio dos dados que sero replicados - Implementada atravs de Views Materializadas, Oracle Streams, Advanced Replication, Oracle Golden Gate

Oracle Data-Guard (Standby Database)

- Principal soluo Oracle especialmente desenvolvida para lidar com desastres; - Mantm um (ou vrios) banco de dados sincronizados com o principal; - Dados alterados no site principal so enviados e aplicados rapidamente no site standby; - Preparado para ser utilizado em caso de falha no site principal;

Proteo 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 automtico ao identificar um problema. - Data Guard pode minimizar o downtime de um upgrade ou em uma manuteno.

Utilizao do sistema - Data Guard utiliza menos recursos de rede na transmisso de redo. - Data Guard permite a utilizao do DR para relatrios (lgico e fsico 11g) e backups.

Oracle Data Guard Viso 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 corrupo de dados. Existem 2 (dois) tipos de StandBy Database: - Fsico (Physical StandBy Database): Utiliza repliao via Redo e aplica bloco a bloco uma cpia exata do ambiente de produo; - Lgico (Logical StandBy Database): Utiliza repliao via SQL e contm a mesma informao lgica do ambiente de produo, porm a estrutura fsica dos dados pode ser diferente;

Viso Geral da Soluo

- Soluo Oracle para proteo de dados; - Automatiza a criao e manuteno de um ou mais cpias sincronizadas do banco de dados de produo; - Segurana contra falhas, erros, desastres e corrupo de dados; - Mantm at 9 ambientes standby (10gR2); - Mantm at 30 ambientes standby (11gR2); - Servidor de contingncia pode estar situado kilometros; - Incluso na verso DB Enterprise Edition; - Usar o standby para pesquisas, relatrios, teste ou backups; - Replica do banco de dados primrio; - Quando o banco primrio modificado, as mudanas so propagadas para o (possivelmente remoto) banco standby; - O banco primrio est aberto e ativo. O banco standby ou est em recovery ou em read-only; - Se alguma coisa de errado acontecer com o primrio, o standby pode assumir a responsabilidade;

Como o Data Guard Funciona Arquitetura

A configurao do Data Guard inclui um ambiente de Produo, refrenciado como Primary Database e um ambiente de StandBy, referenciado como StandBy Database. Ambos se conectam via TCP/IP usando os servios de Rede do Oracle (Oracle Net Services). No existem restries de local onde cada ambiente se encontra, desde que ambos possam se comunicar. O Ambiente Standby criado atravs de backup do Ambiente Produtivo. O Data Guard sincroniza automaticamente o Banco de Dados Primrio com todos os seus respectivos Bancos de Dados Standby atravs de aplicao de Redo Logs ou instrues SQL (Logical Standby).

Data Guard Transport Services Quando um usurio realiza um COMMIT em uma transao no Banco de Dados, o Oracle escreve as alteraes em um arquivo de redo log local. O Data Guard transfere as alteraes do Redo Log local do Primary Database para o StandBy Database tanto de maneira Sncrona como Assncrona. No caso do Oracle 11gR2 os Redo Logs podem ser transferidos com compresso, utilizando o Oracle Advanced Compression. Transporte de Redo Sncrono (SYNC) Nesta configurao o Primary Database ir aguardar a confirmao do StandBy Database que o Redo foi descarregado em disco antes de efetivamente realizar o COMMIT, garantindo proteo 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 verso 11gR2, o Oracle Dataguard foi melhorado para realizar as transferncias 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 distncia geogrfica entre o Primary Database e o StandBy Database seja maior. Em ambientes com baixa latncia de rede esta configurao reduz o tempo de consumo de rede utilizado pela configurao de transporte SYNC. Transporte de Redo Assncrono (ASYNC)

Evita problemas de performance no Primary Database uma vez que no aguarda resposta do Standby Database sobre o recebimento e aplicao do Redo Log. Na verso 11gR2 ocorreram melhorias neste processo, diminuindo o impacto no Primary Database uma vez que que o as alteraes ocorridas so transferidas diretamente do Log Buffer (ao invs 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 benefcio da configurao ASYNC acompanhado por uma pequena possibilidade de perda de dados no Standby Database, uma vez que no existem garantidas que os Redo Logs foram aplicados.

Servios de Aplicao de Alteraes 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 configurao de Redo Apply (Standby Fsico) ou SQL Apply (Standby Lgico). importante observar que os servios de aplicao so totalemente independentes. A performance do Standby Database no tem impacto algum sobre o transporte de Redo Logs do Primary Database, esta isolao bastante importante. A configurao dos servios de transporte essencial para determinao da Performance do Primary Database, consumo de rede, I/O de Redo Logs no Primary e Standby Databases e tambm garantia ou no de perda de dados. (Data Loss). Redo Apply Standby Fsico O Standby Fsico, aplica Redo Logs recebidos do ambiente Primary utilizando o Managed Recovery Process (MRP). O Processo MRP executado em paralelo a fim de otimizar ao mximo a performance e tempo de aplicao de Redo Logs.

Na verso 11gR2, o Data Guard atinge performance de processos de Recovery de at 50MB/Segundo para Bancos de Dados OLTP e mais de 100MB/segundo atravs de Direct Path Load (Este no caso do Exadata). A configurao de Redo Apply simples, rpida e mais confivel maneira de manter uma cpia exata e sincronizada do Primary Database. Aspectos: - Fisicamente idntico ao banco de dados principal; - Enquanto o banco principal est trabalhando, o standby pode estar em dois modos: - Modo de recuperao logs de alteraes gerados no banco principal so enviados e aplicados no standby, bloco a bloco; - Aberto somente para leituras usado para consultas; - Estruturas em disco idnticas; - Cada bloco de dados do banco standby exatamente igual ao do banco principal;

SQL Apply Standby Lgico O Standby Lgico possui a mesma estrutura lgica do Primary Database, porm a estrutura fsica pode ser diferente.

O Standby Lgico transforma redo logs recebidos do Primary Database em instrues SQL, e aplica estas instrues no Banco de Dados aberto em modo Read Only. Existem algumas restries em operaes DDL e DML que podem ser encontradas na documentao 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#i10270 52

Aspectos: - Logicamente idntico ao banco principal, porm pode ser fisicamente diferente; - Os logs gerados no banco principal so aplicados como comandos SQL no standby; - Est disponvel em modo somente leitura enquanto os logs so aplicados; - As tabelas podem ter ndices diferentes e caractersticas fsicas diferentes do Primary Database; - Mantm a consistncia lgica dos dados, para manter as caractersticas de standby;

Resoluo Automtica de Sincronizao 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 proteo configurado, o

Primary Database ir continuar normalmente as operaes e ir acumular Redo Logs que no podem ser enviados ao Standby at que uma nova conexo seja estabelecida. Enquanto estiver nesta condio, o Data Guard ir continuamente monitorar o Standby at que a conexo seja re-estabelecida e os Redo Logs sejam automaticamente aplicados no Standby Database. Nenhuma ao administrativa necessria, uma vez que os archives logs do Primary Database sero enviados e aplicados no Standby Database. Caso ocorra um longo tempo de indisponibilidade do Standby, onde no existiro mais os archives necessrios para sincronismo do Banco de Dados, pode-se utilizar um backup incremental via RMAN para sincronizar o Standby.

Validao de Dados Uma das grandes vantagens do Oracle Data Guard capacidade de validao dos Redo Logs antes da aplicao no Standby Database. Somente so aplicados os Redos recebidos do Primary depois de uma validao e garantia de que no existam blocos corrompidos ou algum tipo de inconsistncia de dados. No caso do Oracle Dataguard 11gR2, os redos so extrados diretamente da memria (SGA) assim evitando qualquer tipo de corrupo de dados, e somente ento enviados para o Standby. Para o caso de Standby Fsico (Physical Standby) o Oracle utiliza o parmetro DB_LOST_WRITE_PROTECT (Apenas para verso 11g). Este parmetro evita problemas de gravao em disco que foram confirmadas para o Oracle, porm no ocorreram efetivamente em disco.

Modos de Proteo
Mxima Proteo (Maximum Protection) - Altssimo nvel de proteo de dados; - Configurao: LGWR SYNC; - Proteo a cada transao; - S libera transao aps 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; Mxima Disponibilidade (Maximum Availability) - Proteo a cada transao; - Configurao: LGWR SYNC; - S libera transao aps 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 sincronizao feita de forma automtica.; - Pr requisito para Failover automtico (Fast-start failover); Mxima Performance (Maximum Performance) - Alto nvel de performance; - Configurao: LGWR ASYNC, ou ARCH; - Mnimo impacto ao ambiente de produo; - Utilizado para aplicaes que toleram perda de dados;

Modos de Proteo
Mxima Proteo (Maximum Protection) - Altssimo nvel de proteo de dados; - Configurao: LGWR SYNC; - Proteo a cada transao; - S libera transao aps 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; Mxima Disponibilidade (Maximum Availability) - Proteo a cada transao; - Configurao: LGWR SYNC; - S libera transao aps 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 sincronizao feita de forma automtica.; - Pr requisito para Failover automtico (Fast-start failover);

Mxima Performance (Maximum Performance) - Alto nvel de performance; - Configurao: LGWR ASYNC, ou ARCH; - Mnimo impacto ao ambiente de produo; - Utilizado para aplicaes que toleram perda de dados;

O Enterprise Manager Grid Control ainda mantm dados histricos de disponibilidade do Data Guard e permite configurao 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 manutenes (criao, switch entre Standby e Primary, etc);

Gerenciamento de Diretivas (Role Management Services)

Este servio permite mudar a Role de um Banco de Dados Primary para Standby e Vice-Versa. Um Switchover pode-ser utilizado para executar manutenes programadas, Atualizaes, entre outras. Independentemente da configurao de transporte dos Redos, uma operao 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 operao de Failover no necessita que o Standby seja re-iniciado para assumir a Role de Primary. Uma vez que os dados e arquivos do Primary permaneam intactos, o Primary Database Original pode ser reconfigurado para assumir de volta sua Role de Primary, utilizando a feature de Flashback Database, assim o mesmo no precisar ser restaurado de um Backup anterior. Aspectos: Switchover - Mudanas planejadas; - No requerida recriao do database; - Utilizado para manutenes de hardware, sistema operacional, Banco de Dados, etc; Failover - Alterao automtica; - Falhas no planejadas com o Primary Database;

- Primary pode ser recuperado com Flashback Database; Fast-Start Failover Permite a sincronizao e troca de Roles dos bancos (Primary e Standby) automaticamente em eventos de perda do ambiente Primary, sem necessria interveno manual, de forma transparente chegando ao mais alto nvel de disponibilidade do Data Guard. A tecnologia de alta disponibilidade e proteo de dados da Oracle (atravs do Observer) executar o Failoverautomtico na presena dos eventos abaixo: - Datafile Offine (erros IO); - Controlfile corrompido; - Dicionrio corrompido; - Logfile inacessvel (erros IO); - Problemas de archives; - Lista cadastrada de erros ORA-;

Proteo Automtica contra Falhas - Falha detectada pelo Servio OBSERVER; - Falha confirmada no Standby;

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

Re-Sincronizao Automtica - O Servio OBSERVER automaticamente re-sincroniza o Primary com falhas para Standby;

Recuperao automtica de Blocos - Detecta e recupera automaticamente possveis blocos corrompidos; - Transparente para usurios e aplicaes; - Disponvel apenas na verso 11gR2; Alta Disponibilidade Downtime Reduzido Alguns exemplos: Standby Fsico Atualizaes de Database Aplicaes de Patchs primeiro em ambiente Standby Movimentao Fsica de Servidores Atualizaes Gerais Migraes de 32bit para 64bit Standby Lgico Atualizaes de Database Alteraes dno Database Exemplos: ASSM, initrans, blocksize Alteraes em ndices Implementaes de Advanced Compression (11.2) Migrao para Secure Files (11.2)

Migraes de SO (Windos -> Linux) Migraes de SO (AIX 64 bit -> Solaris Migraes para Exadata SPARC) Single instance para RAC Note: Veja a Nota no My Oracle Support Migraes para ASM 413484.1 para maiores detalhes

 Testes de Novas Features Migraes para Exadata Manutenes de Sistema Manutenes - Permite atualizao e testes no Standby; - Aps validao, aplicar atualizaes no Primary;

Active Data Guard - Disponvel apenas na verso 11g; - Utilize Standby Fsico para diminuir a carga do Primary; - Ambiente sempre ativo (Para Consultas, Relatrios, Backups, etc)

Referncias

Data Guard Technical Information and Best Practices: www.oracle.com/goto/dataguard Data Guard Compared to Storage Remote Mirroring: http://www.oracle.com/technetwork/database/features/availability/dat aguardremotemirroring-086151.html Active Data Guard Demonstrations: http://www.oracle.com/technetwork/database/features/availabil ity/demonstrations-092317.html Customer case studies, pod-casts and OpenWorld presentations: http://www.oracle.com/technetwork/database/features/availability /ha-casestudies-098033.html Active Data Guard Hands On Lab: http://www.oracle.com/technetwork/database/features/availability/dataguard-hol-176005.html HA Best Practices: www.oracle.com/goto/maa Fast-Start Failover Best Practices: Oracle Data Guard 10g Release 2: http://www.oracle.com/technology/pub/articles/smiley-fsfo.html Oracle Database 10g Dataguard Handbook - Michael Smith, Bill Burke: Oracle Data Guard - Bipul Kumar