A propos de la base de données Conteneur Autonomous

Autonomous Container Database (ACD) est l'un des quatre composants du modèle d'architecture de base de données à quatre niveaux, qui constitue la base d'une base de données d'IA autonome sur une infrastructure Exadata dédiée. Les bases de données Conteneur Autonomous sont provisionnées dans un cluster de machines virtuelles Exadata Autonomous et servent de conteneurs pour des bases de données Autonomous AI.

Vous pouvez créer plusieurs ressources de base de données Conteneur Autonomous dans une seule ressource AVMC, mais vous devez en créer au moins une avant de pouvoir créer des bases de données Autonomous AI. Pour mieux comprendre l'architecture à quatre niveaux utilisée avec une base de données d'IA autonome sur une infrastructure Exadata dédiée et pour comprendre le positionnement de la base de données Conteneur Autonomous au sein de cette architecture, reportez-vous à Composants de pour en savoir plus.

Conditions requises pour la base de données Conteneur Autonomous

Conditions requises pour la stratégie IAM

Vous devez disposer d'un compte Oracle Cloud Infrastructure avec des privilèges accordés par le biais des stratégies IAM requises. Les stratégies requises dépendent de l'opération que vous effectuez. Pour obtenir la liste des stratégies IAM relatives aux bases de données Conteneur Autonomous, reportez-vous à Stratégies de gestion des bases de données Conteneur Autonomous.

Ressources requises minimales

Pour créer une base de données Conteneur Autonomous, vous devez disposer au moins de :

8 ECPU ou 2 OCPU par noeud
50 Go de stockage local par noeud

Fonctionnalités de base de données gérées à partir d'une base de données Conteneur Autonomous

Les fonctionnalités suivantes de la base de données Autonomous AI peuvent être définies et gérées au niveau de la base de données Conteneur Autonomous.

Fonctionnalité de base de données d'IA autonome	Remarques	Références supplémentaires
Version du logiciel Oracle Database Vous pouvez définir la version du logiciel de base de données Conteneur lors du provisionnement d'une base de données Conteneur Autonomous.	Vous pouvez choisir la version du logiciel Oracle Database à partir d'une version d'image de base ou d'une image logicielle de base de données Autonomous AI créée à partir d'une autre base de données Conteneur Autonomous. Lorsque vous sélectionnez une version dans l'image de base, vous pouvez choisir la dernière version du logiciel Oracle Database ou son prédécesseur immédiat. Par exemple : supposons que la dernière version d'Oracle Database prise en charge par Autonomous AI Database soit la version 19.26.0.1.0. Ensuite, la liste déroulante Sélectionner l'image de base répertorie 19.26.0.1.0 et 19.25.0.1.0. que vous pouvez choisir.	-
Autonomous Data Guard La configuration d'Autonomous Data Guard permet d'assurer la disponibilité de vos bases de données d'exploitation essentielles pour vos applications stratégiques, malgré la panne.	Vous pouvez activer Autonomous Data Guard à partir de la page Détails d'une base de données Conteneur Autonomous et créer jusqu'à deux bases de données Conteneur Autonomous de secours. Les bases de données Conteneur Autonomous principale et secondaire peuvent également être déployées dans différentes régions (inter-région). Dans une configuration Autonomous Data Guard inter-région à l'aide de clés gérées par le client ou de KMS, selon le nombre de bases de données Autonomous AI dans la base de données Conteneur Autonomous principale, de nouvelles versions de clé seront automatiquement générées pour les bases de données de secours dans le coffre inter-région.	Protection des bases de données critiques contre les échecs et les sinistres à l'aide d'Autonomous Data Guard
Programmation de maintenance En général, Oracle planifie et effectue une maintenance complète du parc répartie sur chaque trimestre et des correctifs de sécurité d'infrastructure mensuels pour les vulnérabilités dont les scores CVSS sont supérieurs ou égaux à 7. Vous pouvez laisser Oracle gérer la programmation de la maintenance ou définir une fenêtre spécifique pendant laquelle Oracle peut commencer les opérations de maintenance.	Vous pouvez choisir entre les méthodes de maintenance non simultanée ou non simultanée pour une base de données Conteneur Autonomous. Si vous choisissez une méthode de maintenance simultanée dans une configuration Autonomous Data Guard, un temps d'inactivité sera appliqué à la base de données Conteneur Autonomous et à toutes les bases de données Autonomous AI associées jusqu'à la fin de l'application de patches. Vous pouvez également sélectionner Activer la mise à jour du fuseau horaire. Les fichiers de fuseaux horaires ne peuvent être mis à jour qu'à l'aide de la méthode de configuration simultanée. Vous pouvez définir ou modifier les paramètres de programmation de maintenance d'une base de données Conteneur Autonomous à gérer par Oracle ou vous pouvez définir une programmation de maintenance personnalisée. Lors de la personnalisation de la programmation de maintenance d'une base de données Conteneur Autonomous, vous pouvez choisir d'ignorer l'application de patches pendant un trimestre. Toutefois, vous ne pouvez pas ignorer l'application de patches pendant deux trimestres consécutifs. Lorsque vous choisissez d'ignorer l'application de patches pour un trimestre, vous devez sélectionner au moins un mois à partir de ce trimestre. Il s'agit d'une restauration au cas où la maintenance n'aurait pas eu lieu au cours du trimestre non ignoré précédent. Dans ce scénario, Oracle effectuera automatiquement la maintenance au cours du mois sélectionné, même si l'option Ignorer est sélectionnée pour ce trimestre. Vous pouvez afficher le nombre de patches exceptionnels disponibles pour une base de données Conteneur Autonomous sur sa page Détails. Cliquez sur le lien Copier en regard de ce lien pour copier tous ces numéros de patch exceptionnels. Lorsque vous reprogrammez un événement d'entretien de base de données Conteneur Autonomous déjà programmé, Oracle peut le placer dans une file d'attente si les ressources d'infrastructure Exadata ou de cluster de machines virtuelles Exadata Autonomous correspondantes sont : font déjà l'objet d'une mise à jour de maintenance, ou sont programmés pour une activité de maintenance simultanément en tant que base de données Conteneur Autonomous. Vous pouvez programmer une maintenance à la demande pour mettre à jour la RU (Mise à jour de version) avec le fichier de fuseau horaire ou uniquement le fichier de fuseau horaire pour une base de données Conteneur Autonomous. Vous pouvez également choisir de mettre à jour à l'aide d'une image logicielle de base de données personnalisée existante. Le temps d'inactivité de votre base de données Conteneur Autonomous et des bases de données Autonomous AI associées peut dépendre de la configuration de la programmation de maintenance de votre base de données Conteneur Autonomous.	Maintenance des services Planifier une mise à jour de maintenance trimestrielle
Sauvegarde et restauration Pour prendre en charge la haute disponibilité, Autonomous AI Database sauvegarde automatiquement votre base de données pour vous. La durée de conservation des sauvegardes est de 95 jours au maximum, en fonction de la stratégie/période de conservation de sauvegarde choisie pour la base de données Conteneur Autonomous Vous pouvez restaurer et récupérer votre base de données jusqu'à n'importe quel point dans le temps au cours de cette période de conservation.	Une fois activées, les sauvegardes automatiques ne peuvent pas être désactivées pour une base de données Conteneur Autonomous. Lorsque les sauvegardes automatiques sont activées, vous pouvez également effectuer des sauvegardes inter-région, des sauvegardes à long terme et des sauvegardes manuelles. Vous pouvez définir la période/la stratégie de conservation de sauvegarde lors du provisionnement d'une base de données Conteneur Autonomous ou la modifier ultérieurement à partir de sa page de détails sur la console Oracle Cloud Infrastructure. Vous pouvez conserver les sauvegardes d'une base de données Conteneur Autonomous arrêtée jusqu'à 72 heures ou jusqu'à la fin de sa période de conservation. Vous pouvez activer le verrou de conservation de sauvegarde pour empêcher toute suppression indésirable des sauvegardes de base de données Conteneur Autonomous et Autonomous AI avant leur période de conservation. Vous pouvez activer le verrou de conservation lors du provisionnement de la base de données Conteneur Autonomous ou ultérieurement. Une fois activé, vous pouvez désactiver le verrou de conservation dans les 14 jours, au-delà duquel le paramètre devient permanent. Une fois le verrou de conservation activé, vous ne pouvez qu'augmenter la valeur de la période de conservation et il ne peut pas être réduit. Toutes les sauvegardes à long terme sont également verrouillées et ne peuvent pas être supprimées lorsque le verrouillage de conservation est activé. Les sauvegardes à long terme sont automatiquement supprimées après leur expiration. Toutefois, dans le cas de déploiements Exadata Cloud@Customer, si la destination de sauvegarde est NFS, aucune des sauvegardes n'est automatiquement supprimée lorsqu'une base de données Conteneur Autonomous est arrêtée. Vous devez supprimer manuellement toutes les sauvegardes automatiques, manuelles et à long terme après la fin de la base de données Conteneur Autonomous et après la date d'expiration. Reportez-vous à Stratégie de conservation de sauvegarde pour plus de détails sur les valeurs de stratégie de conservation de sauvegarde pour les différents déploiements de base de données Autonomous AI.	Sauvegarde et restauration de bases de données Autonomous AI.
Destination de sauvegarde Une destination de sauvegarde définit les propriétés requises pour la connexion à un emplacement de sauvegarde. Chacune de ces destinations doit être accessible dans votre centre de données à partir de noeuds de cluster.	La possibilité de choisir une destination de sauvegarde lors du provisionnement d'une base de données Conteneur Autonomous et les destinations de sauvegarde prises en charge varient en fonction de la plate-forme de déploiement. Pour plus d'informations sur les différents types de destination de sauvegarde, reportez-vous à Destination de sauvegarde.	Pour en savoir plus sur la configuration de la destination de sauvegarde NFS pour Cloud@Customer, reportez-vous à Prérequis pour les destinations de sauvegarde pour Exadata Cloud@Customer. Pour obtenir des instructions sur la modification du type de destination de sauvegarde après le provisionnement de la base de données Conteneur Autonomous, reportez-vous à Modification des paramètres de sauvegarde de base de données Conteneur Autonomous.
Utilisation de l'emplacement NFS	S'applique à : Exadata Cloud@Customer uniquement Si le type de destination de sauvegarde en cours est NFS, l'utilisation de l'espace NFS en cours est affichée sous forme de pourcentage avec une icône de statut.	Pour plus d'informations, reportez-vous à Affichage de l'utilisation de l'espace NFS.
Attributs Resource Management Les attributs de gestion des ressources ont une incidence sur la façon dont les ressources sont gérées pour consolider davantage de bases de données ou disposer de la disponibilité de base de données la plus élevée.	Lors du provisionnement d'une base de données Conteneur Autonomous, vous pouvez éventuellement définir une valeur appropriée pour les attributs de gestion des ressources suivants en fonction de vos besoins : Seuil de fractionnement de base de données (UC) : valeur d'UC au-delà de laquelle une base de données Autonomous AI sera ouverte sur plusieurs noeuds. La valeur par défaut de cet attribut est 16 pour les OCPU et 64 pour les ECPU. Réservation de basculement de noeud (%) : détermine le pourcentage d'UC réservées sur les noeuds pour prendre en charge le basculement de noeud. Les valeurs autorisées sont 0 %, 25 % et 50 %, 50 % étant l'option par défaut. Affinité de distribution : détermine si une base de données Autonomous AI doit être ouverte sur un nombre minimal ou maximal de noeuds. Par défaut, le nombre minimal de noeuds est sélectionné.	Pour plus d'informations sur l'impact de ces attributs de base de données Conteneur Autonomous sur les performances de vos bases de données, reportez-vous à Détails de facturation de l'UC.
Connexions au serveur partagé L'architecture de serveur partagé permet à un serveur de base de données d'autoriser un certain nombre de processus client à partager très peu de processus serveur, afin d'accroître le nombre d'utilisateurs pouvant être pris en charge.	Lors du provisionnement d'une base de données Conteneur Autonomous, vous pouvez éventuellement activer les connexions au serveur partagé. Vous ne pouvez pas désactiver l'architecture de serveur partagé après le provisionnement de la base de données Conteneur Autonomous.	Fonctionnalités de connexion à usage spécial
Clé de cryptage Par défaut, Autonomous AI Database crée et gère toutes les clés de cryptage maître utilisées pour protéger vos données, et les stocke dans un fichier d'clés PKCS 12 sécurisé sur les systèmes Exadata sur lesquels résident les bases de données. Si les stratégies d'assurance de votre entreprise l'exigent, Autonomous AI Database peut utiliser les clés de votre création et de votre gestion.	Lors du provisionnement d'une base de données Conteneur Autonomous, vous pouvez éventuellement la configurer pour qu'elle utilise des clés de cryptage gérées par le client plutôt que des clés de cryptage gérées par Oracle. Lorsque vous utilisez des clés de cryptage gérées par le client, vous avez le choix entre les options suivantes : Service OCI Vault : avec cette option, vous sélectionnez un coffre et une clé de cryptage maître. Cette option n'est disponible que sur Oracle Public Cloud. Oracle Key Vault : sélectionnez un fichier de clés avec cette option et entrez un nom de groupe d'adresses OKV. Service AWS KMS : dans la base de données Autonomous AI sur Oracle Database@AWS, vous pouvez utiliser AWS Key Management Service (AWS KMS) pour gérer les clés de cryptage maître. Vous pouvez utiliser une clé de cryptage gérée par un client avec des base de données Autonomous Data Guard sur lesquelles les bases de données principale et de secours situées dans différents domaines d'accès de la même région.	A propos des clés de cryptage maître Utilisation de vos propres clés (BYOK) dans le service Vault Utilisation de clés gérées par l'utilisateur dans Oracle Key Vault Rotation de la clé de cryptage d'une base de données Conteneur Autonomous
Adresse électronique du contact Vous pouvez fournir des courriels de contact dans lesquels vous pouvez recevoir des notifications opérationnelles, des annonces et des notifications de maintenance non planifiée concernant votre base de données Conteneur Autonomous.	Oracle recommande d'utiliser l'adresse électronique d'un groupe d'administrateurs plutôt que celle d'une personne, chaque fois que cela est possible, afin de garantir qu'aucune notification ou annonce importante n'est manquée.
Full Stack Disaster Recovery Full Stack DR est un service de gestion et d'orchestration de la récupération après sinistre Oracle Cloud Infrastructure (OCI) qui fournit les fonctionnalités complètes pour toutes les couches de la pile d'applications, y compris l'infrastructure, le middleware, la base de données et l'application.	Vous pouvez activer OCI Full Stack Disaster Recovery et l'utiliser pour effectuer des opérations de permutation/basculement ou éventuellement effectuer des opérations de permutation/basculement de base de données Autonomous AI uniquement.	Utilisation d'OCI Full Stack Disaster Recovery sur une base de données d'IA autonome sur une infrastructure Exadata dédiée
Copier de sauvegarde inter-région Vous pouvez sélectionner une région secondaire pour une copie de vos sauvegardes. En cas d'échec d'une région, vous pouvez cloner la sauvegarde distante de la base de données Conteneur Autonomous pour restaurer les données. La sauvegarde d'une base de données Conteneur Autonomous peut uniquement être clonée vers un cluster de machines virtuelles Exadata Autonomous différent de son base de données AVMC source.	S'APPLIQUE À : Oracle Public Cloud uniquement La copie de sauvegarde inter-région peut être activée lors du provisionnement d'une base de données Conteneur Autonomous ou à partir de la page de détails d'une base de données Conteneur Autonomous existante. Vous ne pouvez pas activer la sauvegarde inter-région si Autonomous Data Guard est activé.	A propos du clonage d'une base de données Conteneur Autonomous sur un environnement Exadata dédié Clonage d'une base de données Conteneur Autonomous

Fonctionnalité de base de données d'IA autonome

Remarques

Références supplémentaires

Version du logiciel Oracle Database

Vous pouvez définir la version du logiciel de base de données Conteneur lors du provisionnement d'une base de données Conteneur Autonomous.

Vous pouvez choisir la version du logiciel Oracle Database à partir d'une version d'image de base ou d'une image logicielle de base de données Autonomous AI créée à partir d'une autre base de données Conteneur Autonomous.

Lorsque vous sélectionnez une version dans l'image de base, vous pouvez choisir la dernière version du logiciel Oracle Database ou son prédécesseur immédiat. Par exemple : supposons que la dernière version d'Oracle Database prise en charge par Autonomous AI Database soit la version 19.26.0.1.0. Ensuite, la liste déroulante Sélectionner l'image de base répertorie 19.26.0.1.0 et 19.25.0.1.0. que vous pouvez choisir.

Autonomous Data Guard

La configuration d'Autonomous Data Guard permet d'assurer la disponibilité de vos bases de données d'exploitation essentielles pour vos applications stratégiques, malgré la panne.

Vous pouvez activer Autonomous Data Guard à partir de la page Détails d'une base de données Conteneur Autonomous et créer jusqu'à deux bases de données Conteneur Autonomous de secours.

Les bases de données Conteneur Autonomous principale et secondaire peuvent également être déployées dans différentes régions (inter-région). Dans une configuration Autonomous Data Guard inter-région à l'aide de clés gérées par le client ou de KMS, selon le nombre de bases de données Autonomous AI dans la base de données Conteneur Autonomous principale, de nouvelles versions de clé seront automatiquement générées pour les bases de données de secours dans le coffre inter-région.

Protection des bases de données critiques contre les échecs et les sinistres à l'aide d'Autonomous Data Guard

Programmation de maintenance

En général, Oracle planifie et effectue une maintenance complète du parc répartie sur chaque trimestre et des correctifs de sécurité d'infrastructure mensuels pour les vulnérabilités dont les scores CVSS sont supérieurs ou égaux à 7.

Vous pouvez laisser Oracle gérer la programmation de la maintenance ou définir une fenêtre spécifique pendant laquelle Oracle peut commencer les opérations de maintenance.

Vous pouvez choisir entre les méthodes de maintenance non simultanée ou non simultanée pour une base de données Conteneur Autonomous. Si vous choisissez une méthode de maintenance simultanée dans une configuration Autonomous Data Guard, un temps d'inactivité sera appliqué à la base de données Conteneur Autonomous et à toutes les bases de données Autonomous AI associées jusqu'à la fin de l'application de patches. Vous pouvez également sélectionner Activer la mise à jour du fuseau horaire. Les fichiers de fuseaux horaires ne peuvent être mis à jour qu'à l'aide de la méthode de configuration simultanée.

Vous pouvez définir ou modifier les paramètres de programmation de maintenance d'une base de données Conteneur Autonomous à gérer par Oracle ou vous pouvez définir une programmation de maintenance personnalisée.

Lors de la personnalisation de la programmation de maintenance d'une base de données Conteneur Autonomous, vous pouvez choisir d'ignorer l'application de patches pendant un trimestre. Toutefois, vous ne pouvez pas ignorer l'application de patches pendant deux trimestres consécutifs. Lorsque vous choisissez d'ignorer l'application de patches pour un trimestre, vous devez sélectionner au moins un mois à partir de ce trimestre. Il s'agit d'une restauration au cas où la maintenance n'aurait pas eu lieu au cours du trimestre non ignoré précédent. Dans ce scénario, Oracle effectuera automatiquement la maintenance au cours du mois sélectionné, même si l'option Ignorer est sélectionnée pour ce trimestre.

Vous pouvez afficher le nombre de patches exceptionnels disponibles pour une base de données Conteneur Autonomous sur sa page Détails. Cliquez sur le lien Copier en regard de ce lien pour copier tous ces numéros de patch exceptionnels.

Lorsque vous reprogrammez un événement d'entretien de base de données Conteneur Autonomous déjà programmé, Oracle peut le placer dans une file d'attente si les ressources d'infrastructure Exadata ou de cluster de machines virtuelles Exadata Autonomous correspondantes sont :

font déjà l'objet d'une mise à jour de maintenance, ou
sont programmés pour une activité de maintenance simultanément en tant que base de données Conteneur Autonomous.

Vous pouvez programmer une maintenance à la demande pour mettre à jour la RU (Mise à jour de version) avec le fichier de fuseau horaire ou uniquement le fichier de fuseau horaire pour une base de données Conteneur Autonomous. Vous pouvez également choisir de mettre à jour à l'aide d'une image logicielle de base de données personnalisée existante.

Le temps d'inactivité de votre base de données Conteneur Autonomous et des bases de données Autonomous AI associées peut dépendre de la configuration de la programmation de maintenance de votre base de données Conteneur Autonomous.

Maintenance des services

Planifier une mise à jour de maintenance trimestrielle

Sauvegarde et restauration

Pour prendre en charge la haute disponibilité, Autonomous AI Database sauvegarde automatiquement votre base de données pour vous. La durée de conservation des sauvegardes est de 95 jours au maximum, en fonction de la stratégie/période de conservation de sauvegarde choisie pour la base de données Conteneur Autonomous Vous pouvez restaurer et récupérer votre base de données jusqu'à n'importe quel point dans le temps au cours de cette période de conservation.

Une fois activées, les sauvegardes automatiques ne peuvent pas être désactivées pour une base de données Conteneur Autonomous. Lorsque les sauvegardes automatiques sont activées, vous pouvez également effectuer des sauvegardes inter-région, des sauvegardes à long terme et des sauvegardes manuelles.

Vous pouvez définir la période/la stratégie de conservation de sauvegarde lors du provisionnement d'une base de données Conteneur Autonomous ou la modifier ultérieurement à partir de sa page de détails sur la console Oracle Cloud Infrastructure.

Vous pouvez conserver les sauvegardes d'une base de données Conteneur Autonomous arrêtée jusqu'à 72 heures ou jusqu'à la fin de sa période de conservation.
Vous pouvez activer le verrou de conservation de sauvegarde pour empêcher toute suppression indésirable des sauvegardes de base de données Conteneur Autonomous et Autonomous AI avant leur période de conservation.
Vous pouvez activer le verrou de conservation lors du provisionnement de la base de données Conteneur Autonomous ou ultérieurement.
Une fois activé, vous pouvez désactiver le verrou de conservation dans les 14 jours, au-delà duquel le paramètre devient permanent.
Une fois le verrou de conservation activé, vous ne pouvez qu'augmenter la valeur de la période de conservation et il ne peut pas être réduit.
Toutes les sauvegardes à long terme sont également verrouillées et ne peuvent pas être supprimées lorsque le verrouillage de conservation est activé.

Les sauvegardes à long terme sont automatiquement supprimées après leur expiration. Toutefois, dans le cas de déploiements Exadata Cloud@Customer, si la destination de sauvegarde est NFS, aucune des sauvegardes n'est automatiquement supprimée lorsqu'une base de données Conteneur Autonomous est arrêtée. Vous devez supprimer manuellement toutes les sauvegardes automatiques, manuelles et à long terme après la fin de la base de données Conteneur Autonomous et après la date d'expiration.

Reportez-vous à Stratégie de conservation de sauvegarde pour plus de détails sur les valeurs de stratégie de conservation de sauvegarde pour les différents déploiements de base de données Autonomous AI.

Sauvegarde et restauration de bases de données Autonomous AI.

Destination de sauvegarde

Une destination de sauvegarde définit les propriétés requises pour la connexion à un emplacement de sauvegarde. Chacune de ces destinations doit être accessible dans votre centre de données à partir de noeuds de cluster.

La possibilité de choisir une destination de sauvegarde lors du provisionnement d'une base de données Conteneur Autonomous et les destinations de sauvegarde prises en charge varient en fonction de la plate-forme de déploiement.

Pour plus d'informations sur les différents types de destination de sauvegarde, reportez-vous à Destination de sauvegarde.

Pour en savoir plus sur la configuration de la destination de sauvegarde NFS pour Cloud@Customer, reportez-vous à Prérequis pour les destinations de sauvegarde pour Exadata Cloud@Customer.

Pour obtenir des instructions sur la modification du type de destination de sauvegarde après le provisionnement de la base de données Conteneur Autonomous, reportez-vous à Modification des paramètres de sauvegarde de base de données Conteneur Autonomous.

Utilisation de l'emplacement NFS

S'applique à : Applicable

Exadata Cloud@Customer uniquement

Si le type de destination de sauvegarde en cours est NFS, l'utilisation de l'espace NFS en cours est affichée sous forme de pourcentage avec une icône de statut.

Pour plus d'informations, reportez-vous à Affichage de l'utilisation de l'espace NFS.

Attributs Resource Management

Les attributs de gestion des ressources ont une incidence sur la façon dont les ressources sont gérées pour consolider davantage de bases de données ou disposer de la disponibilité de base de données la plus élevée.

Lors du provisionnement d'une base de données Conteneur Autonomous, vous pouvez éventuellement définir une valeur appropriée pour les attributs de gestion des ressources suivants en fonction de vos besoins :

Seuil de fractionnement de base de données (UC) : valeur d'UC au-delà de laquelle une base de données Autonomous AI sera ouverte sur plusieurs noeuds. La valeur par défaut de cet attribut est 16 pour les OCPU et 64 pour les ECPU.
Réservation de basculement de noeud (%) : détermine le pourcentage d'UC réservées sur les noeuds pour prendre en charge le basculement de noeud. Les valeurs autorisées sont 0 %, 25 % et 50 %, 50 % étant l'option par défaut.
Affinité de distribution : détermine si une base de données Autonomous AI doit être ouverte sur un nombre minimal ou maximal de noeuds. Par défaut, le nombre minimal de noeuds est sélectionné.

Pour plus d'informations sur l'impact de ces attributs de base de données Conteneur Autonomous sur les performances de vos bases de données, reportez-vous à Détails de facturation de l'UC.

Connexions au serveur partagé

L'architecture de serveur partagé permet à un serveur de base de données d'autoriser un certain nombre de processus client à partager très peu de processus serveur, afin d'accroître le nombre d'utilisateurs pouvant être pris en charge.

Lors du provisionnement d'une base de données Conteneur Autonomous, vous pouvez éventuellement activer les connexions au serveur partagé. Vous ne pouvez pas désactiver l'architecture de serveur partagé après le provisionnement de la base de données Conteneur Autonomous.

Fonctionnalités de connexion à usage spécial

Clé de cryptage

Par défaut, Autonomous AI Database crée et gère toutes les clés de cryptage maître utilisées pour protéger vos données, et les stocke dans un fichier d'clés PKCS 12 sécurisé sur les systèmes Exadata sur lesquels résident les bases de données.

Si les stratégies d'assurance de votre entreprise l'exigent, Autonomous AI Database peut utiliser les clés de votre création et de votre gestion.

Lors du provisionnement d'une base de données Conteneur Autonomous, vous pouvez éventuellement la configurer pour qu'elle utilise des clés de cryptage gérées par le client plutôt que des clés de cryptage gérées par Oracle.

Lorsque vous utilisez des clés de cryptage gérées par le client, vous avez le choix entre les options suivantes :

Service OCI Vault : avec cette option, vous sélectionnez un coffre et une clé de cryptage maître. Cette option n'est disponible que sur Oracle Public Cloud.
Oracle Key Vault : sélectionnez un fichier de clés avec cette option et entrez un nom de groupe d'adresses OKV.
Service AWS KMS : dans la base de données Autonomous AI sur Oracle Database@AWS, vous pouvez utiliser AWS Key Management Service (AWS KMS) pour gérer les clés de cryptage maître.

Vous pouvez utiliser une clé de cryptage gérée par un client avec des base de données Autonomous Data Guard sur lesquelles les bases de données principale et de secours situées dans différents domaines d'accès de la même région.

A propos des clés de cryptage maître

Utilisation de vos propres clés (BYOK) dans le service Vault

Utilisation de clés gérées par l'utilisateur dans Oracle Key Vault

Rotation de la clé de cryptage d'une base de données Conteneur Autonomous

Adresse électronique du contact

Vous pouvez fournir des courriels de contact dans lesquels vous pouvez recevoir des notifications opérationnelles, des annonces et des notifications de maintenance non planifiée concernant votre base de données Conteneur Autonomous.

Oracle recommande d'utiliser l'adresse électronique d'un groupe d'administrateurs plutôt que celle d'une personne, chaque fois que cela est possible, afin de garantir qu'aucune notification ou annonce importante n'est manquée.

Full Stack Disaster Recovery

Full Stack DR est un service de gestion et d'orchestration de la récupération après sinistre Oracle Cloud Infrastructure (OCI) qui fournit les fonctionnalités complètes pour toutes les couches de la pile d'applications, y compris l'infrastructure, le middleware, la base de données et l'application.

Vous pouvez activer OCI Full Stack Disaster Recovery et l'utiliser pour effectuer des opérations de permutation/basculement ou éventuellement effectuer des opérations de permutation/basculement de base de données Autonomous AI uniquement.

Utilisation d'OCI Full Stack Disaster Recovery sur une base de données d'IA autonome sur une infrastructure Exadata dédiée

Copier de sauvegarde inter-région

Vous pouvez sélectionner une région secondaire pour une copie de vos sauvegardes. En cas d'échec d'une région, vous pouvez cloner la sauvegarde distante de la base de données Conteneur Autonomous pour restaurer les données. La sauvegarde d'une base de données Conteneur Autonomous peut uniquement être clonée vers un cluster de machines virtuelles Exadata Autonomous différent de son base de données AVMC source.

S'APPLIQUE À : Applicable

Oracle Public Cloud uniquement

La copie de sauvegarde inter-région peut être activée lors du provisionnement d'une base de données Conteneur Autonomous ou à partir de la page de détails d'une base de données Conteneur Autonomous existante.

Vous ne pouvez pas activer la sauvegarde inter-région si Autonomous Data Guard est activé.

A propos du clonage d'une base de données Conteneur Autonomous sur un environnement Exadata dédié

Clonage d'une base de données Conteneur Autonomous

Opérations de gestion de base de données Conteneur Autonomous

Vous pouvez effectuer les opérations de gestion suivantes sur une base de données Conteneur Autonomous.

Opération	Instructions de tâche
Création d'une base de données Conteneur Autonomous	Création d'une base de données Conteneur Autonomous
Modification de la stratégie de conservation de sauvegarde d'une base de données Conteneur Autonomous	Modifier les paramètres de sauvegarde de base de données Conteneur Autonomous
Création d'une image logicielle de base de données Autonomous AI	Création d'une image logicielle de base de données d'IA autonome
Modification des préférences de maintenance d'une base de données Conteneur Autonomous	Mise à jour des préférences de maintenance de la base de données Conteneur Autonomous
Gérer une configuration Autonomous Data Guard	Gérer une configuration Autonomous Data Guard
Déplacement d'une base de données Conteneur Autonomous vers un autre compartiment	Déplacement d'une base de données Conteneur Autonomous vers un autre compartiment
Rotation d'une clé de cryptage de base des données Conteneur Autonomous	Rotation de la clé de cryptage d'une base de données Conteneur Autonomous
Redémarrage d'une base de données Conteneur Autonomous	Redémarrage d'une base de données Conteneur Autonomous
Terminaison d'une base de données Conteneur Autonomous	Terminaison d'une base de données Conteneur Autonomous
Gestion des contacts client pour une base de données Conteneur Autonomous	Gérer les contacts client pour une base de données Conteneur Autonomous
Affichage de la liste des bases de données Conteneur Autonomous	Affichage de la liste des bases de données Conteneur Autonomous
Affichage des détails d'une base de données Conteneur Autonomous	Affichage des détails d'une base de données Conteneur Autonomous
Affichage de l'utilisation de l'espace NFS	S'applique à : Exadata Cloud@Customer uniquement Affichage de l'utilisation de l'espace NFS

Les opérations répertoriées ci-dessus peuvent également être réalisées à l'aide de l'API. Pour plus d'informations, reportez-vous à API de gestion des bases de données Conteneur Autonomous.

Surveillance d'une base de données Conteneur Autonomous

Vous pouvez utiliser des vues dynamiques des performances pour surveiller votre base de données Conteneur Autonomous de l'une des manières suivantes :

Consulter les mesures en temps réel relatives aux différents événements Wait et classes Wait.
Affichez l'historique des clichés des mesures de classe Wait.
Consulter les données de métriques de performances en temps réel, historiques et récapitulatives.
Afficher les limites de ressources et l'utilisation actuelle.

Pour plus d'informations, reportez-vous à Vues de performances dynamiques.