Remarques sur Autonomous Data Guard

Fournit des remarques sur l'utilisation d'Autonomous Database avec une base de données de secours Autonomous Data Guard.

  • Vous ne pouvez pas vous connecter à une base de données de secours tant qu'elle n'est pas définie comme principale par un basculement ou une permutation. Par conséquent, une base de données de secours ne peut pas être ouverte pour un accès en lecture seule et ne peut pas être utilisée pour décharger les requêtes d'une base de données principale.

  • Autonomous Data Guard est disponible avec les types de charge globale Entrepôt de données et Traitement des transactions. Autonomous Data Guard n'est pas disponible avec les types de charge globale JSON et APEX.

  • Autonomous Data Guard n'est pas disponible avec les bases de données autonomes Toujours gratuit.

  • Autonomous Database ne donne pas accès à une base de données de secours locale :

    • Vous effectuez toutes les opérations, telles que l'augmentation du nombre d'ECPU (nombre d'OCPU si votre base de données utilise des OCPU), et Autonomous Database effectue les mêmes actions sur la base de données de secours locale. De même, vous effectuez des actions telles que l'arrêt ou le redémarrage de la base de données uniquement sur la base de données principale.

    • Une base de données de secours locale n'est pas disponible pour une utilisation en lecture seule.

  • Les graphiques Nombre d'OCPU (si votre base de données utilise des OCPU) et Utilisation de l'UC sur la carte Tableau de bord de base de données de Database Actions affichent les ECPU (si votre base de données utilise des OCPU) allouées et l'utilisation de l'UC pour la base de données principale. Ces graphiques n'incluent pas d'informations sur une base de données de secours locale ou sur une base de données de secours distante.

    Les mesures relatives à l'utilisation de l'UC sont affichées sur la page des mesures de la console Oracle Cloud Infrastructure pour la base de données principale. D'autres mesures sur cette page s'appliquent également à la base de données principale. Ces mesures n'incluent pas d'informations sur la base de données de secours locale ou la base de données de secours distante.

  • Après une permutation ou un basculement vers une base de données homologue, celle-ci devient la base de données principale, et les graphiques sur le tableau de bord de base de données de Database Actions et la page des mesures de la console Oracle Cloud Infrastructure affichent des informations sur la base de données principale. Les graphiques et les mesures ne contiennent pas d'informations sur la base de données qui était la principale avant l'opération de permutation ou de basculement.

  • Le basculement automatique vers une base de données de secours locale est désactivé lorsqu'une opération de restauration est en cours.

  • Le basculement automatique vers une base de données de secours locale est désactivé lors de la mise à niveau d'une base de données.

  • Lorsque le champ Etat de cycle de vie de la base de données principale affiche Arrêté, les bases de données de secours sont également arrêtées. Vous pouvez toujours effectuer une permutation lorsque la base de données principale affiche l'état Arrêté.

Remarques sur Autonomous Data Guard inter-région

Vous trouverez ci-dessous les restrictions et limites applicables lorsque vous activez Autonomous Data Guard avec une base de données de secours inter-région (distant) :

  • Pour désactiver Autonomous Data Guard avec une base de données de secours inter-régions, vous mettez fin à la base de données de secours distante. Pour plus d'informations, reportez-vous à Terminaison d'une base de données de secours inter-région.

  • Lorsqu'une adresse privée est activée ou désactivée sur la base de données principale, toute liste de contrôle d'accès précédemment configurée sur la base de données de secours est activée et les valeurs sont effacées. Vous devez réinitialiser et vérifier la liste de contrôle d'accès sur la base de données de secours après avoir désactivé une adresse privée sur la base de données principale.

  • Vous effectuez la plupart des opérations, telles que l'augmentation du nombre d'ECPU (nombre d'OCPU si votre base de données utilise des OCPU) et l'activation du redimensionnement automatique du calcul, sur la base de données principale et Autonomous Database effectue les mêmes actions sur la base de données de secours distante. De même, vous effectuez des actions telles que l'arrêt ou le redémarrage de la base de données uniquement sur la base de données principale.

  • Vous pouvez effectuer certaines opérations, telles que la configuration d'adresses privées, sur une base de données de secours distante.

  • Vous pouvez modifier la configuration réseau des listes de contrôle d'accès sur une base de secours distante. Pour plus d'informations, reportez-vous à la section Manage Remote Peer Network ACLs.

  • Une base de données de secours distante n'est pas disponible pour une utilisation en lecture seule.

  • Oracle Data Safe peut être activé sur une base de données sur laquelle une base de données de secours inter-régions est activée, mais il surveille uniquement la base de données dans sa région et ne peut pas surveiller la base de données de secours en cas de permutation ou de basculement.

  • Lorsque vous autorisez l'authentification TLS pour la base de données principale, Autonomous Data Guard active l'authentification TLS dans la base de données de secours inter-région. Par conséquent, lorsqu'Autonomous Data Guard est activé avec une base de données de secours distante, vous pouvez uniquement autoriser les connexions TLS sur la base de données principale si cette dernière et la base de données de secours distante sont configurées pour prendre en charge les connexions TLS. En d'autres termes, les bases de données principale et de secours distante doivent être configurées avec des listes de contrôle d'accès ou avec une adresse privée. Pour plus d'informations, reportez-vous à Prérequis de configuration réseau pour autoriser l'authentification TLS.

  • Reportez-vous aux informations suivantes sur l'utilisation de clés gérées par le client avec Autonomous Data Guard :

  • La limite d'ECPU BYOL que vous définissez sur 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-locations. Sur une base de données de secours inter-région ou inter-locations, vous pouvez définir indépendamment la limite d'ECPU BYOL, selon vos besoins. La définition d'une valeur pour la limite de licence BYOL limite le nombre d'ECPU couvertes par les licences BYOL.

    Pour plus d'informations, reportez-vous à Licences BYOL inter-région Autonomous Data Guard.

  • Lorsque vous activez Autonomous Data Guard avec une base de données de secours inter-région, les portefeuilles de la base de données principale et de la base de données de secours indiquent des noms d'hôte de base de données différents et utilisent des chaînes de connexion différentes. Oracle recommande aux applications d'utiliser la chaîne de connexion ou le portefeuille téléchargé à partir de la même région que la base de données principale.

    Si vous devez utiliser une chaîne de connexion ou un portefeuille unique contenant les noms d'hôte des bases de données principale et de secours, vous pouvez le construire manuellement.

    Pour construire manuellement un "wallet" contenant à la fois les chaînes de connexions de base de données principale et distante, procédez comme suit :

    1. Dans la console Oracle Cloud Infrastructure de la base de données principale, cliquez sur Connexion à la base de données pour télécharger le fichier wallet.zip de la base de données principale.

    2. Dans la console Oracle Cloud Infrastructure de la base de données de secours distante, cliquez sur Connexion à la base de données pour télécharger le fichier wallet.zip de la base de données de secours.

    3. Décompressez les deux fichiers de portefeuille et ouvrez les deux fichiers tnsnames.ora.

    4. Copiez le descripteur de connexion de la base de données distante dans la chaîne de connexion de la base de données principale dans le fichier tnsnames.ora de la base principale en utilisant les délais de nouvelle tentative de votre choix.

    5. Compressez le dossier de portefeuille de la base de données principale mise à jour.

    Avec cette mise à jour tnsnames.ora, les chaînes de connexion à la base de données principale dans la mise à jour wallet.zip contiendront les noms d'hôte principal et de secours afin de prendre en charge le basculement. Une application utilisant le "wallet" mis à jour tente de se connecter au premier nom d'hôte de base de données répertorié, et si cette connexion échoue en raison de l'indisponibilité de la base de données, l'application tente automatiquement de se connecter au deuxième nom d'hôte de base de données.

    Par exemple, si Autonomous Data Guard est configuré avec la base de données principale dans Ashburn (IAD) et une base de données de secours inter-région dans Phoenix (PHX), Oracle recommande que vos applications de niveau intermédiaire s'exécutent dans IAD utilise la chaîne de connexion ou le portefeuille de la base de données principale dans IAD, et les applications correspondantes exécutées dans PHX utilisent la chaîne de connexion ou le portefeuille de la base de données de secours dans PHX. Pour un basculement ou une permutation régional, Oracle recommande de basculer à la fois votre base de données et votre application ou niveau intermédiaire, afin d'obtenir des performances optimales et de minimiser toute latence interrégionale.

    Exemple :

    a6gxf2example9ep_high = (description_list= 
         (failover=on) (load_balance=off) 
         (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))) 
         (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-phoenix-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))))
    
    a6gxf2example9ep_low = 
         (description_list= (failover=on) (load_balance=off) 
         (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))) 
         (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-phoenix-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))))
    
    a6gxf2example9ep_medium = 
         (description_list= (failover=on) (load_balance=off) 
         (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))) 
         (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.us-phoenix-1.oraclecloud.com))(connect_data=(service_name=mqssyowmexample_a6gxf2example9ep_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes))))