Configurar o Ambiente
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
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:@soapdb
The tnsnames.ora file in primary contains:
SOAPDB =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=soapdb.example.com))
)
Connect string in data sources in secondary site:
jdbc:oracle:thin:@soapdb
The tnsnames.ora file in secondary:
SOAPDB =
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=soapdb.example.com))
)
Estas são as vantagens do uso do alias TNS:
- Como a mesma string de conexão do bd é usada no domínio WebLogic
config
, você não precisa alterar a configuração WebLogic após replicar oconfig
do principal para o standby. - Como cada site aponta apenas para o banco de dados local, não há risco de conexões cruzadas da camada intermediária com o banco de dados remoto.
Se você ainda não estiver usando essa abordagem no sistema SOA principal, execute as etapas a seguir para usar um alias TNS nas origens de dados.
Configurar a Rede
Configurar Oracle Data Guard
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 formas:
- 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, você terá de aplicar patch ao ambiente de origem para o 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 de BD local é 19.6 e o Home de BD do OCI é 19.11.
- Execute o comando
$ORACLE_HOME/OPatch/opatch lspatches
para identificar os patches instalados nos ambientes de Origem e 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 EXCEÇÃO DE ASM ORA-07445 ENCONTRADA DUMP DE NÚCLEO [KSXPOSDIFQRY()+556]
30613937;ERRO DO TIPO IPCOR TOPO DE SERVIÇO DE CORREÇÃO NA SELEÇÃO IP
30484981;ATUALIZAÇÃO DA VERSÃO DO JVM: 19.6.0.0.200114 (30484981)
30489227;OCW RELEASE UPDATE 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 DA CORREÇÃO DE BUG 29416368
30310195;RESTRIÇÕES DESATIVADAS REPORTADAS PARA SHARDING STS_CHUNKS EM GSMADMIN_INTERNAL.SHARD_TS
32327201;RDBMS - DSTV36 ATUALIZAÇÃO - TZDATA2020E
31335037;RDBMS - DSTV35 ATUALIZAÇÃO - TZDATA2020A
30432118;SOLICITAÇÃO DE MESCLAGEM NO INÍCIO 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 VERSÃO DO OJVM: 19.11.0.0.210420 (32399816)
32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761)
32545013;Atualização da Release do Banco de Dados: 19.11.0.0.210420 (32545013)
- 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.
- Com base na análise, desinstale os patches únicos que já foram corrigidos na nova RU antes de instalar a atualização RU (caso contrário, eles causarão conflito). Neste exemplo, os patches in-off são corrigidos na versão 19.11, portanto, os patches devem ser revertidos antes da instalação da versão 19.11.
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
- Localize, faça download e instale os patches da RU. Neste exemplo, os patches RU 19.11 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)
- Localize, faça download e instale as sobreposições, pontuações e outros patches que o Home de BD do OCI tem sobre o 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
- Execute uma análise semelhante para os patches de GI.
Observação:
- 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 prática recomendada aplicar patches de 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.