Configurar el entorno
Los scripts están disponibles para automatizar algunos de los pasos. Estos scripts no automatizan la configuración completa, por lo que debe completar las tareas y puede usar los scripts cuando se hace referencia a ellos.
Vaya a Descargar código del enlace para descargar los scripts a los que se hace referencia en este documento.
Preparación de los orígenes de datos WebLogic en el centro de datos principal
El alias TNS es el mismo nombre en el primario y el secundario; por lo tanto, los orígenes de datos utilizan la misma cadena de conexión de base de datos. Se resuelve con un archivo tnsnames.ora
que no se copia en espera, por lo que puede tener contenido tnsnames.ora
diferente en cada sitio. Puede colocarlo por separado de la configuración de dominio WebLogic, en un sistema de archivos que no se replica entre sitios. O bien, dado que forma parte de la configuración, también puede almacenarlo en una carpeta en la configuración de dominio. En este caso, asegúrese de excluir esa carpeta al copiar la configuración de dominio de principal a en espera. Cada sitio resolverá el alias TNS con la cadena de conexión adecuada en cada sitio, apuntando solo a la base de datos local. Por ejemplo:
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))
)
A continuación, se muestran las ventajas del uso del alias TNS:
- Como se utiliza la misma cadena de conexión de base de datos en el dominio WebLogic
config
, no es necesario modificar la configuración WebLogic después de replicarconfig
de la base de datos principal a la base de datos en espera. - Como cada sitio apunta solo a la base de datos local, no hay riesgo de interconexiones desde el nivel medio a la base de datos remota.
Si aún no está utilizando este enfoque en el sistema WebLogic Server principal, realice los siguientes pasos para utilizar un alias TNS en los orígenes de datos.
Configuración de la red
Configurar Oracle Data Guard
Acerca de la versión de la base de datos y el nivel de parche
El directorio raíz de Oracle de la base de datos local y la base de datos en espera de OCI deben tener la misma versión y el mismo nivel de parche. Puede realizar esta acción de las siguientes formas:
- Al seleccionar la imagen de software de base de datos durante el aprovisionamiento del sistema de base de datos en OCI, seleccione Mostrar todas las versiones y seleccione la misma versión de base de datos y el mismo nivel de juego de parches que la base de datos local.
- Si la versión del directorio raíz de Oracle de la base de datos origen ya no está disponible en OCI para el aprovisionamiento, tendrá que aplicar parches al entorno de origen al mismo nivel de parche de la base de datos que el directorio raíz de la base de datos en el entorno en la nube.
El siguiente escenario es un ejemplo real de referencia. El directorio raíz de base de datos local es 19.6 y el directorio raíz de base de datos de OCI es 19.11.
- Ejecute el comando
$ORACLE_HOME/OPatch/opatch lspatches
para identificar los parches instalados en los entornos de origen y destino.$ORACLE_HOME/OPatch/opatch lspatches
La siguiente es la salida de este ejemplo:
Parches de directorio raíz de base de datos de Oracle locales Parches de DB Oracle HOME en OCI 30676209;LNX64-20.1-RAC EXCEPCIÓN DE ACIERTO DE ASM ORA-07445 SE HA ENCONTRADO UN VOLCADO DEL NÚCLEO CENTRAL [KSXPOSDIFQRY()+556]
30613937;IPCOR TOPO SERVICE FIX IP TYPE BUG IN IP SELECTION
30484981;ACTUALIZACIÓN DE VERSIÓN DE OEM: 19.6.0.0.200114 (30484981)
30489227;ACTUALIZACIÓN DE VERSIÓN DE OCW 19.6.0.0.0 (30489227)
30557433;Actualización de la Versión de la Base de Datos: 19.6.0.0.200114 (30557433)
29780459;AUMENTE _LM_RES_HASH_BUCKET Y RETROCEDA LOS CAMBIOS DEL BUG 29416368 FIX
30310195;DBSAT INFORMÓ RESTRICCIONES DESACTIVADAS PARA LA PARTICIÓN HORIZONTAL STS_CHUNKS EN GSMADMIN_INTERNAL.SHARD_TS
32327201;RDBMS - ACTUALIZACIÓN DSTV36 - TZDATA2020E
31335037;RDBMS - ACTUALIZACIÓN DSTV35 - TZDATA2020A
30432118;SOLICITUD DE FUSIÓN SOBRE 19.0.0.0.0 PARA ERRORES 28852325 29997937
31732095;ACTUALIZAR PERL EN ORACLE HOME DE LA BASE DE DATOS 19C A V5.32
32490416;PARCHE DE PAQUETE DE JDK 19.0.0.0.210420
32399816;ACTUALIZACIÓN DE VERSIÓN DE OEM: 19.11.0.0.210420 (32399816)
32579761;ACTUALIZACIÓN DE VERSIÓN DE OCW 19.11.0.0.0 (32579761)
32545013;Actualización de la Versión de la Base de Datos: 19.11.0.0.210420 (32545013)
- Analice los parches existentes: determine qué parches son puntuales, revise si ya están corregidos en los nuevos parches de RU o si se necesitan nuevos parches superpuestos, determine cuál de ellos se debe desinstalar, localice los archivos de parches adecuados para RU, etc.
- Según el análisis, desinstale los parches puntuales que ya están corregidos en la nueva RU antes de instalar la actualización de la RU (de lo contrario, provocarán conflictos). En este ejemplo, los parches desactivados se corrigen en 19.11, por lo que se debe realizar un rollback de los parches antes de instalar la RU 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
- Localice, descargue e instale los parches de RU. En este ejemplo, los parches RU 19.11 están ubicados en el parche combinado 32578973: COMBO OF OJVM RU COMPONENT 19.11.0.0.210420 + GI RU 19.11.0.0.210420 y son los siguientes:
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)
- Localice, descargue e instale las superposiciones, puntuales y otros parches que el directorio raíz de base de datos de OCI tiene sobre la RU. Por ejemplo:
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
- Realice un análisis similar para los parches de GI.
Nota:
- Desde la perspectiva de Oracle Data Guard, no es estrictamente necesario tener las mismas versiones de GI en la base de datos primaria y en espera: Oracle Data Guard es completamente independiente de cualquier elemento de la base de datos, por lo que puede ejecutar diferentes versiones del sistema operativo, Oracle Clusterware, hardware o software de almacenamiento en diferentes ubicaciones sin restricciones de versiones ni tiempo. (ID de documento 12655700.1)
- Independientemente de Oracle Data Guard, no es necesario tener la misma versión en las versiones de GI y RDBMS en una base de datos RAC: a partir de la versión 18c, la versión de Oracle Grid Infrastructure (GI) /Clusterware (CRS) debe ser igual o la versión más alta hasta el primer dígito en las combinaciones posibles en todo momento. Por ejemplo: la infraestructura de Grid puede estar en 18.1.0.0 y la base de datos en 18.3.0.0. (ID de documento 337737.1)
Se recomienda aplicar parches a GI al mismo nivel que el directorio raíz de base de datos. Una vez que tenga que aplicar parches al directorio raíz de base de datos a una actualización de versión (RU) más reciente, muchos de los parches son comunes para la base de datos y GI, y puede utilizar OPatchAuto
en ambos directorios raíz al mismo tiempo.