1. Configurar uma solução de DR híbrida para o Oracle WebLogic Server
  2. Configurar o Ambiente

Configurar o Ambiente

Configure o sistema secundário no OCI e o configure como standby do principal sistema local.

Os scripts estão disponíveis para automatizar algumas das etapas. Esses scripts não automatizam a configuração completa, portanto, você deve concluir as tarefas e pode usar os scripts quando forem referenciados.

Vá para Fazer Download do Código do link para fazer download dos scripts mencionados neste documento.

Preparar as Origens de Dados WebLogic no Data Center Principal

Há várias abordagens que você pode usar para a string de conexão de banco de dados das origens de dados WebLogic em uma topologia de recuperação de desastre, como string dupla, strings de conexão diferentes e alias TNS. Consulte o Oracle Fusion Middleware Disaster Recovery Guide para obter mais detalhes e comparação entre as diferentes abordagens. Usaremos o alias TNS porque ele requer uma configuração única. O uso de um alias TNS significa que você não precisará alterar a configuração WebLogic toda vez que a copiar para a secundária. É suportado o uso de um alias TNS nas origens de dados GridLink iniciando o FMW versão 12.2.1.3.

O alias TNS é o mesmo nome no principal e no secundário; portanto, as origens de dados usam a mesma string de conexão de bd. Ele é resolvido com um arquivo tnsnames.ora que não é copiado para o standby; portanto, você pode ter conteúdo tnsnames.ora diferente em cada site. Você pode colocá-lo separadamente da configuração do domínio WebLogic, em um sistema de arquivos que não é replicado entre sites. Ou, dado que faz parte da configuração, você também pode armazená-la em uma pasta na configuração do domínio. Nesse caso, certifique-se de excluir essa pasta quando copiar a configuração de domínio do principal para o stand-by. Cada site resolverá o alias TNS com a string de conexão apropriada em cada site, apontando apenas para o banco de dados local. Por exemplo: 

Connect string in data sources in primary site:
jdbc:oracle:thin:@mypdbservice

The tnsnames.ora file in primary contains:
MYPDBSERVICE =
(DESCRIPTION=
 (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=mypdbservice.example.com))
)

Connect string in data sources in secondary site:
jdbc:oracle:thin:@mypdbservice
The tnsnames.ora file in secondary: 
MYPDBSERVICE =
(DESCRIPTION=
 (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=mypdbservice.example.com))
)

Estas são as vantagens do uso do alias TNS:

  • Como a mesma string de conexão db é usada no domínio WebLogic config, você não precisa alterar a configuração WebLogic após replicar o config do principal para o stand-by.
  • Como cada site aponta somente para o banco de dados local, não há risco de conexões cruzadas da camada intermediária para o banco de dados remoto.

Se você ainda não estiver usando essa abordagem no sistema principal do WebLogic Server, execute as etapas a seguir para usar um alias TNS nas origens de dados.

  1. Crie a pasta tns nos hosts de camada intermediária principais:

    Essa pasta deve ser legível pelo usuário Oracle e colocada em um sistema de arquivos que não é replicado entre sites.

    Uma vez que a pasta tns faz parte da configuração, você também pode criá-la na pasta de configuração que é compartilhada por todos os servidores. Mas nesse caso, certifique-se de excluir a pasta tns quando copiar a configuração do domínio do principal para o stand-by ou atualizar tnsnames.ora no sistema stand-by, após um failover ou switchover, para apontar para o banco de dados secundário. 

    [oracle@host3 ~]$ mkdir -p /home/oracle/tnsnames_dir
[oracle@host4 ~]$ mkdir -p /home/oracle/tnsnames_dir
  2. Crie um arquivo tnsnames.ora no diretório com o alias TNS que será usado nas origens de dados, conforme mostrado no exemplo.
    A Oracle recomenda inserir a string em uma única linha.
    MYPDBSERVICE = 
(DESCRIPTION=
  (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=dbhost-scan.example.com)(PORT=1521))
  )
  (CONNECT_DATA=(SERVICE_NAME= mypdbservice.example.com))
)
  3. Especifique a propriedade oracle.net.tns_admin apontando para a localização do diretório do arquivo tnsnames.ora. Utilize um dos seguintes métodos:

    • Opção 1: Defina a propriedade como uma propriedade de conexão de origem de dados. A Oracle recomenda esse método.

      1. Especifique a propriedade oracle.net.tns_admin=tns_directory na configuração da origem de dados.

        Para especificar essa propriedade na Console de Administração WebLogic, vá para Serviços, clique em Origens de Dados, selecione uma origem de dados na lista, clique em Pool de Conexões e adicione-a à caixa de texto Propriedades. Repita essa etapa para cada origem de dados.

        Por exemplo: oracle.net.tns_admin=/home/oracle/tnsnames_dir

      2. Especifique essa propriedade na segurança do OPSS armazena arquivos jps-config-jse.xml e jps-config.xm disponíveis na pasta $ASERVER_HOME/config/fmwconfig.

        Para modificar esses arquivos jps, edite-os e adicione a propriedade oracle.net.tns_admin após a propriedade jdbc.url. Por exemplo, 

        …
<property name="jdbc.url" value="jdbc:oracle:thin:@soaedg"/>
<property name="oracle.net.tns_admin" value="tns_directory"/>
…

        Observação:

        Essa propriedade se aplica ao arquivo específico (origem de dados, arquivo jps) no qual ele é especificado.

    • Opção 2: Defina a propriedade como uma propriedade do sistema java.

      1. Especifique a propriedade do sistema -Doracle.net.tns_admin=tns_directory em que tns_directory é a localização do diretório do arquivo tnsnames.ora.

        Para defini-la como uma propriedade java para os servidores, edite os seguintes arquivos:
        • $ASERVER_HOME/bin/setUserOverrides.sh and
        • $MSERVER_HOME/bin/setUserOverrides.sh (Esse arquivo não é compartilhado. Portanto, você deve editar o arquivo em todos os hosts da camada intermediária SOA.)

      2. Adicione o seguinte conteúdo a estes arquivos: 

        # For using tns alias in the datasources 
export EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Doracle.net.tns_admin=/home/oracle/tnsnames_dir

        Observação:

        Essa propriedade se aplica a todas as origens de dados e arquivos jps no Oracle WebLogic Server. Antes de executar alguns comandos WLST e o Assistente de Configuração, essa abordagem requer que você defina a propriedade no ambiente.
        • Antes de executar o WLST, defina a propriedade na variável de ambiente WLST_PROPERTIES.
        • Antes de executar o Assistente de Configuração, adicione a propriedade à variável de ambiente JVM_ARGS do script config_internal.sh.
      3. Opção 3: Defina a propriedade no URL jdbc.

        Especifique o local do arquivo tnsnames.ora como parte da string de conexão nas origens de dados e nos arquivos jps: 

        jdbc:oracle:thin:@alias?TNS_ADMIN=tns_directory

      Observação:

      Essa propriedade se aplica ao arquivo específico (origem de dados, arquivo jps) no qual ele é especificado.

      Você pode usar esse método com o Driver JDBC 18.3 e versões posteriores. Isso se aplica ao Fusion Middleware 12.2.1.4 (que usa o Driver JDBC 19.3) e posterior.

  4. Use o alias no URL de definição da origem de dados substituindo a string de conexão pelo alias.
    jdbc:oracle:thin:@mypdbservice
    Modifica os seguintes arquivos:
    • Em arquivos de origem de dados, localizados em $ASERVER_HOME/config/jdbc/
    • Nos arquivos jps-config.xml e jps-config-jse.xml, localizados em $ASERVER_HOME/config/fmwconfig/
    Você pode usar a Console de Administração do Oracle WebLogic Server para modificar as origens de dados, mas deverá editar manualmente os arquivos jps-config xml. Você pode usar o script update_dbconnect.sh para realizar a substituição em todos os arquivos mencionados.

    Vá para Fazer Download do Código do link para fazer download do script.

  5. Reinicie cada Oracle WebLogic Server no domínio.
    1. Interrompa todos os Servidores WebLogic no domínio principal (servidor Admin e servidores Gerenciados).
    2. Inicie o servidor de Administração no domínio principal.
    3. Depois que o servidor de Administração estiver em execução, inicie os Servidores Gerenciados.
    4. Verifique se as conexões foram estabelecidas corretamente com o banco de dados.
  6. Melhores práticas adicionais: Quando você estiver usando um Oracle Database 12c ou versões posteriores, os valores de configuração de Host e Porta do Oracle Notification Service (ONS) não serão necessários nas origens de dados GridLink.
    A lista Oracle Notification Service é obtida automaticamente do banco de dados pelo driver do cliente. A Oracle recomenda o uso desse recurso em vez de fornecer o endereço de verificação ou a lista dos nós do Oracle RAC na configuração ONS de cada origem de dados. Certifique-se de que o FAN esteja ativado e que a propriedade ONS nodes esteja vazia em cada origem de dados.
    1. Abra o Oracle WebLogic Server Administration Console.
    2. Vá para Serviços e Origens de Dados. Selecione o nome da origem de dados, Configuração e ONS.
    3. Verifique se a lista de nós ONS está vazia.

Configurar a Rede

É necessária conectividade entre a rede local principal e a rede secundária do Oracle Cloud Infrastructure (OCI). A Oracle recomenda o uso do Oracle Cloud Infrastructure FastConnect, que permite a você estabelecer conexão diretamente com a sua rede virtual na nuvem OCI por meio de uma conexão dedicada, privada de alta largura de banda. Você escolhe uma velocidade de porta apropriada com base no volume de dados. Como alternativa, você pode usar a VPN Site a Site, embora ela forneça menos largura de banda e latência variável, jitter e custo.
  1. Crie a VCN e as sub-redes no compartimento do OCI conforme definido em Determinar os Recursos Necessários no OCI. Configure o Oracle Cloud Infrastructure FastConnect (ou VPN Site a Site) para permitir a comunicação entre sua rede local e a VCN. Consulte FastConnect e VPN Site a Site para obter informações.
  2. Crie as regras de rede necessárias no OCI e no firewall local e configure a origem, os destinos, os protocolos e as portas, conforme mostrado na tabela.

    Supõe-se que todo o tráfego esteja ativado dentro de cada sub-rede.

    Consulte a Documentação do OCI para obter informações sobre regras de segurança de rede.

    Origem Destino Protocolo e Porta Utilização
    Rede local Sub-rede de camada intermediária do OCI SSH (porta 22) Configuração e ciclo de vida
    Rede local Sub-rede da camada web do OCI SSH (porta 22) Configuração e ciclo de vida (quando o Oracle HTTP Server é usado no OCI)
    Rede local Sub-rede de camada db do OCI SSH (porta 22) Configuração e ciclo de vida
    Hosts de BD locais Sub-rede de camada db do OCI SQLNET (porta 1521) Para o Oracle Data Guard redo transport
    Rede local Sub-rede da camada web do OCI HTTPS/HTTP (443, 80, 7001) Acesso ao aplicativo Web e aos consoles de administração
    Rede local Sub-rede de camada intermediária do OCI HTTP (7001,8001,9001) Para verificações diretas no Oracle WebLogic Servers
    Sub-rede da camada web do OCI Sub-rede de camada intermediária do OCI HTTP (7001,8001,9001) Para conectividade dos componentes da camada Web (Balanceador de Carga do OCI, Oracle HTTP Server) com os Servidores WebLogic
    Sub-rede de camada intermediária do OCI Sub-rede de camada db do OCI SQLNET (1521), ONS (6200) Para conectividade do WebLogic Servers com o banco de dados
    Sub-rede de camada intermediária do OCI Sub-rede fss-tier do OCI Consulte Configurando Regras de Segurança da VCN para Armazenamento de Arquivos para obter informações específicas. Para montar as exportações do sistema de arquivos do OCI File Storage com NFS.
    Sub-rede de camada intermediária do OCI Hosts de camada intermediária no local SSH (porta 22) Para rsync
    Sub-rede de camada db do OCI Hosts de banco de dados locais SQLNET (1521) Para o Oracle Data Guard redo transport
    Sub-rede de camada intermediária do OCI Sub-rede da camada web do OCI HTTPS (443) Para callbacks do aplicativo para o front-end

    Observação:

    Você pode encontrar o código terraform para criar a VCN, as sub-redes e as regras de segurança em Fazer Download do Código.

Configurar Oracle Data Guard

Configure o Oracle Data Guard entre o banco de dados principal local e o banco de dados stand-by no Oracle Cloud Infrastructure (OCI).
  1. Configure o Oracle Data Guard entre um banco de dados principal local e um stand-by na OCI, conforme descrito em Hybrid Data Guard to Oracle Cloud Infrastructure.
    Para ajudar a configurar o Oracle Data Guard, os scripts estão disponíveis em GitHub e são referenciados em Código de Download.
  2. Verifique se a configuração do Oracle Data Guard está correta usando a interface de linha de comandos do Oracle Data Guard (DGMGRL).
    DGMGRL> show configuration verbose
  3. Depois de concluir a configuração do Oracle Data Guard (Etapa 2), crie os mesmos serviços de banco de dados no sistema de BD do OCI, como os usados no sistema local principal. Configure o serviço com a atribuição PRIMARY e com a atribuição SNAPSHOT_STANDBY.
    A configuração do serviço com ambas as atribuições permite que o serviço seja iniciado automaticamente pelo DG Broker quando o banco de dados é convertido em stand-by de snapshot, que é necessário quando você deseja validar o sistema secundário sem executar um switchover completo.
    Por exemplo, se o banco de dados principal usar o serviço de banco de dados mypdbservice.example.com para acessar o PDB, crie o mesmo serviço no sistema de BD secundário do OCI. 
    srvctl add service -db $ORACLE_UNQNAME -service mypdbservice.example.com -preferred ORCL1,ORCL2 -pdb PDB1 -role "PRIMARY,SNAPSHOT_STANDBY"
srvctl modify service -db $ORACLE_UNQNAME -service mypdbservice.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT
srvctl config service -db $ORACLE_UNQNAME -service mypdbservice.example.com
  4. Se o serviço no banco de dados principal tiver sido criado somente com a atribuição PRIMARY (que é o padrão), você poderá modificá-lo para adicionar a atribuição stand-by de snapshot.
    srvctl modify service -db $ORACLE_UNQNAME -s mypdbservice.example.com -role "PRIMARY,SNAPSHOT_STANDBY"
  5. Verifique as políticas do Oracle Recovery Manager (RMAN) no banco de dados principal para impedir que os logs de arquivamento sejam excluídos antes de serem aplicados ao banco de dados stand-by.
    Certifique-se de ter a cláusula applied on all standby na política de exclusão archivelog do RMAN, nos bancos de dados principal e stand-by.

Sobre a versão do banco de dados e o nível de patch

O Oracle Home no banco de dados local e o banco de dados stand-by no OCI devem ter a mesma versão e no mesmo nível de patch. Você pode fazer isso das seguintes maneiras:

  • Ao escolher a imagem Software de Banco de Dados durante o provisionamento do Sistema de BD no OCI, selecione Exibir todas as versões e selecione a mesma versão do banco de dados e o mesmo nível de conjunto de patches do banco de dados local.
  • Se a versão do Oracle Home do banco de dados de origem não estiver mais disponível no OCI para provisionamento, será necessário aplicar patch ao ambiente de origem no mesmo nível de patch do banco de dados que o home do banco de dados no ambiente de nuvem.

O cenário a seguir é um exemplo real de referência. O Home do BD local é 19.6 e o Home do BD do OCI é 19.11.

  1. Execute o comando $ORACLE_HOME/OPatch/opatch lspatches para identificar os patches instalados nos ambientes de Origem e de Destino.
    $ORACLE_HOME/OPatch/opatch lspatches

    Esta é a saída deste exemplo:

    Patches do Oracle Home do BD no Local Patches do Oracle HOME no OCI

    30676209;LNX64-20.1-RAC ASM HIT ORA-07445 EXCEÇÃO ENCONTRADA CORE DUMP [KSXPOSDIFQRY()+556]

    30613937;IPCOR TOPO SERVICE FIX IP TYPE BUG NA SELEÇÃO IP

    30484981;ATUALIZAÇÃO DA RELEASE DO OJVM: 19.6.0.0.200114 (30484981)

    30489227;ATUALIZAÇÃO DA RELEASE DO OCW 19.6.0.0.0 (30489227)

    30557433;Atualização da Release do Banco de Dados: 19.6.0.0.200114 (30557433)

    29780459;AUMENTAR _LM_RES_HASH_BUCKET E REVERTER ALTERAÇÕES A PARTIR DA CORREÇÃO DO BUG 29416368

    30310195;RESTRIÇÕES DESATIVADAS REPORTADAS DO DBSAT PARA FRAGMENTAÇÃO STS_CHUNKS EM GSMADMIN_INTERNAL.SHARD_TS

    32327201;RDBMS - ATUALIZAÇÃO DO DSTV36 - TZDATA2020E

    31335037;RDBMS - ATUALIZAÇÃO DO DSTV35 - TZDATA2020A

    30432118;SOLICITAÇÃO DE MESCLAGEM NO TOPO DE 19.0.0.0.0 PARA BUGS 28852325 29997937

    31732095;ATUALIZAR PERL NO ORACLE HOME DO BANCO DE DADOS 19C PARA V5.32

    32490416;PATCH DO PACOTE JDK 19.0.0.0.210420

    32399816;ATUALIZAÇÃO DA RELEASE DO OJVM: 19.11.0.0.210420 (32399816)

    32579761;ATUALIZAÇÃO DA RELEASE DO OCW 19.11.0.0.0 (32579761)

    32545013;Atualização da Release do Banco de Dados: 19.11.0.0.210420 (32545013)
  2. Analise os patches existentes: determine quais patches são one-offs, revise se eles já estão corrigidos nos novos patches RU ou se novos patches de sobreposição são necessários, determine quais deles devem ser desinstalados, localize os arquivos de patch apropriados para RU e assim por diante.
  3. Com base na análise, desinstale os patches one-off que já estão corrigidos na nova RU antes de instalar a atualização RU (caso contrário, eles causarão conflitos). Neste exemplo, os patches on-off são corrigidos na versão 19.11, portanto, eles devem ser revertidos antes de instalar a 19.11 RU.
    30676209;LNX64-20.1-RAC  ASM HIT ORA-07445  EXCEPTION ENCOUNTERED  CORE DUMP [KSXPOSDIFQRY()+556]
30613937;IPCOR TOPO SERVICE  FIX IP TYPE BUG IN IP SELECTION
  4. Localize, faça download e instale os patches RU. Neste exemplo, os patches 19.11 RU estão localizados no patch de combinação 32578973: COMBO OF OJVM RU COMPONENT 19.11.0.0.210420 + GI RU 19.11.0.0.210420 e são os seguintes:
    32399816;OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816)  
32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761)            
32545013;Database Release Update : 19.11.0.0.210420 (32545013)
  5. Localize, faça download e instale os overlays, one-offs e outros patches que o Home de BD do OCI tem sobre a RU. Por exemplo: 
    29780459;INCREASE _LM_RES_HASH_BUCKET AND BACK OUT CHANGES FROM THE BUG 29416368 FIX
30310195;DBSAT REPORTED DISABLED CONSTRAINTS FOR SHARDING STS_CHUNKS ON GSMADMIN_INTERNAL.SHARD_TS
30432118;MERGE REQUEST ON TOP OF 19.0.0.0.0 FOR BUGS 28852325 (DSTV33 update) 29997937 (DSTV34 update)
31335037;RDBMS - DSTV35 UPDATE - TZDATA2020A
32327201;RDBMS - DSTV36 UPDATE - TZDATA2020E
32490416;JDK BUNDLE PATCH 19.0.0.0.210420
31732095;UPDATE PERL IN 19C DATABASE ORACLE HOME TO V5.32
  6. Execute uma análise semelhante para os patches do GI.

Observação:

Este exemplo inclui apenas o Oracle Home do RDBMS. Talvez não seja estritamente necessário aplicar patches à instalação do GI local no mesmo nível secundário:
  • Na perspectiva do Oracle Data Guard, não é estritamente necessário ter as mesmas versões de GI no principal e no stand-by: o Oracle Data Guard é completamente independente de qualquer coisa no banco de dados, para que você possa executar diferentes versões do sistema operacional, do Oracle Clusterware, do hardware ou do software de armazenamento em diferentes sites sem restrições de versões ou tempo. (ID do Documento 1265700.1)
  • Independentemente do Oracle Data Guard, não é necessário ter a mesma versão nas versões GI e RDBMS em um BD RAC: A partir da 18c, a versão do Oracle Grid Infrastructure (GI) /Clusterware (CRS) deve ser igual ou a versão mais alta até o primeiro dígito nas combinações possíveis em todos os momentos. Por exemplo: o Grid infrastructure pode estar em 18.1.0.0 e o Banco de Dados pode estar em 18.3.0.0. (ID do Documento 337737.1)

É uma boa prática aplicar patch ao GI no mesmo nível do home do BD. Depois de aplicar patch ao home do BD para uma Atualização de Release mais recente (RU), muitos dos patches são comuns para DB e GI e você pode usar OPatchAuto para ambos os homes ao mesmo tempo.