Acerca de la base de datos de contenedores autónoma

La base de datos de contenedores autónoma (ACD) es uno de los cuatro componentes del modelo de arquitectura de base de datos de cuatro niveles, que es la base de una instancia de Autonomous Database en infraestructura de Exadata dedicada. Las bases de datos de contenedor autónomas se aprovisionan dentro de un cluster de VM de Exadata autónomo (AVMC) y sirven como contenedores para una o más instancias de Autonomous Database.

Puede crear varios recursos de ACD en un único recurso de AVMC, pero debe crear al menos uno para poder crear instancias de Autonomous Database. Para obtener una comprensión completa de la arquitectura de cuatro capas utilizada con una instancia de Autonomous Database en infraestructura de Exadata dedicada y comprender el posicionamiento de la base de datos de contenedor autónoma en esta arquitectura, consulte Componentes de Autonomous Database en infraestructura de Exadata dedicada.

Las bases de datos de contenedor autónomas proporcionan la ventaja de operar de forma aislada entre sí, lo que le permite separar las instancias de Autonomous Database según sus usos previstos. Por ejemplo, puede crear distintas ACD para fines como la producción y las pruebas, o incluso tener varias ACD utilizando diferentes versiones de base de datos.

Aunque los administradores de conjuntos crean, supervisan y gestionan bases de datos de contenedor autónomas, los administradores de bases de datos de aplicaciones las utilizan principalmente para crear instancias de Autonomous Database. Consulte Roles de usuario asociados a Autonomous Database on Dedicated Exadata Infrastructure para obtener más información.

Temas relacionados

Requisitos de la base de datos de contenedores autónoma

Requisitos de política de IAM

Debe tener una cuenta de Oracle Cloud Infrastructure con privilegios otorgados mediante las políticas de IAM necesarias. Las políticas necesarias dependen de la operación que esté realizando. Para obtener una lista de políticas de IAM pertenecientes a bases de datos de contenedores autónomas, consulte Políticas de gestión de bases de datos de contenedores autónomas.

Requisitos de recursos mínimos

Para crear una base de datos de contenedor autónoma, necesita al menos:

8 ECPU o 2 OCPU por nodo
50 GB de almacenamiento local por nodo

Requisitos de la versión de software de Oracle Database

Para aprovisionar una base de datos de contenedor autónoma con la versión de software de Oracle Database como 23ai, debe seleccionar un cluster de VM de Exadata autónomo (AVMC) basado en ECPU que se haya creado con la etiqueta DatabaseVersion definida en 23ai.
Del mismo modo, para aprovisionar una base de datos de contenedor autónoma con la versión de software de Oracle Database como 19c, debe seleccionar un cluster de VM de Exadata autónomo (AVMC) cuya etiqueta DatabaseVersion no esté definida en 23ai.
No puede aprovisionar ACD 19c y 23ai dentro del mismo AVMC.

Note:

Los despliegues de multinube no requieren una etiqueta especial y soportarán automáticamente las bases de datos 19c y 23ai.

Funciones de base de datos gestionadas desde una base de datos de contenedores autónoma

Las siguientes funciones de Autonomous Database se pueden definir y gestionar en el nivel de base de datos de contenedores autónoma (ACD).

Función de Autonomous Database	Notas:	Referencia adicional
Versión de software de Oracle Database Puede definir la versión de software de la base de datos de contenedores al aprovisionar una ACD.	Puede seleccionar la versión de software de Oracle Database desde una versión de imagen base o una imagen de software de Autonomous Database que se haya creado desde otra ACD. Al seleccionar la versión de la imagen base, puede seleccionar la última versión del software de Oracle Database o su predecesor inmediato. Por ejemplo: suponga que la última versión de Oracle Database soportada por Autonomous Database es la 19.26.0.1.0. A continuación, la lista desplegable Seleccionar imagen base muestra las versiones 19.26.0.1.0 y 19.25.0.1.0. Las bases de datos de contenedores autónomas (ACD) con la versión de software de base de datos 23ai solo se pueden aprovisionar en clusters de VM de Exadata autónomos (AVMC) basados en ECPU creados con las etiquetas adecuadas. Consulte 23ai Database Software Version Tag Requirements para obtener más información. Los despliegues de multinube no requieren una etiqueta especial y soportarán automáticamente tanto las bases de datos 19c como las de 23ai.	-
Autonomous Data Guard La configuración de Autonomous Data Guard permite mantener las bases de datos de producción críticas disponibles para las aplicaciones esenciales a pesar de los fallos.	Puede activar Autonomous Data Guard desde la página Detalles de una ACD y crear hasta dos ACD en espera. Sin embargo, la segunda base de datos de contenedor autónoma en espera debe estar en el mismo arrendamiento que la base de datos de contenedor autónoma principal. Las ACD principales y secundarias también se pueden desplegar en diferentes regiones (entre regiones). En una configuración de Autonomous Data Guard entre regiones mediante claves gestionadas por el cliente o KMS, según el número de instancias de Autonomous Database en la base de datos de contenedor autónoma principal, se generarán automáticamente nuevas versiones de clave para las bases de datos en espera en el almacén entre regiones.	Protección de bases de datos críticas frente a fallos y desastres mediante Autonomous Data Guard
Programación de mantenimiento En general, Oracle programa y realiza toda la distribución de mantenimiento de la flota a lo largo de cada trimestre y correcciones mensuales de seguridad de la infraestructura para vulnerabilidades con puntuaciones CVSS superiores o iguales a 7. Puede dejar que Oracle se encargue de la programación del mantenimiento o puede definir un período de mantenimiento específico durante el cual Oracle pueda iniciar las operaciones de mantenimiento.	Puede elegir entre los métodos de mantenimiento gradual o no gradual para una ACD. Si selecciona un método de mantenimiento de no acumulación en una configuración de Autonomous Data Guard, habrá un tiempo de inactividad para ACD y todas las instancias de Autonomous Database asociadas hasta que finalice la aplicación de parches. Opcionalmente, también puede seleccionar Activar actualización de zona horaria. Los archivos de zona horaria solo se puede actualizar con el método de configuración no gradual. Puede definir o modificar la configuración del programa de mantenimiento para una ACD que gestionará Oracle o puede definir un programa de mantenimiento personalizado. Al personalizar el programa de mantenimiento de una ACD, puede optar por omitir la aplicación de parches durante un trimestre. Sin embargo, no puede omitir la aplicación de parches durante dos trimestres consecutivos. Si decide omitir la aplicación de parches durante un trimestre, debe seleccionar al menos un mes de ese trimestre. Esto actúa como reserva en caso de que el mantenimiento no se haya producido en el trimestre anterior sin omitir. En este escenario, Oracle realizará automáticamente el mantenimiento en el mes seleccionado, incluso si se selecciona la omisión para ese trimestre. Puede ver el número de parches puntuales disponibles para una ACD en su página Detalles. Al hacer clic en el enlace Copiar situado junto a él, se copian todos esos números de parche puntuales. Al reprogramar un evento de mantenimiento de ACD que ya está programado, Oracle puede ponerlo en una cola si en el recurso de infraestructura de Exadata o el recurso de cluster de VM de Exadata autónomo: Ya se está realizando una actualización de mantenimiento, o Programado para una actividad de mantenimiento simultáneamente como ACD. Puede programar un mantenimiento bajo demanda para actualizar la RU (actualización de versión) junto con el archivo de zona horaria o solo el archivo de zona horaria de una ACD. También puede optar por actualizar mediante una imagen de software de base de datos personalizada existente. Puede experimentar tiempo de inactividad para la ACD y las instancias de Autonomous Database asociadas según la configuración del programa de mantenimiento de la ACD.	Mantenimiento de servicios Programar una actualización de mantenimiento trimestral
Copia de seguridad y restauración Para soportar la alta disponibilidad, Autonomous Database realiza automáticamente una copia de Seguridad de la base de datos. El período de retención de las copias de seguridad es de hasta 95 días en función del período/política de retención de copia de seguridad seleccionada para la base de datos autónoma. Puede restaurar y recuperar la base de datos a cualquier momento en este período de retención.	Una vez activadas, las copias de seguridad automáticas no se pueden desactivar para una ACD. Con las copias de seguridad automáticas activadas, tiene opciones para realizar copias de seguridad entre regiones, copias de seguridad a largo plazo y copias de seguridad manuales. Puede definir la política/período de retención de copia de seguridad al aprovisionar una ACD o modificarla posteriormente desde su página de detalles en la consola de la consola de Oracle Cloud Infrastructure. En los despliegues de Oracle Public Cloud y Exadata Cloud@Customer: Puede conservar las copias de seguridad de una ACD terminada durante un máximo de 72 horas o hasta el final de su período de retención de copia de seguridad. Puede activar el bloqueo de retención de copia de seguridad para evitar cualquier supresión no deseada de las copias de seguridad de ACD y Autonomous Database antes de su período de retención. Puede activar el bloqueo de retención mientras aprovisiona la ACD o posteriormente. Una vez activado, puede desactivar el bloqueo de retención en un plazo de 14 días, después del cual la configuración pasa a ser permanente. Una vez activado el bloqueo de retención, solo puede aumentar el valor del período de retención y no se puede reducir. Todas las copias de seguridad a largo plazo también se bloquearán y no se podrán suprimir cuando el bloqueo de retención esté activado. Las copias de seguridad a largo plazo se suprimen automáticamente una vez que caducan. Sin embargo, en el caso de los despliegues de Exadata Cloud@Customer, si el destino de copia de seguridad es NFS, ninguna de las copias de seguridad se suprimirá automáticamente cuando finalice una ACD. Debe suprimir manualmente todas las copias de seguridad automáticas, manuales y a largo plazo después de finalizar la ACD y de que haya pasado la fecha de caducidad. Consulte Política de retención de copia de seguridad para obtener más información sobre los valores de la política de retención de copia de seguridad para diferentes despliegues de Autonomous Database.	Copia de seguridad y restauración de bases de datos autónomas.
Destino de copia de seguridad Un destino de copia de seguridad define las propiedades necesarias para conectarse a una ubicación de copia de seguridad, y se debe acceder a cada destino de copia de seguridad en el centro de datos desde los nodos de cluster de VM.	La capacidad de elegir un destino de copia de seguridad al aprovisionar una ACD y los destinos de copia de seguridad soportados varían en función de la plataforma de despliegue. Consulte Destino de copia de seguridad para obtener más información sobre los diferentes tipos de destino de copia de seguridad.	Para obtener más información sobre la configuración del destino de copia de seguridad NFS para Cloud@Customer, consulte Requisitos para destinos de copia de seguridad para Exadata Cloud@Customer. Consulte Edición de la configuración de copia de seguridad de la base de datos de contenedores autónoma para obtener instrucciones sobre cómo cambiar el tipo de destino de copia de seguridad después de aprovisionar la base de datos de contenedor autónoma.
Uso del espacio del NFS	SOLO SE APLICA A: Exadata Cloud@Customer Si el tipo de destino de copia de seguridad actual es NFS, el uso de espacio NFS actual se muestra como un porcentaje junto con un ícono de estado.	Consulte View NFS Space Utilization para obtener más información.
Atributos de Resource Management Los atributos de gestión de recursos afectan a cómo se gestionan los recursos para consolidar más bases de datos o tener la mayor disponibilidad de la base de datos.	Opcionalmente, al aprovisionar una ACD, puede definir un valor adecuado para los siguientes atributos de gestión de recursos para satisfacer sus necesidades: Umbral de división de base de datos (CPU): valor de CPU por encima del cual se abrirá una instancia de Autonomous Database en varios nodos. El valor por defecto de este atributo es 16 para OCPU y 64 para ECPU. Reserva de failover de nodo (%): determina el porcentaje de CPU reservadas entre nodos para soportar failover de nodo. Los valores permitidos son 0%, 25% y 50%, siendo el 50% la opción por defecto. Afilinidad de distribución: determina si se debe abrir una instancia de Autonomous Database en un mínimo o máximo de nodos. Por defecto, se selecciona Mínimo de nodos.	Para obtener más información sobre cómo afectan estos atributos de ACD al rendimiento de las bases de datos, consulte Detalles de facturación de CPU.
Conexiones de Servidor Compartido La arquitectura de servidor compartido permite que un servidor de base de datos permita que muchos procesos de cliente compartan muy pocos procesos de servidor, por lo que aumenta la cantidad de usuarios soportados.	Al aprovisionar una ACD, puede activar opcionalmente conexiones de servidor compartido. No puede desactivar la arquitectura de servidor compartido después de aprovisionar la ACD.	Funciones de conexión con fines especiales.
Clave de cifrado Por defecto, Autonomous Database crea y gestiona todas las claves de cifrado maestras que se utilizan para proteger los datos, almacenarlas en un almacén de claves PKCS 12 seguro en los mismos sistemas de Exadata en los que residen las bases de datos. Si las políticas de seguridad de la compañía lo requieren, Autonomous Database puede utilizar las claves que crea y gestiona.	Al aprovisionar una ACD, puede configurar opcionalmente la ACD para que utilice claves de cifrado gestionadas por el cliente en lugar de claves de cifrado gestionadas por Oracle. Puede elegir entre las siguientes opciones al utilizar claves de cifrado gestionadas por el cliente: Servicio OCI Vault: con esta opción, selecciona un almacén y una clave de cifrado maestra. Esta opción solo está disponible en Oracle Public Cloud. Oracle Key Vault: seleccione un almacén de claves con esta opción e introduzca un nombre de grupo de puntos finales de OKV. Puede utilizar claves de cifrado gestionadas por el cliente con ACD activadas para Autonomous Data Guard con las bases de datos primaria y en espera ubicadas en diferentes dominios de disponibilidad en la misma región.	Acerca de las claves de cifrado maestras Uso de Bring Your Own Keys (BYOK) en el servicio Vault Uso de Claves Gestionadas por el Cliente en Oracle Key Vault Rotación de la clave de cifrado de una base de datos de contenedores autónoma.
Correo de contacto Puede proporcionar correos electrónicos de contacto en los que puede recibir notificaciones operativas, anuncios y notificaciones de mantenimiento no planificadas sobre la base de datos de contenedores autónoma.	Oracle recomienda utilizar la dirección de correo electrónico de un grupo de administradores en lugar de la de una persona, siempre que sea posible, para garantizar que no se pierdan notificaciones o anuncios importantes.
Full Stack Disaster Recovery Full Stack DR es un servicio de gestión y orquestación de recuperación ante desastres de Oracle Cloud Infrastructure (OCI) que proporciona funciones completas de recuperación ante desastres para todas las capas de una pila de aplicaciones, incluidas la infraestructura, el middleware, la base de datos y la aplicación.	Puede activar OCI Full Stack Disaster Recovery y utilizarla para realizar operaciones de switchover/failover o, opcionalmente, realizar solo operaciones de switchover/failover de Autonomous Database de base de datos.	Uso de OCI Full Stack Disaster Recovery en Autonomous Database on Dedicated Exadata Infrastructure
Copia de seguridad de varias regiones Puede seleccionar una región secundaria para una copia de sus copias de seguridad. En caso de fallo de una región, puede clonar la copia de seguridad remota de ACD para restaurar los datos. La copia de seguridad de una base de datos de contenedor autónoma solo se puede clonar en un cluster de VM de Exadata autónomo (AVMC) diferente de su AVMC de origen.	SE APLICA A: Solo Oracle Public Cloud La copia de seguridad entre regiones se puede activar al aprovisionar una ACD o desde la página de detalles de una ACD existente. No puede activar la copia de seguridad entre regiones si Autonomous Data Guard está activado.	Sobre la clonación de una base de datos de contenedores autónoma en una infraestructura de Exadata dedicada Clonación de una base de datos de contenedores autónoma

Función de Autonomous Database

Notas:

Referencia adicional

Versión de software de Oracle Database

Puede definir la versión de software de la base de datos de contenedores al aprovisionar una ACD.

Puede seleccionar la versión de software de Oracle Database desde una versión de imagen base o una imagen de software de Autonomous Database que se haya creado desde otra ACD.

Al seleccionar la versión de la imagen base, puede seleccionar la última versión del software de Oracle Database o su predecesor inmediato. Por ejemplo: suponga que la última versión de Oracle Database soportada por Autonomous Database es la 19.26.0.1.0. A continuación, la lista desplegable Seleccionar imagen base muestra las versiones 19.26.0.1.0 y 19.25.0.1.0.

Las bases de datos de contenedores autónomas (ACD) con la versión de software de base de datos 23ai solo se pueden aprovisionar en clusters de VM de Exadata autónomos (AVMC) basados en ECPU creados con las etiquetas adecuadas. Consulte 23ai Database Software Version Tag Requirements para obtener más información. Los despliegues de multinube no requieren una etiqueta especial y soportarán automáticamente tanto las bases de datos 19c como las de 23ai.

Autonomous Data Guard

La configuración de Autonomous Data Guard permite mantener las bases de datos de producción críticas disponibles para las aplicaciones esenciales a pesar de los fallos.

Puede activar Autonomous Data Guard desde la página Detalles de una ACD y crear hasta dos ACD en espera. Sin embargo, la segunda base de datos de contenedor autónoma en espera debe estar en el mismo arrendamiento que la base de datos de contenedor autónoma principal.

Las ACD principales y secundarias también se pueden desplegar en diferentes regiones (entre regiones). En una configuración de Autonomous Data Guard entre regiones mediante claves gestionadas por el cliente o KMS, según el número de instancias de Autonomous Database en la base de datos de contenedor autónoma principal, se generarán automáticamente nuevas versiones de clave para las bases de datos en espera en el almacén entre regiones.

Protección de bases de datos críticas frente a fallos y desastres mediante Autonomous Data Guard

Programación de mantenimiento

En general, Oracle programa y realiza toda la distribución de mantenimiento de la flota a lo largo de cada trimestre y correcciones mensuales de seguridad de la infraestructura para vulnerabilidades con puntuaciones CVSS superiores o iguales a 7.

Puede dejar que Oracle se encargue de la programación del mantenimiento o puede definir un período de mantenimiento específico durante el cual Oracle pueda iniciar las operaciones de mantenimiento.

Puede elegir entre los métodos de mantenimiento gradual o no gradual para una ACD. Si selecciona un método de mantenimiento de no acumulación en una configuración de Autonomous Data Guard, habrá un tiempo de inactividad para ACD y todas las instancias de Autonomous Database asociadas hasta que finalice la aplicación de parches. Opcionalmente, también puede seleccionar Activar actualización de zona horaria. Los archivos de zona horaria solo se puede actualizar con el método de configuración no gradual.

Puede definir o modificar la configuración del programa de mantenimiento para una ACD que gestionará Oracle o puede definir un programa de mantenimiento personalizado.

Al personalizar el programa de mantenimiento de una ACD, puede optar por omitir la aplicación de parches durante un trimestre. Sin embargo, no puede omitir la aplicación de parches durante dos trimestres consecutivos. Si decide omitir la aplicación de parches durante un trimestre, debe seleccionar al menos un mes de ese trimestre. Esto actúa como reserva en caso de que el mantenimiento no se haya producido en el trimestre anterior sin omitir. En este escenario, Oracle realizará automáticamente el mantenimiento en el mes seleccionado, incluso si se selecciona la omisión para ese trimestre.

Puede ver el número de parches puntuales disponibles para una ACD en su página Detalles. Al hacer clic en el enlace Copiar situado junto a él, se copian todos esos números de parche puntuales.

Al reprogramar un evento de mantenimiento de ACD que ya está programado, Oracle puede ponerlo en una cola si en el recurso de infraestructura de Exadata o el recurso de cluster de VM de Exadata autónomo:

Ya se está realizando una actualización de mantenimiento, o
Programado para una actividad de mantenimiento simultáneamente como ACD.

Puede programar un mantenimiento bajo demanda para actualizar la RU (actualización de versión) junto con el archivo de zona horaria o solo el archivo de zona horaria de una ACD. También puede optar por actualizar mediante una imagen de software de base de datos personalizada existente.

Puede experimentar tiempo de inactividad para la ACD y las instancias de Autonomous Database asociadas según la configuración del programa de mantenimiento de la ACD.

Mantenimiento de servicios

Programar una actualización de mantenimiento trimestral

Copia de seguridad y restauración

Para soportar la alta disponibilidad, Autonomous Database realiza automáticamente una copia de Seguridad de la base de datos. El período de retención de las copias de seguridad es de hasta 95 días en función del período/política de retención de copia de seguridad seleccionada para la base de datos autónoma. Puede restaurar y recuperar la base de datos a cualquier momento en este período de retención.

Una vez activadas, las copias de seguridad automáticas no se pueden desactivar para una ACD. Con las copias de seguridad automáticas activadas, tiene opciones para realizar copias de seguridad entre regiones, copias de seguridad a largo plazo y copias de seguridad manuales.

Puede definir la política/período de retención de copia de seguridad al aprovisionar una ACD o modificarla posteriormente desde su página de detalles en la consola de la consola de Oracle Cloud Infrastructure.

En los despliegues de Oracle Public Cloud y Exadata Cloud@Customer:

Puede conservar las copias de seguridad de una ACD terminada durante un máximo de 72 horas o hasta el final de su período de retención de copia de seguridad.
Puede activar el bloqueo de retención de copia de seguridad para evitar cualquier supresión no deseada de las copias de seguridad de ACD y Autonomous Database antes de su período de retención.
Puede activar el bloqueo de retención mientras aprovisiona la ACD o posteriormente.
Una vez activado, puede desactivar el bloqueo de retención en un plazo de 14 días, después del cual la configuración pasa a ser permanente.
Una vez activado el bloqueo de retención, solo puede aumentar el valor del período de retención y no se puede reducir.
Todas las copias de seguridad a largo plazo también se bloquearán y no se podrán suprimir cuando el bloqueo de retención esté activado.

Las copias de seguridad a largo plazo se suprimen automáticamente una vez que caducan. Sin embargo, en el caso de los despliegues de Exadata Cloud@Customer, si el destino de copia de seguridad es NFS, ninguna de las copias de seguridad se suprimirá automáticamente cuando finalice una ACD. Debe suprimir manualmente todas las copias de seguridad automáticas, manuales y a largo plazo después de finalizar la ACD y de que haya pasado la fecha de caducidad.

Consulte Política de retención de copia de seguridad para obtener más información sobre los valores de la política de retención de copia de seguridad para diferentes despliegues de Autonomous Database.

Copia de seguridad y restauración de bases de datos autónomas.

Destino de copia de seguridad

Un destino de copia de seguridad define las propiedades necesarias para conectarse a una ubicación de copia de seguridad, y se debe acceder a cada destino de copia de seguridad en el centro de datos desde los nodos de cluster de VM.

La capacidad de elegir un destino de copia de seguridad al aprovisionar una ACD y los destinos de copia de seguridad soportados varían en función de la plataforma de despliegue.

Consulte Destino de copia de seguridad para obtener más información sobre los diferentes tipos de destino de copia de seguridad.

Para obtener más información sobre la configuración del destino de copia de seguridad NFS para Cloud@Customer, consulte Requisitos para destinos de copia de seguridad para Exadata Cloud@Customer.

Consulte Edición de la configuración de copia de seguridad de la base de datos de contenedores autónoma para obtener instrucciones sobre cómo cambiar el tipo de destino de copia de seguridad después de aprovisionar la base de datos de contenedor autónoma.

Uso del espacio del NFS

SOLO SE APLICA A: Exadata Cloud@Customer

Si el tipo de destino de copia de seguridad actual es NFS, el uso de espacio NFS actual se muestra como un porcentaje junto con un ícono de estado.

Consulte View NFS Space Utilization para obtener más información.

Atributos de Resource Management

Los atributos de gestión de recursos afectan a cómo se gestionan los recursos para consolidar más bases de datos o tener la mayor disponibilidad de la base de datos.

Opcionalmente, al aprovisionar una ACD, puede definir un valor adecuado para los siguientes atributos de gestión de recursos para satisfacer sus necesidades:

Umbral de división de base de datos (CPU): valor de CPU por encima del cual se abrirá una instancia de Autonomous Database en varios nodos. El valor por defecto de este atributo es 16 para OCPU y 64 para ECPU.
Reserva de failover de nodo (%): determina el porcentaje de CPU reservadas entre nodos para soportar failover de nodo. Los valores permitidos son 0%, 25% y 50%, siendo el 50% la opción por defecto.
Afilinidad de distribución: determina si se debe abrir una instancia de Autonomous Database en un mínimo o máximo de nodos. Por defecto, se selecciona Mínimo de nodos.

Para obtener más información sobre cómo afectan estos atributos de ACD al rendimiento de las bases de datos, consulte Detalles de facturación de CPU.

Conexiones de Servidor Compartido

La arquitectura de servidor compartido permite que un servidor de base de datos permita que muchos procesos de cliente compartan muy pocos procesos de servidor, por lo que aumenta la cantidad de usuarios soportados.

Al aprovisionar una ACD, puede activar opcionalmente conexiones de servidor compartido. No puede desactivar la arquitectura de servidor compartido después de aprovisionar la ACD.

Funciones de conexión con fines especiales.

Clave de cifrado

Por defecto, Autonomous Database crea y gestiona todas las claves de cifrado maestras que se utilizan para proteger los datos, almacenarlas en un almacén de claves PKCS 12 seguro en los mismos sistemas de Exadata en los que residen las bases de datos.

Si las políticas de seguridad de la compañía lo requieren, Autonomous Database puede utilizar las claves que crea y gestiona.

Al aprovisionar una ACD, puede configurar opcionalmente la ACD para que utilice claves de cifrado gestionadas por el cliente en lugar de claves de cifrado gestionadas por Oracle.

Puede elegir entre las siguientes opciones al utilizar claves de cifrado gestionadas por el cliente:

Servicio OCI Vault: con esta opción, selecciona un almacén y una clave de cifrado maestra. Esta opción solo está disponible en Oracle Public Cloud.
Oracle Key Vault: seleccione un almacén de claves con esta opción e introduzca un nombre de grupo de puntos finales de OKV.

Puede utilizar claves de cifrado gestionadas por el cliente con ACD activadas para Autonomous Data Guard con las bases de datos primaria y en espera ubicadas en diferentes dominios de disponibilidad en la misma región.

Acerca de las claves de cifrado maestras

Uso de Bring Your Own Keys (BYOK) en el servicio Vault

Uso de Claves Gestionadas por el Cliente en Oracle Key Vault

Rotación de la clave de cifrado de una base de datos de contenedores autónoma.

Correo de contacto

Puede proporcionar correos electrónicos de contacto en los que puede recibir notificaciones operativas, anuncios y notificaciones de mantenimiento no planificadas sobre la base de datos de contenedores autónoma.

Oracle recomienda utilizar la dirección de correo electrónico de un grupo de administradores en lugar de la de una persona, siempre que sea posible, para garantizar que no se pierdan notificaciones o anuncios importantes.

Full Stack Disaster Recovery

Full Stack DR es un servicio de gestión y orquestación de recuperación ante desastres de Oracle Cloud Infrastructure (OCI) que proporciona funciones completas de recuperación ante desastres para todas las capas de una pila de aplicaciones, incluidas la infraestructura, el middleware, la base de datos y la aplicación.

Puede activar OCI Full Stack Disaster Recovery y utilizarla para realizar operaciones de switchover/failover o, opcionalmente, realizar solo operaciones de switchover/failover de Autonomous Database de base de datos.

Uso de OCI Full Stack Disaster Recovery en Autonomous Database on Dedicated Exadata Infrastructure

Copia de seguridad de varias regiones

Puede seleccionar una región secundaria para una copia de sus copias de seguridad. En caso de fallo de una región, puede clonar la copia de seguridad remota de ACD para restaurar los datos. La copia de seguridad de una base de datos de contenedor autónoma solo se puede clonar en un cluster de VM de Exadata autónomo (AVMC) diferente de su AVMC de origen.

SE APLICA A:

Solo Oracle Public Cloud

La copia de seguridad entre regiones se puede activar al aprovisionar una ACD o desde la página de detalles de una ACD existente.

No puede activar la copia de seguridad entre regiones si Autonomous Data Guard está activado.

Sobre la clonación de una base de datos de contenedores autónoma en una infraestructura de Exadata dedicada

Clonación de una base de datos de contenedores autónoma

Operaciones de gestión de bases de datos de contenedores autónomas

Puede realizar las siguientes operaciones de gestión en una base de datos de contenedores autónoma.

Operación	Instrucciones de la tarea
Creación de una base de datos de contenedores autónoma	Creación de una base de datos de contenedores autónoma
Cambio de la política de retención de copias de seguridad de una base de datos de contenedores autónoma	Editar configuración de copia de seguridad de base de datos de contenedores autónoma
Crear una imagen de software de Autonomous Database	Creación de una imagen de software de Autonomous Database
Edición de las preferencias de mantenimiento de una base de datos de contenedores autónoma	Actualización de preferencias de mantenimiento de base de datos de contenedores autónoma
Gestión de la configuración de Autonomous Data Guard	Gestión de la configuración de Autonomous Data Guard
Traslado de una base de datos de contenedores autónoma a otro compartimento	Traslado de una base de datos de contenedores autónoma a un compartimento diferente
Rotar una clave de cifrado de base de datos de contenedores autónoma	Rotación de la clave de cifrado de una base de datos de contenedores autónoma
Reinicio de una base de datos de contenedores autónoma	Reinicio de una base de datos de contenedores autónoma
Terminación de una base de datos de contenedores autónoma	Terminación de una base de datos de contenedores autónoma
Gestión de contactos de clientes para una base de datos de contenedores autónoma	Gestionar contactos de cliente para una base de datos de contenedores autónoma
Visualización de una lista de las bases de datos de contenedores autónomas	Visualización de una lista de las bases de datos de contenedores autónomas
Visualización de detalles de una base de datos de contenedores autónoma	Visualización de detalles de una base de datos de contenedores autónoma
Ver el uso del espacio del NFS	SOLO SE APLICA A: Exadata Cloud@Customer Ver uso de espacio de NFS

Las operaciones mencionadas anteriormente también se pueden lograr mediante API. Consulte API para gestionar bases de datos de contenedores autónomas para obtener más información.

Supervisión de una base de datos de contenedores autónoma

Puede utilizar vistas de rendimiento dinámico para supervisar la base de datos de contenedores autónoma (ACD) de las siguientes formas:

Vea métricas en tiempo real sobre diferentes eventos de espera y clases de espera.
Ver instantáneas históricas de métricas de clase de espera.
Vea datos de métricas de rendimiento en tiempo real, históricos y de resumen.
Ver los límites de recursos y el uso actual.

Para obtener información detallada, consulte Vistas de rendimiento dinámico.

Título e Información de Copyright

Oracle y/o sus filiales.