Configurar uma Solução de DR com um Oracle Autonomous Database

Para garantir a continuidade dos negócios em caso de desastres, você vai querer implementar uma estratégia de recuperação de desastres (DR) para seus aplicativos Oracle WebLogic Suite. Esta solução fornece proteção de dados e permite que você use o Oracle Autonomous Database para alternar rapidamente para o sistema stand-by com perda mínima de dados e produtividade.

Você pode configurar e gerenciar um sistema de recuperação de desastres que use o Oracle Autonomous Database como banco de dados para o Oracle WebLogic Server for Oracle Cloud Infrastructure, o Oracle SOA Suite on Marketplace ou qualquer outro serviço de camada intermediária do Oracle Cloud Infrastructure (OCI) que use o Oracle Fusion Middleware.

O Oracle Autonomous Database Serverless e o Oracle Exadata Database Service on Dedicated Infrastructure fornecem um recurso Stand-by Snapshot. Isso permite que você abra o banco de dados stand-by temporariamente para leitura/gravação. Quando você converte seu banco de dados stand-by em um stand-by snapshot, ele é totalmente atualizável. Ele continua recebendo os dados redo de seu banco de dados de origem remota (portanto, você ainda é protegido por DR), mas não aplica o redo até que ele seja convertido de volta para um stand-by físico. Todas as alterações executadas em um banco de dados stand-by snapshot são revertidas quando ele é convertido para stand-by físico novamente. Use esse recurso para provisionar o sistema de camada intermediária na região stand-by. Você também pode usar esse recurso durante o ciclo de vida do seu sistema de DR para validar o sistema stand-by sem executar um switchover completo.

Além do recurso Snapshot Stand-by, o Oracle Autonomous Database Serverless fornece clones atualizáveis remotos. Isso fornece funcionalidade equivalente à funcionalidade tradicional do banco de dados stand-by snapshot do Oracle Data Guard, mas usando um banco de dados adicional. O Clone Atualizável Remoto é gerenciado individual e separadamente do Stand-by do Oracle Autonomous Data Guard. Ao usar o Oracle Autonomous Database Serverless, você pode usar um Clone Atualizável Remoto em vez de um banco de dados Stand-by Snapshot para provisionar o sistema de camada intermediária na região secundária ou para executar tarefas em stand-by, como teste, abertura para validações, aplicação de patches etc. No entanto, os bancos de dados clone stand-by e atualizáveis usam diferentes wallets de conexão e suas strings de conexão devem ser gerenciadas corretamente para executar essas tarefas.

Antes de Começar

Há vários resumos técnicos do Oracle Maximum Availability Architecture (MAA) que descrevem como configurar um sistema de recuperação de desastres (DR) para o Oracle WebLogic Server for Oracle Cloud Infrastructure e o Oracle SOA Suite on Marketplace quando esses sistemas de middleware usam o Oracle Base Database Service.

As topologias Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace e Oracle Fusion Middleware DR usam um modelo ativo-passivo. O sistema principal é um data center do Oracle Cloud Infrastructure (OCI) e um sistema secundário em um data center OCI diferente e remoto.

Revise o seguinte para obter mais detalhes e topologias para cada caso:

Os documentos acima fornecem detalhes detalhados, etapas de configuração e gerenciamento, além de muitas outras considerações, para o Oracle WebLogic Server for Oracle Cloud Infrastructure e o Oracle SOA Suite on Marketplace.

Além dos resumos técnicos, certifique-se de estar familiarizado com os conceitos e a administração do Oracle Cloud Infrastructure (OCI), incluindo rede, instâncias de computação, balanceamento de carga e o Oracle Autonomous Database antes de prosseguir com a análise e as etapas descritas neste manual.

As etapas e exemplos neste playbook são verificados com o Oracle WebLogic Server for OCI e o Oracle SOA Suite on Marketplace para os seguintes cenários:

Oracle Autonomous Data Guard no Oracle Exadata Database Service on Dedicated Infrastructure, usando o recurso Snapshot Standby para a configuração de recuperação de desastre.
Oracle Autonomous Data Guard no Oracle Autonomous Database Serverless, usando o recurso Snapshot Stand-by para a configuração de recuperação de desastre.
Oracle Autonomous Data Guard no Oracle Autonomous Database Serverless, usando Clones Atualizáveis Remotos para a configuração de recuperação de desastre.

A maioria das etapas é comum para os três cenários. Apenas algumas das etapas diferem e são específicas para cada caso.

Não deve ser difícil ajustar as etapas para nenhum sistema do Oracle WebLogic Server ou do Oracle Fusion Middleware que use o Oracle Autonomous Database.

Arquitetura

Este diagrama de arquitetura mostra a topologia do sistema de recuperação de desastres (DR) para as abordagens usadas neste manual. Todas as informações de runtime, configuração e metadados que residem no banco de dados principal são replicadas da Região 1 para a Região 2 com o Oracle Autonomous Data Guard. As topologias Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace e Oracle Fusion Middleware DR usam um modelo ativo-passivo. O sistema principal é um data center do Oracle Cloud Infrastructure (OCI) e um sistema secundário em um data center OCI diferente e remoto.

A configuração do domínio do Oracle WebLogic é replicada usando um diretório de preparação do Oracle Cloud Infrastructure File Storage (OCI File Storage) na região principal, que é replicado para um diretório de estágio do OCI File Storage na região secundária. Em seguida, a configuração é copiada para o diretório de domínio real na secundária. A cópia direta do domínio apresenta riscos que são evitados usando um diretório de preparação. Como as cópias de arquivo são uma operação não transacional, uma primeira cópia para um diretório de preparação é feita. Os arquivos são verificados primeiro nesse diretório intermediário e depois transferidos para o domínio real (final) do Oracle WebLogic.

Descrição da ilustração wls-dr-adb.png

wls-dr-adb-oracle.zip

A topologia é típica do que é usado pelos ambientes de recuperação de desastres do Oracle WebLogic Server, do Oracle SOA ou do Oracle Fusion Middleware no OCI. Para provisionar a camada intermediária stand-by e operações de ciclo de vida como testar secundário, converta o Oracle Autonomous Database stand-by em um Banco de Dados Stand-by Snapshot ou use um Clone Remoto Atualizável.

Ao usar um Clone Remoto Atualizável, há um "banco de dados auxiliar" (um clone atualizável em uma região remota) para o provisionamento inicial e para as operações de teste e validação no secundário. Nesse caso, a camada intermediária secundária é configurada com Origens de Dados que precisam ser alteradas de volta para o endereço stand-by nos eventos de switchover e failover.

Essa arquitetura suporta os seguintes componentes:

Região
Uma região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominada domínios de disponibilidade. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).
Domínio de disponibilidade
Domínios de disponibilidade são data centers stand-alone e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, o que oferece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia ou refrigeração ou a rede interna do domínio de disponibilidade. Portanto, uma falha em um domínio de disponibilidade não deve afetar os outros domínios de disponibilidade na região.
Domínio de falha
Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade tem três domínios de falha com potência e hardware independentes. Quando você distribui recursos entre diversos domínios de falha, seus aplicativos podem tolerar falhas físicas no servidor, na manutenção do sistema e na alimentação dentro de um domínio de falha.
Rede virtual na nuvem (VCN) e sub-rede
Uma VCN é uma rede personalizável e definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs oferecem total controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após criar a VCN. Você pode segmentar uma VCN em sub-redes, que podem ter escopo em uma região ou em um domínio de disponibilidade. Cada sub-rede consiste em um intervalo ininterrupto de endereços que não se sobrepõem às outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.
Balanceador de carga
O serviço Oracle Cloud Infrastructure Load Balancing fornece distribuição automatizada de tráfego de um único ponto de entrada para vários servidores no back-end.
Domínio do Oracle WebLogic
Um domínio é a unidade de administração básica para instâncias do Servidor WebLogic. Um domínio consiste em uma ou mais instâncias do Servidor WebLogic (e seus recursos associados) que você gerencia com um único Servidor de Administração. O domínio do Oracle WebLogic é configurado seguindo as melhores práticas do Oracle Maximum Availability Architecture (MAA) para Alta Disponibilidade.
Gateway de roteamento dinâmico (DRG)
O DRG é um roteador virtual que fornece um caminho para o tráfego de rede privada entre VCNs na mesma região, entre uma VCN e uma rede fora da região, como uma VCN em outra região do Oracle Cloud Infrastructure, uma rede local ou uma rede em outro provedor de nuvem.
Lista de segurança
Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego que deve ser permitido dentro e fora da sub-rede.
Oracle Cloud Infrastructure File Storage
O Oracle Cloud Infrastructure File Storage Service fornece um sistema de arquivos de rede durável, escalável e seguro e de nível empresarial. Você pode se conectar a um sistema de arquivos do serviço File Storage de qualquer instância bare metal, de máquina virtual ou de contêiner em sua VCN (Rede Virtual na Nuvem). O File Storage Service suporta o protocolo Network File System versão 3.0 (NFSv3). O serviço suporta o protocolo Network Lock Manager (NLM) para a funcionalidade de bloqueio de arquivo.

O Oracle Cloud Infrastructure File Storage emprega armazenamento replicado em 5 direções, localizado em diferentes domínios de falha, para fornecer redundância para proteção de dados resiliente. Os dados são protegidos com a codificação de apagamento. O serviço foi projetado para atender às necessidades de aplicativos e usuários que precisam de um sistema de arquivos corporativo em uma grande variedade de casos de uso.
Autonomous Database
O Oracle Autonomous Database é um ambiente de banco de dados pré-configurado totalmente gerenciado que você pode usar para cargas de trabalho de processamento de transações e data warehousing. Não é necessário configurar ou gerenciar qualquer hardware ou instalar qualquer software. O Oracle Cloud Infrastructure trata da criação do banco de dados, bem como do backup, aplicação de patches, upgrade e ajuste do banco de dados.
Oracle Autonomous Database na Infraestrutura Dedicada do Exadata
O Oracle Autonomous Database on Dedicated Exadata Infrastructure é um Oracle Autonomous Database com uma nuvem de banco de dados privada na nuvem pública. Com seu banco de dados dedicado, você obtém um serviço de computação, armazenamento, rede e banco de dados completamente dedicado, fornecendo os mais altos níveis de segurança, isolamento e governança.
Oracle Autonomous Database sem Servidor

O Oracle Autonomous Database Serverless é um Oracle Autonomous Database. Você tem um banco de dados totalmente elástico no qual a Oracle opera de forma autônoma todos os aspectos do ciclo de vida do banco de dados, desde o posicionamento do banco de dados até o backup e as atualizações.
Data Guard
O Oracle Data Guard fornece um conjunto abrangente de serviços que criam, mantêm, gerenciam e monitoram um ou mais bancos de dados standby para permitir que os bancos de dados Oracle de produção permaneçam disponíveis sem interrupção. O Oracle Data Guard mantém esses bancos de dados standby como cópias do banco de dados de produção. Em seguida, 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 stand-by para a atribuição de produção, minimizando o tempo de indisponibilidade associado à interrupção.
Oracle Autonomous Data Guard
O Oracle Autonomous Data Guard permite que um banco de dados standby (de pareamento) forneça proteção de dados e recuperação de desastres para sua instância do Autonomous Database. Ele oferece um conjunto abrangente de serviços que criam, mantêm, gerenciam e monitoram um ou mais bancos de dados standby para permitir que bancos de dados Oracle de produção permaneçam disponíveis sem interrupção. O Oracle Data Guard mantém esses bancos de dados stand-by como cópias do banco de dados de produção. Em seguida, se o banco de dados de produção ficar indisponível por causa de uma interrupção planejada ou não planejada, você poderá alternar qualquer banco de dados stand-by para a atribuição de produção, minimizando o tempo de inatividade associado à interrupção.
Stand-by de Snapshot
Um banco de dados stand-by de snapshot é um banco de dados standby totalmente atualizável criado por meio da conversão de um banco de dados standby físico em um banco de dados standby de snapshot.

Um banco de dados stand-by de snapshot recebe e arquiva, mas não se aplica, dados redo de um banco de dados principal. Os dados redo recebidos do banco de dados principal são aplicados depois que um banco de dados stand-by de snapshot é convertido de volta em um banco de dados stand-by físico, após descartar todas as atualizações locais no banco de dados stand-by de snapshot.
Clone Atualizável
O Oracle Autonomous Database fornece clonagem na qual você pode optar por criar um clone completo da instância ativa, criar um clone de metadados ou criar um clone atualizável. Com um clone atualizável, o sistema cria um clone que pode ser facilmente atualizado com as alterações do banco de dados de origem.

Considerações para o Nível Médio

Todas as considerações em Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery e SOA Suite on Oracle Cloud Infrastructure Marketplace Disaster Recovery para a camada intermediária são aplicáveis nos cenários do Oracle Autonomous Database descritos neste documento.

Considere os seguintes aspectos para a camada intermediária:

Endereço front-end
O acesso dos clientes ao sistema Oracle WebLogic Server deve ser independente do site que está sendo usado como local principal. Para fazer isso, o nome do endereço front-end usado para acessar o sistema deve ser exclusivo e sempre apontar para o sistema principal no momento. Esse nome geralmente é chamado de front-end virtual ou URL personalizado.

Você pode reutilizar o endereço de nome de host de front-end do sistema existente como front-end virtual para proteção de desastres. Por exemplo, se o sistema original tiver mywebapps.example.com como URL personalizado para o sistema principal, você poderá remapear o mesmo nome de host virtual para o IP do balanceador de carga do segundo site após um switchover ou failover.

Use um serviço DNS (domain name system) apropriado para o nome front-end a ser mapeado para qualquer site. Por exemplo, (serviço Oracle Cloud Infrastructure DNS, outro DNS comercial, DNS local ou resolução de hosts locais).
Prefixo do Nome da Instância
Forneça um Instance Name Prefix ao provisionar o Oracle WebLogic Server for OCI ou o Oracle SOA Suite on Marketplace. Essa propriedade é usada para construir os nomes de todos os recursos, incluindo: o nome do domínio do Servidor WebLogic, o nome do cluster, os nomes do servidor WebLogic, os nomes de host da VM e assim por diante.

Defina Instance Name Prefix como o mesmo valor nos sistemas Oracle WebLogic Server principal e secundário, para que ambos os sistemas tenham o mesmo nome para os recursos do Oracle WebLogic. O uso do mesmo nome garante a consistência e é necessário para a recuperação de mensagens JMS e TLogs. Ele também simplifica personalizações e operações em ambos os sites.

Você pode usar o mesmo Instance Name Prefix em várias instâncias na mesma tenancy do Oracle Cloud, desde que as crie em diferentes regiões ou compartimentos. Cada instância só é mostrada em sua região e compartimento específicos.

O processo de provisionamento do Oracle SOA Suite on Marketplace fornece um recurso opcional que permite configurar nomes personalizados para o domínio, o cluster, o servidor admin, o prefixo do servidor gerenciado etc. Nesse caso, os nomes não são derivados do Instance Name Prefix. Eles utilizam os valores fornecidos. É possível usar esse recurso na topologia de recuperação de desastres (DR) descrita neste documento, desde que os nomes personalizados fornecidos sejam os mesmos nos sistemas principal e stand-by.
Arquivos personalizados
A maioria da configuração do domínio do Oracle WebLogic Server for OCI que o WebLogic Cloud usa é sincronizada inicialmente entre sites com as seguintes considerações:

Cada sistema WebLogic mantém os URLs JDBC originais usados para estabelecer conexão com seu banco de dados local, mesmo após a conclusão da configuração do DR. Somente o prefixo do esquema é alterado para que ambos os locais apontem para os mesmos esquemas (esquemas principais).

O recurso Infraestrutura de Domínio WebLogic distribui automaticamente a configuração no diretório weblogic_domain_name/config para os outros nós no mesmo domínio.

As implantações de aplicativos personalizados (arquivos de ouvido/guerra, planos de implantação etc.) e tudo que reside no diretório de domínio do Oracle WebLogic Administration Server (exceto dados temporários) é inicialmente sincronizado entre sites usando os procedimentos descritos neste documento. Se o Oracle WebLogic Administration Server usar dados que residem em outros nós ou fora do diretório de domínio, você deverá copiá-lo manualmente para o local secundário. Detalhes adicionais sobre a replicação da configuração são fornecidos mais adiante.

Considerações para Snapshot Stand-by no Oracle Autonomous Database Serverless

Ao implementar essa solução, considere o seguinte ao ativar o Snapshot Stand-by em um banco de dados Oracle Autonomous Database Serverless.

Limite de tempo para stand-by snapshot em uma infraestrutura sem servidor
Quando um stand-by de snapshot no Oracle Autonomous Database Serverless não é reconectado em 48 horas, o stand-by de snapshot se reconecta automaticamente ao banco de dados de origem.
Convertendo de volta para o par de recuperação de desastres
A Oracle recomenda que você converta um stand-by de snapshot de volta para um par de recuperação de desastre assim que você terminar com as operações que exigiram que o stand-by fosse aberto para operações de leitura-gravação. Quando você faz a conversão de volta para um sistema remoto de recuperação de desastres, as alterações acumuladas do banco de dados de origem são aplicadas no sistema remoto. Se você manter o par de recuperação de desastres aberto como um stand-by de snapshot por um período mais longo, pressupondo que haja alterações contínuas no principal durante esse tempo, levará mais tempo para ser convertido de volta para um par de recuperação de desastres.
Implicações de custo do stand-by snapshot no Oracle Autonomous Database Serverless
O uso da CPU standby do snapshot será cobrado com base na contagem de CPUs base e qualquer uso adicional de CPU se o dimensionamento automático de computação estiver ativado. O número de CPUs base é especificado pelo número de ECPUs (OCPUs se seu banco de dados usar OCPUs), conforme mostrado no campo Contagem de ECPUs ou Contagem de OCPUs na Console do Oracle Cloud Infrastructure.

O uso do armazenamento stand-by de snapshot é cobrado com base no armazenamento do stand-by de snapshot mais 1 vez o armazenamento do banco de dados principal de origem.

Para obter mais detalhes, consulte Sobre Bancos de Dados Stand-by Snapshot de Recuperação de Desastre.

Considerações para Stand-by Snapshot no Oracle Autonomous Database on Dedicated Exadata Infrastructure

Ao implementar essa solução, considere o seguinte ao ativar o Snapshot Stand-by em um Oracle Autonomous Database on Dedicated Exadata Infrastructure.

Limite de tempo para stand-by snapshot em uma infraestrutura dedicada
Quando um stand-by snapshot no Oracle Autonomous Database on Dedicated Exadata Infrastructure não é convertido em stand-by físico em 7 dias, o stand-by snapshot é convertido automaticamente em stand-by físico.
Convertendo de volta para um stand-by físico
A Oracle recomenda que você converta um stand-by de snapshot de volta para um stand-by físico assim que você terminar com as operações que exigem que o stand-by esteja aberto para operações de leitura/gravação. Quando você converte o standby físico de volta, as alterações acumuladas do banco de dados de origem são aplicadas no stand-by. Se você manter o banco de dados stand-by aberto como um stand-by de snapshot por um período mais longo, pressupondo que há alterações contínuas no principal durante esse tempo, levará mais tempo para ser convertido de volta para um stand-by físico.
Serviços de banco de dados ao converter em um stand-by de snapshot
No Oracle Autonomous Database on Dedicated Exadata Infrastructure, a caixa de diálogo "Converter em stand-by snapshot" exibe duas opções:
- Usar novos serviços de Banco de Dados: Selecione esta opção para estabelecer conexão com um stand-by snapshot usando novos serviços que estão ativos apenas no modo stand-by snapshot.
- Usar serviços de Banco de Dados principal: Selecione essa opção se quiser estabelecer conexão com o banco de dados stand-by snapshot usando os mesmos serviços do banco de dados principal.
Para a configuração de recuperação de desastre, use a opção Usar serviços de Banco de Dados principal ao converter o stand-by em stand-by físico. Dessa forma, o nome do alias de conexão configurado pelo Oracle WebLogic Server na camada intermediária secundária é consistente com o principal.

Para obter mais detalhes, consulte Sobre o Autonomous Data Guard.

Considerações sobre Clones Atualizáveis Remotos no Oracle Autonomous Database Serverless

Considere o seguinte ao usar um Clone Atualizável do Oracle Autonomous Database Serverless para testar e validar um sistema secundário do Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace ou Oracle Fusion Middleware.

Ciclo de vida dos Clones Atualizáveis
Ao contrário de um Standby tradicional do Oracle Data Guard, os Clones Remotos Atualizáveis são ativados separadamente e gerenciados separadamente de um principal e um stand-by. É uma entidade separada com seu próprio ciclo de vida além das operações de atualização que a sincronizam com seu banco de dados de origem (principal).
Alocação de recursos da CPU
Os Clones Remotos Atualizáveis não são criados com base na alocação de recursos de CPU do sistema principal ou standby. Isso significa que você deve especificar opções de OCPU para o Clone Atualizável separadamente. Configure manualmente os testes de carga de trabalho no Clone Atualizável remoto para corresponder à capacidade do sistema principal. Idealmente, você deve criar o Clone Atualizável remoto com uma configuração correspondente ao banco de dados principal para que as cargas de trabalho de teste sejam realistas na secundária. No entanto, os Clones Atualizáveis remotos "transferem" a configuração de armazenamento usada no principal.
Aplicação de patches
Os patches são aplicados automaticamente semanalmente no Oracle Autonomous Database Serverless, de acordo com a janela de manutenção semanal; portanto, há uma sincronização contínua e forçada de patches entre o Clone Atualizável principal, stand-by e remoto.
Limites do serviço
Os Clones Atualizáveis Remotos são uma entidade de primeira classe, eles incorrem em custo adicional por implicações de armazenamento, CPU e licença de um Autonomous Database formal e serão contados nos limites de serviço da região para o Oracle Autonomous Database Serverless.
Clone Atualizável no switchover
Quando um failover ou "switchover não reversível imediatamente" ocorre, você deve criar manualmente um clone atualizável em principal para manter o sistema pronto para operações de teste e manutenção no que é agora o sistema secundário, com os limites de serviço, o gerenciamento e outras considerações apropriados. Os Clones Remotos Atualizáveis não têm controle de reversão de função.

Após um switchover para o secundário, o clone atualizável criado não poderá mais ser atualizado (já que sua origem agora é um standby) e é marcado como desconectado. Após 24 horas, torna-se um clone não atualizável e desconectado.
Janela de atualização de Clones Atualizáveis
Os Clones Remotos Atualizáveis devem ser atualizados pelo menos uma vez por semana. Depois disso, estar em sincronia com os dados do principal requer a criação de um novo Clone Atualizável remoto e o descarte do não atualizado.
Modo de gravação de Clones Atualizáveis
Os Clones Atualizáveis Remotos não podem permanecer no modo de gravação (desconexão da instância principal) por mais de 24 horas. Após esse período, o banco de dados remoto de Clones Atualizáveis não poderá ser conectado novamente ao principal. Depois disso, estar em sincronia com os dados do principal requer a criação de um novo Clone Remoto Atualizável e o descarte não atualizado.

Considerações sobre a Localização da Pasta de Configuração `tns_admin`

Considere o seguinte para a pasta de configuração tns_admin.

Use um local consistente para a pasta tns_admin
As camadas intermediárias em um Domínio WebLogic usam uma pasta para armazenar a wallet do Oracle Autonomous Database e o arquivo tnsnames.ora. A propriedade oracle.net.tns_admin aponta para essa pasta nos arquivos de configuração jps e origens de dados. O caminho desta pasta deve ser o mesmo nas camadas principal e stand-by. Se o caminho da pasta for diferente, altere a pasta em principal ou stand-by; portanto, eles usam a mesma pasta, antes de executar os scripts de configuração de DR (recuperação de desastres).
Observação:
O seguinte pode causar diferenças entre principal e standby neste local de pasta:
- As instâncias do Oracle SOA Suite on Marketplace provisionadas antes do final de fevereiro de 2023 (antes da versão 23.1.1) usam $DOMAIN_HOME/config/atp para a pasta tns_admin. A partir da release 23.1.1, o local é $DOMAIN_HOME/config/tnsadmin.
A pasta tns_admin na pasta config do domínio
Verifique o local da wallet do Oracle Autonomous Database na configuração da origem de dados WebLogic. Se a wallet não estiver localizada no diretório DOMAIN_HOME/config, as alterações no conteúdo do diretório da wallet NÃO serão replicadas pela infraestrutura do Oracle WebLogic Server para outros nós automaticamente. Nesses casos, você deve alterar o diretório da wallet (e atualizar as configurações de origens de dados necessárias) ou copiá-lo manualmente para outros nós quando ele for atualizado.