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

La fonctionnalité Autonomous Data Guard permet de maintenir la disponibilité des bases de données de production essentielles pour vos applications stratégiques, malgré les pannes, les sinistres, les erreurs humaines ou l'altération des données. Ce type de fonction est souvent appelé récupération après sinistre.

Dans la base de données Autonomous AI sur une infrastructure Exadata dédiée, vous configurez et géez Autonomous Data Guard au niveau de la base de données Conteneur Autonomous.

A propos d'Autonomous Data Guard

Autonomous Data Guard permet de créer et de tenir à jour deux copies complètement distinctes de votre base d'informations : une base d'informations principale à laquelle vos applications se connectent et qu'elles utilisent, et une base d'informations de secours, qui est une copie synchronisée de la base principale. Ainsi, si la base de données principale devient indisponible pour quelque raison que ce soient, Autonomous Data Guard peut convertir la base de données de secours à la base de données principale et peut, de ce fait, commencer à couvert vos applications.

Les bases de données principale et de secours sont souvent appelées base de données homologues. Vous pouvez disposer d'un maximum de deux bases de données de secours par base de données Conteneur Autonomous.

Remarque : les applications doivent être configurées avec la continuité d'application transparente (TAC) afin de bénéficier pleinement de la fonctionnalité de disponibilité de base de donnée fournie par Autonomous Data Guard.

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

Description de l'illustration autonomous-data-guard.png ci-après

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écalage de transport, et l'autre, décalage d'application. Vous pouvez visualiser les valeurs de décalage en cours pour une base de données Autonomous AI à partir de la page Détails de la base de données sous Autonomous Data Guard. Vous pouvez visualiser les valeurs de décalage en cours dans toutes les bases de données Autonomous AI 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.

Remarque : 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 la base de données Autonomous AI sur une infrastructure Exadata dédiée, vous configurez et gérez 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.

Vous pouvez désormais créer et gérer Autonomous Data Guard entre une base de données Conteneur Autonomous dans Oracle Cloud Infrastructure (OCI) et une base de données Conteneur Autonomous dans Amazon Web Services (AWS).
Vous pouvez ajouter une base de données Conteneur Autonomous de secours de la région AWS à la base de données Conteneur Autonomous déjà provisionnée dans la région OCI. Vous pouvez également ajouter une base de données Conteneur Autonomous de secours dans la région OCI à une base de données Conteneur Autonomous déjà provisionnée dans la région AWS.

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

Le port 1522 doit être ouvert pour les bases de données Autonomous AI déployées sur Exadata Cloud@Customer afin d'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'a pas été ajoutée.
L'ajout d'une deuxième base de données de secours nécessite un redémarrage automatique non simultané pour 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 AI 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 (ACD). 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 de coffres et de clés.
- Vous ne pouvez avoir les bases de données principale et de secours que dans un maximum de 2 régions. Autrement dit, si vous voulez ajouter une seconde base de données de secours et que vous avez déjà utilisé la région croisée pour la première base de données de secours, la seconde doit se trouver dans la région principale ou la première.
Remarque : 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, vérifiez que vous avez ajouté des adresses IP de connexion pour votre cluster OKV dans le fichier de clés.

Remarque : si vous configurez Autonomous Data Guard entre une base de données Conteneur Autonomous dans une région OCI et une base de données Conteneur Autonomous dans la région AWS, vous ne pouvez utiliser que des clés gérées par Oracle ou Oracle Key Vault. Vous ne pouvez pas utiliser de clés KMS OCI ou de clés KMS AWS.

Changements de rôle et opérations

Une fois qu'une base de données Conteneur Autonomous (ACD) est 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 devient activé, Autonomous Data Guard effectue automatiquement une opération de basculement chaque fois que la base de données principale devient indisponible, pour une raison quelconque.

Une 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 (RTO). 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 (RPO). 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 principale défaillante devient une base de données de secours désactivée et reste indisponible pour toute connexion de 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 défaillante 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 ce basculement, chaque fois que la Base de données Conteneur Autonomous principale devient indisponible en raison d'une panne d'une région, d'une défaillance d'un domaine de disponibilité, d'une panne d'infrastructure Exadata ou d'AVMC (Autonomous Exadata VM Cluster) ou qu'elle retombe elle-même en panne, elle bascule automatiquement vers la Base de données Conteneur Autonomous. 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.

Remarque : le basculement automatique ne peut pas être activé pour les bases de données Autonomous AI déployées dans Exadata Cloud@Customer avec une configuration Autonomous Data Guard inter-région.

Vous ne pouvez pas ajouter une deuxième base de données Conteneur Autonomous de secours avec basculement automatique activé pour la première base de données Conteneur Autonomous de secours. Désactivez donc 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, puis 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 des 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 Performance maximale. 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 de Fast Start à n'importe quelle valeur comprise entre 5 et 3600.

Pour plus de détails, 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 avec plusieurs bases de données de secours et un basculement automatique :

Les basculements manuels nécessitent le rétablissement manuel de la base principale d'origine, qui devient la nouvelle base de secours.
Chaque fois qu'un basculement automatique se produit, la base de données Autonomous AI sur une infrastructure Exadata dédiée 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 entièrement modifiable créée en convertissant une base de données Conteneur Autonomous de secours en base de données Conteneur Autonomous de secours cliché. Pour obtenir des instructions détaillées, reportez-vous à Conversion de la base de données de secours physique en base de données de secours instantanée.

Une base de secours instantanée reçoit et archive, mais ne s'applique pas, les données de journalisation de la base principale. Toutefois, il augmente votre objectif de temps de récupération (RTO) 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'emploi, mais voici les principaux cas d'emploi :

Connectez les instances d'application principale et de secours aux bases de données principale et de secours en mode lecture-écriture pour effectuer les 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.

Remarque : vous ne pouvez pas convertir une base de données Conteneur Autonomous de secours physique en base de données de secours cliché pour laquelle le basculement automatique est activé.

Lors de la conversion en base de données de secours instantanée, vous pouvez soit activer de nouveaux services de base de données actifs uniquement en mode cliché, soit 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 instantanée peut entraîner le transfert de 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 veiller à utiliser la chaîne de connexion appropriée lors de la connexion à la base de données principale et à la base de données de secours instantanée.

Remarque : lorsque vous créez des services avec la base de données de secours cliché, les portefeuilles de toutes les bases de données Autonomous AI 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 de bases de données Autonomous AI 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 de la base de données de secours cliché en base de données de secours physique. Si une base de données de secours instantanée n'est pas convertie manuellement en base de données de secours physique, elle est automatiquement convertie en base de données de secours physique au bout de 7 jours à compter de sa création. Dans tous les cas, la conversion de la base de données de secours cliché en base de données de secours physique annule toutes les mises à jour locales de ces bases 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 base de données de secours instantanée, 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 Autonomous AI
Augmentez ou réduisez les bases de données d'IA autonomes
Restauration de bases de données Autonomous AI

Si la situation le demande, 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 instantanée en base de données de secours physique en supprimant toutes les mises à jour locales apportées à la base de données de secours instantanée et en appliquant les données de la base de données principale. Pour obtenir des instructions détaillées, reportez-vous à Basculement vers la base de données de secours dans une configuration Autonomous Data Guard.

Une commutation entre la base de données principale et sa base de données de secours cliché 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 secours physique

Outre cette connectivité standard, Autonomous Data Guard permet d'associer les applications client qui effectuent des opérations en lecture seule à 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 AI.

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 cliché. 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 "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 Autonomous AI.

Remarque : lorsque la base de données de secours est en mode de secours cliché, tous les services de base de données qui incluent des 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 des bases de donnée qui utilisent Autonomous Data Guard sont en cours d'exécution, vous pouvez surveiller les décalages de transport et appliquer des délais à partir de la page Détails de base de donnée (ou de la base de donnée Conteneur) en sélectionnant Groupes Autonomous Data Guard. 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 base de données avec les mesures de base de données Autonomous AI.

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. 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 cette situation, augmentez les OCPU de la base de données, comme décrit dans Ajout de ressources d'UC ou de stockage à une base de données d'IA 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 configurez Autonomous Data Guard, vous indiquez l'infrastructure Exadata et les ressources de cluster d'instances de machines virtuelles Exadata Autonomous dans lesquelles la base de donnée de secours doit avoir été créée, ainsi que la protection du mode des données à utiliser.

Vous pouvez choisir les options 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 autre région que celle de l'infrastructure Exadata et du cluster De machines virtuelles Exadata Autonomous de l'infrastructure 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 de la grappe de machines virtuelles Exadata Autonomous de l'infrastructure principale :

Cette option apporte un haut niveau de protection contre les sinistrés, y compris la perte catastrophique de connectivité ou d'alimentation du réseau externe, dans un domaine 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 d'accès, Oracle vous recommande d'utiliser le mode Disponibilité maximale.
Dans le même domaine de disponibilité que celui de l'infrastructure Exadata et de la grappe de machines virtuelles Exadata Autonomous de l'infrastructure principale :

Cette option apporte un niveau minimal de protection contre les sinistres, et Oracle vous recommande de ne pas la choisir.

Si les ressources Exadata Infrastructure et Autonomous Exadata VM Cluster de la bases de données principale se trouvent dans une région comportant une seule 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, Oracle vous recommande d'utiliser le mode Disponibilité maximale.
Dans une autre location que celle de l'infrastructure Exadata et de la grappe de machines virtuelles Exadata Autonomous de l'infrastructure principale :

S'APPLIQUE À : Oracle Public Cloud uniquement

Cette option vous permet d'ajouter une base de données de secours dans une location différente de celle de la base de données principale, ce qui permet le basculement ou la permutation de la base de données vers cette base de données de secours inter-location. Vous pouvez également créer une base de données de secours instantanée 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 la base de données entre les locations.

Bases de données de secours inter-locations :
- Peut être activé avec un modèle de calcul ECPU ou OCPU. La base de données de secours doit utiliser le même modèle de calcul que la base de données principale.
- Prise en charge du basculement automatique. Toutefois, le basculement automatique ne peut pas être activé pour les bases de données Autonomous AI déployées dans Exadata Cloud@Customer avec une configuration Autonomous Data Guard inter-région.
- ne peut pas être ajouté à l'aide de la console d'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. Une fois la base de données de secours ajoutée, vous pouvez visualiser la base de données de secours inter-location, effectuer un basculement ou une permutation vers la base de données de secours inter-location à partir de la console Oracle Cloud Infrastructure.

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ée principale ne valide pas les transactions tant qu'elle n'a pas reçu d'accusé de réception de la réception de la donnée sur la base de donnée de secours (et non de son écriture dans le disque). Si la base de données principale n'obtient pas cet accusé de réception dans les 30 secondes, elle fonctionne comme en mode de performances maximales pour préserver sa disponibilité jusqu'à ce qu'elle obtienne à 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 de configuration d'Autonomous Data Guard

Bien qu'Autonomous AI Database vous permette 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. Toutefois, pour utiliser l'option de récupération après sinistre la plus résiliente proposée par une base de données Autonomous AI, vous pouvez ajouter une base de données Conteneur Autonomous de secours locale et une base de données Conteneur Autonomous de secours distante ou inter-région avec une disponibilité maximale en tant que mode de protection des données.

Comprenons les avantages de cette conception :

Base de secours locale :
- Le basculement automatique vers une base de données de secours locale dans la même région offre une isolation locale significative en cas de sinistre et une simplicité de basculement des applications.
- La valeur commerciale d'une base de données de secours locale se voit dans un basculement sans perte de données et un temps d'inactivité des applications réduit à quelques secondes.
- Les applications basculent automatiquement et de manière transparente vers la base de données de secours locale, ce qui maintient 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 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 reste 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 de DNS, d'application et de basculement de la base de données vers la région secondaire.
Disponibilité maximale:
- Si le basculement automatique ou le basculement rapide en cas d'incident 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 de démarrage 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.
Gérer 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 la rotation des clés de cryptage à partir de la base de données Conteneur Autonomous principale ou de la base de données principale.
Terminer

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 primaire met fin aux bases de données Conteneur primaire et de secours. Vous ne pouvez pas mettre fin à une base de données Conteneur principale contenant des bases de données Autonomous AI.
- La terminaison d'une base de données Conteneur de secours met fin aux bases de données Conteneur de secours et enlève la configuration Autonomous Data Guard. S'il ne reste qu'une base de données principale, la configuration Autonomous Data Guard est enlevée et la base de données principale devient une 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 d'une configuration Autonomous Data Guard.

Contenu connexe

Gérer une configuration Autonomous Data Guard