À propos de la base de données conteneur autonome

La base de données conteneur autonome 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'intelligence artificielle autonome sur une infrastructure Exadata dédiée. Les bases de données conteneur autonomes sont provisionnées dans une grappe de machines virtuelles Exadata autonome et servent de conteneurs pour une ou plusieurs bases de données autonomes d'IA.

Vous pouvez créer plusieurs ressources de base de données conteneur autonome dans une seule ressource AVMC, mais vous devez en créer au moins une avant de pouvoir créer des bases de données autonomes basées sur l'IA. Pour obtenir une compréhension complète de l'architecture à quatre couches 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 autonome dans cette architecture, voir Composants de la base de données d'IA autonome sur une infrastructure Exadata dédiée.

Les bases de données conteneur autonomes vous permettent d'exploiter séparément les unes des autres et de séparer les bases de données autonomes d'IA en fonction de l'utilisation prévue. Par exemple, vous pouvez créer différentes bases de données conteneur autonomes à des fins de production et de test, ou même avoir plusieurs bases de données conteneur autonomes utilisant différentes versions de base de données.

Bien que les administrateurs de parc créent, surveillent et gèrent les bases de données conteneur autonomes, les administrateurs de base de données d'application les utilisent principalement pour créer des bases de données autonomes d'IA. Voir Rôles d'utilisateur associés à une base de données avec intelligence artificielle autonome sur une infrastructure Exadata dédiée pour en savoir plus.

Rubriques connexes

Exigences relatives aux bases de données conteneur autonomes

Exigences relatives aux politiques IAM

Vous devez avoir un compte Oracle Cloud Infrastructure avec des privilèges accordés au moyen des politiques IAM requises. Les politiques requises dépendent de l'opération que vous effectuez. Pour obtenir la liste des politiques IAM relatives aux bases de données conteneur autonomes, voir Politiques de gestion des bases de données conteneur autonomes.

Ressources minimales requises

Pour créer une base de données conteneur autonome, vous devez disposer d'au moins :

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

Exigences relatives à la version du logiciel Oracle Database

Pour provisionner une base de données conteneur autonome avec la version 26ai du logiciel Oracle Database, vous devez choisir une grappe de machines virtuelles Exadata autonome (AVMC) basée sur ECPU qui a été créée avec le marqueur DatabaseVersion réglé à 26ai.
De même, pour provisionner une base de données conteneur autonome avec la version du logiciel Oracle Database 19c, vous devez choisir une grappe de machines virtuelles Exadata autonome dont le marqueur DatabaseVersion n'est pas réglé à 26ai.
Vous ne pouvez pas provisionner les bases de données conteneur autonomes 19c et 26ai dans la même grappe de machines virtuelles autonome.

Note :

Les déploiements à nuages multiples ne nécessitent pas de marqueur spécial et prendront automatiquement en charge les bases de données 19c et 26ai.

Fonctions de base de données gérées à partir d'une base de données conteneur autonome

Les fonctions suivantes de la base de données Autonomous AI Database peuvent être définies et gérées au niveau de la base de données conteneur autonome.

Fonction de base de données sur l'IA autonome	Notes	Informations de référence supplémentaires
Version du logiciel Oracle Database Vous pouvez définir la version du logiciel de la base de données conteneur lors du provisionnement d'une base de données conteneur autonome.	Vous pouvez choisir la version du logiciel Oracle Database à partir d'une version d'image de base ou d'une image logicielle Autonomous AI Database créée à partir d'une autre base de données conteneur autonome. Lorsque vous sélectionnez une version dans l'image de base, vous pouvez choisir la dernière version du logiciel Oracle Database ou sa version précédente immédiate. Par exemple : Supposons que la dernière version d'Oracle Database prise en charge par Autonomous AI Database soit 19.26.0.1.0. Ensuite, la liste déroulante Sélectionner l'image de base liste les valeurs 19.26.0.1.0 et 19.25.0.1.0. pour que vous puissiez choisir. Les bases de données conteneur autonomes avec la version du logiciel de base de données 26ai ne peuvent être provisionnées que sur des grappes de machines virtuelles Exadata autonomes (AVMC) basées sur ECPU créées avec les marqueurs appropriés. Voir Exigences relatives aux marqueurs de version du logiciel de base de données 26ai pour plus de détails. Les déploiements à nuages multiples ne nécessitent pas de marqueur spécial et prendront automatiquement en charge les bases de données 19c et 26ai.	-
Autonomous Data Guard La configuration d'Autonomous Data Guard vous permet de garder vos bases de données de production critiques disponibles pour les applications stratégiques, malgré les défaillances.	Vous pouvez activer Autonomous Data Guard à partir de la page Détails d'une base de données conteneur autonome et créer jusqu'à deux bases de données conteneur autonomes de secours. Les bases de données conteneur autonomes principale et secondaire peuvent également être déployées dans différentes régions (inter-régions). Dans une configuration Autonomous Data Guard inter-région utilisant des clés gérées par le client ou un système de gestion des clés, selon le nombre de bases de données autonomes basées sur l'IA dans la base de données conteneur autonome principale, de nouvelles versions de clé sont générées automatiquement pour les bases de données de secours dans la chambre forte inter-région.	Protéger les bases de données critiques contre les défaillances et les sinistres à l'aide d'Autonomous Data Guard
Programme de maintenance En général, Oracle programme et effectue la maintenance complète du parc, répartie sur l'ensemble des correctifs de sécurité d'infrastructure trimestriels et mensuels, pour les vulnérabilités dont la note CVSS est supérieure ou égale à 7. Vous pouvez laisser Oracle gérer la programmation de la maintenance ou définir une fenêtre de maintenance spécifique pendant laquelle Oracle peut commencer les opérations de maintenance.	Vous pouvez choisir entre les méthodes de maintenance continue ou non continue pour une base de données conteneur autonome. Si vous choisissez une méthode de maintenance non continue dans une configuration Autonomous Data Guard, il y aura un temps d'arrêt pour la base de données conteneur autonome et toutes les bases de données autonomes d'IA associées jusqu'à la fin de l'application de correctifs. Facultativement, vous pouvez également sélectionner Activer la mise à jour du fuseau horaire. Les fichiers de fuseaux horaires peuvent seulement être mis à jour avec la méthode de configuration non continue Vous pouvez définir ou modifier les paramètres du programme de maintenance pour une base de données conteneur autonome à gérer par Oracle ou vous pouvez définir un programme de maintenance personnalisé. Lors de la personnalisation du programme de maintenance d'une base de données conteneur autonome, vous pouvez choisir d'ignorer l'application de correctifs pour un trimestre. Toutefois, vous ne pouvez pas ignorer l'application de correctifs pendant deux trimestres consécutifs. Lorsque vous choisissez d'ignorer l'application de correctifs pour un trimestre, vous devez sélectionner au moins un mois dans ce trimestre. Il s'agit d'un traitement de secours si la maintenance n'a pas eu lieu au cours du trimestre précédent non ignoré. 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 voir le nombre de correctifs ponctuels disponibles pour une base de données conteneur autonome dans sa page Détails. Cliquer sur le lien Copier à côté copie tous ces numéros de correctif ponctuel. Lorsque vous programmez un événement de maintenance de base de données conteneur autonome qui est déjà programmé, Oracle peut le placer dans une file d'attente si sa ressource d'infrastructure Exadata ou de grappe de machines virtuelles Exadata autonome : Font déjà l'objet d'une mise à jour de maintenance, ou Programmé pour une activité de maintenance simultanément en tant que base de données conteneur autonome. Vous pouvez programmer une maintenance sur demande pour mettre à jour l'UR (mise à jour de version) avec le fichier de fuseaux horaires ou simplement le fichier de fuseaux horaires d'une base de données conteneur autonome. Vous pouvez également choisir d'effectuer une mise à jour à l'aide d'une image logicielle de base de données personnalisée existante. Vous pouvez subir un temps d'arrêt pour votre base de données conteneur autonome et les bases de données autonomes d'IA associées, selon la configuration du programme de maintenance de votre base de données conteneur autonome.	Maintenance du service Programmer 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. La période de conservation des sauvegardes est de 95 jours, selon la politique/période de conservation de sauvegarde sélectionnée pour la base de données conteneur autonome. Vous pouvez restaurer et récupérer votre base de données à tout point dans le temps pendant cette période.	Une fois activées, les sauvegardes automatiques ne peuvent pas être désactivées pour une base de données conteneur autonome. Lorsque les sauvegardes automatiques sont activées, vous pouvez en outre effectuer des sauvegardes inter-régions, des sauvegardes à long terme et des sauvegardes manuelles. Vous pouvez définir la politique/période de conservation des sauvegardes lors du provisionnement d'une base de données conteneur autonome ou la modifier ultérieurement à partir de sa page de détails dans la console Console Oracle Cloud Infrastructure. Dans les déploiements d'Oracle Public Cloud et d'Exadata Cloud@Customer : Vous pouvez conserver les sauvegardes d'une base de données conteneur autonome arrêtée jusqu'à 72 heures ou jusqu'à la fin de sa période de conservation des sauvegardes. Vous pouvez activer le verrouillage de conservation des sauvegardes pour empêcher toute suppression indésirable des sauvegardes ACD et Autonomous AI Database avant leur période de conservation. Vous pouvez activer le verrouillage de conservation lors du provisionnement de la base de données conteneur autonome ou ultérieurement. Une fois activé, vous pouvez désactiver le verrouillage de rétention dans les 14 jours, au-delà desquels le paramètre devient permanent. Une fois le verrouillage de conservation activé, vous ne pouvez augmenter la valeur de la période de conservation que si elle ne peut pas être réduite. Toutes les sauvegardes à long terme seront également verrouillées et ne pourront pas être supprimées lorsque le verrouillage de conservation sera activé. Les sauvegardes à long terme sont automatiquement supprimées une fois qu'elles expirent. Toutefois, dans le cas des 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 autonome 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 autonome et la date d'expiration. Voir Politique de conservation des sauvegardes pour plus de détails sur les valeurs de la politique de conservation des sauvegardes pour différents déploiements de base de données autonome sur intelligence artificielle.	Sauvegarder et restaurer des bases de données d'IA autonomes.
Destination de sauvegarde Une destination de sauvegarde définit les propriétés requises pour la connexion à un emplacement de sauvegarde et chaque destination de sauvegarde doit être accessible dans votre centre de données à partir des noeuds de grappe de machines virtuelles.	La possibilité de choisir une destination de sauvegarde lors du provisionnement d'une base de données conteneur autonome, et les destinations de sauvegarde prises en charge varient en fonction de la plate-forme de déploiement. Voir Destination de sauvegarde pour plus de détails sur les différents types de destination de sauvegarde.	Pour en savoir plus sur la configuration de la destination de sauvegarde NFS pour Cloud@Customer, voir Préalables pour les destinations de sauvegarde pour Exadata Cloud@Customer. Reportez-vous à Modifier les paramètres de sauvegarde de base de données conteneur autonome pour obtenir des instructions sur la modification du type de destination de sauvegarde après le provisionnement de la base de données conteneur autonome.
Utilisation de l'espace NFS	S'APPLIQUE À : Exadata Cloud@Customer seulement Si le type de destination de sauvegarde courant est NFS, l'utilisation de l'espace NFS courant est affichée sous forme de pourcentage avec une icône de statut.	Pour plus de détails, voir Voir 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 afin de consolider davantage de bases de données ou d'offrir la disponibilité la plus élevée.	Facultativement, lors du provisionnement d'une base de données conteneur autonome, vous pouvez 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 d'intelligence artificielle autonome 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 répartition : Détermine si une base de données autonome sur l'IA doit être ouverte sur un nombre minimal ou maximal de noeuds. Par défaut, Minimum node est sélectionné.	Pour plus d'informations sur l'incidence de ces attributs de base de données conteneur autonome sur la performance de vos bases de données, voir 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 plusieurs processus clients à partager très peu de processus serveurs, de sorte que le nombre d'utilisateurs pouvant être pris en charge est augmenté.	Lors du provisionnement d'une base de données conteneur autonome, vous pouvez éventuellement activer les connexions de serveur partagé. Vous ne pouvez pas désactiver l'architecture de serveur partagé après avoir provisionné la base de données conteneur autonome.	Fonctions de connexion à usage spécifique.
Clé de chiffrement Par défaut, Autonomous AI Database crée et gère toutes les clés de chiffrement principales utilisées pour protéger vos données, en les stockant dans un magasin de clés PKCS 12 sécurisé sur les systèmes Exadata où résident les bases de données. Si les politiques de sécurité de votre entreprise le nécessitent, Autonomous AI Database peut utiliser des clés que vous créez et gérez.	Lors du provisionnement d'une base de données conteneur autonome, vous pouvez éventuellement configurer cette dernière pour qu'elle utilise des clés de chiffrement gérées par le client au lieu de celles gérées par Oracle. Vous pouvez choisir entre les options suivantes lors de l'utilisation de clés de chiffrement gérées par le client : Service de chambre forte OCI : Avec cette option, vous sélectionnez une chambre forte et une clé de chiffrement principale. Cette option n'est disponible que dans Oracle Public Cloud. Oracle Key Vault : Vous sélectionnez un magasin de clés avec cette option et entrez un nom de groupe de points d'extrémité OKV. Vous pouvez utiliser des clés de chiffrement gérées par le client avec des bases de données conteneur autonomes activées pour Autonomous Data Guard lorsque les bases de données principale et de secours se trouvent dans différents domaines de disponibilité au sein de la même région.	À propos des clés de chiffrement principales Utiliser ses propres clés (BYOK) dans le service de chambre forte Utiliser des clés gérées par le client dans Oracle Key Vault Effectuer une rotation de la clé de chiffrement pour une base de données conteneur autonome.
Adresse de contact Vous pouvez fournir des courriels de contact où vous pouvez recevoir des avis opérationnels, des annonces et des avis de maintenance non planifiés concernant votre base de données conteneur autonome.	Oracle recommande d'utiliser l'adresse de courriel d'un groupe d'administrateurs plutôt que celle d'une personne, dans la mesure du possible, pour s'assurer qu'aucun avis ou annonce important n'est manqué.
Récupération après sinistre de pile complète Full Stack DR est un service d'orchestration et de gestion de la récupération après sinistre pour Oracle Cloud Infrastructure qui fournit des fonctions complètes de récupération après sinistre pour toutes les couches d'une pile d'applications, notamment l'infrastructure, l'intergiciel, la base de données et les applications.	Vous pouvez activer la récupération après sinistre de pile complète pour OCI et l'utiliser pour effectuer des opérations de permutation ou de basculement ou, facultativement, effectuer uniquement des opérations de permutation ou de basculement pour une base de données d'intelligence artificielle autonome.	Utiliser la récupération après sinistre de pile complète pour OCI sur une base de données d'intelligence artificielle autonome sur une infrastructure Exadata dédiée
Copie de sauvegarde inter-région Vous pouvez sélectionner une région secondaire pour une copie de vos sauvegardes. En cas de défaillance d'une région, vous pouvez cloner la sauvegarde distante de la base de données conteneur autonome pour restaurer les données. La sauvegarde d'une base de données conteneur autonome ne peut être clonée que dans une grappe de machines virtuelles Exadata autonome (AVMC) différente de sa base de données autonome source.	S'APPLIQUE À : Oracle Public Cloud seulement La copie de sauvegarde inter-région peut être activée lors du provisionnement d'une base de données conteneur autonome ou à partir de la page de détails d'une base de données conteneur autonome existante. Vous ne pouvez pas activer la sauvegarde inter-région si Autonomous Data Guard est activé.	À propos du clonage d'une base de données conteneur autonome sur une infrastructure Exadata dédiée Cloner une base de données conteneur autonome

Fonction de base de données sur l'IA autonome

Notes

Informations de référence supplémentaires

Version du logiciel Oracle Database

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

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

Lorsque vous sélectionnez une version dans l'image de base, vous pouvez choisir la dernière version du logiciel Oracle Database ou sa version précédente immédiate. Par exemple : Supposons que la dernière version d'Oracle Database prise en charge par Autonomous AI Database soit 19.26.0.1.0. Ensuite, la liste déroulante Sélectionner l'image de base liste les valeurs 19.26.0.1.0 et 19.25.0.1.0. pour que vous puissiez choisir.

Les bases de données conteneur autonomes avec la version du logiciel de base de données 26ai ne peuvent être provisionnées que sur des grappes de machines virtuelles Exadata autonomes (AVMC) basées sur ECPU créées avec les marqueurs appropriés. Voir Exigences relatives aux marqueurs de version du logiciel de base de données 26ai pour plus de détails. Les déploiements à nuages multiples ne nécessitent pas de marqueur spécial et prendront automatiquement en charge les bases de données 19c et 26ai.

Autonomous Data Guard

La configuration d'Autonomous Data Guard vous permet de garder vos bases de données de production critiques disponibles pour les applications stratégiques, malgré les défaillances.

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

Les bases de données conteneur autonomes principale et secondaire peuvent également être déployées dans différentes régions (inter-régions). Dans une configuration Autonomous Data Guard inter-région utilisant des clés gérées par le client ou un système de gestion des clés, selon le nombre de bases de données autonomes basées sur l'IA dans la base de données conteneur autonome principale, de nouvelles versions de clé sont générées automatiquement pour les bases de données de secours dans la chambre forte inter-région.

Protéger les bases de données critiques contre les défaillances et les sinistres à l'aide d'Autonomous Data Guard

Programme de maintenance

En général, Oracle programme et effectue la maintenance complète du parc, répartie sur l'ensemble des correctifs de sécurité d'infrastructure trimestriels et mensuels, pour les vulnérabilités dont la note CVSS est supérieure ou égale à 7.

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

Vous pouvez choisir entre les méthodes de maintenance continue ou non continue pour une base de données conteneur autonome. Si vous choisissez une méthode de maintenance non continue dans une configuration Autonomous Data Guard, il y aura un temps d'arrêt pour la base de données conteneur autonome et toutes les bases de données autonomes d'IA associées jusqu'à la fin de l'application de correctifs. Facultativement, vous pouvez également sélectionner Activer la mise à jour du fuseau horaire. Les fichiers de fuseaux horaires peuvent seulement être mis à jour avec la méthode de configuration non continue

Vous pouvez définir ou modifier les paramètres du programme de maintenance pour une base de données conteneur autonome à gérer par Oracle ou vous pouvez définir un programme de maintenance personnalisé.

Lors de la personnalisation du programme de maintenance d'une base de données conteneur autonome, vous pouvez choisir d'ignorer l'application de correctifs pour un trimestre. Toutefois, vous ne pouvez pas ignorer l'application de correctifs pendant deux trimestres consécutifs. Lorsque vous choisissez d'ignorer l'application de correctifs pour un trimestre, vous devez sélectionner au moins un mois dans ce trimestre. Il s'agit d'un traitement de secours si la maintenance n'a pas eu lieu au cours du trimestre précédent non ignoré. 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 voir le nombre de correctifs ponctuels disponibles pour une base de données conteneur autonome dans sa page Détails. Cliquer sur le lien Copier à côté copie tous ces numéros de correctif ponctuel.

Lorsque vous programmez un événement de maintenance de base de données conteneur autonome qui est déjà programmé, Oracle peut le placer dans une file d'attente si sa ressource d'infrastructure Exadata ou de grappe de machines virtuelles Exadata autonome :

Font déjà l'objet d'une mise à jour de maintenance, ou
Programmé pour une activité de maintenance simultanément en tant que base de données conteneur autonome.

Vous pouvez programmer une maintenance sur demande pour mettre à jour l'UR (mise à jour de version) avec le fichier de fuseaux horaires ou simplement le fichier de fuseaux horaires d'une base de données conteneur autonome. Vous pouvez également choisir d'effectuer une mise à jour à l'aide d'une image logicielle de base de données personnalisée existante.

Vous pouvez subir un temps d'arrêt pour votre base de données conteneur autonome et les bases de données autonomes d'IA associées, selon la configuration du programme de maintenance de votre base de données conteneur autonome.

Maintenance du service

Programmer 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. La période de conservation des sauvegardes est de 95 jours, selon la politique/période de conservation de sauvegarde sélectionnée pour la base de données conteneur autonome. Vous pouvez restaurer et récupérer votre base de données à tout point dans le temps pendant cette période.

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

Vous pouvez définir la politique/période de conservation des sauvegardes lors du provisionnement d'une base de données conteneur autonome ou la modifier ultérieurement à partir de sa page de détails dans la console Console Oracle Cloud Infrastructure.

Dans les déploiements d'Oracle Public Cloud et d'Exadata Cloud@Customer :

Vous pouvez conserver les sauvegardes d'une base de données conteneur autonome arrêtée jusqu'à 72 heures ou jusqu'à la fin de sa période de conservation des sauvegardes.
Vous pouvez activer le verrouillage de conservation des sauvegardes pour empêcher toute suppression indésirable des sauvegardes ACD et Autonomous AI Database avant leur période de conservation.
Vous pouvez activer le verrouillage de conservation lors du provisionnement de la base de données conteneur autonome ou ultérieurement.
Une fois activé, vous pouvez désactiver le verrouillage de rétention dans les 14 jours, au-delà desquels le paramètre devient permanent.
Une fois le verrouillage de conservation activé, vous ne pouvez augmenter la valeur de la période de conservation que si elle ne peut pas être réduite.
Toutes les sauvegardes à long terme seront également verrouillées et ne pourront pas être supprimées lorsque le verrouillage de conservation sera activé.

Les sauvegardes à long terme sont automatiquement supprimées une fois qu'elles expirent. Toutefois, dans le cas des 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 autonome 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 autonome et la date d'expiration.

Voir Politique de conservation des sauvegardes pour plus de détails sur les valeurs de la politique de conservation des sauvegardes pour différents déploiements de base de données autonome sur intelligence artificielle.

Sauvegarder et restaurer des bases de données d'IA autonomes.

Destination de sauvegarde

Une destination de sauvegarde définit les propriétés requises pour la connexion à un emplacement de sauvegarde et chaque destination de sauvegarde doit être accessible dans votre centre de données à partir des noeuds de grappe de machines virtuelles.

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

Voir Destination de sauvegarde pour plus de détails sur les différents types de destination de sauvegarde.

Pour en savoir plus sur la configuration de la destination de sauvegarde NFS pour Cloud@Customer, voir Préalables pour les destinations de sauvegarde pour Exadata Cloud@Customer.

Reportez-vous à Modifier les paramètres de sauvegarde de base de données conteneur autonome pour obtenir des instructions sur la modification du type de destination de sauvegarde après le provisionnement de la base de données conteneur autonome.

Utilisation de l'espace NFS

S'APPLIQUE À : Exadata Cloud@Customer seulement

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

Pour plus de détails, voir Voir 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 afin de consolider davantage de bases de données ou d'offrir la disponibilité la plus élevée.

Facultativement, lors du provisionnement d'une base de données conteneur autonome, vous pouvez 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 d'intelligence artificielle autonome 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 répartition : Détermine si une base de données autonome sur l'IA doit être ouverte sur un nombre minimal ou maximal de noeuds. Par défaut, Minimum node est sélectionné.

Pour plus d'informations sur l'incidence de ces attributs de base de données conteneur autonome sur la performance de vos bases de données, voir 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 plusieurs processus clients à partager très peu de processus serveurs, de sorte que le nombre d'utilisateurs pouvant être pris en charge est augmenté.

Lors du provisionnement d'une base de données conteneur autonome, vous pouvez éventuellement activer les connexions de serveur partagé. Vous ne pouvez pas désactiver l'architecture de serveur partagé après avoir provisionné la base de données conteneur autonome.

Fonctions de connexion à usage spécifique.

Clé de chiffrement

Par défaut, Autonomous AI Database crée et gère toutes les clés de chiffrement principales utilisées pour protéger vos données, en les stockant dans un magasin de clés PKCS 12 sécurisé sur les systèmes Exadata où résident les bases de données.

Si les politiques de sécurité de votre entreprise le nécessitent, Autonomous AI Database peut utiliser des clés que vous créez et gérez.

Lors du provisionnement d'une base de données conteneur autonome, vous pouvez éventuellement configurer cette dernière pour qu'elle utilise des clés de chiffrement gérées par le client au lieu de celles gérées par Oracle.

Vous pouvez choisir entre les options suivantes lors de l'utilisation de clés de chiffrement gérées par le client :

Service de chambre forte OCI : Avec cette option, vous sélectionnez une chambre forte et une clé de chiffrement principale. Cette option n'est disponible que dans Oracle Public Cloud.
Oracle Key Vault : Vous sélectionnez un magasin de clés avec cette option et entrez un nom de groupe de points d'extrémité OKV.

Vous pouvez utiliser des clés de chiffrement gérées par le client avec des bases de données conteneur autonomes activées pour Autonomous Data Guard lorsque les bases de données principale et de secours se trouvent dans différents domaines de disponibilité au sein de la même région.

À propos des clés de chiffrement principales

Utiliser ses propres clés (BYOK) dans le service de chambre forte

Utiliser des clés gérées par le client dans Oracle Key Vault

Effectuer une rotation de la clé de chiffrement pour une base de données conteneur autonome.

Adresse de contact

Vous pouvez fournir des courriels de contact où vous pouvez recevoir des avis opérationnels, des annonces et des avis de maintenance non planifiés concernant votre base de données conteneur autonome.

Oracle recommande d'utiliser l'adresse de courriel d'un groupe d'administrateurs plutôt que celle d'une personne, dans la mesure du possible, pour s'assurer qu'aucun avis ou annonce important n'est manqué.

Récupération après sinistre de pile complète

Full Stack DR est un service d'orchestration et de gestion de la récupération après sinistre pour Oracle Cloud Infrastructure qui fournit des fonctions complètes de récupération après sinistre pour toutes les couches d'une pile d'applications, notamment l'infrastructure, l'intergiciel, la base de données et les applications.

Vous pouvez activer la récupération après sinistre de pile complète pour OCI et l'utiliser pour effectuer des opérations de permutation ou de basculement ou, facultativement, effectuer uniquement des opérations de permutation ou de basculement pour une base de données d'intelligence artificielle autonome.

Utiliser la récupération après sinistre de pile complète pour OCI sur une base de données d'intelligence artificielle autonome sur une infrastructure Exadata dédiée

Copie de sauvegarde inter-région

Vous pouvez sélectionner une région secondaire pour une copie de vos sauvegardes. En cas de défaillance d'une région, vous pouvez cloner la sauvegarde distante de la base de données conteneur autonome pour restaurer les données. La sauvegarde d'une base de données conteneur autonome ne peut être clonée que dans une grappe de machines virtuelles Exadata autonome (AVMC) différente de sa base de données autonome source.

S'APPLIQUE À :

Oracle Public Cloud seulement

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

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

À propos du clonage d'une base de données conteneur autonome sur une infrastructure Exadata dédiée

Cloner une base de données conteneur autonome

Opérations de gestion de base de données conteneur autonome

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

Opération	Tâche Instructions
Créer une base de données conteneur autonome	Créer une base de données conteneur autonome
Modifier la politique de conservation des sauvegardes d'une base de données conteneur autonome	Modifier les paramètres de sauvegarde de base de données conteneur autonome
Créer une image logicielle Autonomous AI Database	Créer une image logicielle de base de données d'IA autonome
Modifier les préférences de maintenance d'une base de données conteneur autonome	Mettre à jour les préférences de maintenance d'une base de données conteneur autonome
Gérer la configuration d'Autonomous Data Guard	Gérer la configuration d'Autonomous Data Guard
Déplacer une base de données conteneur autonome vers un autre compartiment	Déplacer une base de données conteneur autonome vers un autre compartiment
Rotation d'une clé de chiffrement de base de données conteneur autonome	Effectuer une rotation de la clé de chiffrement pour une base de données conteneur autonome
Redémarrer une base de données conteneur autonome	Redémarrer une base de données conteneur autonome
Mettre fin à une base de données conteneur autonome	Mettre fin à une base de données conteneur autonome
Gérer les contacts de client pour une base de données conteneur autonome	Gérer les contacts de client pour une base de données conteneur autonome
Voir une liste de bases de données conteneur autonomes	Voir une liste de bases de données conteneur autonomes
Voir les détails d'une base de données conteneur autonome	Voir les détails d'une base de données conteneur autonome
Voir l'utilisation de l'espace NFS	S'APPLIQUE À : Exadata Cloud@Customer seulement Voir l'utilisation de l'espace NFS

Les opérations énumérées ci-dessus peuvent également être réalisées à l'aide d'API. Voir API de gestion des bases de données conteneur autonomes pour plus de référence.

Surveillance de la base de données conteneur autonome

Vous pouvez utiliser des vues dynamiques de la performance pour surveiller votre base de données conteneur autonome de l'une des façons suivantes :

Affichez des mesures en temps réel sur différents événements d'attente et classes d'attente.
Affichez les instantanés historiques des mesures des classes d'attente.
Consulter les données de mesures de rendement en temps réel, historiques et sommaires.
Voir les limites des ressources et l'utilisation courante.

Pour des informations détaillées, voir Vues dynamiques de la performance.

Titre et Copyright

Oracle et/ou ses sociétés affiliées.