A propos de la base de données Conteneur Autonomous

La base de données Conteneur Autonomous 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 Autonomous Database on Dedicated Exadata Infrastructure. Les bases de données Conteneur Autonomous sont provisionnées dans un cluster de machines virtuelles Exadata Autonomous et servent de conteneurs pour des instances Autonomous Database.

Vous pouvez créer plusieurs ressources ACD dans une même ressource AVMC, mais vous devez en créer au moins une pour pouvoir créer des instances Autonomous Database. Pour mieux comprendre l'architecture à quatre couches utilisée avec Autonomous Database on Dedicated Exadata Infrastructure et comprendre le positionnement de la base de données Conteneur Autonomous au sein de cette architecture, reportez-vous à Composants d'Autonomous Database on Dedicated Exadata Infrastructure.

Les bases de données Conteneur Autonomous offrent l'avantage de fonctionner de manière isolée les unes des autres, ce qui vous permet de séparer les bases de données Autonomous Database par leurs utilisations prévues. Par exemple, vous pouvez créer différentes bases de données Conteneur Autonomous à des fins de production et de test, ou même en utiliser plusieurs à l'aide de 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 Autonomous, les administrateurs de base de données d'application les utilisent principalement pour créer des bases de données Autonomous Database. Pour en savoir plus, reportez-vous à Rôles utilisateur associés à Autonomous Database on Dedicated Exadata Infrastructure.

Rubriques connexes

Exigences relatives aux bases de données Conteneur Autonomous

Exigences de stratégie IAM

Vous devez disposer d'un compte Oracle Cloud Infrastructure avec des privilèges accordés via les 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 de 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

Configuration requise pour la version du logiciel Oracle Database

Pour provisionner une base de données Conteneur Autonomous avec la version 23ai du logiciel Oracle Database, vous devez choisir un cluster de machines virtuelles Exadata Autonomous (AVMC) basé sur ECPU qui a été créé avec la balise DatabaseVersion définie sur 23ai.
De même, pour provisionner une base de données Conteneur Autonomous avec la version du logiciel Oracle Database 19c, vous devez choisir un cluster de machines virtuelles Exadata Autonomous (AVMC) dont la balise DatabaseVersion n'est pas définie sur 23ai.
Vous ne pouvez pas provisionner à la fois des bases de données Conteneur Autonomous 19c et 23ai dans la même instance AVMC.

Remarques :

Les déploiements multicloud ne nécessitent pas de balise spéciale et prennent automatiquement en charge les bases de données 19c et 23ai.

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

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

Fonctionnalité Autonomous Database	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 Autonomous Database 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 Database soit la version 19.26.0.1.0. Ensuite, la liste déroulante Sélectionner une image de base répertorie les versions 19.26.0.1.0 et 19.25.0.1.0. Les bases de données Conteneur Autonomous avec la version du logiciel de base de données 23ai peuvent uniquement être provisionnées sur les clusters de machines virtuelles Exadata Autonomous (AVMC) basés sur l'ECPU créés avec les balises appropriées. Pour plus d'informations, reportez-vous à Exigences relatives aux balises de version logicielle de base de données 23ai. Les déploiements multicloud ne nécessitent pas de balise spéciale et prennent automatiquement en charge les bases de données 19c et 23ai.	-
Autonomous Data Guard La configuration d'Autonomous Data Guard permet de maintenir la disponibilité des bases de données de production essentielles pour vos applications stratégiques malgré les pannes.	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. Toutefois, la deuxième base de données Conteneur Autonomous de secours doit se trouver dans la même location que la base de données Conteneur Autonomous principale. Les bases de données Conteneur Autonomous principale et secondaire peuvent également être déployées dans différentes régions (entre régions). Dans une configuration Autonomous Data Guard inter-région à l'aide de clés gérées par le client ou de KMS, en fonction du nombre d'instances Autonomous Database dans la base de données Conteneur Autonomous principale, de nouvelles versions de clé sont 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 la maintenance complète du parc répartie sur chaque trimestre et les correctifs mensuels de sécurité de l'infrastructure 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 Database 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 pour une base de données Conteneur Autonomous à gérer par Oracle ou 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 dans ce trimestre. Cela sert de repli si la maintenance n'a 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 visualiser le nombre de patches exceptionnels disponibles pour une base de données Conteneur Autonomous sur sa page Détails. Si vous cliquez sur le lien Copier en regard de ce lien, tous ces numéros de patch exceptionnels sont copiés. Lorsque vous programmez à nouveau un événement de maintenance de base de données Conteneur Autonomous déjà programmé, Oracle peut le placer dans une file d'attente si la ressource d'infrastructure Exadata ou de cluster de machines virtuelles Exadata Autonomous correspondante : font déjà l'objet d'une mise à jour de maintenance, ou Programmé pour une activité de maintenance en même temps que la base de données Conteneur Autonomous. Vous pouvez programmer une maintenance à la demande pour mettre à jour la RU (Release Update) avec le fichier de fuseau horaire ou uniquement le fichier de fuseau horaire d'une base de données Conteneur Autonomous. 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'inactivité pour votre base de données Conteneur Autonomous et les instances Autonomous Database associées en fonction de la configuration de la programmation de maintenance de votre base de données Conteneur Autonomous.	Maintenance de service Programmation d'une mise à jour de maintenance trimestrielle
Sauvegarde et restauration Pour prendre en charge la haute disponibilité, Autonomous Database sauvegarde automatiquement votre base de données. 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 stratégie/période 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. Sur les déploiements Oracle Public Cloud et Exadata Cloud@Customer : 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 non souhaitée des sauvegardes de base de données Conteneur Autonomous et Autonomous Database 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. Pour plus de détails sur les valeurs de stratégie de conservation de sauvegarde pour différents déploiements Autonomous Database, reportez-vous à Stratégie de conservation de sauvegarde.	Sauvegarde et restauration de bases de données autonomes.
Destination de sauvegarde Une destination de sauvegarde définit les propriétés requises pour la connexion à un emplacement de sauvegarde. Chaque destination de sauvegarde doit être accessible à partir des noeuds de cluster de machines virtuelles dans le centre de données.	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 la base de données Conteneur Autonomous.
Utilisation de l'espace 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 de 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 avoir la disponibilité 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 instance Autonomous Database 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 de CPU 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 instance Autonomous Database doit être ouverte sur un nombre minimal ou maximal de noeuds. L'option Minimum nodes est sélectionnée par défaut.	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 à un serveur partagé L'architecture de serveur partagé permet à un serveur de base de données de permettre à de nombreux processus client de partager un petit nombre de processus serveur, de sorte que le nombre d'utilisateurs puisse augmenter.	Lors du provisionnement d'une base de données Conteneur Autonomous, 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 Autonomous.	Fonctionnalités de connexion à usage spécial.
Clé de cryptage Par défaut, Autonomous Database crée et gère toutes les clés de cryptage maître utilisées pour protéger les données, et les stocke dans un fichier de clés PKCS 12 sécurisé sur les systèmes Exadata sur lesquels résident les bases de données. Si les stratégies de sécurité de votre entreprise l' nécessitent, Autonomous Database peut plutôt utiliser des clés que vous créez et gérez.	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 au lieu des clés de cryptage gérées par Oracle. Vous pouvez choisir entre les options suivantes lorsque vous utilisez des clés de cryptage gérées par le client : Service OCI Vault : avec cette option, vous sélectionnez un coffre et une clé de cryptage maître. Cette option est uniquement disponible 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. Vous pouvez utiliser des clés de cryptage gérées par le client avec des bases de données Conteneur Autonomous sur lesquelles Autonomous Data Guard est activé, avec les bases de données principale et de secours situées dans des domaines de disponibilité différents 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 Utiliser des clés gérées par le client 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 pour recevoir des notifications opérationnelles, des annonces et des notifications de maintenance non planifiées 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, pour s'assurer qu'aucune notification ou annonce importante n'est manquée.
Full Stack Disaster Recovery Full Stack DR est un service Oracle Cloud Infrastructure (OCI) d'orchestration et de gestion de la récupération après sinistre qui fournit des 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 la récupération après sinistre OCI Full Stack et l'utiliser pour effectuer des opérations de permutation/basculement ou éventuellement effectuer uniquement des opérations de permutation/basculement de base de données Autonomous Database.	Utilisation d'OCI Full Stack Disaster Recovery sur Autonomous Database on Dedicated Exadata Infrastructure
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é Autonomous Database

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 Autonomous Database 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 Database soit la version 19.26.0.1.0. Ensuite, la liste déroulante Sélectionner une image de base répertorie les versions 19.26.0.1.0 et 19.25.0.1.0.

Les bases de données Conteneur Autonomous avec la version du logiciel de base de données 23ai peuvent uniquement être provisionnées sur les clusters de machines virtuelles Exadata Autonomous (AVMC) basés sur l'ECPU créés avec les balises appropriées. Pour plus d'informations, reportez-vous à Exigences relatives aux balises de version logicielle de base de données 23ai. Les déploiements multicloud ne nécessitent pas de balise spéciale et prennent automatiquement en charge les bases de données 19c et 23ai.

Autonomous Data Guard

La configuration d'Autonomous Data Guard permet de maintenir la disponibilité des bases de données de production essentielles pour vos applications stratégiques malgré les pannes.

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. Toutefois, la deuxième base de données Conteneur Autonomous de secours doit se trouver dans la même location que la base de données Conteneur Autonomous principale.

Les bases de données Conteneur Autonomous principale et secondaire peuvent également être déployées dans différentes régions (entre régions). Dans une configuration Autonomous Data Guard inter-région à l'aide de clés gérées par le client ou de KMS, en fonction du nombre d'instances Autonomous Database dans la base de données Conteneur Autonomous principale, de nouvelles versions de clé sont 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 la maintenance complète du parc répartie sur chaque trimestre et les correctifs mensuels de sécurité de l'infrastructure 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 Database 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 pour une base de données Conteneur Autonomous à gérer par Oracle ou 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 dans ce trimestre. Cela sert de repli si la maintenance n'a 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 visualiser le nombre de patches exceptionnels disponibles pour une base de données Conteneur Autonomous sur sa page Détails. Si vous cliquez sur le lien Copier en regard de ce lien, tous ces numéros de patch exceptionnels sont copiés.

Lorsque vous programmez à nouveau un événement de maintenance de base de données Conteneur Autonomous déjà programmé, Oracle peut le placer dans une file d'attente si la ressource d'infrastructure Exadata ou de cluster de machines virtuelles Exadata Autonomous correspondante :

font déjà l'objet d'une mise à jour de maintenance, ou
Programmé pour une activité de maintenance en même temps que la base de données Conteneur Autonomous.

Vous pouvez programmer une maintenance à la demande pour mettre à jour la RU (Release Update) avec le fichier de fuseau horaire ou uniquement le fichier de fuseau horaire d'une base de données Conteneur Autonomous. 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'inactivité pour votre base de données Conteneur Autonomous et les instances Autonomous Database associées en fonction de la configuration de la programmation de maintenance de votre base de données Conteneur Autonomous.

Maintenance de service

Programmation d'une mise à jour de maintenance trimestrielle

Sauvegarde et restauration

Pour prendre en charge la haute disponibilité, Autonomous Database sauvegarde automatiquement votre base de données. 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 stratégie/période 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.

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

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 non souhaitée des sauvegardes de base de données Conteneur Autonomous et Autonomous Database 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.

Pour plus de détails sur les valeurs de stratégie de conservation de sauvegarde pour différents déploiements Autonomous Database, reportez-vous à Stratégie de conservation de sauvegarde.

Sauvegarde et restauration de bases de données autonomes.

Destination de sauvegarde

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

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 la base de données Conteneur Autonomous.

Utilisation de l'espace 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 de 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 avoir la disponibilité 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 instance Autonomous Database 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 de CPU 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 instance Autonomous Database doit être ouverte sur un nombre minimal ou maximal de noeuds. L'option Minimum nodes est sélectionnée par défaut.

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 à un serveur partagé

L'architecture de serveur partagé permet à un serveur de base de données de permettre à de nombreux processus client de partager un petit nombre de processus serveur, de sorte que le nombre d'utilisateurs puisse augmenter.

Lors du provisionnement d'une base de données Conteneur Autonomous, 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 Autonomous.

Fonctionnalités de connexion à usage spécial.

Clé de cryptage

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

Si les stratégies de sécurité de votre entreprise l' nécessitent, Autonomous Database peut plutôt utiliser des clés que vous créez et gérez.

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 au lieu des clés de cryptage gérées par Oracle.

Vous pouvez choisir entre les options suivantes lorsque vous utilisez des clés de cryptage gérées par le client :

Service OCI Vault : avec cette option, vous sélectionnez un coffre et une clé de cryptage maître. Cette option est uniquement disponible 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.

Vous pouvez utiliser des clés de cryptage gérées par le client avec des bases de données Conteneur Autonomous sur lesquelles Autonomous Data Guard est activé, avec les bases de données principale et de secours situées dans des domaines de disponibilité différents 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

Utiliser des clés gérées par le client 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 pour recevoir des notifications opérationnelles, des annonces et des notifications de maintenance non planifiées 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, pour s'assurer qu'aucune notification ou annonce importante n'est manquée.

Full Stack Disaster Recovery

Full Stack DR est un service Oracle Cloud Infrastructure (OCI) d'orchestration et de gestion de la récupération après sinistre qui fournit des 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 la récupération après sinistre OCI Full Stack et l'utiliser pour effectuer des opérations de permutation/basculement ou éventuellement effectuer uniquement des opérations de permutation/basculement de base de données Autonomous Database.

Utilisation d'OCI Full Stack Disaster Recovery sur Autonomous Database on Dedicated Exadata Infrastructure

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

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	Tâche Instructions
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 la base de données Conteneur Autonomous
Création d'image logicielle Autonomous Database	Création d'une image logicielle Autonomous Database
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
Gestion de la configuration Autonomous Data Guard	Gestion de la 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 de 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 d'API. Pour plus d'informations, reportez-vous à API de gestion des bases de données Conteneur Autonomous.

Surveillance de la 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 :

Visualiser des mesures en temps réel sur différents événements Wait et classes Wait.
Visualiser les clichés historiques des mesures de classe Wait.
Consulter les données de métriques de performances en temps réel, historiques et récapitulatives.
Visualiser les limites de ressource et l'utilisation en cours.

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

Informations relatives au titre et au copyright

Oracle et/ou ses affiliés.