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

A propos d'Autonomous Data Guard

Autonomous Data Guard crée et tient à jour deux copies complètement distinctes de la base de données : une base de données principale, à laquelle les applications se connectent et qu'elles utilisent, et une base de données de secours, qui est une copie synchronisée de la base de données principale. Ainsi, si la base de données principale devient indisponible pour quelque raison que ce soit, Autonomous Data Guard peut convertir la base de données de secours en base de données principale et, de ce fait, elle commencera à servir vos applications.

Les bases de données principale et de secours sont souvent appelées bases de données homologues. Vous pouvez avoir jusqu'à deux bases de données de secours par base de données Conteneur Autonomous.

Remarques :

Les applications doivent être configurées avec la continuité d'application transparente (TAC) afin de bénéficier pleinement des fonctionnalités de disponibilité de base de données fournies par Autonomous Data Guard.

Le schéma suivant montre comment chaque base de données de secours reste synchronisée avec la base de données principale.

Description de l'image autonomous-data-guard.eps

Les modifications apportées à la base de données principale sont enregistrées dans son fichier de journalisation. Autonomous Data Guard transmet ces enregistrements de journalisation sous forme de flux de données sur le réseau vers le fichier de journalisation de la base de données de secours. Ensuite, la base de données de secours applique ces enregistrements. Ainsi, la base de données de secours reste synchronisée avec la base de données principale.

La synchronisation est presque instantanée, mais comme l'implique le processus qui vient d'être décrit, deux opérations prennent du temps : le transport des enregistrements de journalisation vers la base de données de secours et l'application de ces enregistrements à la base de données. Le premier délai est appelé délai de transport, et le second, délai d'application des transactions. Vous pouvez visualiser les valeurs de décalage en cours pour une instance Autonomous Database à partir de la page Détails de la base de données d'Autonomous Data Guard sous Ressources. sous Ressources dans le menu latéral. Vous pouvez visualiser les valeurs de décalage en cours sur toutes les instances Autonomous Database d'une base de données Conteneur à partir de la page Détails de la base de données Conteneur de la même manière.

Remarques :

Avec plusieurs bases de données de secours, le transport des informations de journalisation en cascade n'est pas pris en charge.

Configuration d'Autonomous Data Guard

Dans Autonomous Database on Dedicated Exadata Infrastructure, vous pouvez configurer et gérer Autonomous Data Guard au niveau de la base de données Conteneur Autonomous. Vous pouvez activer Autonomous Data Guard pour les bases de données Conteneur Autonomous déjà provisionnées et ajouter jusqu'à deux bases de données Conteneur Autonomous de secours à partir de sa page Détails à l'aide de la console Oracle Cloud Infrastructure. Pour obtenir des instructions, reportez-vous à Activation d'Autonomous Data Guard sur une base de données Conteneur Autonomous et à Ajout d'une deuxième base de données Conteneur Autonomous de secours.

Avant de configurer Autonomous Data Guard, tenez compte des points suivants :

Les instances Autonomous Database déployées sur Exadata Cloud@Customer doivent disposer du port 1522 ouvert pour autoriser le trafic TCP entre la base de données principale et la base de données de secours dans une configuration Autonomous Data Guard.
Autonomous Data Guard ne peut pas être activé sur une base de données Conteneur Autonomous avec une exécution de maintenance active programmée dans les trois prochains jours. Vous pouvez d'abord exécuter la maintenance active, puis activer Autonomous Data Guard, ou modifier la programmation de l'exécution de maintenance afin qu'elle ne commence pas tant que la deuxième base de données de secours n'est pas ajoutée.
L'ajout d'une deuxième base de données de secours nécessite un redémarrage automatique simultané de la première base de données de secours. La base de données principale n'est pas affectée par ce redémarrage simultané.

Configurer Autonomous Data Guard avec des clés gérées par le client

Dans Autonomous Database on Dedicated Exadata Infrastructure, vous pouvez configurer et gérer Autonomous Data Guard avec des clés gérées par le client au niveau de la base de données Conteneur Autonomous. Vous pouvez activer Autonomous Data Guard pour les bases de données Conteneur Autonomous déjà provisionnées et ajouter jusqu'à deux bases de données Conteneur Autonomous de secours à partir de sa page Détails à l'aide de la console Oracle Cloud Infrastructure. Pour obtenir des instructions, reportez-vous à Activation d'Autonomous Data Guard sur une base de données Conteneur Autonomous et à Ajout d'une deuxième base de données Conteneur Autonomous de secours.

Avant de configurer Autonomous Data Guard avec des clés gérées par le client, tenez compte des points suivants :

Si vous utilisez OCI KMS (Oracle Cloud Infrastructure Key Management System) et que vous voulez activer Autonomous Data Guard inter-région, vous devez d'abord répliquer le coffre OCI vers la région dans laquelle ajouter la base de données de secours. Pour plus d'informations, reportez-vous à Réplication des coffres et des clés.

Remarques :
Les coffres virtuels créés avant l'introduction de la fonctionnalité de réplication de coffre inter-région ne peuvent pas être répliqués entre les régions. Créez un coffre et de nouvelles clés si vous avez un coffre à répliquer dans une autre région et que la réplication n'est pas prise en charge pour ce coffre. Toutefois, tous les coffres privés prennent en charge la réplication inter-région. Pour plus de détails, reportez-vous à Réplication inter-régions de coffre virtuel.
Si vous utilisez Oracle Key Vault (OKV) et que vous voulez activer Autonomous Data Guard inter-région, assurez-vous que vous avez ajouté des adresses IP de connexion pour votre cluster OKV dans le fichier de clés.

Modèles Autonomous Data Guard

A partir du mars 2025, les bases de données Conteneur Autonomous peuvent activer Autonomous Data Guard à partir de leur page Détails et créer jusqu'à deux bases de données Conteneur Autonomous de secours. Avec cette version, le modèle d'association Autonomous Data Guard précédent et les API associées seront en phase d'abandon et remplacés par les nouveauxgroupes Autonomous Data Guard et les API. Toutes les nouvelles bases de données Conteneur Autonomous provisionnées après mars 2025 à partir de la console Oracle Cloud Infrastructure (OCI) utiliseront automatiquement le nouveau modèle Groupes Autonomous Data Guard.

Pour faire passer des bases de données Conteneur Autonomous existantes, les clients peuvent effectuer une migration vers le nouveau modèle en cliquant sur Mettre à niveau vers des groupes Autonomous Data Guard à partir de la page Détails de la base de données Conteneur Autonomous sur la console OCI ou à l'aide de l'API MigrateAutonomousContainerDatabaseDataguardAssociation.

Lors de la mise à niveau :

Vous passerez à la nouvelle expérience utilisateur dans laquelle les opérations Autonomous Data Guard sont effectuées sur la ressource Base de données Conteneur Autonomous au lieu de la ressource Association Autonomous Container Database Data Guard.
Votre ressource d'associations Autonomous Data Guard est convertie en ressource de groupes Autonomous Data Guard avec prise en charge de plusieurs bases de données de secours. Il n'y a aucun impact sur la configuration Data Guard ou les bases de données autonomes existantes.
Vous devez activer Autonomous Data Guard à partir de la page Détails de la base de données Conteneur Autonomous après son provisionnement pour utiliser la fonctionnalité Autonomous Data Guard.
Vous devez lancer les opérations de permutation et de basculement à partir de la base de données Conteneur Autonomous de secours vers laquelle vous souhaitez basculer les rôles avec la base de données Conteneur Autonomous principale ou le basculement, respectivement.
Vous basculerez vers les nouvelles API de groupes Autonomous Data Guard répertoriées en tant qu'API de remplacement sur l'API de gestion de la configuration Autonomous Data Guard. L'API Autonomous Data Guard Associations existante est en phase d'abandon et ne sera pas disponible à partir de mars 2026.
Vous devez vous abonner aux nouveaux événements de groupes Autonomous Data Guard répertoriés sur les types d'événement Autonomous Data Guard. Les événements Associations Autonomous Data Guard existants fonctionnent uniquement avec l'ancienne API Associations Autonomous Data Guard et sont en phase d'abandon avec ces API.

Changements de rôle et opérations

Une fois une base de données Conteneur Autonomous créée, vous pouvez modifier le rôle des bases de données homologues à l'aide d'une opération de permutation ou de basculement. Si le basculement automatique est activé, Autonomous Data Guard effectue automatiquement une opération de basculement chaque fois que la base de données principale devient indisponible, pour quelque raison que ce soit.

La permutation est une inversion de rôle entre la base de données principale et sa base de données de secours. La permutation de bases de données garantit l'absence de perte de données. Au cours d'une permutation, la base principale prend le rôle de base de données de secours, et la base de données de secours prend le rôle de base de données principale. Pour effectuer une opération de permutation, reportez-vous à Echange de rôles dans une configuration Autonomous Data Guard.

Le basculement a lieu lorsque la base de données principale est indisponible. Le basculement entraîne une transition de la base de données de secours vers le rôle de base de données principale. Si le basculement automatique n'est pas activé, vous pouvez effectuer un basculement manuel, comme décrit dans Basculement vers la base de données de secours dans une configuration Autonomous Data Guard.

La disponibilité et le statut de la base de données après une opération de basculement se caractérisent par deux objectifs de récupération :

Objectif de délai de récupération. durée maximale requise afin que la base de données devienne disponible pour les applications après un basculement. Il est lié, dans une certaine mesure, au décalage d'application des transactions au moment de la panne. Pour Autonomous Data Guard, l'objectif de délai de récupération va de quelques secondes à deux minutes.
Objectif de point de récupération : durée maximale de perte de données potentielle sur la base de données principale en échec. Il est lié, dans une certaine mesure, au décalage de transport au moment de la panne. Pour Autonomous Data Guard, l'objectif de point de récupération est proche de zéro.

Après un basculement, la base de données principale en échec devient une base de données de secours désactivée et reste indisponible pour toute connexion à la base de données. Vous pouvez la réactiver et la transformer en base de données de secours en bon état en effectuant une opération de réintégration. Une fois qu'une base de données principale en échec a été rétablie en tant que base de données de secours, vous pouvez effectuer une permutation pour la rétablir dans son rôle principal d'origine. Pour effectuer une opération de rétablissement, reportez-vous à Rétablissement de la base de données de secours désactivée dans une configuration Autonomous Data Guard.

Basculement automatique ou Fast-Start Failover

Avec le basculement automatique, chaque fois que la base de données Conteneur Autonomous principale devient indisponible en raison d'une défaillance de région, de domaine de disponibilité, d'infrastructure Exadata ou de cluster de machines virtuelles Exadata Autonomous, ou qu'elle tombe elle-même en panne, elle bascule automatiquement vers la base de données Conteneur Autonomous de secours. On parle également de Fast-Start Failover.

Vous ne pouvez pas activer le basculement automatique lors de la configuration d'Autonomous Data Guard sur une base de données Conteneur Autonomous. Le basculement automatique peut uniquement être activé ou désactivé lors de la mise à jour des paramètres Autonomous Data Guard à partir de la page Détails de la base de données Conteneur Autonomous.

Remarques :

Le basculement automatique ne peut pas être activé pour les instances Autonomous Database déployées dans Exadata Cloud@Customer avec une configuration Autonomous Data Guard inter-région.

Vous ne pouvez pas ajouter une seconde base de données Conteneur Autonomous de secours pour laquelle le basculement automatique est activé. Par conséquent, désactivez le basculement automatique à l'aide de Mise à jour des paramètres Autonomous Data Guard avant de créer la deuxième base de données Conteneur Autonomous de secours et réactivez-la ultérieurement, si nécessaire.

Les modes de protection Performances maximales et Disponibilité maximale prennent en charge le basculement automatique :

En mode Disponibilité maximale, le basculement automatique garantit une perte de données nulle.
En mode Performances maximales, le basculement automatique garantit que le retard de la base de données de secours par rapport à la base de données principale ne dépasse pas la limite de décalage Fast-Start Failover indiquée. Par défaut, la limite de décalage Fast-Start Failover est définie sur 30 secondes et s'applique uniquement au mode Performances maximales. Dans ce cas, le basculement automatique n'est possible que lorsque le décalage d'application (perte de données potentielle) de la base de données de secours ne dépasse pas la limite de décalage configurée. Vous pouvez modifier la limite de décalage du basculement Fast Start à n'importe quelle valeur comprise entre 5 et 3600.

Pour plus d'informations, reportez-vous à Mise à jour des paramètres Autonomous Data Guard.

Outre les pannes matérielles, les pannes de domaine de disponibilité et les coupures régionales, il existe quelques situations liées à l'état de la base de données qui peuvent déclencher la fonction Fast-Start Failover, comme indiqué ci-dessous :

Etat général de base de données	Description
Fichier de contrôle endommagé	Le fichier de contrôle est définitivement endommagé en raison d'une défaillance du disque.
Dictionnaire endommagé	Endommagement du dictionnaire d'une base de données critique. Actuellement, cet état ne peut être détecté que lorsque la base de données est ouverte.
Erreurs d'écriture de fichier de données	Des erreurs d'écriture sont détectées dans des fichiers de données, y compris les fichiers temporaires, les fichiers de données système et les fichiers d'annulation.

Suite au basculement automatique, le rôle de la base de données principale en panne devient Instance de secours désactivée et, après une courte période, la base de données de secours assume le rôle de base de données principale. Une fois le basculement automatique terminé, un message s'affiche sur la page de détails de la base de données de secours désactivée pour vous en informer.

Une fois que le service a résolu les problèmes de l'ancienne base de données Conteneur Autonomous principale, vous pouvez effectuer une permutation manuelle pour rétablir les deux bases de données dans leur rôle initial. Une fois la base de données de secours provisionnée, vous pouvez effectuer diverses tâches de gestion liées à celle-ci, notamment les suivantes :

Permutation manuelle d'une base de données principale vers le rôle de secours
Basculement manuel d'une base de données principale vers une base de données de secours
Rétablissement du rôle de secours d'une base de données principale après un basculement
Terminaison d'une base de données de secours

Dans une configuration Autonomous Data Guard comportant plusieurs bases de données de secours et un basculement automatique :

Pour les basculements manuels, vous devez rétablir manuellement la base principale d'origine, qui devient la nouvelle base de secours.
Chaque fois qu'un basculement automatique se produit, Autonomous Database on Dedicated Exadata Infrastructure tente de rétablir l'ancienne base de données principale en tant que base de données de secours. Toutefois, si cette tentative échoue, elle doit être rétablie manuellement.

Base de données de secours cliché

Une base de données de secours cliché est une base de données de secours qui peut entièrement mettre à jour, créée par conversion d'une base de données Conteneur Autonomous de secours. Pour obtenir des instructions détaillées, reportez-vous à Conversion d'une base de données de secours physique en base de données de secours instantanée.

Une base de données de secours cliché reçoit et archive, mais n'applique pas, les données redo provenant de la base de données principale. Toutefois, il augmente votre objectif de délai de récupération car les modifications en temps réel de la base de données principale ne sont pas appliquées.

La fonctionnalité de secours instantanée prend en charge différents cas d'utilisation, mais voici les principaux cas d'utilisation.

Connectez les instances d'application principale et de secours aux bases de données principale et de secours en mode lecture/écriture pour effectuer des configurations initiales.
Appliquez d'abord des patches à la base de données de secours instantanée et testez-la avec l'instance d'application de secours pour confirmer la stabilité des patches. Pour ce faire, vous devez d'abord convertir la base de données de secours physique en base de données de secours instantanée, afin que le patch puisse être appliqué à la base de données de secours instantanée.

Remarques :

Vous ne pouvez pas convertir une base de données Conteneur Autonomous de secours physique en base de données de secours cliché lorsque le basculement automatique est activé.

Lors de la conversion en base de données de secours cliché, vous pouvez activer de nouveaux services de base de données actifs uniquement en mode cliché ou utiliser le même ensemble de services que celui utilisé avec la base de données principale. Toutefois, l'activation des services de base de données principale sur la base de données de secours cliché peut entraîner la transmission des demandes de connexion à la base de données principale ou inversement si vous utilisez des chaînes de connexion de base de données incorrectes. Par conséquent, vous devez faire attention à utiliser la chaîne de connexion appropriée lors de la connexion à la base de données de secours principale et instantanée.

Remarques :

Lorsque vous créez des services avec une base de données de secours cliché, les portefeuilles de toutes les instances Autonomous Database de la base de données Conteneur Autonomous de secours cliché sont mis à jour. Pour accéder à la base de données, rechargez les portefeuilles à partir des instances Autonomous Database de secours et utilisez des chaînes de connexion de secours cliché.

Vous pouvez convertir manuellement la base de données Conteneur Autonomous de secours cliché en base de données Conteneur Autonomous de secours physique à partir d'Oracle Cloud Infrastructure (OCI). Pour obtenir des instructions détaillées, reportez-vous à Conversion d'une base de données de secours instantanée en base de données de secours physique. Si une base de données de secours cliché n'est pas convertie manuellement en base de données de secours physique, elle le sera automatiquement au bout de 7 jours à compter de sa création. Dans tous les cas, la conversion de la base de données de secours instantanée en base de données de secours physique annule toutes les mises à jour locales des bases de données de secours cliché et applique les données de journalisation reçues des bases de données principales.

Lorsqu'une base de données Conteneur Autonomous de secours est en mode de secours cliché, vous ne pouvez pas effectuer les opérations suivantes sur la base de données Conteneur Autonomous principale :

Création ou terminaison de bases de données autonomes
Augmenter ou réduire les bases de données autonomes
Restaurer les bases de données autonomes

Si la situation l'exige, vous pouvez effectuer manuellement un basculement vers une base de données de secours instantanée à partir de la base de données principale. Dans ce cas, le basculement convertit la base de données de secours cliché en base de données de secours physique en annulant toutes les mises à jour locales apportées à la base de données de secours cliché et en appliquant les données de la base de données principale. Pour obtenir des instructions détaillées, reportez-vous à Echec du basculement vers la base de données de secours dans une configuration Autonomous Data Guard.

La permutation entre la base de données principale et sa base de données de secours instantanée n'est pas autorisée. Vous devez convertir manuellement la base de données de secours instantanée en base de données de secours physique avant de tenter une permutation.

Accès aux bases de données de secours à partir d'applications client

Dans une configuration Autonomous Data Guard, les applications client se connectent normalement à la base de données principale et effectuent des opérations sur celle-ci.

Connexion à la base de données de secours physique

Outre cette connectivité standard, Autonomous Data Guard permet de connecter les applications client qui effectuent des opérations en lecture seule sur la base de données de secours. Pour tirer parti de cette option, les applications client se connectent à la base de données avec des noms de service de base de données qui incluent "_RO" (lecture seule), tel que décrit dans Noms de service de base de données prédéfinis pour les bases de données autonomes.

Connexion à la base de données de secours cliché

Autonomous Data Guard vous permet également de connecter des applications client qui effectuent des opérations de lecture/écriture à la base de données de secours instantanée. Ces opérations sont locales pour la base de données de secours instantanée et ne modifient pas sa base de données principale. Pour se connecter à une base de données de secours cliché, les applications client peuvent utiliser des noms de service de base de données qui incluent "_SS" (pour la base de données de secours cliché), comme décrit dans Noms de service de base de données prédéfinis pour les bases de données autonomes.

Remarques :

Lorsque la base de données de secours est en mode de secours cliché, tous les services de base de données qui incluent les services "_RO" dans leur nom sont inactifs et ne peuvent pas être utilisés pour les connexions.

Surveillance des durées des décalages

Lorsque les bases de données qui utilisent Autonomous Data Guard sont en cours d'exécution, vous pouvez surveiller le décalage de transport et appliquer des durées de décalage à partir de la page Détails de la base de données (ou de la base de données Conteneur) en sélectionnant Associations Autonomous Data Guard sous Ressources dans le menu latéral. Vous pouvez également utiliser la console OCI ou les API d'observabilité pour surveiller le décalage de transport et configurer des alarmes et des notifications. Pour plus d'informations, reportez-vous à Observabilité de la base de données avec les mesures Autonomous Database.

Vous devriez observer des fluctuations mineures au fil du temps et des variations de la charge globale de la base de données. Toutefois, si vous constatez une tendance à la hausse continue du décalage, vous pouvez prendre les mesures suivantes pour régler la situation :

Tendance à la hausse du décalage d'application des transactions : application. une tendance à la hausse continue du décalage d'application des transactions indique que la base de données de secours ne dispose pas d'une capacité suffisante pour suivre les enregistrements de journalisation provenant de la base de données principale. Pour résoudre ce problème, augmentez les OCPU de la base de données, tel que décrit dans Ajout de ressources d'UC ou de stockage à une base de données autonome dédiée.
Tendance à la hausse du décalage de transport : une tendance à la hausse continue du décalage de transport indique un problème de performances réseau. Sachant que le personnel en charge des opérations Oracle Cloud surveille en permanence les performances réseau, vous devriez constater une amélioration de la situation sans aucune action de votre part. Toutefois, si vous le souhaitez, vous pouvez en informer le personnel en charge des opérations en générant une demande d'assistance, tel que décrit dans Création d'une demande d'assistance dans My Oracle Support.

Options de configuration d'Autonomous Data Guard

Lorsque vous créez une base de données Conteneur Autonomous où Autonomous Data Guard est activé, vous indiquez les ressources d'infrastructure Exadata et de cluster de machines virtuelles Exadata Autonomous dans lesquelles la base de données de secours doit être créée, ainsi que le mode de protection des données à utiliser.

Vous disposez des possibilités suivantes lorsque vous spécifiez les ressources d'infrastructure Exadata et de cluster de machines virtuelles Exadata Autonomous à utiliser pour la base de données de secours :

Dans une région différente de celle de l'infrastructure Exadata et du cluster de machines virtuelles Exadata Autonomous Exadata Autonomous de la base de données principale :
Cette option apporte le plus haut niveau de protection contre les sinistres, y compris contre la perte catastrophique de connectivité ou d'alimentation du réseau externe dans toute une région.

Pour tirer parti au maximum de cette protection inter-région, vous devez également configurer le niveau d'application de façon à prendre en charge cette protection inter-région. Par conséquent, Oracle recommande de choisir cette option si le niveau d'application est déjà configuré de cette manière ou si vous comptez le reconfigurer pour prendre en charge la protection inter-région.

Si vous choisissez de localiser la base de données de secours dans une autre région, Oracle vous recommande d'utiliser le mode de protection Performances maximales.
Dans un autre domaine de disponibilité que celui de l'infrastructure Exadata et du cluster de machines virtuelles Exadata Autonomous Exadata Autonomous de la base de données principale :
Cette option offre un haut niveau de protection contre les sinistres, y compris contre la perte catastrophique de connectivité ou d'alimentation du réseau externe dans un domaine de disponibilité d'une région.

Elle constitue un bon compromis entre la protection des données et la simplicité de la configuration du niveau d'application.

Si vous choisissez de localiser la base de données de secours dans un autre domaine de disponibilité, Oracle vous recommande d'utiliser le mode de protection Disponibilité maximale.
Dans le même domaine de disponibilité que celui de l'infrastructure Exadata et du cluster de machines virtuelles Exadata autonome de la base de données principale :
Cette option apporte un niveau minimal de protection contre les sinistres, et Oracle vous recommande de ne pas la choisir.

Si les ressources d'infrastructure Exadata et de cluster de machines virtuelles Exadata Autonomous de la base de données principale se trouvent dans une région comportant un seul domaine de disponibilité, Oracle vous recommande de recourir à l'option "dans une autre région".

Si vous choisissez de localiser la base de données de secours dans le même domaine de disponibilité, Oracle vous recommande d'utiliser le mode de protection Disponibilité maximale.
Dans une location différente de celle de l'infrastructure Exadata et du cluster de machines virtuelles Exadata Autonomous de la base de données principale :
S'APPLIQUE À : Oracle Public Cloud uniquement

Ce choix vous permet d'ajouter une base de données de secours à partir d'une autre location, ce qui vous permet de basculer ou de permuter votre base de données vers cette base de données de secours inter-locations. Vous pouvez également créer une base de données de secours cliché dans la location distante. Le fait de disposer d'une base de données de secours inter-locations peut être utile pour la migration de base de données entre les locations.

Bases de données de secours inter-locations :
- Peut être activé avec un modèle de calcul d'ECPU ou d'OCPU. La base de données de secours doit utiliser le même modèle de calcul que la base de données principale.
- Ne prenez pas en charge le basculement automatique. Vous pouvez uniquement utiliser un basculement manuel.
- Vous ne pouvez pas l'ajouter à l'aide de la console Oracle Cloud Infrastructure. Vous pouvez uniquement ajouter une base de données de secours inter-locations à l'aide de l'interface de ligne de commande ou de l'API REST.

A propos des modes de protection

Autonomous Data Guard offre les modes de protection des données suivants :

Disponibilité maximale. Ce mode de protection fournit le niveau maximal de protection des données sans compromettre la disponibilité de la base de données principale.

La base de données principale ne valide pas les transactions tant qu'elle n'a pas reçu confirmation de la réception des données sur la base de données de secours (et non de leur écriture sur le disque). Si la base de données principale ne reçoit pas cet accusé de réception dans les 30 secondes, elle fonctionne comme en mode Performances maximales pour préserver la disponibilité de la base de données principale jusqu'à ce qu'elle reçoive à nouveau des accusés de réception en temps opportun.

Ce mode de protection assure l'absence de perte de données, sauf dans le cas de certaines doubles pannes, comme l'échec de la base de données principale après l'échec de la base de données de secours.
Performances maximales. Il s'agit du mode de protection par défaut. Il fournit le meilleur niveau de protection qu'il est possible d'obtenir sans nuire aux performances de la base de données principale.

La base de données principale valide les transactions dès que toutes les données redo générées par ces transactions ont été écrites dans son fichier de journalisation en ligne. Elle envoie également les données redo à la base de données de secours, mais cette opération est effectuée de manière asynchrone par rapport à la validation des transactions. De ce fait, les performances de la base de données principale ne sont pas affectées par les délais d'écriture des données redo dans la base de données de secours.

Ce mode de protection offre une protection des données légèrement inférieure au mode Disponibilité maximale, et son impact est minime sur les performances de la base de données principale.

Vous pouvez modifier le mode de protection dans une configuration Autonomous Data Guard à partir de la console Oracle Cloud Infrastructure (OCI). Pour obtenir des instructions détaillées, reportez-vous à Mise à jour des paramètres Autonomous Data Guard.

Pour plus d'informations sur les modes de protection dans Oracle Data Guard (qui est à la base de la fonctionnalité Autonomous Data Guard), reportez-vous à Modes de protection Oracle Data Guard dans Administration et concepts Oracle Data Guard.

Meilleures pratiques lors de la configuration d'Autonomous Data Guard

Alors qu'Autonomous Database vous permet de créer jusqu'à deux bases de données Conteneur Autonomous de secours avec Autonomous Data Guard, vous pouvez choisir d'utiliser une ou plusieurs bases de données Conteneur Autonomous de secours, selon vos besoins. Cependant, pour utiliser l'option de récupération après sinistre la plus résiliente proposée par Autonomous Database, vous pouvez ajouter une base de données Conteneur Autonomous de base de données de secours locale et une base de données Conteneur Autonomous de base de données de secours distante ou inter-région avec une disponibilité maximale comme mode de protection des données.

Comprenons les avantages de cette conception :

Base de données de secours locale :
- Le basculement automatique vers une base de données de secours locale dans la même région offre une isolation significative des sinistres locaux et une simplicité de basculement des applications.
- La valeur commerciale d'une base de données de secours locale est représentée par un basculement sans perte de données et un temps d'inactivité d'application réduit à quelques secondes.
- Les applications basculent automatiquement et de manière transparente vers la base de données de secours locale, en maintenant la même latence entre les serveurs d'applications et la base de données. Cela est particulièrement important pour les applications OLTP et de package, car une latence plus élevée peut avoir un impact significatif sur le débit et le temps de réponse global des applications.
Base de données de secours distante :
- Si un sinistre régional rend les systèmes de secours principal et local inaccessibles, l'application et la base de données peuvent basculer vers la base de données de secours distante.
- Même si le temps d'inactivité de la base de données est encore très faible en cas de sinistre régional, le temps d'inactivité de l'application peut être plus élevé en raison de l'orchestration supplémentaire requise pour les opérations DNS, d'application et de basculement de base de données vers la région secondaire.
Disponibilité maximale:
- Si le basculement automatique ou le basculement rapide (FSFO) est activé, chaque fois que la base de données Conteneur Autonomous principale devient indisponible, Autonomous Data Guard bascule vers la base de données de secours locale sans perte de données et sans modification de la latence de la base de données dans l'application.
- Si le basculement automatique ou le basculement rapide (FSFO) est activé, chaque fois que la région principale entière devient inaccessible, le système bascule vers la base de données de secours distante avec une perte de données potentielle.

Impact d'Autonomous Data Guard sur les opérations de gestion standard

Dans certains cas, les opérations de gestion standard effectuées sur les bases de données Conteneur Autonomous fonctionnent différemment sur les bases de données Conteneur principale et de secours dans une configuration Autonomous Data Guard par rapport aux bases de données Conteneur standard. La liste suivante décrit ces différences.

Modifier la programmation de maintenance
Les programmations de maintenance d'une base de données Conteneur principale et de sa base de données de secours sont liées : la maintenance de la base de données de secours est effectuée un certain nombre de jours avant la maintenance de la base de données principale. La valeur par défaut est de 7 jours. Vous pouvez choisir entre 1 et 7 jours, lorsque vous créez la base de données Conteneur principale ou ultérieurement en modifiant ses détails de maintenance.
Modifier le type de maintenance
Les types de maintenance d'une base de données Conteneur principale et de sa base de données de secours doivent être identiques. Vous choisissez le type de maintenance pour les bases de données principale et de secours lorsque vous créez la base de données Conteneur principale ou ultérieurement en modifiant ses détails de maintenance.
Désactiver les sauvegardes automatiques
Vous ne pouvez pas désactiver les sauvegardes automatiques lors du provisionnement d'une base de données Conteneur Autonomous avec Autonomous Data Guard.
Gestion de la maintenance programmée
Vous pouvez gérer la maintenance programmée d'une base de données Conteneur principale et de sa base de données de secours séparément. Toutefois, les maintenances des deux bases de données étant liées, vous devez effectuer la maintenance programmée sur la base de données de secours avant la base de données principale si vous choisissez de remplacer l'heure de maintenance programmée.
Déplacer vers un autre compartiment
Vous pouvez déplacer les bases de données Conteneur principale et de secours vers d'autres compartiments séparément et indépendamment, comme s'il s'agissait de bases de données Conteneur standard. Cependant, comme pour les bases de données Conteneur standard, vous devez faire preuve d'une extrême prudence lorsque vous déplacez une base de données Conteneur, afin de vous assurer que celle-ci reste accessible aux groupes d'utilisateurs cloud appropriés.
Redémarrer
Vous pouvez redémarrer les bases de données Conteneur principale et de secours séparément et indépendamment, comme s'il s'agissait de bases de données Conteneur standard.
Rotation de la clé de cryptage
Vous pouvez effectuer une rotation des clés de cryptage à partir de la base de données Conteneur Autonomous principale ou de la base de données principale.
Interrompre
Vous pouvez mettre fin aux bases de données Conteneur principale et de secours séparément. Toutefois, les conséquences de la terminaison d'une base de données Conteneur principale et de la terminaison d'une base de données Conteneur de secours diffèrent :
- La terminaison d'une base de données Conteneur principale met fin aux bases de données Conteneur principale et de secours. Vous ne pouvez pas mettre fin à une base de données Conteneur principale contenant des bases de données autonomes.
- La terminaison d'une base de données Conteneur de secours met fin à la base de données Conteneur de secours et l'enlève de la configuration Autonomous Data Guard. S'il ne reste qu'une base de données principale, la configuration Autonomous Data Guard est enlevée, ce qui la transforme en base de données Conteneur autonome.

Guides étape par étape

Pour obtenir des instructions détaillées sur la gestion de la configuration Autonomous Data Guard dans une base de données Conteneur Autonomous, reportez-vous aux sections suivantes :

Vous pouvez également utiliser l'API pour visualiser et gérer la configuration Autonomous Data Guard. Pour plus de détails, reportez-vous à API de gestion de la configuration Autonomous Data Guard.