DISASTER RECOVERY: GARANTINDO A DISPONIBILIDADE DE DADOS – Parte 2

Neste post vamos dar continuidade ao post anterior “Disaster Recovery: Garantindo a disponibilidade de dados”.

Aqui iremos abordar a ferramenta Oracle Data Guard que tem como objetivo, garantir alta disponibilidade, proteção de dados e recuperação de desastres para os dados de uma corporação.

Os bancos de dados principal e em standby conectam-se por meio do protocolo TCP/IP usando o Oracle Net Services não havendo restrições em relação à localização dos bancos de dados desde que haja comunicação entre eles.

O Data Guard sincroniza automaticamente o banco de dados principal e todos os seus bancos de dados em standby, transmitindo os dados de recuperação (informação usada pela Oracle para recuperar transações) do banco de dados principal e aplicando-os no banco de dados em standby. (RICH, 2012).

A Figura a seguir, ilustra uma visão geral da arquitetura de um Data Guard, que consiste em um banco de dados de produção, chamado de “primário” (Primary Site) e um ambiente de recuperação, chamado de “standby” (active Standby Site), sendo que a estrutura de um Data Guard, permite ter até 30 bancos em dados em standby..

Figura 1_Estrutura funcional de um Data Guard

Estrutura funcional de um Data Guard (Fonte: Portal Oracle, 2009).

Como pode ser observada nesta ilustração, o Data Guard sincroniza automaticamente o banco de dados principal com o banco de dados em standby, transmitindo os dados de recuperação do banco de dados principal e aplicando-os no banco de dados em standby tanto de forma síncrona como assíncrona, onde são gravados em um arquivo de redo log de standby.

Serviços de transporte do Oracle Data Guard

A medida que usuários confirmam as transações no banco de dados, o Oracle gera registros de recuperação e os grava em um arquivo de redo log local. Os serviços de transporte do Data Guard transferem as alterações do redo log local do banco de dados primário para o banco de dados em standby, tanto de maneira síncrona, como assíncrona.

Os dados de recuperação podem ser transmitidos em um formato comprimido para reduzir os requisitos de largura de banda através da “Opção de Compressão Avançada Oracle” (Oracle Advanced Compression).

O transporte de dados de recuperação síncrono (SYNC) é uma configuração que permite ao banco de dados primário aguardar pela confirmação do banco de dados em standby para que o redo log seja descarregado em disco antes de efetivamente realizar a operação de “commit” sobre o banco. Essa operação garante proteção contra a perda de dados. A performance no banco de dados primário está ligada diretamente ao tempo de envio do redo log para o banco de dados em standby.

O transporte assíncrono dos dados de recuperação (ASYNC) evita problemas de performance no banco de dados primário, uma vez que não aguarda resposta do banco de dados em standby sobre o recebimento e aplicação do redo log.

Esta configuração vem acompanhada por uma pequena possibilidade de perda de dados no banco de dados standby, uma vez que não existem garantias de que o redo log foi aplicado.

No próximo post, estarei falando sobre os serviços de aplicação de alteração do Oracle Data Guard e sobre a resolução automática de falhas.

Acompanhe a Matera Systems também nas redes sociais!

#SomosTodosMATERA

Por ELISANGELA SILVA MORAIS

Postado em: 17 de março de 2016

Confira outros artigos do nosso blog

[Webinar] Profile de aplicações Java com Oracle Mission Control e Flight Recorder

24 de julho de 2017

Danival Calegari

Criando Mocks de serviços REST com SoapUI

27 de junho de 2017

Monise Costa

Three laws that enable agile software development

09 de março de 2017

Celso Gonçalves Junior

Medindo performance de uma API REST

21 de fevereiro de 2017

Monise Costa

Deixe seu comentário