Saiba mais sobre a Configuração de um Banco de Dados Standby para Recuperação de Desastres

O Oracle Data Guard garante alta disponibilidade, proteção de dados e recuperação de desastre para dados empresariais que residem em um Oracle Database. O Oracle Data Guard fornece um conjunto abrangente de serviços que cria, mantém, gerencia e monitora um ou mais bancos de dados standby para permitir que os bancos de dados Oracle de produção sobrevivam a desastres e danos aos dados.

O Oracle Data Guard mantém esses bancos de dados standby como cópias do banco de dados de produção. Se o banco de dados de produção ficar indisponível por causa de uma interrupção planejada ou não planejada, o Oracle Data Guard poderá alternar qualquer banco de dados standby para a atribuição de produção, minimizando o tempo de inatividade associado à interrupção.

Arquitetura

Esta arquitetura mostra uma configuração do Oracle Data Guard com um banco de dados principal que transmite dados de redo para um banco de dados stand-by. O banco de dados standby está localizado remotamente do banco de dados principal para operações de backup e recuperação de desastres.

Veja a seguir a descrição da ilustração dataguard-dr-db.png
Descrição da ilustração dataguard-dr-db.png

dataguard-dr_db-oracle.zip

O Oracle Data Guard usa Serviços de Transporte de Redo e Serviços de Aplicação para gerenciar a transmissão de dados de redo, a aplicação de dados de redo e as alterações nas atribuições do banco de dados.

Essa arquitetura suporta os seguintes componentes do Oracle Data Guard:

  • Serviços de Redo Transport

    Os serviços de transporte de redo controlam a transferência automatizada de dados de redo do banco de dados de produção para um ou mais destinos de arquivamento.

    Os serviços de transporte de redo executam as seguintes tarefas:

    • Transmita dados de redo do sistema principal para os sistemas stand-by na configuração.
    • Gerencie o processo de resolver quaisquer lacunas nos arquivos de redo log arquivados devido a uma falha de rede.
    • Detecte automaticamente arquivos de redo log arquivados ausentes ou corrompidos em um sistema standby e recupere automaticamente os arquivos de redo log arquivados de substituição do banco de dados principal ou de outro banco de dados standby.
  • Aplicar Serviços

    Os serviços de aplicação aplicam automaticamente os dados de redo no banco de dados standby para manter a consistência com o banco de dados principal.

    Os dados de redo são transmitidos do banco de dados principal e gravados no redo log stand-by no banco de dados stand-by. Os dados de redo são aplicados diretamente dos arquivos de redo log stand-by, pois eles são preenchidos usando a aplicação em tempo real. A aplicação de serviços também permite acesso somente para leitura aos dados.

  • Transições de Funções
    Usando o Oracle Data Guard, você pode alterar a atribuição de um banco de dados standby para um banco de dados principal ou de um banco de dados principal para um banco de dados standby usando uma operação de switchover ou failover. O Oracle Data Guard simplifica as transições de atribuição e automatiza failovers.
    • Um switchover é um estorno de atribuição entre o banco de dados principal e um de seus bancos de dados standby. Um switchover garante que não haja perda de dados. Isso normalmente é feito para manutenção planejada do sistema principal. Durante um switchover, o banco de dados principal faz a transição para uma atribuição standby, e o banco de dados standby faz a transição para a atribuição principal.
    • Um failover ocorre quando o banco de dados principal está indisponível. O failover só é executado no caso de uma falha do banco de dados principal, e o failover resulta em uma transição de um banco de dados standby para a atribuição principal. O administrador do banco de dados pode configurar o Oracle Data Guard para garantir que não haja perda de dados.

Várias etapas manuais estão envolvidas na configuração do Oracle Data Guard, incluindo, entre outras, o seguinte:

  • Prepare o banco de dados principal com os parâmetros recomendados
  • Preparar os aliases TNS nos ambientes principal e standby
  • Criar o banco de dados standby físico como duplicação do banco de dados principal
  • Configurar o Data Guard

Essas etapas manuais são amplamente documentadas em vários documentos Oracle. Este playbook fornece um conjunto de scripts que você pode usar para automatizar a maioria dessas ações. Esses scripts ajudam a configurar o Oracle Data Guard configurando um banco de dados standby para um banco de dados principal existente. Os scripts usam o recurso restore from service Oracle Recovery Manager (RMAN) e o Oracle Data Guard Broker.

Antes de Começar

Antes de configurar o Oracle Data Guard usando os scripts fornecidos neste documento, revise as seguintes suposições e requisitos:

  • O banco de dados principal já existe.

  • Os nós stand-by já existem, com ou sem um banco de dados existente.

    Observação:

    Se já houver um banco de dados no local stand-by, os scripts o excluirão antes de recriar o stand-by.
  • Há uma conectividade mútua entre o principal e o standby usando a porta de listener do banco de dados.

    • Para bancos de dados de instância única, deve haver uma conexão bidirecional entre o host de banco de dados principal e o IP e a porta do listener do banco de dados standby.
    • Para bancos de dados Oracle Real Application Clusters (Oracle RAC), deve haver uma conexão bidirecional entre os hosts db principais e a varredura do banco de dados stand-by e IPs e portas VIPs.

    Os scripts executam verificações de conectividade, mas você pode usar o comando nc -vw 5 -z IP PORT para verificar a conectividade remota.

  • O Oracle Automatic Storage Management (Oracle ASM) é usado para arquivos de dados, arquivos de controle, redo logs on-line e redo logs de arquivamento.

    • Para bancos de dados de instância única, o arquivo de senha e o spfile podem estar localizados em sistemas de arquivos regulares ou no Oracle ASM.
    • Para bancos de dados do Oracle RAC, o arquivo de senha e o spfile devem estar localizados no Oracle ASM.
  • Os bancos de dados principal e standby são gerenciados pelo Oracle Clusterware (o Oracle Grid Infrastructure deve ser instalado, pois as topologias simples e do Oracle RAC usam srvctl).
  • Como os Arquivos Gerenciados Oracle são usados, os parâmetros de banco de dados db_create_file_dest, db_create_online_log_dest_1 e db_recovery_file_dest já devem estar definidos no banco de dados principal com o local apropriado do grupo de discos Oracle ASM (como +DATA ou +RECO).
  • O proprietário do software RDBMS (sistema de gerenciamento de banco de dados relacional) (por exemplo, usuário oracle) define as variáveis de ambiente Oracle necessárias (ORACLE_HOME, LD_LIBRARY_PATH, PATH, ORACLE_UNQNAME e ORACLE_SID) em seu perfil.
  • Presume-se que uma topologia simétrica seja usada (ou seja, se o principal for um único BD, o standby será um único BD; se o principal for um banco de dados Oracle RAC, o standby será também um banco de dados Oracle RAC).
  • Se os bancos de dados forem Oracle RAC, supõe-se que cada Oracle RAC tenha 2 nós.
  • Os scripts são válidos para configurar um banco de dados stand-by para um banco de dados principal que ainda não tem um banco de dados stand-by.
  • Os scripts também são válidos para adicionar um novo banco de dados stand-by adicional a um Oracle Data Guard existente. Para este cenário, você deve usar a propriedade ADDITIONAL_STANDBY=YES no arquivo de propriedades. Nesse caso, o novo standby é adicionado à configuração existente do Data Guard Broker.

Sobre os Recursos de Script

Estes são os recursos dos scripts:

  • Os scripts são idempotentes: eles podem ser reexecutados em caso de erros.
  • Os nomes de usuário do sistema operacional (como oracle e grid) e as pastas (Database home e Grid home) são configuráveis.
  • Os usuários do Oracle e do Grid OS podem ser o mesmo usuário ou usuários diferentes.
  • TDE (Transparent Data Encryption) para os arquivos de banco de dados é opcional: os scripts são válidos para ambos os casos (TDE e nenhum TDE).

    Observação:

    uma configuração simétrica será executada: se o banco de dados principal usar TDE, o banco de dados standby será configurado com TDE; se o banco de dados principal não usar TDE, o banco de dados standby não usará TDE.
  • O Oracle Home Somente para Leitura (ROOH) é suportado. Os scripts são preparados para funcionar automaticamente em ambientes com ROOH e com Oracle homes "tradicionais".
  • Os scripts são válidos tanto para ambientes do Oracle RAC quanto para ambientes de instância única (em uma topologia simétrica).
  • Os scripts são validados nas versões 12c (12.2), 18c, 19c e 21c RDBMS.
  • Os scripts são validados no Oracle Cloud Infrastructure (Sistemas de BD) e em ambientes locais.
  • Os scripts foram validados para configurar um Oracle Data Guard híbrido, em que o banco de dados principal está local e o standby é um Sistema de BD no Oracle Cloud Infrastructure.

Sobre os Arquivos de Script

A seguir estão descrições dos arquivos de script usados nesta solução:

  • 1_prepare_primary_maa_parameters.sh

    Conecta-se ao banco de dados principal e o configura com os parâmetros recomendados do Oracle Maximum Availability Architecture (MAA) para o Oracle Data Guard. Ele cria os arquivos de redo log stand-by, ele define os valores para DB_BLOCK_CHECKSUM, DB_FLASHBACK_RETENTION_TARGET e assim por diante. Este script é executado somente uma vez, quer o banco de dados principal seja um Oracle Real Application Clusters (Oracle RAC) ou um banco de dados de instância única.

  • 2_dataguardit_primary.sh

    Prepara os hosts principais do Oracle Data Guard. Ele adiciona os aliases TNS necessários ao arquivo tnsnames.ora, verifica a conectividade com o standby remoto, configura a criptografia de rede se ainda não estiver definida e gera os arquivos tar de saída que contêm o arquivo de senha principal e a wallet (se usada) Transparent Data Encryption (TDE).

  • create_pw_tar_from_asm_root.sh

    Este script nem sempre é necessário. É obrigatório somente quando o arquivo de senha principal é armazenado no Oracle Automatic Storage Management (Oracle ASM). Ele cria um arquivo tar de saída com o arquivo de senha.

  • 3_dataguardit_standby_root.sh

    Prepara os novos hosts stand-by e cria o banco de dados stand-by usando o recurso restore from service Oracle Recovery Manager (RMAN) e o broker do Oracle Data Guard. Se houver um banco de dados existente nesses hosts (um banco de dados funcional ou como resultado de uma falha na tentativa de execução de script anterior), os scripts o excluirão antes de recriar o novo banco de dados como standby.

  • DG_properties.ini

    Este é o arquivo de propriedades que deve ser personalizado com os valores específicos do ambiente. Ele é usado por todos os scripts, tanto no principal como no standby.

Sobre os produtos e funções necessários

Esta solução requer as seguintes atribuições para os sistemas de banco de dados principal e standby:

Nome do Produto: Função Obrigatório para...
Oracle Database: sys executar todos os scripts
Host do Oracle Database (principal): usuário do SO oracle com permissões de execução executar os seguintes scripts:
  • 1_prepare_primary_maa_parameters.sh
  • 2_dataguardit_primary.sh
Host do Oracle Database (principal): root execute o seguinte script quando o arquivo de senha principal estiver armazenado no ASM: create_pw_tar_from_asm_root.sh
Host do Oracle Database (secundário): root execute o seguinte script:
  • 3_dataguardit_standby_root.sh

Consulte Produtos, Soluções e Serviços Oracle para obter o que você precisa.