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

Por Skant Gupta, Joel Pérez & Andre Rocha
Publicado en noviembre 2017

Na segunda parte deste artigo vimos alguns conhecimentos técnicos importantes sobre o Oracle Data Guard e sua integração com a orquestração da nuvem da Oracle. Usamos a automação disponível no Console Web para realizarmos operações de SWITCHOVER, FAILOVER e REINSTATE.

Nesta terceira parte do artigo iremos executar as mesmas operações de SWITCHOVER, FAILOVER e REINSTATE, só que agora utilizando a ferramenta de comando dbaascli.

Executando a operação de Switchover usando o dbasscli

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 usando o utilitário dbaascli

Você pode usar o subcomando dataguard switch over do utilitário dbaascli para executar o SWITCHOVER para o banco STANDBY da sua configuração do Oracle Data Guard.

Para executar o SWITCHOVER use o subcomando dataguard switch over:

  1. Conecte-se ao recurso computacional que está com a atribuição de banco PRIMÁRIO em seu serviço de banco de dados usando o usuário opc .
    
    
    
    Using username "opc".
            Authenticating with public key "rsa-key-20170425"
            Passphrase for key "rsa-key-20170425":
            [opc@DATAGUARD-dg01 ~]$    
            
    
  2. Inicie uma sessão no prompt de comando e utilize o sudo para logar como usuário oracle.
    
    
    
      [opc@DATAGUARD-dg01 ~]$ sudo su - oracle
            [oracle@DATAGUARD-dg01 ~]$
    
    
  3. Inicialize o SWITCHOVER para que o banco STANDBY que está rodando o outro recurso computacional deste serviço DBCS ser torne o novo banco PRIMÁRIO.
    
    
    
      [oracle@DATAGUARD-dg01 ~]$ dbaascli dataguard switch over
            DBAAS CLI version 1.0.0
            Executing command dataguard switch over
            Performing switch over NOW, please wait...
            New primary database "ORCL_02" is opening...
            Operation requires startup of instance "ORCL" on database "ORCL_01"
            Starting instance "ORCL"...
            ORACLE instance started.
            Database mounted.
            Switchover succeeded, new primary is "ORCL_02"
            SUCCESS : Switchover to Standby operation completed successfully
            [oracle@DATAGUARD-dg01 ~]    
    
    
  4. Reinicie o ORDS server
    
    
    [root@DATAGUARD-dg01 ~]# /etc/init.d/ords restart
            INFO: Stopping Oracle REST Data Services...
            INFO: Oracle REST Data Services stopped
            INFO: Starting Oracle REST Data Services...
            INFO: Oracle REST Data Services bound to ports 8080,8181 854
            INFO: Oracle REST Data Services started with PID 854
            [root@DATAGUARD-dg01 ~]#
    
    
  5. Verifique as atribuições correntes dos recursos do seu DBCS.
    
    
    
     [oracle@DATAGUARD-dg01 ~]$ dbaascli dataguard status
            DBAAS CLI version 1.0.0
            Executing command dataguard status
            SUCCESS : Dataguard is up and running
            DETAILS:
            Configuration - fsc
              Protection Mode: MaxPerformance
              Databases:
                ORCL_02 - Primary database
                ORCL_01 - Physical standby database
              Properties:
                FastStartFailoverThreshold      = '30'
                OperationTimeout                = '120'
                FastStartFailoverLagLimit       = '30'
                CommunicationTimeout            = '180'
                ObserverReconnect               = '0'
                FastStartFailoverAutoReinstate  = 'TRUE'
                FastStartFailoverPmyShutdown    = 'TRUE'
                BystandersFollowRoleChange      = 'ALL'
                ObserverOverride                = 'FALSE'
                ExternalDestination1            = ''
                ExternalDestination2            = ''
                PrimaryLostWriteAction          = 'CONTINUE'
            Fast-Start Failover: DISABLED
            Configuration Status:
            SUCCESS
            [oracle@DATAGUARD-dg01 ~]$    
    
    
    

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.

08

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

09

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

Agora vamos continuar o 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 necessário em virtude de uma falha no servidor onde está rodando o serviço (PRIMÁRIO), forçando 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 será muito longo e a indisponibilidade gerada será 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, dados ainda não replicados do banco PRIMÁRIO poderão 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, uma 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 quando é impossível acessar o servidor PRIMÁRIO para se obter as alterações ainda não enviadas para o servidor STANDBY.
  2. Durante a transição iniciada pela operação de FAILOVER o Oracle Database tentará resolver eventual LAG de replicação, seja tentando acessar os dados necessários em outros recursos computacionais disponível na configuração do Data Guard, seja tentando aplicar as modificações que já chegaram ao 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 conseguiram ser aplicada no banco STANDBY no momento da “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 de dados. 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 utilizando o comando dbaascli

Você pode usar o subcomando dataguard failover do utilitário dbaascli para executar o FAILOVER manual.

Para executar o FAILOVER utilizando o subcomando dataguard failover :

1. Conecte-se no recurso computacional que está com o DATABASE ROLE no modo PRIMÁRIO com o usuário opc .




Using username "opc".
Authenticating with public key "rsa-key-20170425"
Passphrase for key "rsa-key-20170425":
[opc@DATAGUARD-dg02 ~]$
Code 13  


2. Inicie a sessão no prompt de comando e utilize o sudo para ir para o usuário oracle.




[opc@DATAGUARD-dg02 ~]$ sudo su - oracle
[oracle@DATAGUARD-dg02 ~]$
Code 14  


3. Inicie o FAILOVER para que o banco STANDBY se torne o banco PRIMÁRIO.




[oracle@DATAGUARD-dg02 ~]$ dbaascli dataguard failover
DBAAS CLI version 1.0.0
Executing command dataguard failover
Performing failover NOW, please wait...
Failover succeeded, new primary is "ORCL_01"
SUCCESS : Successfully failed over to Standby
[oracle@DATAGUARD-dg02 ~]$
Code 15   

4. Reinicie o ORDS S erver



[root@DATAGUARD-dg02 ~]# /etc/init.d/ords restart
INFO: Stopping Oracle REST Data Services...
INFO: Oracle REST Data Services stopped
INFO: Starting Oracle REST Data Services...
INFO: Oracle REST Data Services bound to ports 8080,8181 24177
INFO: Oracle REST Data Services started with PID 24177
[root@DATAGUARD-dg02 ~]#
Code 16 

5. Verifique o status do Data Guard. Note a mensagem ORA-16661




[oracle@DATAGUARD-dg02 ~]$ dbaascli dataguard status
DBAAS CLI version 1.0.0
Executing command dataguard status
SUCCESS : Dataguard is up and running
DETAILS:
Configuration - fsc
  Protection Mode: MaxPerformance
  Databases:
    ORCL_01 - Primary database
    ORCL_02 - Physical standby database (disabled)
      ORA-16661: the standby database needs to be reinstated
  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '120'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    ObserverReconnect               = '0'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
    ObserverOverride                = 'FALSE'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    PrimaryLostWriteAction          = 'CONTINUE'
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
[oracle@DATAGUARD-dg02 ~]$
Code 17


Restabelecendo a funcionalidade do Data Guard

Depois de corrigir o problema que gerou a necessidade de perda da configuração do Data Guard (impossibilitando a replicação de dados), 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 restabeceler o Data Guard usando o utilitário dbaascli

Você pode utilizar o subcomando dataguard reinstate do utilitário dbaascli para restabelecer a replicação do banco PRIMÁRIO para o banco STANDBY.

Para identificar que a configuração do Data Guard precisa ser restabelecida (reabilitando a replicação) use o subcomando dataguard status. Verifique o Status da Configuração do Oracle Data Guard. A mensagem ORA-16661: the standby database needs to be reinstated indica que é necessário restabelecer a configuração.

Para restabelecer a sincronização entre os bancos PRIMÁRIO e STANDBY use o subcomando dataguard reinstate. Veja:

1. Conecte-se a um dos servidores da configuração do Oracle Data Guard como usuário oracle .




Using username "opc".
Authenticating with public key "rsa-key-20170425"
Passphrase for key "rsa-key-20170425":
[opc@DATAGUARD-dg02 ~]$ sudo su - oracle
[oracle@DATAGUARD-dg02 ~]$
Code 18 

2. Inicie o restabelecimento da configuração do Data Guard para ajustar o banco STANDBY.




[oracle@DATAGUARD-dg02 ~]$ dbaascli dataguard reinstate
DBAAS CLI version 1.0.0
Executing command dataguard reinstate
Successfully reinstated dataguard instances
Detail : Successfully reinstated database : ORCL_02
oracle@DATAGUARD-dg02 ~]$
Code 19  

3. Verifique o status do banco STANDBY que foi restabelecido.




[oracle@DATAGUARD-dg02 ~]$ dbaascli dataguard status
DBAAS CLI version 1.0.0
Executing command dataguard status
SUCCESS : Dataguard is up and running

DETAILS:

Configuration - fsc

  Protection Mode: MaxPerformance
  Databases:
    ORCL_01 - Primary database
    ORCL_02 - Physical standby database

  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '120'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    ObserverReconnect               = '0'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
    ObserverOverride                = 'FALSE'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    PrimaryLostWriteAction          = 'CONTINUE'

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

[oracle@DATAGUARD-dg02 ~]$
Code 20    


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 operações podem ser realizadas com a execução de simples comandos do utilitário dbaascli.

Esperamos que este artigo tenha sido útil. Convidamos você a ler nossas próximas publicações com foco na nuvem da Oracle.

Até a próxima!

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 II

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.