ORACLE E MAA (Maximum Availability Architecture) – Parte X
Nesta série de artigos apresentei um passo a passo sobre como configurar um ambiente Oracle RAC 11GR2 com Data Guard e seguindo o MAA. Mas será que é só isso que você deve se preocupar? Para ter um banco de dados Oracle operando em MAA basta configurar o Data Guard? Neste último artigo da série vou falar um pouco sobre isso, um resumo dos artigos passados e o que podemos esperar pela frente (12C).
DÉCIMO ARTIGO
Neste artigo vou fazer um guia com os tópicos anteriores, algo sucinto. Também vou escrever sobre o que está além do MAA e Oracle, quais outros fatores que podem influenciar para o sucesso do ambiente. Por fim, o que temos para o Data Guard no Oracle 12C.
ARTIGOS ANTERIORES
Os tópicos abaixo foram agrupados para ajudar você a montar e gerenciar seu Oracle Data Guard com MAA.
Rac + Rac
Se você está iniciando a configuração de um ambiente com Data Guard + RAC (em ambos, primary e standby) para buscar o MAA leia o primeiro artigo. Neste existem informações sobre como preparar o banco principal com FlashBack; também verá explicações sobre os parâmetros que precisam ser ajustados no spfile para permitir clonar o banco. Também verá 3 diferentes formas de clonar seu banco: com backup local, clone via Active Database e clone através de fita/backup na MML.
Depois, sugiro passar direto para o quinto artigo onde demonstrei como configurar o Broker. Além de entender o que é o Broker o importante é saber ajustar corretamente a conexão dele com todas as instâncias individualmente (através StaticConnectIdentifier). Na internet você vê diversos exemplo de como fazer em um ambiente sem RAC, neste artigo você viu como fazer isso com o RAC no standby também.
Por fim, você deve configurar o ambiente para fazer o Failover automático em caso de falha do primary (Fast-Start Failover). Demonstrei isso no oitavo artigo, como habilitar a configuração no Broker e adicionar o Observer no ambiente.
Com estes três artigos você terá no fim um ambiente com RAC em ambos os lados do DataGuard, primary e standby, operando com Broker e Fast-Start Failover. Além disso terá um ambiente com MAA.
O que fazer em caso de falhas
Caso você esteja enfrentando problemas com o ambiente primary e necessita de um Switchover pode fazer usando o modo manual como no quarto artigo ou através do Broker no sétimo artigo. O procedimento apresentado nestes artigos é semelhante ao que você precisaria fazer na aplicação de um patch no ambiente por exemplo.
Se o problema é maior e precisa de um Failover você pode usar o segundo artigo para o passo a passo manual ou o sexto artigo para fazer isso através do Broker. Lembre-se de que é importante garantir que o envio de archives está correto e que não exista nenhum gap entre eles, caso contrário estará sujeito a perder informações.
Se você tem um ambiente que sofreu um Failover e precisa fazer o Reinstate, siga como exemplo o terceiro artigo. Assim, mesmo em caso de falha poderá resgatar o seu ambiente de forma rápida.
O AMBIENTE
As falhas graves no ambiente de servidores geralmente ocorrem sem qualquer aviso, um link de comunicação que falhou pode causar a troca entre primary e standby. Muitas vezes você não tem controle nem como se antever do que irá acontecer e a melhor opção é sempre estar preparado.
Você não precisa esperar uma falha para saber que seus aplicativos não estão prontos para a troca de papeis do banco. Já falei isso em artigos anteriores, se você está configurando um Oracle com MAA + Data Guard + RAC em ambos os lados com certeza está lidando com ambiente importante e dados críticos, perder dados não é uma opção. Mantenha alertas configurados no GridControl/Cloud Control para que, em caso de falhas (qualquer uma), você seja rapidamente avisado.
Além de fatores internos do próprio banco existem outros que influenciam na performance do sistema, o mais sensível em um ambiente Data Guard é o link de comunicação. Já foram feitos testes (pela própria Oracle aqui) que demonstram que ambientes com latência de rede superior a 10ms entre os sites tem impacto negativo. Claro que depende da configuração adotada, em ambientes operando com Maximum Availability qualquer latência acima de 10ms será ruim para o sistema, ambientes que não são “síncronos” na transmissão de redo sofrerão um impacto bem menor.
Outro ponto importante é com a figura do Observer. Por exemplo, se você deixar ele “do lado” do Standby e tiver uma queda de comunicação entre os sites o Observer pode entender que ocorreu uma falha e chavear para o standby. Fazer um design correto do ambiente também é fundamental.
O importante aqui é perceber que um ambiente Data Guard não é só banco de dados. Todas as peças devem estar dimensionadas adequadamente, em ambientes sensíveis qualquer sobrecarga ou falha pode deixar o ambiente indisponível. Esteja preparando para lidar com elas.
DATA GUARD E FUTURO
Uma das funcionalidade que tiveram mudanças significativas no Oracle 12C foi o Data Guard, indo além de CDB’s e PDB’s tivemos a adição do FAR SYNC e FAST SYNC.
O FAR SYNC é indicado para locais onde você não consegue ter a comunicação com baixa latência entre o standby e o primary. Se você notou nos artigos anteriores para ter um ambiente standby síncrono (com Maximum Availability ou Protection) este precisa ser uma cópia fidedigna dos datafiles do primary. No FAR SYNC você terá uma instância sincronizada com o primary mas que apresenta somente os controlfiles, redo’s e standby redo’s. E esta instância estaria operando em modo assíncrono com o standby (que este sim seria uma cópia fiel do primary).
O que você ganha com isso? A principal vantagem é ter um ambiente primary protegido com Data Guard mas sem sofrer problemas de latência com o envio até o standy. E também ganha em segurança, no caso de uma queda do primary você ainda teria um ambiente standby sincronizado já que o chaveamento só ocorre se o FAR SYNC enviar todos os redo’s. A recomendação é colocar o FAR SYNC o mais próximo possível do primary (ele ainda poderia servir de hub para outros primaries).
O FAST SYNC do 12c permite uma agilidade maior do primary pois não precisa esperar que os standby redo logs retornem dizendo que a escrita foi completada nos discos. Resumindo, o primary retorna ao usuário após os standby logs informarem o recebimento da informação (mas não espera a escrita efetiva em disco).
Na FAST SYNC o que você ganha? Um throughput maior do primary, já que o retorno ao usuário será mais rápido e mesmo assim terá uma garantia que o standby recebeu a informação.
Existem outras funcionalidades interessantes no 12c como o realtime-cascade e preview de swithover. Acredito que farei uma nova séria sobre o DataGuard para o 12c, mas só depois da release R2, fique ligado.
MAA E ORACLE
Você deve ter notado que o MAA para a Oracle é estratégico, garantir que nenhum cliente perca dados é importante. De qualquer forma, esse é um tópico bem complexo e que muitos DBAs podem acabar nem tendo contato no seu dia a dia.
O intuito desta série que contou com 10 artigos foi demonstrar como usar e configurar o ambiente seguindo os preceitos do MAA. Em suma, servir como referência/passo a passo/guia e ainda assim cobrir pontos como Swicthover, Failover e afins.
Claro que ele não substitui o conhecimento prático do dia a dia, você também deve se manter atualizado. Recomendo fortemente acompanhar a página do grupo de MAA da Oracle onde encontrará informações sobre High Availability, MAA, apresentações específicas sobre MAA, best practices para diversos ambientes e versões (como Exadata) e pappers com novidades (aqui e aqui).
Espero que tenham aproveitado a série de artigos sobre MAA e acompanhem as novas (como a do Exadata).
Este artigo também está publicado em meu blog pessoal neste link.
