Documentation sur Oracle Cloud Infrastructure

À propos d'Autonomous Data Guard avec une base de données de secours inter-région

Fournit des informations sur les fonctions et le fonctionnement d'Autonomous Data Guard avec une base de données de secours inter-région ou interlocation.

Lorsque vous ajoutez une base de données de secours dans une autre région, si l'instance principale tombe en panne, Autonomous Data Guard fournit une base de données de secours qui est physiquement séparée dans une région distante. La base de données de secours est disponible pour assumer le rôle d'instance principale non disponible. Lorsque vous ajoutez une base de données de secours dans une autre location, Autonomous Data Guard fournit une base de données de secours qui se trouve dans une autre location. La base de données de secours est disponible pour assumer le rôle d'instance principale non disponible.

Une base de données de secours inter-région est une réplique de la base de données principale et peut être utilisée pour la récupération en cas de défaillance ou lorsque la base de données principale n'est pas disponible. L'activation d'Autonomous Data Guard avec une base de données de secours inter-région offre une solution d'ODR faible pour la récupération après sinistre si une région entière n'est pas disponible ou si la base de données principale est arrêtée pour une raison quelconque.

Les bases de données de secours inter-région Autonomous Data Guard entraînent le coût supplémentaire des UC de base et le double du stockage de la base de données principale, y compris toute utilisation de stockage mise à l'échelle automatique, facturé sur la base de données pair distante. Les UC mises à l'échelle automatiquement de la base principale ne sont pas facturées en plus sur la base de données pair distante. Le nombre d'UC de base est spécifié par le nombre d'ECPU (OCPU si votre base de données utilise des OCPU), comme indiqué dans le champ Nombre d'ECPU (Nombre d'OCPU) de la console Oracle Cloud Infrastructure.

Autonomous AI Database vous permet de créer une ou plusieurs bases de données pairs de récupération après sinistre distantes, selon votre modèle de calcul :

  • Modèle de calcul d'OCPU : Vous pouvez ajouter une base de données de secours distante dans une région appariée. Les régions appariées sont des régions distantes où vous pouvez créer un pair inter-région.

  • Modèle de calcul ECPU : Vous pouvez ajouter plusieurs pairs de reprise après sinistre distants, avec un maximum d'un pair dans chaque région appariée distante. Par exemple, si votre base de données principale se trouve dans la région IAD, vous pouvez ajouter une base de données de secours dans PHX et une base de données de secours dans SJC, mais vous ne pouvez pas ajouter deux pairs de récupération après sinistre distants dans PHX.

Les régions appariées sont des régions distantes où vous pouvez créer une base de données de secours inter-région. Pour plus d'informations sur les régions appariées, voir Régions appariées inter-régions d'Autonomous AI Database.

Vous effectuez presque toutes les opérations, telles que l'ajustement du nombre d'ECPU (nombre d'OCPU si votre base de données utilise des OCPU) et l'activation de l'ajustement automatique du calcul sur la base de données principale. Autonomous Data Guard effectue ensuite les mêmes actions sur la base de données de secours inter-région.

Après avoir ajouté une base de données de secours distante, Autonomous AI Database fournit l'accès à la base de données de secours distante à partir de la console Oracle Cloud Infrastructure. Autonomous AI Database fournit l'accès à la base de données de secours distante afin que vous puissiez effectuer certaines opérations indépendamment sur la base de secours distante, telles que la configuration des réseaux et des réseaux en nuage virtuels pour les points d'extrémité privés et l'ajout d'un marquage pour définir des clés et des valeurs qui ne sont pas répliquées entre la base de données principale et la base de secours distante.

Note

Autonomous Data Guard n'effectue pas de basculement automatique pour une base de données de secours inter-région. Si la base de données principale n'est pas disponible et qu'une base de données de secours locale n'est pas disponible, vous pouvez effectuer un basculement manuel pour qu'une base de données de secours inter-région assume le rôle de base de données principale.

Vous ne pouvez pas vous connecter à une base de données de secours inter-région lorsqu'elle fonctionne en tant que base de données de secours et qu'elle n'est pas disponible pour les opérations en lecture seule. Vous pouvez vous connecter à la base de données dans les cas suivants :

Les zones suivantes présentent des différences pour le basculement ou la migration de la base de données principale vers une base de données de secours distante, par rapport au basculement ou à la migration vers une base de secours locale :

  • Nom d'affichage : Le nom d'affichage a l'extension "_region". Où région est le nom de la région, par exemple IAD ou BOM.

    Si vous avez créé le pair inter-région avant l'introduction de la prise en charge de plusieurs pairs inter-région, le nom d'affichage du pair inter-région comporte l'extension "_Remote".

  • Carnets OML : Après une permutation inter-région ou un basculement, les carnets OML de la base principale qui ont fait l'objet d'une permutation ou d'un basculement ne sont pas présents dans la base de données principale (la base de données principale courante après le changement de rôle). De nouveaux carnets OML peuvent être créés.

  • Point d'extrémité privé : Vous pouvez configurer et mettre à jour des points d'extrémité privés de manière indépendante sur une base de données de secours avant le basculement ou avant d'effectuer une permutation. Cela vous permet d'avoir un point d'extrémité privé configuré différemment, après le basculement ou après l'exécution d'une permutation. La base de données Autonomous AI Database ne synchronise pas la configuration réseau de la base principale vers une base de secours distante.

    L'appairage de VCN et le transfert de domaine sont requis pour que les portefeuilles fonctionnent entre les régions, avec des bases de données d'IA autonomes avec un point d'extrémité privé avec une base de données de secours Autonomous Data Guard, où les bases de données principale et de secours se trouvent dans des réseaux en nuage virtuels différents. Voir Appairage distant de réseaux en nuage virtuels à l'aide d'une connexion d'appairage distant et DNS dans le réseau en nuage virtuel pour plus d'informations sur l'appairage de VCN et le transfert de domaine.

  • Liste de contrôle d'accès au réseau : Par défaut, une base de données principale de récupération après sinistre et des bases de données pairs distantes utilisent les mêmes listes de contrôle d'accès au réseau (LCA). Facultativement, vous pouvez modifier indépendamment les listes de contrôle d'accès réseau sur une base de données pair distante. Cela vous permet d'utiliser différentes listes de contrôle d'accès sur une base de données pair distante.

    Pour plus d'informations, voir Gérer les listes de contrôle d'accès de réseau pair distant.

  • Marqueurs : Les marqueurs sont traités indépendamment sur une base principale de récupération après sinistre et sur une base de données pair distante. Cela signifie :

    • Lorsque vous ajoutez, supprimez ou mettez à jour un marqueur sur un pair distant, la modification s'applique uniquement à la base de données pair distante.

    • Lorsque vous ajoutez, mettez à jour ou supprimez un marqueur sur la base principale, ce marqueur n'est pas ajouté, mis à jour ou supprimé dans les bases de données pairs distantes.

  • API ou scripts : Toutes les API ou scripts que vous utilisez pour gérer la base de données d'IA autonome peuvent devoir être mis à jour pour appeler les API de la base de données principale.

    Vous pouvez également utiliser des variables de substitution prédéfinies dans vos URL Oracle Cloud Infrastructure (OCI) pour le basculement inter-région pour la base de données d'intelligence artificielle autonome lors de l'utilisation des API REST OCI. Pour plus d'informations, voir Variables de substitution dans les URL Oracle Cloud Infrastructure (OCI).

    Pour les connexions mTLS, vous devez télécharger un portefeuille à partir de la base principale, la base principale courante, après un basculement ou après une permutation. Pour plus d'informations, voir Chaînes et portefeuilles de connexion pour la récupération après sinistre inter-région.

  • Applications clients : Les applications clients doivent se connecter à l'aide des chaînes de connexion et du portefeuille que vous téléchargez à partir de la base de données principale, la base de données principale courante, après un basculement ou après une permutation. Pour plus d'informations, voir Chaînes et portefeuilles de connexion pour la récupération après sinistre inter-région.

  • Connexions basées sur un portefeuille : Vous devez télécharger un portefeuille et vous connecter à l'aide des chaînes de connexion de la base de données principale, la base de données principale courante, pour vous connecter à la base de données après un basculement ou après une permutation. Pour plus d'informations, voir Chaînes et portefeuilles de connexion pour la récupération après sinistre inter-région.

  • Autonomous AI Database Outils : Les outils ont des URL différentes dans la base de données principale, la base de données principale courante, après un basculement ou après une permutation (les URL des outils ne changent pas pour une permutation ou un basculement vers une base de secours locale) :

    • Database Actions

    • Oracle APEX

    • Services de données Oracle REST (ORDS)

    • Graph Studio

    • Carnets Oracle Machine Learning

    • Transformations de données

    • API MongoDB

  • Utilisation du service de stockage d'objets pour Oracle Cloud Infrastructure Object Storage : Après le basculement ou la permutation de la base de données principale vers une base de données de secours, sur la base de données principale (la base de données principale courante), les données d'identification et les URL qui fournissent l'accès au service de stockage d'objets continuent de fonctionner comme avant le basculement ou la permutation, ce qui permet d'accéder aux éléments suivants :

    • Tables externes

    • Tables partitionnées externes

    • Tables partitionnées hybrides externes

    Note

    Cela s'applique lorsque le service de stockage d'objets est disponible. Pour des scénarios rares où le stockage d'objets n'est pas disponible, Oracle recommande d'avoir des sauvegardes ou une réplication du stockage d'objets dans une autre région. Si le stockage d'objets n'est pas disponible (c'est-à-dire la ressource de stockage d'objets que vous avez utilisée avec la ressource principale avant une permutation ou un basculement), vous pouvez mettre à jour vos données d'identification d'utilisateur et vos paramètres qui définissent les URL pour le stockage d'objets afin que les paramètres spécifient des valeurs pour accéder au stockage d'objets d'une région disponible. Pour plus d'informations, voir Utilisation de la réplication.

Autonomous Data Guard interlocation avec base de données de secours inter-région

Vous pouvez activer Autonomous Data Guard interlocation avec une base de données de secours inter-région. Lorsque vous ajoutez une base de données de secours Autonomous Data Guard interlocation dans une autre région, la base de données Autonomous AI Database provisionne une base de données de secours inter-région dans la location de destination. Avec une base de données de secours Autonomous Data Guard interlocation, vous pouvez effectuer un basculement, une permutation ou créer une base de données de secours instantanée avec une base de données de secours inter-région dans une autre location. Cette fonction vous permet d'utiliser Autonomous Data Guard pour migrer une base de données vers une autre location.

Pour plus d'informations, voir Utiliser une base de données de secours Autonomous Data Guard interlocation.

Récupération après sinistre de pile complète OCI avec une base de données de secours inter-région Autonomous Data Guard

Lorsque la récupération après sinistre de pile complète est activée, la page des détails de la base de données d'intelligence artificielle autonome, sous Récupération après sinistre, affiche le champ Récupération après sinistre de pile complète comme Activée.


Description de adb_full_stack_dr_enabled.png :
Description de l'illustration adb_full_stack_dr_enabled.png

Pour plus d'informations, voir Utiliser la récupération après sinistre de pile complète OCI avec une base de données d'intelligence artificielle autonome.

Rubriques

Rubrique parent : Utiliser des bases de données de secours avec Autonomous Data Guard pour la récupération après sinistre

Rôle de base de données Autonomous Data Guard

Après avoir ajouté une base de données de secours inter-région, chaque base de données a un rôle désigné : base de données principale, base de secours ou base de secours instantanée.

Ce rôle indique l'état actuel d'une base de données, d'une base de données principale, d'une base de données de secours ou d'une base de données de secours instantanée, et cette valeur change après une permutation ou un basculement, ou après la conversion d'une base de données de secours en base de données de secours instantanée. Vous pouvez voir le rôle Base de données d'IA autonome dans l'icône qui s'affiche à côté du nom d'affichage dans la page Informations sur la base de données d'IA autonome. Exemple :

Une description de adb_adg_primary.png suit
Description de l'illustration adb_adg_primary.png

Une description de adb_adg_standby.png suit
Description de l'illustration adb_adg_standby.png

Après avoir ajouté une base de données de secours inter-région, vous pouvez voir le rôle dans la zone Reprise après sinistre de la page de détails. Le rôle est l'un des suivants :

  • Le rôle affiche Principal dans la base de données principale.

  • Après une permutation ou un basculement, sur la même base de données, le rôle affiche De secours.

  • Après avoir converti un pair inter-région en base de données de secours instantanée, le rôle affiche Base de données de secours instantanée.

Pour voir les détails d'un pair, dans la page des détails de la base de données du service d'intelligence artificielle autonome, sélectionnez l'onglet Reprise après sinistre. La liste affiche les informations sur la base de données pair et la colonne Rôle de pair affiche le rôle de pair :

  • De secours (local) : La colonne Rôle de pair affiche De secours et la base de données a le même nom d'affichage dans la colonne Peer Autonomous Database. La colonne Région affiche le nom de la région courante.

  • Standby (cross-region) the Peer role column shows Standby for a remote standby database and the database has the same name with an "_region" extension in the Peer Autonomous Database column. Vous pouvez cliquer sur le lien pour accéder à la base de données distante. La colonne Région affiche le nom de la région distante.

    Si vous avez créé le pair inter-région avant l'introduction de la prise en charge de plusieurs pairs inter-région, le nom d'affichage du pair inter-région comporte l'extension "_Remote".

  • Base de données de secours instantanée : La colonne Rôle de pair affiche Base de données de secours instantanée. La colonne Région affiche le nom de la région distante.

Basculement et permutation inter-région Autonomous Data Guard

Vous pouvez avoir un pair de récupération après sinistre local et, éventuellement, vous pouvez ajouter un ou plusieurs pairs inter-régions (plusieurs pairs inter-régions sont autorisés avec le modèle de calcul ECPU). Dans les cas locaux et inter-régions, un pair peut être une copie de récupération après sinistre basée sur une sauvegarde ou une base de secours Autonomous Data Guard.

Avec une région courante et une ou plusieurs bases de données pair Autonomous Data Guard inter-régions, selon l'état de la base de données principale, vous disposez des options suivantes :

  • Si votre base de données principale tombe en panne et que la base de données de secours locale est disponible, Autonomous Data Guard effectue automatiquement un basculement pour convertir la base de données de secours locale en base de données principale, avec une interruption minimale. Une fois le basculement terminé, Autonomous Data Guard crée une nouvelle base de données de secours locale pour vous. Si le basculement automatique n'est pas possible, vous avez la possibilité d'effectuer un basculement manuel.

    Autonomous Data Guard continue d'utiliser les mêmes bases de données pairs inter-régions.

  • Si votre base de données principale tombe en panne et que la base de données de secours locale n'est pas disponible, vous pouvez effectuer un basculement manuel vers une base de données pair inter-région et la base de données pair inter-région vers laquelle vous basculez deviendra la base de données principale.

    Dans ce cas, une fois le basculement terminé, Autonomous Data Guard ne crée pas de nouvelle base de données de secours locale (par défaut, vous disposez d'un pair de copie de sauvegarde).

  • Vous pouvez effectuer une opération de basculement, au cours de laquelle la base de données principale devient la base de données de secours locale, et la base de données de secours locale devient la base de données principale.

    Autonomous Data Guard continue d'utiliser les mêmes bases de données pairs inter-régions.

  • Vous pouvez effectuer une opération de permutation, dans laquelle une base de données pair inter-région devient la base de données principale (et la base de données qui était la base principale est recréée en tant que nouvelle base de données de secours afin qu'elle devienne une base de données pair).

    Une permutation modifie les rôles de la base principale et d'une base de données pair. Si vous effectuez une permutation deux fois entre les deux mêmes régions distantes, la base principale redevient la base principale.

Sauvegarde et restauration inter-régions d'une base de données Autonomous Data Guard

Une fois que vous avez ajouté une base de données de secours inter-région Autonomous Data Guard, la sauvegarde et la restauration à partir d'une sauvegarde sont traitées comme suit :

  • Si la base de données principale est restaurée à partir d'une sauvegarde, une nouvelle base de secours distante est créée à partir de la base de données principale restaurée.

  • Les sauvegardes automatiques ne sont effectuées que sur la base de données principale (base de données affichant Role : Primaire). Par exemple, après une permutation ou un basculement, la base de données avec le rôle Principal commence à effectuer des sauvegardes automatiques. Une base de données avec le rôle De secours ne prend plus de sauvegardes. Si vous effectuez une nouvelle permutation, la base de données qui devient la base de données de rôle Principale recommence à effectuer des sauvegardes.

  • Vous ne pouvez pas restaurer ou cloner à partir d'une sauvegarde lorsqu'une base de données pair est dans le rôle De secours. Les sauvegardes sont effectuées uniquement sur la base de données du rôle principal et l'opération de restauration n'est pas disponible dans la console Oracle Cloud Infrastructure d'une base de données De secours.

Chaînes et portefeuilles de connexion pour la récupération après sinistre inter-région

Lorsque vous ajoutez une base de données de secours inter-région (distante) Autonomous Data Guard ou lorsque vous utilisez un pair de récupération après sinistre basé sur une sauvegarde inter-région, le portefeuille et la chaîne de connexion de la base de données principale contiennent uniquement le nom d'hôte de la base de données principale.

En outre, le portefeuille et la chaîne de connexion d'une base de données pair distante ne contiennent que le nom d'hôte de la base de données distante. Cela s'applique à la fois aux portefeuilles d'instance et aux portefeuilles régionaux.

Oracle recommande de configurer vos applications s'exécutant sur la base de données Rôle principal pour qu'elles utilisent le portefeuille ou la chaîne de connexion téléchargés à partir de la base de données principale. Pour les applications qui s'exécutent sur une base de données distante, utilisez le "wallet" ou la chaîne de connexion téléchargée à partir de la base distante (où la base distante est la base principale courante après un basculement ou après une permutation). Vous pouvez obtenir ces chaînes de connexion ou le portefeuille en cliquant sur Connexion à la base de données dans la console Oracle Cloud Infrastructure.

Par exemple, si Autonomous Data Guard inter-région est configuré avec la base principale dans Ashburn (IAD) et une base de données de secours inter-région dans Phoenix (PHX), Oracle recommande à vos applications de milieu de gamme s'exécutant dans IAD d'utiliser la chaîne de connexion ou portefeuille de la base de données principale dans IAD et des applications correspondantes exécutées dans PHX après un basculement ou après une permutation, utilisez la chaîne de connexion ou le portefeuille de la base de données de secours dans PHX. Lors d'un basculement régional ou d'une permutation, Oracle recommande de basculer à la fois votre base de données et vos applications de niveau intermédiaire vers la nouvelle base de données de rôle principal pour une performance optimale et pour minimiser toute latence inter-régionale.

Pour plus d'informations, voir Télécharger les données d'identification du client (portefeuilles).

Si votre application l'exige, vous pouvez créer manuellement des chaînes de connexion contenant à la fois les noms d'hôte de base de données principale et de base de données distante, afin de prendre en charge la connexion à l'instance disponible et ouverte automatiquement pour les connexions, la base de données principale ou la base de données distante.

Pour plus de détails sur les étapes de création manuelle de ces chaînes de connexion, voir :

Autonomous Data Guard inter-régions avec les clés de chiffrement gérées par le client

Lorsque vous ajoutez une base de données de secours inter-région Autonomous Data Guard, il existe des considérations particulières lorsque la base de données principale utilise des clés de chiffrement gérées par le client ou si vous voulez passer à l'utilisation de clés de chiffrement gérées par le client sur la base de données principale.

Note

La base de données autonome d'IA prend en charge plusieurs fournisseurs de clés gérées par le client. Seule Oracle Cloud Infrastructure Vault est prise en charge pour une utilisation avec Autonomous Data Guard. Les autres chambres fortes ne sont pas prises en charge pour les clés gérées par le client.

Pour qu'une base de données de secours distante puisse utiliser la même clé de chiffrement principale que la base de données principale, la clé de chiffrement principale doit être répliquée dans la région distante. Les clés de chiffrement gérées par le client ne sont prises en charge qu'avec une seule base de données de secours Autonomous Data Guard inter-région. Les bases de secours inter-régions multiples ne sont pas prises en charge, car Oracle Cloud Infrastructure Vault ne prend en charge que la réplication vers une région distante.

Prenons les cas suivants :

  • L'ajout d'une base de données de secours distante Autonomous Data Guard est autorisé si la base de données Autonomous AI Database utilise des clés gérées par le client. Lorsque la base de données utilise une clé gérée par le client et que vous ajoutez une base de données de secours inter-région Autonomous Data Guard, la liste Région de la boîte de dialogue Ajouter une base de données pair affiche uniquement les régions qui contiennent la chambre forte et les clés répliquées. Si vous ne voyez pas de région distante répertoriée, vous devez répliquer votre chambre forte et vos clés vers la région dans laquelle vous voulez votre base de données de secours (il doit s'agir d'une région appariée).

  • Le passage aux clés gérées par le client est autorisé sur la base principale lorsque vous disposez d'une base de données de secours inter-région Autonomous Data Guard. Dans le cas où la base de données utilise des clés gérées par Oracle et que vous passez à des clés gérées par le client sur la base principale, vous ne voyez que les clés qui sont répliquées dans les régions principale et de secours. La liste Gérer la clé de chiffrement du service Chambre forte et de la clé de chiffrement principale affiche uniquement les chambres fortes et les clés qui sont répliquées à la fois dans les régions principale et de secours. Si aucune clé ne s'affiche, répliquez votre chambre forte et vos clés vers une région appariée.

Voir ce qui suit pour plus d'informations :

Autonomous Data Guard interlocation avec clés de chiffrement gérées par le client

Lorsque vous ajoutez une base de données de secours interlocation Autonomous Data Guard, il existe des considérations particulières lorsque la base de données principale utilise des clés de chiffrement gérées par le client ou si vous voulez passer à l'utilisation de clés de chiffrement sur la base de données principale.

Lorsque vous ajoutez une base de données de secours interlocation Autonomous Data Guard pour une sécurité supplémentaire, par exemple pour la protection contre les rançongiciels, si la base principale utilise une clé gérée par le client, vous pouvez répliquer la clé de chiffrement et l'utiliser dans la base de données de secours. Vous devez utiliser la même clé de chiffrement, qu'il s'agisse d'une clé gérée par Oracle ou d'une clé gérée par le client, à la fois dans la location principale et dans la base de secours. Comme chaque location dispose d'une copie indépendante de la clé, la désactivation ou la suppression de la clé dans une location n'a aucune incidence sur l'autre.

Note

La base de données autonome d'IA prend en charge plusieurs fournisseurs de clés gérées par le client. Seule Oracle Cloud Infrastructure Vault est prise en charge pour une utilisation avec Autonomous Data Guard. Les autres chambres fortes ne sont pas prises en charge pour les clés gérées par le client sur la base principale ou de secours avec Autonomous Data Guard.

Pour plus d'informations, voir Notes sur les clés de chiffrement gérées par le client avec une base de données de secours Autonomous Data Guard interlocation.

Réplication de sauvegardes vers une base de données de secours Autonomous Data Guard inter-région

Lorsque vous ajoutez une base de données de secours Autonomous Data Guard inter-région, vous pouvez activer la réplication de sauvegarde inter-région afin que les sauvegardes automatiques à partir de la base principale soient également disponibles sur une région distante.

Par défaut, les sauvegardes effectuées sur la base principale ne sont pas répliquées sur une base de données de secours inter-région. Lorsque vous activez la réplication de sauvegarde inter-région, jusqu'à 7 jours de sauvegardes automatiques pour la base principale sont répliqués vers une base de données de secours inter-région. Lorsque cette fonction est activée, les sauvegardes automatiques sont disponibles dans la région distante comme suit :

  • Après une permutation ou un basculement, vous pouvez restaurer ou cloner un horodatage au cours des sept (7) derniers jours, ou un horodatage au cours de la période de conservation spécifiée lorsque la période de conservation est réglée à moins de sept jours.

  • Toutes les sauvegardes de la base principale qui sont répliquées vers la région distante sont supprimées sur le pair de la région distante après sept jours, ou après le nombre de jours de la période de conservation lorsque la période de conservation est réglée à moins de sept jours.

  • Vous ne pouvez pas modifier la période de conservation des sauvegardes répliquées, sauf si vous modifiez la période de conservation des sauvegardes sur la base principale pour spécifier une valeur inférieure à sept jours. Dans ce cas, la période de conservation des sauvegardes répliquées sur la région distante correspond à la période de conservation des sauvegardes automatiques définie sur la région principale.

La réplication de sauvegarde inter-région entraîne des frais supplémentaires. Pour plus d'informations, voir Facturation des fonctions sans serveur d'Oracle Autonomous AI Database.

Pour plus d'informations, voir Ajouter une base de données de secours inter-région et Activer ou désactiver la réplication de sauvegarde pour une base de données de secours inter-région existante.

Notez les points suivants pour la réplication de sauvegarde automatique inter-région :

  • Après une permutation ou un basculement, alors que la base de données inter-région occupe le rôle de base principale, les sauvegardes sont effectuées sur la base principale courante et sont répliquées sur la base de secours (distante) courante.

  • Dans une région distante, vous pouvez créer un clone à partir d'une sauvegarde répliquée alors que la base de données est dans le rôle De secours.

Licence BYOL inter-régions d'Autonomous Data Guard

La limite d'ECPU BYOL que vous avez définie pour une base de données principale Autonomous Data Guard ne s'applique pas à une base de données de secours Autonomous Data Guard inter-région ou inter-location.

Sur une base de données de secours inter-région ou interlocation, vous pouvez définir indépendamment la limite d'UC BYOL, selon les besoins. La définition d'une valeur pour Limite de licence BYOL limite le nombre d'ECPU couvertes par les licences BYOL.

Par exemple, considérons une base de données principale Autonomous Data Guard à 8 ECPU utilisant une licence BYOL. Lorsque vous ajoutez une base de données de secours inter-région ou interlocation, la base de données de secours prend sa licence à partir de la base de données principale (à l'aide d'une licence BYOL).

Dans cet exemple, si vous réglez la limite de licence BYOL à 4 (ECPU) sur la base principale, 4 des 8 ECPU utilisent une licence BYOL. Toutefois, la limite de licence BYOL que vous avez définie pour la base de données principale ne s'applique pas à une base de données de secours inter-région ou interlocation. La base de données de secours utilise la licence Utiliser sa propre licence (BYOL) (sans limite de licence BYOL). Si vous définissez séparément une limite de licence BYOL sur la base de données de secours, par exemple si vous réglez la valeur de la limite de licence BYOL à 2 (ECPU), 2 ECPU sur la base de données de secours sont facturées à l'aide de la licence BYOL et 6 ECPU. De même, la limite d'UC BYOL que vous avez définie sur la base de données de secours n'a pas d'incidence sur la limite d'UC BYOL de la base de données principale.

Pour plus d'informations, voir Sélectionner l'option Utiliser sa propre licence lors du provisionnement ou du clonage et Sélectionner Utiliser sa propre licence sur la base de données autonome d'IA (modèle de calcul ECPU).