Documentación de Oracle Cloud Infrastructure

Acerca de Autonomous Data Guard con BD entre regiones en espera

Proporciona información sobre las funciones y el funcionamiento de Autonomous Data Guard con una base de datos en espera entre regiones o entre arrendamientos.

Al agregar una base de datos en espera en una región diferente, si la instancia principal cae, Autonomous Data Guard proporciona una base de datos en espera que está separada físicamente en una región remota. La base de datos en espera está disponible para asumir el rol de la instancia principal no disponible. Al agregar una base de datos en espera en un arrendamiento diferente, Autonomous Data Guard proporciona una base de datos en espera que se encuentra en un arrendamiento diferente. La base de datos en espera está disponible para asumir el rol de la instancia principal no disponible.

Las bases de datos en espera entre regiones son una réplica de las bases de datos principales y se pueden utilizar para su recuperación en caso de fallo o cuando la principal no esté disponible. La activación de Autonomous Data Guard con una base en espera entre las regiones proporciona una solución para la recuperación ante desastres con un nivel bajo de RTO en caso de no haber disponible toda una región o de que la base datos principal esté caída por cualquier motivo.

Las bases de datos en espera entre regiones de Autonomous Data Guard generan el costo adicional de las CPU base y el doble del almacenamiento de la base de datos principal, incluido cualquier uso de almacenamiento escalado automáticamente, facturado en la base de datos peer remota. Las CPU escaladas automáticamente de la base de datos principal no se facturan además en la base de datos peer remota. El número de CPU base se especifica por el número de ECPU (OCPU si la base de datos utiliza OCPU), como se muestra en el campo Recuento de ECPU (Recuento de OCPU) de la consola de Oracle Cloud Infrastructure.

La base de datos de IA autónoma te permite crear una o más bases de datos peer de recuperación ante desastres remotas, según tu modelo informático:

  • Modelo de recursos informáticos de OCPU: puede agregar una base de datos en espera remota en una región emparejada. Las regiones emparejadas son regiones remotas en la que puede crear un peer entre regiones

  • Modelo de recursos informáticos de ECPU: puede agregar varios pares de recuperación ante desastres remotos, con hasta un par en cada región emparejada remota. Por ejemplo, si la base de datos primaria está en la región IAD, puede agregar una base de datos en espera en PHX y una base de datos en espera en SJC, pero no puede agregar dos pares de recuperación ante desastres remotos en PHX.

Las regiones emparejadas son regiones remotas en la que puede crear una base datos en espera entre distintas regiones. Consulte Regiones emparejadas entre regiones de la base de datos de IA autónoma para obtener más información sobre las regiones emparejadas.

Puede realizar casi todas las operaciones, como escalar verticalmente el recuento de ECPU (recuento de OCPU si la base de datos utiliza OCPU) y activar la escala automática de recursos informáticos en la base de datos primaria. A continuación, Autonomous Data Guard realiza las mismas acciones en la base de datos en espera entre regiones.

Una vez agregada una base del sistema en espera remota, la base del sistema de IA autónoma proporciona acceso a la base del sistema en espera remota desde la consola de Oracle Cloud Infrastructure. Autonomous AI Database proporciona acceso a la base de datos en espera remota para que pueda realizar algunas operaciones de forma independiente en la base de datos en espera remota, como la configuración de redes y redes virtuales en la nube para puntos finales privados y la adición de etiquetado para definir claves y valores que no se replican entre la base de datos primaria y la base de datos en espera remota.

Nota

Nota: Autonomous Data Guard no realiza una conmutación por error automática para una BD en espera entre regiones. Si la base del datos principal no está disponible y no hay una base del datos en espera local disponible, puede realizar un failover manual para que una base del datos en espera entre regiones asuma el rol principal.

No puede conectarse a una base de datos en espera entre regiones mientras funciona como base de datos en espera y no está disponible para operaciones de solo lectura. Puede conectarse a la base de datos en los siguientes casos:

Las siguientes áreas presentan diferencias para el failover o el switchover desde la base de Datos Principal a una base de datos en espera remota, en comparación con el failover o el switchover a una base de datos en espera local.

  • Nombre mostrado: el nombre mostrado tiene la extensión "_region". Donde region es el nombre de la región, como IAD o BOM.

    Si ha creado el par entre regiones antes de la introducción del soporte para varios pares entre regiones, el nombre mostrado del par entre regiones tiene una extensión "_Remote".

  • Libros de notas de OML: después de un switchover o failover entre regiones, los blocs de notas de OML de la base de datos principal que se ha realizado un switchover o un failover no están presentes en la base de datos primaria (la base de datos primaria actual después del cambio de rol). Se pueden crear nuevos blocs de notas del OML.

  • Punto final privada: puede configurar y actualizar independientemente los puntos finales privados en una base de Datos en espera antes de la conmutación por error o antes de la misma. Esto le permite tener un punto final privado que se configura de forma diferente, después de un failover o después de realizar un switchover. Autonomous AI Database no mantiene la configuración del red sincronizada de la instancia principal a una instancia en espera remota.

    El intercambio de tráfico de VCN y el reenvío de dominio son necesarios para que las carteras funcionen entre regiones, con bases de datos de IA autónomas con un punto final privado con una base de datos en espera de Autonomous Data Guard, donde la base de datos principal y la base de datos en espera se encuentran en distintas redes virtuales en la nube. Consulte Intercambio de tráfico de VCN remotas a través de una RPC y DNS en su red virtual en la nube para obtener información sobre el intercambio de tráfico de VCN y el reenvío de dominios.

  • Lista de control de acceso de red: por defecto, una base de datos primaria de recuperación ante desastres y las bases de datos peer remotas utilizan las mismas listas de control de acceso de red (ACL). Opcionalmente, puede editar de forma independiente las ACL de red en una base de datos peer remota. Esto le permite utilizar diferentes ACL en una base de datos peer remota.

    Consulte Manage Remote Peer Network ACLs para obtener más información.

  • Etiquetas: las etiquetas se gestionan de forma independiente en una base de datos primaria de recuperación ante desastres y en una base de datos peer remota. Esto significa que:

    • Cuando agrega, elimina o actualiza una etiqueta en un par remoto, el cambio se aplica solo en la base de datos de pares remota.

    • Cuando agrega, actualiza o elimina una etiqueta en la principal, la etiqueta no se agrega, actualiza ni elimina en bases de datos peer remotas.

  • API o scripts: puede que sea necesario actualizar todas las API o scripts que utilice para gestionar Autonomous AI Database para llamar a las API de la base datos principal.

    También puede utilizar variables de sustitución predefinidas en las URL de Oracle Cloud Infrastructure (OCI) para el failover entre regiones para Autonomous AI Database al utilizar las API de REST de OCI. Consulte Variables de sustitución en URL de Oracle Cloud Infrastructure (OCI) para obtener más información.

    Para las conexiones mTLS, debe descargar una cartera de la base de datos primaria, la base de datos primaria actual, después de un failover o después de realizar un switchover. Consulte Carteras y cadenas de conexión de recuperación ante desastres entre regiones para obtener más información.

  • Aplicaciones Cliente: las aplicaciones cliente deben conectarse mediante las cadenas de conexión y la cartera que descargue de la base de datos primaria, la base de datos primaria actual, después de un failover o después de realizar un switchover. Consulte Carteras y cadenas de conexión de recuperación ante desastres entre regiones para obtener más información.

  • Conexiones Basadas en Carteras: Debe descargar una cartera y conectarse mediante las cadenas de conexión de la base de datos primaria, la base de datos primaria actual, para conectarse a la base de datos después de un failover o después de realizar un switchover. Consulte Carteras y cadenas de conexión de recuperación ante desastres entre regiones para obtener más información.

  • Herramientas de base de datos de IA autónoma: las herramientas tienen diferentes URL en la base de datos principal, la base de datos principal actual, después de un failover o el failover entre regiones (las URL de las herramientas no cambian para un switchover o un failover a una ubicación en espera local):

    • Acciones de base de datos

    • Oracle APEX

    • Oracle REST Data Services (ORDS)

    • Spatial Studio

    • Graph Studio

    • Blocs de notas de Oracle Machine Learning (OML)

    • Transformaciones de datos

    • API de MongoDB

  • Uso de Oracle Cloud Infrastructure Object Storage: después de realizar un failover o un switchover de la base de datos primaria a una base de datos en espera, en la base de datos primaria (la base de datos primaria actual) las credenciales y las URL que proporcionan acceso a Object Storage siguen funcionando como lo hacían antes del failover o el switchover, proporcionando acceso a lo siguiente:

    • Tablas externas

    • Tablas particionadas externas

    • Tablas particionadas híbridas externas

    Nota

    Nota: Esto se aplica cuando Object Storage está disponible. En el caso de escenarios excepcionales en los que no esté disponible Object Storage, Oracle recomienda hacer copias del servicio de almacenamiento de objetos o la replicación en una región diferente. Si no está disponible Object Storage (es decir, el recurso de Object Storage que utilizó con el principal antes de realizar un switchover o un failover), puede actualizar las credenciales de usuario y los parámetros que definen las URL de Object Storage para que estos parámetros especifiquen valores para acceder a Object Storage de una región disponible. Consulte Uso de la replicación para obtener más información.

Autonomous Data Guard entre arrendamientos con una base de Datos en Espera entre regiones

Puede activar Autonomous Data Guard entre arrendamientos con una base de datos en espera entre regiones. Al agregar una base de datos en espera de Autonomous Data Guard entre arrendamientos en una región diferente, la base de datos de IA autónoma aprovisiona una base de datos en espera entre regiones en el arrendamiento de destino. Con una base de datos en espera de Autonomous Data Guard entre arrendamientos, puede realizar un failover, un switchover o crear una base de datos en espera de instantánea con una base de datos en espera entre regiones en un arrendamiento diferente. Esta función permite utilizar Autonomous Data Guard para migrar una base de datos a un arrendamiento diferente.

Consulte Uso de una base de datos en espera de Autonomous Data Guard entre arrendamientos para obtener más información.

Recuperación ante desastres de pila completa de OCI con una base de datos en espera entre regiones de Autonomous Data Guard

Cuando está activada la recuperación ante desastres de pila completa, la página de detalles de la base de datos de IA autónoma, en Recuperación ante desastres, muestra el campo Full Stack DR como Enabled.

A continuación se muestra la descripción de adb_full_stack_dr_enabled.png

Descripción de la ilustración adb_full_stack_dr_enabled.png

Consulte Uso de OCI Full Stack Disaster Recovery con Autonomous AI Database para obtener más información.

Rol de base de datos de Autonomous Data Guard

Después de agregar una base de datos en espera entre regiones, cada base de datos tiene un rol designado: principal, en espera o de instantánea en espera.

El rol especifica el estado actual de una base de datos, principal, en espera o instantánea en espera, y este valor cambia después de realizar una operación de switchover o failover o después de convertir una base de datos en espera en una instantánea en espera. Puede ver el rol de base de datos de IA autónoma en el icono que se muestra junto al nombre mostrado en la página Información de base de datos de IA autónoma. Por ejemplo:

A continuación se muestra la descripción de adb_adg_primary.png

Descripción de la ilustración adb_adg_primary.png

A continuación se muestra la descripción de adb_adg_standby.png

Descripción de la ilustración adb_adg_standby.png

Después de agregar una base de datos en espera entre regiones, puede ver el rol en el área Recuperación ante desastres de la página de detalles. El rol es uno de los siguientes:

  • El rol muestra Principal en la base de datos principal.

  • Después de una operación de switchover o failover, en la misma base de datos, el rol muestra Standby.

  • Después de convertir un par entre regiones en una instantánea en espera, el rol se muestra como Snapshot Standby.

Para ver los detalles de un peer, en la página de detalles de la base de datos de IA autónoma, seleccione el separador Recuperación ante desastres. La lista muestra la información de la base de datos de peer y la columna Rol de peer muestra el rol de peer:

  • En espera (local): la columna Rol peer muestra En espera y la base de datos tiene el mismo nombre mostrado en la columna Base de datos de IA autónoma peer. La columna Región muestra el nombre de la región actual.

  • En espera (entre regiones) La columna Rol peer muestra En espera para una base de datos en espera remota y la base de datos tiene el mismo nombre con una extensión "_region" en la columna Base de datos de IA autónoma peer. Para acceder, haga clic en el enlace para acceder a la base de datos remota. La columna Región muestra el nombre de la región remota.

    Si ha creado el par entre regiones antes de la introducción del soporte para varios pares entre regiones, el nombre mostrado del par entre regiones tiene una extensión "_Remote".

  • Instantánea en espera: la columna Rol peer muestra Instantánea en espera. La columna Región muestra el nombre de la región remota.

Failover y switchover entre regiones de Autonomous Data Guard

Puede tener un par de recuperación ante desastres local y, opcionalmente, puede agregar uno o más pares entre regiones (se permiten varios pares entre regiones con el modelo informático de ECPU). Tanto en los casos locales como entre regiones, el peer puede ser una copia de seguridad de recuperación ante desastres basada en copia de seguridad o una base de datos en espera de Autonomous Data Guard.

Con una región actual y una o más bases de datos peer de Autonomous Data Guard entre regiones, según el estado de la base de datos principal, tiene las siguientes opciones:

  • Si el sistema deja de estar activo y el sistema de bases de datos en espera local está disponible, Autonomous Data Guard realiza automáticamente un failover para convertir el sistema de bases de datos en espera local en el sistema de bases de datos principal con una interrupción mínima. Una vez completado el failover, Autonomous Data Guard crea una nueva base de datos en espera local. Si no es posible realizar un failover automático, tiene la opción de realizar un failover manual.

    Autonomous Data Guard sigue utilizando las mismas bases de datos entre regiones peer.

  • Si se cae la base del sistema principal y la base del sistema en espera local no está disponible, puede realizar un failover manual en una base del sistema peer entre regiones y la base del sistema peer entre regiones en la que se realiza el failover para que se convierta en la base del sistema principal.

    En este caso, una vez que finaliza el failover, Autonomous Data Guard no crea una nueva base de datos en espera local (por defecto, tiene un peer de copia de seguridad).

  • Puede realizar una operación de switchover en la que la base de datos principal se convierta en la base de datos en espera local y la base de datos en espera local se convierta en la base de datos principal.

    Autonomous Data Guard sigue utilizando las mismas bases de datos entre regiones peer.

  • Puede realizar una operación de switchover, en la que una base de datos peer entre regiones se convierte en la base de datos primaria (y la base de datos que era la primaria se vuelve a crear como una nueva base de datos en espera para que se convierta en una base de datos peer).

    Un switchover cambia los roles de la base de datos primaria y una base de datos peer. Si realiza una operación de switchover dos veces entre las mismas dos regiones remotas, la base de datos primaria vuelve a ser la base de datos primaria.

Copia de seguridad y restauración entre regiones de la base de datos de Autonomous Data Guard

Una vez que ha agregado una base de Datos en espera entre las regiones de Autonomous Data Guard, las copias de seguridad y las restauraciones a partir de las copias de seguridad se gestionan del siguiente modo:

  • Si la base del datos principal se restaura a partir de una copia, se crea una nueva base del sistema en espera remota a partir de la base del sistema restaurada.

  • La copia de seguridad automática solo se realiza en la base de datos principal (la base de datos que muestra Rol: Principal). Por ejemplo, después de un switchover o una conmutación por error, la base de datos con el rol Primary comienza a realizar copia de seguridad automáticas. Una base de datos con el rol Standby ya no realiza copias de seguridad. Si vuelve a realizar la operación de switchover, la base de datos que se convierte en la base de datos de rol principal comienza a realizar copias de seguridad de nuevo.

  • No puede restaurar ni clonar a partir de una copia de seguridad cuando una base de datos peer tiene el rol En espera. Las Copias de seguridad solo se realizan en las bases de datos con el rol Principal, y la operación de restauración no está disponible desde la consola de Oracle Cloud Infrastructure en una base de Datos en espera.

Cadenas y Carteras de Conexión de Recuperación ante Desastres entre Regiones

Al agregar una base de datos en espera entre regiones (remota) de Autonomous Data Guard o al utilizar un peer de recuperación ante desastres basada en copia de seguridad entre regiones, la cartera y la cadena de conexión de la base de datos primaria solo contienen el nombre de host de la base de datos primaria.

Además, la cartera y la cadena de conexión de una base de datos peer remota solo contienen el nombre de host de la base de datos remota. Esto se aplica tanto a las carteras de instancia como a las regionales.

Oracle recomienda configurar las aplicaciones que se ejecutan en la base de datos de rol principal para utilizar la cartera o la cadena de conexión descargada de la base de datos principal. Para las aplicaciones que se ejecutan en una base de datos remota, utilice la cadena de conexión o cartera descargada de la base de datos remota (donde la base de datos remota es la base de datos primaria actual después de un failover o después de realizar un switchover). Puede obtener estas cadenas de conexión o la cartera haciendo clic en Conexión de base de datos en la consola de Oracle Cloud Infrastructure.

Por ejemplo, si Autonomous Data Guard entre regiones está configurado con la base de datos principal en Ashburn (IAD) y una base de datos en espera entre regiones en Phoenix (PHX), Oracle recomienda que las aplicaciones de nivel medio que se ejecutan en IAD utilicen la cadena o cartera de conexión de la base de datos primaria en IAD y las aplicaciones correspondientes que se ejecutan en PHX después de un failover o después de realizar un switchover, utilice la cadena o cartera de conexión de la base de datos en espera en PHX. Durante el failover regional o el switchover, Oracle recomienda realizar un failover tanto de la base de datos como de las aplicaciones de nivel medio en la nueva base de datos de roles principal para obtener un rendimiento óptimo y minimizar cualquier latencia entre regiones.

Consulte Descarga de credenciales de cliente (carteras) para obtener más información.

Si la aplicación lo necesita, puede crear manualmente cadenas de conexión que contengan nombres de host de base de datos primaria y remota, para soportar la conexión a cualquier instancia que esté disponible y abierta para conexiones automáticamente, la base de datos primaria o remota.

Para obtener más información sobre los pasos para crear manualmente estas cadenas de conexión, consulte:

Autonomous Data Guard entre regiones con claves de cifrado gestionadas por el cliente

Al agregar una base de datos en espera entre regiones de Autonomous Data Guard, hay consideraciones especiales cuando la base de datos primaria utiliza claves de cifrado gestionadas por el cliente o si desea cambiar a utilizar claves de cifrado gestionadas por el cliente en la base de datos primaria.

Nota

Nota: Autonomous AI Database admite varios proveedores de claves gestionadas por el cliente. Solo Oracle Cloud Infrastructure Vault está soportado para su uso con Autonomous Data Guard. Otros almacenes no están soportados para las claves gestionadas por el cliente.

Para que una base de datos en espera remota pueda utilizar la misma clave de cifrado maestra que la base de datos primaria, la clave de cifrado maestra se debe replicar en la región remota. Las claves de cifrado gestionadas por el cliente solo están soportadas con una única base de datos en espera de Autonomous Data Guard entre regiones. No están soportadas varias bases de datos en espera entre regiones porque Oracle Cloud Infrastructure Vault solo soporta la replicación en una región remota.

Considere los siguientes casos:

  • Se permite agregar una base de datos en Espera remota de Autonomous Data Guard si la base de datos de IA autónoma utiliza claves gestionadas por la cliente. Cuando la base de datos utiliza una clave gestionada por el cliente y agrega una base de datos en espera entre regiones de Autonomous Data Guard, la lista Región del cuadro de diálogo Agregar base de datos peer solo muestra las regiones que contienen el almacén replicado y las claves. Si no aparece una región remota, debe replicar el almacén y las claves en la región en la que desea que aparezca la base de datos en espera (debe ser una región emparejada).

  • El cambio a claves gestionadas por el cliente se permite en la base de datos principal cuando tiene una base de datos en espera entre regiones de Autonomous Data Guard. En el caso de que la base de datos utilice claves gestionadas por Oracle y cambie a claves gestionadas por el cliente en la primaria, solo verá las claves que se replican tanto en la primaria como en la en espera. El almacén y la clave de cifrado maestra de gestión de claves de cifrado solo muestran los almacenes y las claves que se replican en las regiones principal y en espera. Si no ve una clave en la lista, replique el almacén y las claves en una región emparejada.

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

Autonomous Data Guard entre arrendamientos con claves de cifrado gestionadas por el cliente

Al agregar una base de datos en espera entre arrendamientos de Autonomous Data Guard, hay consideraciones especiales cuando la base de datos primaria utiliza claves de cifrado gestionadas por el cliente o si desea cambiar a utilizar claves de cifrado en la base de datos primaria.

Al agregar una base de datos en espera entre arrendamientos de Autonomous Data Guard para obtener seguridad adicional, por ejemplo, para proteger contra el ransomware, si la base de datos principal utiliza una clave gestionada por el cliente, puede replicar la clave de cifrado y utilizarla en la base de datos en espera. Debe utilizar la misma clave de cifrado, ya sea una clave gestionada por Oracle o una clave gestionada por el cliente, tanto en el arrendamiento primario como en la en espera. Dado que cada arrendamiento tiene una copia independiente de la clave, la desactivación o supresión de la clave en un arrendamiento no afecta al otro.

Nota

Nota: Autonomous AI Database admite varios proveedores de claves gestionadas por el cliente. Solo Oracle Cloud Infrastructure Vault está soportado para su uso con Autonomous Data Guard. Otros almacenes no están soportados para las claves gestionadas por el cliente en la base de datos principal o en espera con Autonomous Data Guard.

Consulte Notas para claves de cifrado gestionadas por el cliente con una base de datos en espera de Autonomous Data Guard entre arrendamientos para obtener más información.

Replicación de copias de seguridad en una base de datos en espera de Autonomous Data Guard entre regiones

Al agregar una base de datos en espera de Autonomous Data Guard entre regiones, puede activar la replicación de copia de seguridad entre regiones para que las copias de seguridad automáticas de la base de datos principal también estén disponibles en una región remota.

Por defecto, las copias de seguridad realizadas en la base de datos primaria no se replican en una base de datos en espera entre regiones. Al activar la replicación de copia de seguridad entre regiones, se replican hasta 7 días de copias de seguridad automáticas para la base de datos primaria en una base de datos en espera entre regiones. Cuando esta función está activada, las copias de seguridad automáticas están disponibles en la región remota de la siguiente manera:

  • Después de una operación de switchover o failover, puede restaurar o clonar en cualquier registro de hora de los últimos siete (7) días o en cualquier registro de hora del período de retención especificado cuando el período de retención se define en menos de siete días.

  • Todas las copias de seguridad de la base de datos primaria que se replican en la región remota se suprimen en el peer de la región remota después de siete días o después del número de días del período de retención cuando el período de retención se define en menos de siete días.

  • No puede modificar el período de retención de copia de seguridad para copias de seguridad replicadas, excepto si modifica el período de retención de copia de seguridad en la base de datos primaria para especificar un valor inferior a siete días. En este caso, el período de retención para las copias de seguridad replicadas en la región remota coincide con el período de retención de copia de seguridad automática definido en la principal.

La replicación de copia de seguridad entre regiones tiene un costo adicional. Consulte Facturación de funciones sin servidor de Oracle Autonomous AI Database para obtener más información.

Consulte Agregar una Base de Datos en Espera entre Regiones y Activar o Desactivar Replicación de Copia de Seguridad para una Base de Datos en Espera entre Regiones Existente para obtener más información.

Tenga en cuenta lo siguiente para la replicación automática de copias de seguridad entre regiones:

  • Después de realizar un switchover o un failover, mientras que la base de datos entre regiones tiene el rol principal, las copias de seguridad se realizan en la base de datos principal actual y se replican en la base de datos en espera (remota) actual.

  • En una región remota, puede crear una clonación a partir de una copia de seguridad replicada mientras la base de datos tiene el rol En espera.

Licencias BYOL entre regiones de Autonomous Data Guard

El límite de ECPU de BYOL que defina en una base de datos principal de Autonomous Data Guard no se aplica a una base de datos en espera de Autonomous Data Guard entre regiones o entre arrendamientos.

En una base de datos en espera entre regiones o entre arrendamientos, puede definir de forma independiente el límite de ECPU de BYOL, según sea necesario. La definición de un valor para el límite de licencia BYOL limita cuántas ECPU estarán cubiertas por las licencias BYOL.

Por ejemplo, considere una base de datos principal de Autonomous Data Guard de 8 ECPU con licencia BYOL. Al agregar una base de datos en espera entre regiones o entre arrendamientos, la base de datos en espera obtiene sus licencias de la principal (mediante licencias BYOL).

En este ejemplo, si define el límite de licencia BYOL en 4 (ECPU) en la instancia principal, 4 de las 8 ECPU utilizan la licencia BYOL. Sin embargo, el límite de licencia BYOL que define en el principal no se aplica a una base de datos en espera entre regiones o entre arrendamientos. La base de datos en espera utiliza la licencia Traiga su propia licencia (BYOL) (sin un límite de licencia BYOL). Si define por separado un límite de licencia BYOL en la base de datos en espera, por ejemplo, si define el valor Límite de licencia BYOL en 2 (ECPU), se facturarán 2 ECPU en la base de datos en espera mediante licencias BYOL y 6 ECPU. Del mismo modo, el límite de ECPU de BYOL que define en la base de datos en espera no afecta el límite de ECPU de BYOL del principal.

Consulte Elija Traiga su propia opción de licencia durante el aprovisionamiento o la clonación y Elija Traiga su propia licencia en la base de datos de IA autónoma (modelo de recursos informáticos de ECPU) para obtener más información.