Zero Data Loss Recovery Appliance (ZDLRA)

Por Fernando Simon
Postado em Abril 2016

Revisado por Marcelo Pivovar - Solution Architect

É interessante observar como a evolução tecnológica pode acontecer em áreas que parecem já ter alcançado o seu máximo, e é exatamente nesta evolução que está o Zero Data Loss Recovery Appliance (ZDLRA). Desde o seu lançamento na Oracle Open World de 2014 ele vem se destacando e mudando a forma como o backup em banco de dados Oracle é realizada.

Isso ocorre principalmente pelas tecnologias empregadas e pelas novas funcionalidades presentes. O ZDLRA ataca em três frentes: Continuous Data Protection (CDP), Recovery Point Objective (RPO) e Recovery Time Objective (RTO). Basicamente ele reduz os três a zero, você não terá perda de transações (CDP e RTO iguais a 0) e garantia de restauração e recuperação do banco de dados (RPO igual a zero).

Se observamos abaixo vemos a evolução das metodologias de backup, saindo desde backup em fitas, passando por deduplicação e appliances de backup. Tudo isso está presente no ZDLRA (e muito mais): é um Oracle Engineering System baseado em hardware Exadata (o que lhe confere alta disponibilidade e redundância a falhas), tem comunicação com tape libraries, backup via rede e deduplicação de dados (na origem).

Mas como tudo isso se encaixa no ZDLRA e o que ele provê? Se você pensar nas limitações atuais de backups de bancos de dados nós temos:

  • Backups Lentos: Transmitir um backup full do banco pode ser proibitivo.
  • Impacto no ambiente: backup concorre com o workload de produção (por I/O e rede)
  • Constante monitoramento: Como a ferramenta de backup é desacoplada do banco (ela não entende conteúdo do backup) é necessário políticas de testes. O backup está feito, mas é possível recuperar o banco?
  • Deduplicação: O backup tradicional não entende o conteúdo bloco enviado e uma simples modificação (como variáveis de controle interno do bloco do rman) impede comparação (mesmo ele sendo idêntico internamente).
  • Ponto de restauração: Somente é possível restaurar ao momento do último backup realizado.

Para tentar resolver estes problemas muitas vezes temos metodologias complexas de backup com mesclas de backup full, incrementais e backups de archivelogs redundantes entre outras. Mas isso tudo é um círculo vicioso, a complexidade irá aumentar e consequentemente criar muitos pontos de falhas que precisam ser constantemente verificados.

E como o ZDLRA resolve isso, quais funcionalidades ele traz?

Delta Push e Delta Store
A primeira delas é o que chamamos de Delta Push, onde os backups incrementais enviados pelo rman são interpretados e armazenados. Ele é o backup incremental padrão do rman enviado ao ZDLRA.

O delta push é armazenado dentro do ZDLRA no Delta Store. É o principal pilar do ZDLRA, é ele que tem a inteligência que converte e sumariza backups incrementais do rman em backup full chamados de virtual full backups.

Virtual full backups é uma ideia simples, a partir de um backup nível zero inicial os consequentes backups incrementais níveis 1 (cumulativos ou não) são utilizados para criar um novo backup full (virtual). Assim o rman do banco que fez um backup vê um backup nível zero no catálogo logo após o incremental ser realizado. Abaixo um resumo gráfico de como isso ocorre

Na a esquerda, no Day 0 é realizado um backup full nível zero. Todos os blocos enviados pelo rman são catalogados no delta store. No Day 1 é realizado um backup incremental nível 1 do banco de dados e somente os blocos modificados são enviados. E assim consequentemente para todos os incrementais consequentes.

Na direita, é o que ocorre no delta store. Após receber o backup incremental do Day 1 o ZDLRA cria um backup nível zero virtual e disponibiliza para o rman (através do catalogo). Quando o backup do Day 2 for realizado o rman, com base no último backup nível zero (o virtual do Day 1) que ele tem no catálogo (para o rman não existe diferença entre backup virtual ou não), faz um novo incremental e envia ao ZDLRA e com base nesse incremental cria um novo virtual full backup e disponibiliza ao catálogo. Esse processo acontece para todos os backups incrementais.

O ZDLRA é o único que consegue entender o que o rman envia através do delta push. Pense em um ambiente tradicional de backup com qualquer outra ferramenta, elas recebem um bloco para armazenar mas não conhecem o conteúdo do bloco enviado. Mas o ZDLRA sim, ele consegue ver e entender o bloco do banco de dados que está dentro do que foi enviado pelo RMAN (que é um bloco totalmente diferente), ele identifica para qual datafile pertencente e aglutina ele com os que já estão armazenados no delta store. Nenhuma outra ferramenta consegue (ou irá conseguir) fazer isso. Pense que blocos do rman são como livros, ferramentas tradicionais conseguem ler só a capa, o ZDLRA sabe ler o conteúdo deste livro e sabe o que cada página significa.

Incremental Forever e Validação de Backup
Observe que existe a necessidade de realizar somente um único backup incremental nível zero no rman (o backup inicial) e depois somente backups incrementais. Como virtual full backups são disponibilizados no catálogo após o backup incremental a transmissão de dados fica reduzida. Somente os blocos modificados são enviados e assim para ter um backup full o tempo deixa de ser em horas ou até dias para poucos minutos (que é o tempo do backup incremental). Perceba que isso leva a uma redução drástica do uso de rede e da janela de backup, tudo será resumido ao tempo e tamanho do backup incremental

Some a isso a ideia que você está deduplicando na origem, pois somente dados novos são enviados ao ZDLRA. E mesmo assim estes dados novos são compreendidos, analisados e catalogados para criar uma imagem completa e integra do seu datafile.

Uma funcionalidade interessante decorrente da capacidade do ZDLRA entender os blocos enviados pelo rman é a validação do backup. O ZDLRA valida automaticamente seu backup quanto a erros de corrupção, os blocos enviados e aqueles que estão contidos neste são validados quanto a corrupções. Assim você não precisa mais realizar restore periódicos do seu backup para saber se o conteúdo dele está OK.

Real-Time Redo Transport
Através do Real-Time Redo o ZDLRA consegue garantir que nenhuma transação contida dos redologs será perdida, quando habilitado para o banco de dados o ZDLRA torna-se um destino remoto de redo. Basicamente quando um bloco redo é gerado no buffer de memória no banco de dados ele é copiado para a área de recovery do ZDLRA e quando ocorre um switch de redolog no banco de dados o ZDLRA converte os blocos de redo recebidos em um archivelog. Assim a garantia é de um RPO entre 0 e 1 segundos de diferença. Isso funciona através da mesma tecnologia empregada no DataGuard (sem a necessidade de ter um).

Replicação
O ZDLRA suporta nativamente a replicação de seus dados. Você pode ter mais de um e replicar entre eles o backup para ter maior segurança. Existem diversos modos de replicação:

Assim, você pode ter segurança completa, os backups estão em locais separados e completamente integrados. Além disso, o catálogo do rman do banco de dados vê todos os backups, independentemente do local que estejam.

Monitoramento
O ZDLRA é completamente integrado ao Enterprise Manager ou Cloud Control 12c (ou 13), assim através de um único local os DBA’s podem acompanhar tudo, do banco ao backup. Além disso, todo o monitoramento de espaço, taxa de deduplicação, replicação e cópias para fita também estão disponíveis na mesma ferramenta. Assim você não precisa treinar a equipes de DBA’s ou ter uma equipe dedicada para a ferramenta de backup tradicional.

Solução com Inteligência
Como você pode ver elas são inúmeras, através do ZDLRA problemas críticos de backup são resolvidos, não com hardware mas com inteligência/software:

  • Delta push/delta store/incremental forever: Reduzem a janela de backup de horas ou dias para minutos. Você pode ter 30 full backups diários, mas ocupando somente o tamanho de um único full + incrementais.
  • Deduplicação: Deixa de ser importante, pois seu backup sempre transmitirá somente o necessário. E isso ocorre na origem!
  • Lentidão nos backups: Tempos de restore também são reduzidos, você pode escolher qualquer dia dentro da janela de retenção da política de backup e terá um full disponível. Como as redes do ZDLRA são de 10Gbps (ou Infiniband) o throughput de backup e restore é infinitamente maior.
  • Integração, Monitoramento e Segurança: A integração é completa com o banco de dados Oracle. Não existe a necessidade de treinar equipes em ferramentas de backup. Ele é 100% compatível com rman (na realidade é a única forma de fazer backup) e com Enterprise Manager. Os backups são validados automaticamente pelo ZDLRA aumentando a segurança.

Utilizando inteligência e software a Oracle revolucionou a forma de realizar backups em bancos de dados sem precisar trocar o confiável rman.

Você pode baixar e ler este documento sobre case de ZDLRA no mundo real.


Fernando Simon é DBA do Tribunal de Justiça de Santa Catarina. Trabalha como DBA a diversos anos, desde o Oracle 9i até o Oracle 12c. Tem experiência prática com Oracle Exadata (do V2 ao X5) e soluções que dependem de High Availability como Zero Data Loss, Data Guard, Oracle RAC e replicações diversas. Também atua como palestrante em eventos Oracle no Brasil. Blog: http://www.fernandosimon.com/blog

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.