Verificar a Configuração

Quando a configuração do DR estiver concluída, valide imediatamente se a configuração está correta executando um switchover completo ou abrindo o site secundário para validação. A abertura do site secundário para validação não afetará o sistema em execução no principal.

Abrir o Secundário para Validação

Você pode validar o site stand-by sem executar um switchover completo convertendo o banco de dados stand-by no snapshot standby. Isso permite que os servidores SOA secundários sejam iniciados no site stand-by e verifique o sistema secundário. Qualquer alteração executada no banco de dados do site stand-by enquanto ele estiver no modo stand-by de snapshot será descartada assim que for convertido para stand-by físico novamente. Os dados principais não são afetados por validações de sites secundários.

Observação:

Esta operação deve ser feita com cuidado: se houver mensagens ou compostos pendentes no banco de dados quando ele for convertido em snapshot, os servidores SOA do site stand-by os processarão quando iniciarem. Verifique se não há ações pendentes no banco de dados principal ao converter em stand-by snapshot. Caso contrário, remova registros das tabelas SOA de runtime no banco de dados stand-by depois que ele for convertido em banco de dados stand-by snapshot e antes de iniciar os servidores SOA do site secundário. Consulte Removendo Registros das Tabelas de Runtime sem Eliminar as Tabelas para obter as etapas para validar o site stand-by sem executar um switchover.

1. Como usuário oracle, use o broker do Oracle Data Guard no host do bd principal e converta o secundário em um standby de snapshot.

   [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
   DGMGRL> convert database secondary_db_unqname to snapshot standby
   

   Use o comando show configuration para verificar se a conversão foi executada corretamente.
2. Verifique se não há ações pendentes no ambiente secundário.
   Se houver ações pendentes (transações, mensagens) no banco de dados principal quando o stand-by for convertido em snapshot, os servidores SOA secundários tentarão processá-los quando start.You puderem usar o script de truncamento SOA para remover os registros das tabelas de runtime SOA no banco de dados secundário para limpar os dados de runtime antes de iniciar os servidores secundários. Execute esta ação com CUIDADO; não trunque tabelas no banco de dados principal. Consulte Removendo Registros das Tabelas de Runtime sem Eliminar as Tabelas.
3. Se ainda não estiverem ativos, inicie os sistemas Oracle HTTP Server no site secundário.
4. Inicie o Servidor Admin no site secundário.
5. Inicie os servidores gerenciados secundários no site secundário.
   Use a Console WebLogic ou scripts para iniciar os servidores gerenciados secundários.
6. Validar o site secundário.

   Como esse não é um switchover e o site principal ainda está ativo, o nome do front-end virtual será resolvido para o endereço IP do balanceador de carga do site principal; portanto, qualquer acesso do browser será, por padrão, redirecionado para o site principal ativo.

   Para acessar diretamente os serviços SOA do site secundário, atualize o arquivo /etc/hosts em um cliente controlado (por exemplo, um laptop), defina o nome do front-end virtual para resolver o endereço IP do balanceador de carga front-end do site secundário e execute qualquer validação desse cliente.

   Observação:

   Verifique se o cliente usado para validações não acessa o sistema por meio de um proxy HTTP, porque o proxy HTTP pode continuar a resolver o nome front-end virtual com o endereço IP do balanceador de carga do site principal, independentemente do nome no /etc/hosts do cliente.

   Clientes não Linux podem exigir uma redefinição de seu cache DNS local antes que um navegador resolva o endereço IP usando a entrada personalizada do arquivo do host.

   Depois que o site secundário tiver sido validado, vá para a próxima etapa para revertê-lo para a atribuição standby.

   Observação:

   Pode levar algum tempo para validar o site secundário.
7. Interrompa os servidores gerenciados e os servidores de administração no site secundário.
   Use a Console secundária WebLogic para fazer shutdown dos servidores gerenciados e do servidor Admin no site secundário.
8. Como usuário oracle, use o broker do Oracle Data Guard no host do banco de dados principal e converta o secundário em standby físico novamente.
   Você precisará da senha do sistema e do nome exclusivo do banco de dados principal.

   [oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
       DGMGRL> convert database secondary_db_unqname to physical standby

   Use show configuration para verificar a conversão.
9. Reverta todos os arquivos /etc/hosts atualizados.
   Se você atualizou quaisquer arquivos /etc/hosts em um cliente para apontar para o site secundário para validações, reverta para que o nome do front-end virtual aponte para o endereço IP do front-end principal novamente.

Observação:

ORA-01403: nenhum dado encontrado erros ORA-06512

Ao validar o site secundário conforme descrito aqui (sem executar um switchover completo, ou seja, apenas abrir stand-by no modo stand-by de snapshot) "ORA-01403: nenhum dado encontrado ORA-06512" erros podem aparecer nos logs dos servidores SOA stand-by. Esses erros estão relacionados ao job de expurgação automática SOA. Esses erros surgem porque os jobs no banco de dados podem ter dependências de atribuição de bd (eles são definidos para serem ativados somente quando o banco de dados está na atribuição principal). Esse é um comportamento esperado e desejado que impede que os jobs sejam executados duas vezes (uma vez no principal e outra no stand-by). O job de expurgação automática SOA é definido com a atribuição principal; portanto, ele não é mostrado na view DBA_SCHEDULER_JOBS quando o banco de dados está no modo stand-by de snapshot. A database_role definida para cada job pode ser vista na view DBA_SCHEDULER_JOB_ROLE. Em resumo, esses erros podem ser ignorados desde que apareçam no sistema stand-by. O job do programador para expurgação automática SOA será executado no banco de dados se, e somente se, a instância alterar sua atribuição para PRIMARY.

Executar um Switchover

Um switchover é uma operação planejada na qual um administrador reverte as funções dos dois sites. Depois de um switchover, o sistema principal se torna secundário e o sistema secundário se torna principal. A execução de um switchover causará tempo de inatividade no site principal.

Antes de executar um switchover em uma configuração de DR Híbrida SOA, propague todas as alterações de configuração pendentes. Certifique-se de que não haja alterações replicadas para o site secundário pendente.

1. Desative qualquer replicação programada enquanto o switchover for executado, pois pode falhar e interferir na própria operação de switchover.
2. Interrompa os sistemas Oracle HTTP Server no site principal.
3. Interrompa os servidores no site principal.
   Use a Console do Servidor de Administração WebLogic ou scripts para interromper os servidores WebLogic no site principal.

   Observação:

   O servidor Admin no site principal pode permanecer ativo durante o switchover. No entanto, é recomendável interrompê-lo quando o site estiver na atribuição stand-by porque é esperado que a configuração do domínio no site stand-by seja substituída pela configuração principal durante o ciclo de vida. Se o servidor Admin estiver ativo enquanto isso acontecer, ele será executado com uma configuração desatualizada.
4. Alterne o nome do DNS front-end.

   Execute a operação de push de DNS necessária no servidor DNS que hospeda os nomes usados pelo sistema ou altere a resolução do host de arquivo em clientes para apontar o nome virtual de front-end do sistema para o IP público usado pelo Balanceador de Carga no site secundário.

   Para cenários em que o DNS é usado para a resolução de front-end externa (como DNS do OCI ou DNS comercial), você pode usar uma API para enviar a alteração. Para ver um exemplo que envia essa alteração em um DNS do OCI, vá para GitHub, por exemplo, scripts.

   Observe que o valor TTL da entrada de DNS afetará o RTO da alternância: se o TTL for alto (exemplo, 20 min), a alteração de DNS levará esse tempo para ser efetivo nos clientes. O uso de valores de TTL mais baixos fará com que isso seja mais rápido; no entanto, isso pode causar uma sobrecarga porque os clientes afetarão o DNS com mais frequência, em vez de usar nomes armazenados em cache. Uma boa abordagem é definir o TTL para um valor baixo temporariamente (por exemplo, 1 min), antes da alteração no DNS. Em seguida, execute a alteração e, depois que o procedimento de switchover for concluído, reverta o TTL para o respectivo valor original novamente.

5. Como usuário oracle, use o broker do Oracle Data Guard no host do banco de dados principal para executar o switchover do banco de dados.
   Você precisará da senha do sistema e do nome exclusivo do banco de dados principal.

   [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
   DGMGRL> switchover to secondary_db_unqname

6. Se ainda não estiverem ativos, inicie os sistemas Oracle HTTP Server no site secundário (novo principal).
7. Inicie o Servidor Admin no site secundário (novo principal) ou reinicie o servidor se ele já tiver sido iniciado.
   A inicialização do Servidor Admin permite alterações de configuração que foram replicadas enquanto este era um stand-by para entrar em vigor.
8. Inicie os servidores gerenciados secundários no site secundário (novo principal).
   Use a Console WebLogic ou scripts para iniciar os servidores gerenciados secundários.