Configuración de una solución de DR con Oracle Autonomous Database

Configurar una solución de DR con Oracle Autonomous Database

Para garantizar la continuidad del negocio en caso de desastres, deberá implantar una estrategia de recuperación ante desastres (DR) para sus aplicaciones de Oracle WebLogic Suite. Esta solución proporciona protección de datos y permite utilizar Oracle Autonomous Database para cambiar rápidamente al sistema en espera con una pérdida mínima de datos y productividad.

Puede configurar y gestionar un sistema de recuperación ante desastres que utilice Oracle Autonomous Database como base de datos para Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace o cualquier otro servicio de nivel medio de Oracle Cloud Infrastructure (OCI) que utilice Oracle Fusion Middleware.

Oracle Autonomous Database Serverless y Oracle Exadata Database Service on Dedicated Infrastructure proporcionan una función de instantánea en espera. Esto permite abrir temporalmente la base de datos en espera para lectura-escritura. Al convertir la base de datos en espera en una base de datos de instantánea en espera, se puede actualizar por completo. Continúa recibiendo los datos redo de su base de datos de origen remoto (por lo que aún está protegido contra DR), pero no aplica redo hasta que se vuelve a convertir a una base de datos física en espera. Todos los cambios realizados en una base de datos de instantánea en espera se revierten cuando se vuelve a convertir a la base de datos física en espera. Utilice esta función para aprovisionar el sistema de nivel medio en la región en espera. También puede utilizar esta función durante el ciclo de vida del sistema de DR para validar el sistema en espera sin realizar un switchover completo.

Además de la función de instantánea en espera, Oracle Autonomous Database Serverless proporciona clonaciones de refrescamiento remoto. Esto proporciona una funcionalidad equivalente a la funcionalidad tradicional de la base de datos de instantánea en espera de Oracle Data Guard, pero mediante una base de datos adicional. La clonación de refrescamiento remoto se gestiona de forma individual y por separado de la base de datos en espera de Oracle Autonomous Data Guard. Al utilizar Oracle Autonomous Database Serverless, puede utilizar una clonación de refrescamiento remoto en lugar de una base de datos de instantánea en espera para aprovisionar el sistema de nivel medio en la región secundaria o realizar tareas en espera como pruebas, apertura para validaciones, aplicación de parches, etc. Sin embargo, las bases de datos de clonación en espera y de refrescamiento utilizan diferentes carteras de conexión y sus cadenas de conexión se deben gestionar correctamente para realizar estas tareas.

Antes de empezar

Hay varios resúmenes técnicos de Oracle Maximum Availability Architecture (MAA) que describen cómo configurar un sistema de recuperación ante desastres (DR) para Oracle WebLogic Server for Oracle Cloud Infrastructure y Oracle SOA Suite on Marketplace cuando estos sistemas de middleware utilizan Oracle Base Database Service.

Las topologías de DR de Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace y Oracle Fusion Middleware utilizan un modelo activo-pasivo. El sistema principal es un centro de datos de Oracle Cloud Infrastructure (OCI) y un sistema secundario en un centro de datos OCI diferente y remoto.

Revise lo siguiente para obtener más detalles y topologías para cada caso:

En los documentos anteriores se proporcionan detalles detallados, pasos de configuración y gestión, así como muchas otras consideraciones, para Oracle WebLogic Server for Oracle Cloud Infrastructure y Oracle SOA Suite on Marketplace.

Además de los resúmenes técnicos, asegúrese de estar familiarizado con los conceptos y la administración de Oracle Cloud Infrastructure (OCI), incluidas las redes, las instancias informáticas, el equilibrio de carga y Oracle Autonomous Database antes de continuar con el análisis y los pasos descritos en este manual.

Los pasos y ejemplos de este manual se verifican con Oracle WebLogic Server para OCI y Oracle SOA Suite en Marketplace para los siguientes escenarios:

Oracle Autonomous Data Guard en Oracle Exadata Database Service on Dedicated Infrastructure, mediante la función Instantánea en espera para la configuración de recuperación ante desastres.
Oracle Autonomous Data Guard en Oracle Autonomous Database Serverless, mediante la función Instantánea en espera para la configuración de recuperación ante desastres.
Oracle Autonomous Data Guard en Oracle Autonomous Database Serverless, mediante Clonaciones de refrescamiento remoto para la configuración de recuperación ante desastres.

La mayoría de los pasos son comunes para los tres escenarios. Solo algunos de los pasos difieren y son específicos de cada caso.

No debería ser difícil ajustar los pasos a ningún sistema de Oracle WebLogic Server u Oracle Fusion Middleware que utilice Oracle Autonomous Database.

Arquitectura

Este diagrama de arquitectura muestra la topología del sistema de recuperación ante desastres (DR) para los enfoques utilizados en este manual. Toda la información de tiempo de ejecución, configuración y metadatos que reside en la base de datos primaria se replica de la región 1 a la región 2 con Oracle Autonomous Data Guard. Las topologías de DR de Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace y Oracle Fusion Middleware utilizan un modelo activo-pasivo. El sistema principal es un centro de datos de Oracle Cloud Infrastructure (OCI) y un sistema secundario en un centro de datos OCI diferente y remoto.

La configuración del dominio de Oracle WebLogic se replica mediante un directorio temporal de Oracle Cloud Infrastructure File Storage (OCI File Storage) en la región principal, que se replica en un directorio temporal de OCI File Storage en la región secundaria. A continuación, la configuración se copia en el directorio de dominio real en el secundario. La copia directa del dominio presenta riesgos que se evitan mediante un directorio temporal. Dado que las copias de archivos son una operación no transaccional, se realiza una primera copia en un directorio temporal. Los archivos se verifican primero en este directorio intermedio y, a continuación, se transfieren al dominio real (final) de Oracle WebLogic.

A continuación se muestra la descripción de wls-dr-adb.png

Descripción de la ilustración wls-dr-adb.png

wls-dr-adb-oracle.zip

La topología es típica de lo que utilizan los entornos de recuperación ante desastres de Oracle WebLogic Server, Oracle SOA u Oracle Fusion Middleware en OCI. Para aprovisionar el nivel medio en espera y para operaciones de ciclo de vida como la prueba secundaria, convierta Oracle Autonomous Database en espera en una base de datos de instantánea en espera o utilice una clonación de refrescamiento remoto.

Al utilizar una clonación de refrescamiento remoto, hay una "base de datos auxiliar" (una clonación de refrescamiento en una región remota) para el aprovisionamiento inicial y para las operaciones de prueba y validación en la secundaria. En este caso, la capa media secundaria se configura con orígenes de datos que se deben volver a cambiar a la dirección en espera en los eventos de switchover y failover.

Esta arquitectura soporta los siguientes componentes:

Región
Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones, y las grandes distancias pueden separarlas (entre países e incluso continentes).
Dominio de disponibilidad
Los dominios de disponibilidad son centros de datos independientes dentro de una región. Los recursos físicos de cada dominio de disponibilidad están aislados de los recursos de los otros dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten infraestructura, como la alimentación o la refrigeración, ni la red interna del dominio de disponibilidad. Por tanto, un fallo en un dominio de disponibilidad no debería afectar a los otros dominios de disponibilidad de la región.
Dominio de errores
Un dominio de errores es una agrupación de hardware e infraestructura dentro de un dominio de disponibilidad. Cada dominio de disponibilidad tiene tres dominios de errores con energía y hardware independientes. Al distribuir recursos entre varios dominios de errores, sus aplicaciones pueden tolerar fallos en el servidor físico, el mantenimiento del sistema y los fallos de energía dentro de un dominio de errores.
Red virtual en la nube (VCN) y subred
Una VCN es una red personalizable y definida por software que se configura en una región de Oracle Cloud Infrastructure. Al igual que las redes de centros de datos tradicionales, las redes virtuales le proporcionan un control completo de su entorno de red. Una VCN puede tener varios bloques CIDR no superpuestos que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, que se pueden acotar a una región o a un dominio de disponibilidad. Cada subred está compuesta por un rango contiguo de direcciones que no se solapan con las demás subredes de la VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.
Equilibrador de carga
El servicio Oracle Cloud Infrastructure Load Balancing proporciona una distribución automatizada de tráfico desde un único punto de entrada a varios servidores en el backend.
Dominio de Oracle WebLogic
Un dominio es la unidad de administración básica para las instancias de servidor WebLogic. Un dominio consta de una o más instancias del servidor WebLogic (y sus recursos asociados), que se gestionan con un único servidor de administración. El dominio de Oracle WebLogic se configura siguiendo las mejores prácticas de Oracle Maximum Availability Architecture (MAA) para alta disponibilidad.
Gateway de enrutamiento dinámico (DRG)
El DRG es un enrutador virtual que proporciona una ruta para el tráfico de red privada entre las redes virtuales de la misma región, entre una VCN y una red fuera de la región, como una VCN de otra región de Oracle Cloud Infrastructure, una red local o una red de otro proveedor en la nube.
Lista de seguridad
Para cada subred, puede crear reglas de seguridad que especifiquen el origen, el destino y el tipo de tráfico que se debe permitir dentro y fuera de la subred.
Almacenamiento de archivos de Oracle Cloud Infrastructure
El servicio Oracle Cloud Infrastructure File Storage ofrece un sistema de archivos de red duradero, escalable, seguro y empresarial. Puede conectarse a un sistema de archivos del servicio File Storage desde cualquier instancia con hardware dedicado, de máquina virtual o de contenedor en su red virtual en la nube (VCN). El servicio de almacenamiento de archivos admite el protocolo del sistema de archivos de red versión 3.0 (NFSv3). El servicio soporta el protocolo de administrador de bloqueo de red (NLM) para la funcionalidad de bloqueo de archivos.

Oracle Cloud Infrastructure File Storage utiliza un almacenamiento replicado en 5 direcciones, ubicado en diferentes dominios de errores, para proporcionar redundancia a la protección de datos resiliente. Los datos están protegidos con la codificación de supresión. El servicio está diseñado para cumplir las necesidades de aplicaciones y usuarios que necesitan un sistema de archivos de empresa en una amplia gama de casos de uso.
Autonomous Database
Oracle Autonomous Database es un entorno de base de datos totalmente gestionado y preconfigurado que puede utilizar para cargas de trabajo de procesamiento de transacciones y almacenamiento de datos. No necesita configurar ni gestionar ningún hardware, ni instalar ningún software. Oracle Cloud Infrastructure gestiona la creación de la base de datos, así como la realización de copias de seguridad, la aplicación de parches, la actualización y el ajuste de la base de datos.
Oracle Autonomous Database en infraestructura de Exadata dedicada
Oracle Autonomous Database on Dedicated Exadata Infrastructure es una instancia de Oracle Autonomous Database con una base de datos privada en la nube pública. Con su base de datos dedicada, obtiene un servicio informático, de almacenamiento, de red y de base de datos completamente dedicado que proporciona los niveles de seguridad, aislamiento y gobernanza más altos.
Oracle Autonomous Database Serverless

Oracle Autonomous Database Serverless es una instancia de Oracle Autonomous Database. Tiene una base de datos totalmente flexible en la que Oracle opera de manera autónoma todos los aspectos del ciclo de vida de la base de datos, desde la ubicación de la base de datos hasta la realización de copias de seguridad y las actualizaciones.
Data Guard
Oracle Data Guard proporciona un completo conjunto de servicios que permite crear, mantener, gestionar y supervisar una o más bases de datos en espera para permitir que las bases de datos Oracle de producción permanezcan disponibles sin interrupción. Oracle Data Guard mantiene estas bases de datos en espera como copias de la base de datos de producción. A continuación, si la base de datos de producción deja de estar disponible debido a una interrupción planificada o no planificada, Oracle Data Guard puede cambiar cualquier base de datos en espera al rol de producción, minimizando el tiempo de inactividad asociado a la interrupción.
Oracle Autonomous Data Guard
Oracle Autonomous Data Guard permite que una base de datos en espera (peer) proporcione protección de datos y recuperación ante desastres para la instancia de Autonomous Database. Proporciona un conjunto completo de servicios que crean, mantienen, gestionan y controlan una o más bases de datos en espera para permitir que las bases de datos Oracle de producción permanezcan disponibles sin interrupción. Oracle Data Guard mantiene estas bases de datos en espera como copias de la base de datos de producción. A continuación, si la base de datos de producción deja de estar disponible debido a una interrupción planificada o no planificada, puede cambiar cualquier base de datos en espera al rol de producción, minimizando el tiempo de inactividad asociado a la interrupción.
En espera de instantánea
Una base de datos de instantánea en espera es una base de datos en espera completamente actualizable creada mediante la conversión de una base de datos física en espera en una base de datos de instantánea en espera.

Una base de datos de instantánea en espera recibe y archiva, pero no aplica, los datos redo de una base de datos primaria. Los datos redo recibidos de la base de datos primaria se aplican una vez que una base de datos de instantánea en espera se vuelve a convertir en una base de datos física en espera, después de desechar todas las actualizaciones locales en la base de datos de instantánea en espera.
clonación de refrescamiento
Oracle Autonomous Database proporciona una clonación donde puede optar por crear una clonación completa de la instancia activa, una clonación de metadatos o una clonación de refrescamiento. Con una clonación de refrescamiento, el sistema crea una clonación que se puede actualizar fácilmente con cambios de la base de datos de origen.

Consideraciones para el Nivel Medio

Todas las consideraciones de Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery y SOA Suite en Oracle Cloud Infrastructure Marketplace Disaster Recovery para la capa media se aplican en los escenarios de Oracle Autonomous Database descritos en este documento.

Tenga en cuenta los siguientes aspectos para la capa media:

Dirección de front-end
El acceso de los clientes al sistema Oracle WebLogic Server debe ser independiente del sitio que se utilice como sitio principal. Para ello, el nombre de dirección de front-end utilizado para acceder al sistema debe ser único y siempre apuntar al sistema principal en este momento. Este nombre suele denominarse front-end virtual o URL personalizada.

Puede reutilizar la dirección de nombre de host de front-end del sistema existente como front-end virtual para la protección ante desastres. Por ejemplo, si el sistema original tiene mywebapps.example.com como URL personalizada para el sistema principal, puede volver a asignar el mismo nombre de host virtual a la IP del equilibrador de carga del segundo sitio después de una operación de switchover o failover.

Utilice un servicio de sistema de nombres de dominio (DNS) adecuado para asignar el nombre de front-end a cualquier sitio. Por ejemplo, (servicio Oracle Cloud Infrastructure DNS, resolución de otros DNS comerciales, DNS local o hosts locales).
Prefijo de Nombre de Instancia
Proporcione Instance Name Prefix al aprovisionar Oracle WebLogic Server para OCI u Oracle SOA Suite en Marketplace. Esta propiedad se utiliza para crear los nombres de todos los recursos, incluidos: el nombre de dominio del servidor WebLogic, el nombre de cluster, los nombres de servidor WebLogic, los nombres de host de la máquina virtual, etc.

Defina Instance Name Prefix en el mismo valor en los sistemas Oracle WebLogic Server primario y secundario, de modo que ambos sistemas tengan el mismo nombre para los recursos de Oracle WebLogic. El uso del mismo nombre garantiza la consistencia y es necesario para la recuperación de mensajes JMS y TLogs. También simplifica las personalizaciones y operaciones en ambos sitios.

Puede utilizar el mismo Instance Name Prefix en varias instancias del mismo arrendamiento de Oracle Cloud, siempre que lo cree en diferentes regiones o compartimentos. Cada instancia solo se muestra en su región y compartimento específicos.

El proceso de aprovisionamiento de Oracle SOA Suite on Marketplace proporciona una función opcional que permite configurar nombres personalizados para el dominio, el cluster, el servidor de administración, el prefijo del servidor gestionado, etc. En ese caso, los nombres no se derivan de Instance Name Prefix. En su lugar, toman los valores proporcionados. Es posible utilizar esta función en la topología de recuperación ante desastres (DR) descrita en este documento, siempre que los nombres personalizados proporcionados sean los mismos en los sistemas principal y en espera.
Archivos personalizados
La mayor parte de la configuración de dominio de Oracle WebLogic Server para OCI que utiliza WebLogic Cloud se sincroniza inicialmente entre sitios con las siguientes consideraciones:

Cada sistema WebLogic mantiene las URL de JDBC originales utilizadas para conectarse a su base de datos local, incluso después de que se haya completado la configuración de DR. Solo se modifica el prefijo del esquema para que ambas ubicaciones apunten a los mismos esquemas (esquemas primarios).

La función de infraestructura de dominio WebLogic distribuye automáticamente la configuración en el directorio weblogic_domain_name/config a los otros nodos del mismo dominio.

Los despliegues de aplicaciones personalizadas (archivos de oído/guerra, planes de despliegue, etc.) y todo lo que resida en el directorio de dominio de Oracle WebLogic Administration Server (excepto los datos temporales) se sincronizan inicialmente entre los sitios mediante los procedimientos descritos en este documento. Si Oracle WebLogic Administration Server utiliza datos que residen en otros nodos o fuera del directorio de dominio, debe copiarlos manualmente en la ubicación secundaria. Más adelante, se proporcionan detalles adicionales sobre la replicación de la configuración.

Consideraciones sobre la base de datos de instantánea en espera en Oracle Autonomous Database Serverless

Al implantar esta solución, tenga en cuenta lo siguiente al activar la base de datos de instantánea en espera en una base de datos Oracle Autonomous Database Serverless.

Límite de tiempo para la base de datos de instantánea en espera en una infraestructura sin servidor
Cuando una instantánea en espera en Oracle Autonomous Database Serverless no se vuelve a conectar en un plazo de 48 horas, la instantánea en espera se vuelve a conectar automáticamente a la base de datos origen.
Conversión de vuelta al par de recuperación ante desastres
Oracle recomienda que vuelva a convertir una base de datos de instantánea en espera en un par de recuperación ante desastres tan pronto como haya terminado con las operaciones que necesitaban que la base de datos en espera estuviera abierta para operaciones de lectura y escritura. Al volver a convertir a un par de recuperación ante desastres, los cambios acumulados de la base de datos de origen se aplican al par. Si mantiene el par de recuperación ante desastres abierto como una instantánea en espera durante un período más largo, suponiendo que hay cambios continuos en la base de datos primaria durante este tiempo, tardará más en volver a convertirse en un par de recuperación ante desastres.
Implicaciones de costos de la instantánea en espera en Oracle Autonomous Database Serverless
El uso de la CPU en espera de instantánea se factura según el recuento de CPU base y cualquier uso de CPU adicional si la escala automática de recursos informáticos está activada. El número de CPU base se especifica mediante el número de ECPU (OCPU si la base de datos utiliza OCPU), como se muestra en el campo Recuento de ECPU o Recuento de OCPU de la consola de Oracle Cloud Infrastructure.

El uso del almacenamiento de instantánea en espera se factura según el almacenamiento de la instantánea en espera más 1 veces el almacenamiento de la base de datos principal de origen.

Para obtener más información, consulte Acerca de las bases de datos en espera de instantáneas de recuperación ante desastres.

Consideraciones para la base de datos de instantánea en espera en Oracle Autonomous Database on Dedicated Exadata Infrastructure

Al implantar esta solución, tenga en cuenta lo siguiente al activar la base de datos de instantánea en espera en una instancia de Oracle Autonomous Database on Dedicated Exadata Infrastructure.

Límite de tiempo para la base de datos de instantánea en espera en una infraestructura dedicada
Cuando una instantánea en espera de Oracle Autonomous Database on Dedicated Exadata Infrastructure no se convierte a una base de datos física en espera en un plazo de 7 días, la base de datos de instantánea en espera se convierte automáticamente a una base de datos física en espera.
Conversión de nuevo a una base de datos física en espera
Oracle recomienda que vuelva a convertir una base de datos de instantánea en espera en una base de datos física en espera en cuanto termine con las operaciones que requieren que la base de datos en espera esté abierta para operaciones de lectura y escritura. Al volver a convertir la base de datos física en espera, los cambios acumulados de la base de datos origen se aplican en la base de datos en espera. Si mantiene la base de datos en espera abierta como base de datos de instantánea en espera durante un período más largo, suponiendo que hay cambios continuos en la base de datos primaria durante este tiempo, tardará más en volver a convertirla en una base de datos física en espera.
Servicios de base de datos al convertir a una base de datos de instantánea en espera
En Oracle Autonomous Database on Dedicated Exadata Infrastructure, el cuadro de diálogo "Convertir a instantánea en espera" muestra dos opciones:
- Usar nuevos servicios de base de datos: seleccione esta opción para conectarse a una instantánea en espera utilizando nuevos servicios que solo están activos en el modo de instantánea en espera.
- Usar servicios de base de datos principal: seleccione esta opción si desea conectarse a la base de datos de instantánea en espera utilizando los mismos servicios que la base de datos principal.
Para la configuración de recuperación ante desastres, utilice la opción Utilizar servicios de base de datos primaria al convertir la base de datos en espera en física en espera. De esta forma, el nombre de alias de conexión configurado por Oracle WebLogic Server en el nivel medio secundario es consistente con el principal.

Para obtener más información, consulte Acerca de Autonomous Data Guard.

Consideraciones para clonaciones de refrescamiento remoto en Oracle Autonomous Database Serverless

Tenga en cuenta lo siguiente al utilizar una clonación de refrescamiento de Oracle Autonomous Database Serverless para probar y validar un sistema Oracle WebLogic Server for Oracle Cloud Infrastructure secundario, Oracle SOA Suite on Marketplace u Oracle Fusion Middleware.

Ciclo de vida de clonaciones de refrescamiento
A diferencia de una base de datos en espera tradicional de Oracle Data Guard, las clonaciones de refrescamiento remoto se activan por separado y se gestionan por separado de una base de datos primaria y una base de datos en espera. Se trata de una entidad independiente con su propio ciclo de vida más allá de las operaciones de refrescamiento que la sincronizan con su base de datos de origen (principal).
Asignación de Recursos de CPU
Las clonaciones de refrescamiento remoto no se crean según la asignación de recursos de CPU del sistema principal o en espera. Esto significa que debe especificar opciones de OCPU para la clonación de refrescamiento por separado. Debe configurar manualmente las pruebas de carga de trabajo en la clonación de refrescamiento remota para que coincidan con la capacidad del sistema principal. Idealmente, debe crear la clonación de refrescamiento remota con una configuración que coincida con la base de datos principal para que las cargas de trabajo de prueba sean realistas en la secundaria. Sin embargo, las clonaciones de refrescamiento remotas "llevan" la configuración de almacenamiento utilizada en la base de datos primaria.
Aplicación de Parches
Los parches se aplican automáticamente semanalmente en Oracle Autonomous Database Serverless, por la ventana de mantenimiento semanal, por lo que hay una sincronización continua y forzada de parches entre la clonación de refrescamiento principal, en espera y remota.
Los límites de los servicios
Las clonaciones de refrescamiento remotas son una entidad de primera clase, conllevan un costo adicional por las implicaciones de almacenamiento, CPU y licencia de una instancia de Autonomous Database formal y contarán para los límites de servicio de la región para Oracle Autonomous Database Serverless.
Clonación de refrescamiento en switchover
Cuando se produce un failover o un "switchover no inmediatamente reversible", debe crear manualmente una clonación de refrescamiento en la base de datos primaria para mantener el sistema listo para las operaciones de prueba y mantenimiento en el sistema secundario, con los límites de servicio, la gestión y otras consideraciones adecuados. Las clonaciones de refrescamiento remoto carecen de control de reversión de roles.

Después de un switchover al secundario, la clonación de refrescamiento creada no podrá refrescarse más (ya que su origen es ahora un origen en espera) y se marca como desconectado. Después de 24 horas se convierte en un clon no refrescante y desconectado.
Ventana de refrescamiento de clonaciones de refrescamiento
Las clonaciones de refrescamiento remoto se deben refrescar al menos una vez a la semana. Después de eso, estar sincronizado con los datos del principal requiere crear una nueva clonación de refrescamiento remota y desechar la no refrescada.
Modo de escritura de clonaciones de refrescamiento
Las clonaciones de refrescamiento remoto no pueden permanecer en modo de escritura (desconectarse de la principal) durante más de 24 horas. Después de ese período, la base de datos de clonaciones de refrescamiento remota no se puede volver a conectar a su base de datos principal. Después de eso, estar sincronizado con los datos del principal requiere crear una nueva clonación de refrescamiento remoto y desechar la no refrescada.

Consideraciones para la ubicación de la carpeta de configuración `tns_admin`

Tenga en cuenta lo siguiente para la carpeta de configuración tns_admin.

Utilice una ubicación consistente para la carpeta tns_admin
Los niveles intermedios de un dominio WebLogic utilizan una carpeta para almacenar la cartera de Oracle Autonomous Database y el archivo tnsnames.ora. La propiedad oracle.net.tns_admin apunta a esta carpeta en los orígenes de datos y los archivos de configuración de jps. La ruta de acceso de esta carpeta debe ser la misma en las matrices principal y en espera. Si la ruta de acceso de la carpeta es diferente, cambie la carpeta en la base de datos primaria o en espera, de modo que utilice la misma carpeta antes de ejecutar los scripts de configuración de recuperación ante desastres (DR).
Nota:
Las siguientes pueden provocar diferencias entre la base de datos primaria y la base de datos en espera en esta ubicación de carpeta:
- Las instancias de Oracle SOA Suite en Marketplace aprovisionadas antes de finales de febrero de 2023 (antes de la versión 23.1.1) utilizan $DOMAIN_HOME/config/atp para la carpeta tns_admin. A partir de la versión 23.1.1, la ubicación es $DOMAIN_HOME/config/tnsadmin.
La carpeta tns_admin en la carpeta del dominio config
Compruebe la ubicación de la cartera de Oracle Autonomous Database en la configuración del origen de datos WebLogic. Si la cartera no se encuentra en el directorio DOMAIN_HOME/config, la infraestructura de Oracle WebLogic Server NO replicará automáticamente los cambios en el contenido del directorio de cartera en otros nodos. En estos casos, debe cambiar el directorio de cartera (y actualizar las configuraciones de orígenes de datos necesarias) o copiarlo manualmente en otros nodos cuando se actualice.