Oracle Cloud: Disaster Recovery solução Oracle Data Guard ( Cloud-Cloud Deployment ) Parte II

Na primeira parte deste artigo configuramos um serviço de banco de dados (DBCS) na nuvem da Oracle com a funcionalidade do Oracle Data Guard habilitada, permitindo assim ampliar a disponibilidade do serviço. Nesta parte do artigo vamos mostrar os passos necessários para executar as operações de SWITCHOVER e FAILOVER & REINSTATE através do DBCS Console.

Executando uma operação de Switchover

A operação de SWITCHOVER realiza a mudança da atribuição do banco de dados (DATABASE ROLE) entre os recursos computacionais disponíveis no serviço. Assim, um recurso que está como PRIMÁRIO pode passar para STANDBY, e vice-versa. Note que no SWITCHOVER o banco de dados continua participando da configuração do Oracle Data Guard, apenas a atribuição muda, e como ela o sentido de sincronização do banco. O SWITCHOVER é tipicamente usado para reduzir o tempo de indisponibilidade durante uma interrupção programada, algumas razões para se fazer isto são: realizar uma atualização do sistema operacional ou da plataforma de banco de dados; realizar uma correção no hardware (Compute, Storage, Rede); modificar alguma configuração dos recursos de processamento, aumentando memória RAM ou OCPUs.

Passos para executar a operação de Switchover

1. Abra a console do Oracle Database Cloud Service.

   Figura 7: service console

2. Na lista de serviços, clique no nome do serviço de banco de dados que você deseja executar a operação de SWITCHOVER. A página Oracle Database Cloud Service Overview será mostrada.

   Figura 8: Service Overview

3. Para ter certeza que a página de Overview reflete a atribuição corrente de cada banco de dados, clique no icone Refresh Configuration.

   Figura 9: Refresh Configuration

4. A partir do menu  do recurso de computação desejado, selecione Switchover, e então confirme a ação.

   Figura 10: execute o switchover

5. O Deploy entra em status de manutenção no Oracle Database Cloud Service Console até que o SWITCHOVER seja completado.

   Figura 11: maintenance status

6. Atualize a página para ver o papel (atribuição) do banco de dados em cada recurso computacional disponível no serviço. A nova atribuição é mostrada na descrição do DATABASE ROLE.

   Figura 12: atribuicao do banco esta alteradao

Antes de continuar a leitura deste artigo, convidamos você a nos seguir e fazer parte de nossa rede. Para ser atualizado com o conteúdo semanal de artigos "Oracle Cloud", visite nosso Blog: Joel Pérez’s OTN Community Blog: https://community.oracle.com/blogs/Sir.DBaaSJoelPerez

Para ver a lista de artigos:

https://community.oracle.com/people/Sir.CloudDBaaSjoelperez/

content?customTheme=otn&filterID=contentstatus%5Bpublished%

5D~objecttype~objecttype%5Bblogpost%5D

Se você acessar o blog com sua conta OTN, pressionando o acesso "Follow", você será notificado sempre que um artigo for publicado.

Uma vez conectado com sua conta OTN e pressionando "Siga", você obterá isso:

Nossa média de publicação é dois artigos semanais sobre o tema "Oracle Cloud"

Agora vamos aos detalhes do artigo!!

Executando a operação de Failover manualmente

A operação de FAILOVER altera o papel do banco de dados de STANDBY para PRIMÁRIO. Isto pode ser iniciado em virtude de uma falha no servidor onde está rodando o serviço (PRIMÁRIO) que force a “quebra” da replicação entre os bancos que compõem a configuração do Data Guard. Um FAILOVER geralmente ocorre quando o administrador do ambiente julga que o tempo de recuperação do serviço de banco no banco PRIMÁRIO é inviável para a operação da aplicação ou negócio.

É importante saber que na arquitetura do Data Guard, se o banco PRIMÁRIO estiver configurado para operar em modo MAXIMUM PERFORMANCE ou MAXIMUM AVAILABILITY, então, dados ainda não replicados podem ser perdidos. Isto acontece por dois motivos básicos:

1. Nos dois modos indicados acima o Oracle Database pode postergar o envio das modificações realizadas no banco PRIMÁRIO. Ou seja, a transação no banco PRIMÁRIO pode ser concluída sem que a replicação seja realizada de forma síncrona com o banco STANDBY. No caso de FAILOVER, quaisquer modificações ainda não enviadas para o servidor STANDBY podem ser perdidas, especialmente quando é impossível acessar o servidor PRIMÁRIO de qualquer forma para se obter as alterações ainda não enviadas para o servidor STANDBY.
2. Durante a transição iniciada pelo FAILOVER o Oracle Database tenta resolver eventual LAG de replicação, seja tentando acessar os dados necessários em outros locais, seja tentando aplicar as modificações que já chegaram no servidor STANDBY mas que ainda não estão efetivamente aplicadas no banco de dados (que ainda está em modo STANDBY). Haverá perda de dados se houver alteração de dados realizada no banco PRIMÁRIO que não estiver disponível para sincronismo no banco STANDBY no momento de “quebra” da configuração do Data Guard.

A “quebra” de uma configuração do Data Guard significa que o banco STANDY passa a ser o PRIMÁRIO, e o antigo banco PRIMÁRIO (que deveria ser o novo STANDBY no caso de um SWITCHOVER) não pode mais receber replicações. Isto acontece devido à perda do controle de sincronismo entre os dois bancos.

Importante: O modo MAXIMUM PROTECTION garante que toda transação realizada no banco PRIMÁRIO só será concluída quando houver a garantia de que banco STANDBY recebeu a replicação da transação e será capaz de reconstruí-la em uma operação de FAILOVER. Este modo força a realização de uma replicação síncrona.

Se a funcionalidade do FLASHBACK DATABASE estiver habilitada no banco PRIMÁRIO antes da falha ocorrer, será possível restabelecer a configuração do Data Guard de forma mais rápida.

Passos para executar a operação de Failover

1. Abra o Oracle Database Cloud Service console.

   Figura 13: service console

2. Para garantir que a página de Service Overview reflita a atribuição corrente de cada recurso, clique no icone Refresh Configuration.

   Figura 15: Refresh Configuration

3. A partir do menu  do recurso que deseja iniciar o FAILOVER, selecione Failover, e então confirme a ação.

   Figura 16: execute o failover

4. O serviço entrará em modo de Maintenance no Oracle Database Cloud Service console até que a operação de FAILOVER esteja completada.

   Figure 17: maintenance status

5. Atualize a página Service Overview ocasionalmente. A atribuição do banco de dados será atualizada para refletir o papel corrente. Note que o antigo banco PRIMÁRIO agora marca como DATABASE ROLE o estado REINSTATE.

   Figura 18: Failover completado

Restabelecendo a funcionalidade do Data Guard

Depois de corrigir o problema que causou a perda da configuração do Data Guard, provavelmente você desejará restabelecer a funcionalidade para voltar a ter maior disponibilidade do serviço de banco de dados. Você poderá usar a opção de REINSTATE do Data Guard Broker para reconfigurar o ambiente e reiniciar o processo de replicação do banco PRIMÁRIO para o banco STANDBY.

Passos para restabelecer o Data Guard

1. Abra Oracle Database Cloud Service console e clique no serviço que deseja.

   Figura 19: service console

2. Na tela SERVICE OVERVIEW você pode clicar no ícone Refresh Configuration para atualizar as informações de atribuição corrente dos recursos deste serviço. Observe que um dos recursos está com o DATABASE ROLE com o status de REINSTATE.

   Figura 21: Refresh Configuration

3. A partir do menu  do serviço que precisa ser restabelecido, selecione Reinstate, e então confirme a ação.

   Figura 22: execute o reinstate

4. O serviço entrará em modo de Maintenance no Oracle Database Cloud Service console ate que o failover esteja completo.

   Figura 23: maintenance status

5. Atualize a pagina ocasionalmente. A atribuição indicada no Database Role será alterada para STANDBY.

   Figura 24: Reinstate completado

Na última parte deste artigo veremos os passos necessários para executar estas mesmas operações de SWITCHOVER, FAILOVER e REINSTATE através do utilitário dbaascli.

Conclusão

O Database Cloud Service (DBCS) da nuvem da Oracle permite realizar operações de SWITCHOVER, FAILOVER e REINSTATE da configuração do Data Guard de forma totalmente automatizada. Estas são são realizadas com um simple clique no menu de configuração dos recursos do seu serviço.

Outros artigos nesta série:

Disaster Recovery solução Oracle Data Guard ( Cloud-Cloud Deployment ) Parte I

Disaster Recovery solução Oracle Data Guard ( Cloud-Cloud Deployment ) Parte III

Skant Gupta é um Oracle Certified Cloud Professional 12c, OCE RAC 11g and Oracle Certified Professional (10g, 11g, 12c). Atualmente trabalha na Vodafone no Reino Unido e trabalhava anteriormente como DBA Sênior na Etisalat em Dubai. Tem 6 anos de experiência em diferentes tecnologias Oracle, focando principalmente em banco de dados, nuvem, soluções de alta disponibilidade, WebLogic e GoldenGate. Elejá esteve presente em vários grupos de usuários Oracle ao redor do mundo e mais recentemente nos EUA, Emirados Árabes e Índia.

Joel Pérez é um DBA (Oracle ACE Director, Maximum Availability OCM, OCM Cloud Admin. & OCM12c/11g) Especialista com mais de 17 anos de experiência real no mundo da tecnologia Oracle, especializada na concepção e implementação de soluções: Nuvem, alta disponibilida de, recuperação de desastres, Upgrades, replicação e toda a área relacionada com bancos de dados Oracle. Joel serve como "Senior Database Cloud Architect" para en.Enmotech.com Yunhe ENMO (Beijing) Technology Co. Ltd. Beijing, China.

Andre Rocha é um DBA (OCM Cloud Admin. & OCM11g) Instrutor oracle desde 2002 para tecnologias de banco de dados cloud e on-premise, especialista com mais de 15 anos de experiência real no mundo da tecnologia Oracle, realizando projetos em: Oracle VM, Exadata, Data Guard, Performance, RAC, Nuvem, Oracle Linux, Apex e etc. Possui mais de 50 certificações sendo algumas: OCP Solaris, OCP Oracle 10g,11g,12c, Golden Gate, Oracle Rac 11 e 12c.

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.