Documentación de Oracle Cloud Infrastructure

Mejores prácticas para conexiones de baja latencia con Autonomous Database

Tomar medidas para reducir la latencia de las conexiones entre una aplicación y Autonomous Database es fundamental si la aplicación realiza muchas idas y vueltas entre la aplicación y la base de datos.

Por ejemplo, considere una aplicación OLTP que se conecte a Autonomous Database y envíe miles de sentencias SQL a la base de datos de forma individual para ejecutar una orden de venta. En este caso, la aplicación requiere miles de viajes de ida y vuelta, y la reducción de la latencia para cada viaje de ida y vuelta puede acelerar considerablemente el proceso de órdenes de venta. Para estas aplicaciones, existen las mejores prácticas que puede seguir para reducir la latencia de las conexiones de base de datos.

Tema principal: Opciones y funciones de red y conexión

Pasos para Reducir la Latencia de Conexiones de Base de Datos

Puede seguir estas recomendaciones para reducir la latencia de las conexiones entre las aplicaciones y la base de datos.

Primero, determine el dominio de disponibilidad de la base de datos. Para buscar el dominio de disponibilidad de una instancia de Autonomous Database, conéctese como ADMIN y ejecute la siguiente consulta: 

SELECT json_value(cloud_identity, '$.AVAILABILITY_DOMAIN') AVAILABILITY_DOMAIN FROM v$pdbs;

Por ejemplo:

SELECT json_value(cloud_identity, '$.AVAILABILITY_DOMAIN') AVAILABILITY_DOMAIN
             FROM v$pdbs;

AVAILABILITY_DOMAIN  
-------------------- 
SoSC:US-ASHBURN-AD-1

También puede ver la información del dominio de disponibilidad en la consola de Oracle Cloud Infrastructure. Consulte Visualización de información de red en la consola de OCI para obtener más información.

Para reducir la latencia, realice lo siguiente:

  1. Coloque clientes o servidores de nivel medio en el mismo dominio de disponibilidad que la instancia de Autonomous Database.

    Por ejemplo, si la aplicación se ejecuta en una máquina virtual de Oracle Cloud Infrastructure Compute, seleccione el mismo dominio de disponibilidad que la instancia de Autonomous Database al crear la instancia informática.

    Si la aplicación se ejecuta en otra nube o en un centro de datos local, utilice OCI FastConnect para reducir la latencia de la conexión a su región de OCI. Consulte Visión general de FastConnect para obtener más información.

  2. Configure el enrutamiento de red.

    • Si utiliza una instancia de Autonomous Database en un punto final público, configure el enrutamiento de red para que la conexión del cliente a la base de datos pase a través de un gateway de servicio.

      Puede obtener más información en los siguientes enlaces.

    • Si utiliza una instancia de Autonomous Database en un punto final privado, se conecta a la base de datos mediante el punto final privado visible en la red, sin necesidad de configurar un gateway de servicio.

  3. Utilice conexiones TLS unidireccionales sin cartera.

    Como mejor práctica para reducir la latencia, configure la instancia de Autonomous Database para permitir conexiones mTLS y TLS y utilizar conexiones TLS para conectar la aplicación a la base de datos.

    Puede obtener más información en los siguientes enlaces:

  4. Utilice TCP Fast Open (TFO) para conectarse a la base de datos.

Pasos para reducir la latencia de las conexiones de base de datos para bases de datos con Autonomous Data Guard

Proporciona los pasos que se deben seguir para configurar un entorno en espera de Autonomous Data Guard, clientes y niveles intermedios, a fin de reducir la latencia de las conexiones de base de datos al conectarse después de un failover o después de un switchover (cuando la base de datos en espera se convierte en la principal).

Tema principal: Mejores prácticas para conexiones de baja latencia con Autonomous Database

Reducción de la latencia de las conexiones de base de datos con Autonomous Data Guard local

Siga estos pasos para reducir la latencia de las conexiones de base de datos que realiza cuando utiliza Autonomous Data Guard y realiza un failover o un switchover a una base de datos en espera local.

Si tiene una base de datos en espera local de Autonomous Data Guard y se encuentra en una región con varios dominios de disponibilidad, Autonomous Data Guard crea la base de datos en espera local en un dominio de disponibilidad diferente. Cuando se realiza un failover o un switchover a la base de datos en espera, la base de datos en espera local se convierte en la base de datos primaria. Para prepararse para un failover o un switchover, se recomienda tener clientes en espera y niveles intermedios disponibles para activarlos, de modo que después de un fallo o de un switchover, las aplicaciones puedan seguir trabajando en caso de que se produzca un fallo en el dominio de disponibilidad.

En primer lugar, verifique que el tipo de recuperación ante desastres para su par local sea Autonomous Data Guard. Consulte Activación de Autonomous Data Guard para obtener más información.

Realice las siguientes tareas para configurar clientes en espera y niveles medios para una baja latencia cuando utilice Autonomous Data Guard con una base de datos en espera local en una región con varios dominios de disponibilidad.

  1. Coloque los clientes en espera o niveles intermedios en el mismo dominio de disponibilidad que la base de datos en espera local (todos los componentes se deben configurar para utilizar el mismo dominio de disponibilidad).

    Por ejemplo, si la aplicación se ejecuta en una máquina virtual de Oracle Cloud Infrastructure Compute, al crear la instancia informática, seleccione el mismo dominio de disponibilidad para la máquina virtual de Compute que la base de datos en espera. De esta forma, se prepara la configuración de recuperación ante desastres para que la base de datos en espera y la máquina virtual informática en espera utilicen el mismo dominio de disponibilidad después de un failover o switchover. Esto reducirá la latencia de las conexiones a la base de datos en comparación con una configuración en la que los componentes utilizan diferentes dominios de disponibilidad.

    Para determinar el dominio de disponibilidad de la base de datos en espera, conéctese a la base de datos primaria como usuario ADMIN y ejecute la siguiente consulta:

    SELECT availability_domain FROM v$pdbs,
     JSON_TABLE(
       cloud_identity,
       '$.AUTONOMOUS_DATA_GUARD[*]'
       COLUMNS (
         standby_type PATH '$.STANDBY_TYPE',
         availability_domain PATH '$.AVAILABILITY_DOMAIN'
       )
     ) jt
WHERE jt.standby_type = 'local';

    Por ejemplo, este comando muestra el dominio de disponibilidad para una base de datos en espera local:

    AVAILABILITY_DOMAIN 
------------------- 
SoSC:US-ASHBURN-AD-3
  2. No es necesario realizar ninguna configuración de red adicional ni permitir conexiones TLS unidireccionales para la base de datos en espera local. Una base de datos en espera local tiene la misma configuración de red de instalación que la base de datos primaria.
  3. Configure los clientes y los niveles medios para utilizar TCP Fast Open.

Reduce la latencia de las conexiones a bases de datos con Autonomous Data Guard entre regiones

Siga estos pasos para reducir la latencia de las conexiones de base de datos que realiza cuando utiliza Autonomous Data Guard y realiza una operación de failover o switchover a una base de datos en espera entre regiones.

Si agrega una o más bases de datos en espera de Autonomous Data Guard entre regiones, las bases de datos en espera entre regiones se agregan en las regiones que seleccione al agregar un peer entre regiones. Cuando realiza un failover o un switchover en una base de datos en espera de Autonomous Data Guard entre regiones, la base de datos en espera entre regiones se convierte en la base de datos principal. Para prepararse para un failover o switchover regional, se recomienda tener clientes en espera y niveles medios disponibles en la región remota. De esta forma, se preparan los clientes y la capa media de la región remota para que, en caso de fallo o después de un switchover, las aplicaciones puedan seguir funcionando.

En primer lugar, verifique que la recuperación ante desastres incluye al menos una base de datos en espera de Autonomous Data Guard entre regiones. Consulte Adición de una Base de Datos en Espera entre Regiones para obtener más información.

Siga estos pasos para configurar clientes y niveles medios para una baja latencia al utilizar Autonomous Data Guard con una o más bases de datos en espera entre regiones.

  1. Coloque los clientes en espera o niveles intermedios en el mismo dominio de disponibilidad que las bases de datos en espera entre regiones.

    Para determinar los dominios de disponibilidad de las bases de datos en espera de Autonomous Data Guard entre regiones, conéctese a la base de datos principal como usuario ADMIN y ejecute la siguiente consulta: 

    SELECT availability_domain FROM v$pdbs,
     JSON_TABLE(
       cloud_identity,
       '$.AUTONOMOUS_DATA_GUARD[*]'
       COLUMNS (
         standby_type PATH '$.STANDBY_TYPE',
         availability_domain PATH '$.AVAILABILITY_DOMAIN'
       )
     ) jt
WHERE jt.standby_type = 'cross-region';

    Por ejemplo, cuando tiene dos bases de datos en espera entre regiones, al ejecutar este comando se muestran los dominios de disponibilidad para cada base de datos en espera entre regiones:

    AVAILABILITY_DOMAIN    
---------------------- 
SoSC:PHX-AD-3          
SoSC:US-SANJOSE-1-AD-1
    1. Si tiene una base de datos en espera entre regiones, la consulta muestra un único dominio de disponibilidad. Coloque los clientes en espera y los niveles medios en la misma región y utilice el mismo dominio de disponibilidad que la base de datos en espera entre regiones.

      Por ejemplo, si la aplicación se ejecuta en una máquina virtual de Oracle Cloud Infrastructure Compute, al crear la instancia informática, seleccione el mismo dominio de disponibilidad para la máquina virtual de Compute que la base de datos en espera de Autonomous Data Guard. Esto garantiza que la base de datos en espera entre regiones y la máquina virtual de recursos informáticos en espera estén en la misma región y utilicen el mismo dominio de disponibilidad después de un failover o switchover.

    2. Si dispone de más de una base de datos en espera entre regiones, en cada región utilice el dominio de disponibilidad adecuado que coincida con la región y el dominio de disponibilidad de cada base de datos en espera correspondiente. Tendrá que realizar esta configuración varias veces (todos los componentes de una región individual deben utilizar el mismo dominio de disponibilidad que la base de datos en espera de Autonomous Data Guard).

    Si la aplicación se ejecuta en otra nube o en un centro de datos local, utilice OCI FastConnect para reducir la latencia de la conexión a su región de OCI. Consulte Visión general de FastConnect para obtener más información.

  2. Configure el enrutamiento de red en la región en la que reside la base de datos en espera. Realice este paso varias veces si tiene más de una base de datos en espera entre regiones.
    1. Si la base de datos en espera está en un punto final público, configure el enrutamiento de red para que la conexión de los clientes de la región en la que está la base de datos en espera entre regiones pase por un gateway de servicios.
    2. Si la base de datos en espera está en un punto final privado, se conecta a la base de datos mediante el punto final privado visible en la red, sin necesidad de configurar un gateway de servicio.
  3. Utilice conexiones TLS unidireccionales sin cartera.

    Si ha configurado un TLS unidireccional para la base de datos primaria, las bases de datos en espera ya tendrán configurado un TLS en espera. No es necesario realizar ninguna configuración adicional en las bases de datos en espera entre regiones.

  4. Configure los clientes y los niveles medios para utilizar TCP Fast Open.

Diagrama de Red Conceptual para Conexiones de Base de Datos de Baja Latencia

Muestra el diagrama de red conceptual para conexiones de baja latencia que utilizan puntos finales públicos y privados para la base de datos.

Conexiones de baja latencia mediante punto final privado con aplicación que se ejecuta en la región de OCI

A continuación, se incluye la Descripción de adb-private-low-latency.eps
Descripción de la ilustración adb-private-low-latency.eps

Conexiones de baja latencia mediante el punto final público con la aplicación ejecutándose en la región de OCI

A continuación, se incluye la Descripción de adb-public-low-latency.eps
Descripción de la ilustración adb-public-low-latency.eps

Conexiones de baja latencia mediante un punto final privado con aplicación que se ejecuta en el centro de datos local conectado a OCI mediante FastConnect

Descripción de adb-fastconnect-private-low-latency.eps a continuación
Descripción de la ilustración adb-fastconnect-private-low-latency.eps

Conexiones de baja latencia mediante un punto final público con aplicaciones que se ejecutan en su centro de datos local conectado a OCI mediante FastConnect

Descripción de adb-fastconnect-public-low-latency.eps a continuación
Descripción de la ilustración adb-fastconnect-public-low-latency.eps