Configuration d'une solution de récupération après sinistre avec Oracle Autonomous Database

Pour assurer la continuité des activités en cas de sinistre, vous devez implémenter une stratégie de récupération après sinistre pour vos applications Oracle WebLogic Suite. Cette solution assure la protection des données et vous permet d'utiliser Oracle Autonomous Database pour basculer rapidement vers le système de secours avec un minimum de perte de données et de productivité.

Vous pouvez configurer et gérer un système de récupération après sinistre qui utilise Oracle Autonomous Database en tant que base de données pour Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace ou tout autre service Oracle Cloud Infrastructure (OCI) de niveau intermédiaire qui utilise Oracle Fusion Middleware.

Oracle Autonomous Database Serverless et Oracle Exadata Database Service on Dedicated Infrastructure fournissent une fonctionnalité de secours instantanée. Cela vous permet d'ouvrir temporairement la base de données de secours pour la lecture-écriture. Lorsque vous convertissez la base de données de secours en base de données de secours cliché, elle peut être entièrement mise à jour. Il continue à recevoir les données redo de sa base de données source distante (de sorte que vous êtes toujours protégé par la récupération après sinistre), mais il n'applique pas redo tant qu'il n'est pas reconverti en base de données de secours physique. Toutes les modifications effectuées dans une base de secours instantanée sont rétablies lorsqu'elle est à nouveau convertie en base de secours physique. Utilisez cette fonctionnalité pour provisionner le système de niveau intermédiaire dans la région de secours. Vous pouvez également utiliser cette fonctionnalité pendant le cycle de vie de votre système de récupération après sinistre pour valider le système de secours sans effectuer de permutation complète.

Outre la fonctionnalité de base de données de secours instantanée, Oracle Autonomous Database Serverless fournit des clones actualisables distants. Cela fournit des fonctionnalités équivalentes à la fonctionnalité traditionnelle de base de données de secours cliché Oracle Data Guard, mais en utilisant une base de données supplémentaire. Le clone actualisable distant est géré individuellement et séparément de la base de données de secours Oracle Autonomous Data Guard. Lorsque vous utilisez Oracle Autonomous Database Serverless, vous pouvez utiliser un clone actualisable distant au lieu d'une base de données de secours cliché pour provisionner le système de niveau intermédiaire dans la région secondaire, ou pour effectuer des tâches dans la base de données de secours telles que les tests, l'ouverture pour les validations, l'application de patches, etc. Toutefois, les bases de données clone de secours et actualisables utilisent des portefeuilles de connexion différents et leurs chaînes de connexion doivent être gérées correctement pour effectuer ces tâches.

Avant de commencer

Plusieurs présentations techniques d'Oracle Maximum Availability Architecture (MAA) expliquent comment configurer un système de récupération après sinistre pour Oracle WebLogic Server for Oracle Cloud Infrastructure et Oracle SOA Suite on Marketplace lorsque ces systèmes middleware utilisent Oracle Base Database Service.

Les topologies de récupération après sinistre Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace et Oracle Fusion Middleware utilisent un modèle actif-passif. Le système principal est un centre de données Oracle Cloud Infrastructure (OCI) et un système secondaire dans un centre de données OCI différent et distant.

Pour plus de détails et de topologies, consultez les éléments suivants pour chaque cas :

Les documents ci-dessus fournissent des informations détaillées, des étapes de configuration et de gestion, ainsi que de nombreux autres éléments à prendre en compte pour Oracle WebLogic Server for Oracle Cloud Infrastructure et Oracle SOA Suite on Marketplace.

En plus des présentations techniques, assurez-vous que vous connaissez bien les concepts et l'administration d'Oracle Cloud Infrastructure (OCI), notamment la mise en réseau, les instances de calcul, l'équilibrage de charge et Oracle Autonomous Database, avant de passer à l'analyse et aux étapes décrites dans ce livre de jeux.

Les étapes et exemples de ce guide sont vérifiés avec Oracle WebLogic Server pour OCI et Oracle SOA Suite on Marketplace pour les scénarios suivants :

Oracle Autonomous Data Guard sur Oracle Exadata Database Service on Dedicated Infrastructure, à l'aide de la fonctionnalité Base de données de secours instantanée pour la configuration de la récupération après sinistre.
Oracle Autonomous Data Guard sur Oracle Autonomous Database Serverless, à l'aide de la fonctionnalité Base de données de secours instantanée pour la configuration de la récupération après sinistre.
Oracle Autonomous Data Guard sur Oracle Autonomous Database Serverless, à l'aide de clones actualisables distants pour la configuration de la récupération après sinistre.

La plupart des étapes sont communes aux trois scénarios. Seules certaines étapes diffèrent et sont spécifiques à chaque cas.

Il ne devrait pas être difficile d'ajuster les étapes à un système Oracle WebLogic Server ou Oracle Fusion Middleware qui utilise Oracle Autonomous Database.

Architecture

Ce diagramme d'architecture présente la topologie du système de récupération après sinistre pour les approches utilisées dans ce livre de jeux. Toutes les informations d'exécution, de configuration et de métadonnées résidant dans la base de données principale sont répliquées de la région 1 vers la région 2 avec Oracle Autonomous Data Guard. Les topologies de récupération après sinistre Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace et Oracle Fusion Middleware utilisent un modèle actif-passif. Le système principal est un centre de données Oracle Cloud Infrastructure (OCI) et un système secondaire dans un centre de données OCI différent et distant.

La configuration de domaine Oracle WebLogic est répliquée à l'aide d'un répertoire intermédiaire Oracle Cloud Infrastructure File Storage (OCI File Storage) dans la région principale, qui est répliquée vers un répertoire intermédiaire OCI File Storage dans la région secondaire. Ensuite, la configuration est copiée dans le répertoire du domaine réel dans le domaine secondaire. La copie directe du domaine présente des risques évités à l'aide d'un répertoire intermédiaire. Les copies de fichier étant une opération non transactionnelle, une première copie vers un répertoire intermédiaire est effectuée. Les fichiers sont d'abord vérifiés dans ce répertoire intermédiaire, puis transférés vers le domaine Oracle WebLogic réel (final).

Description de l'illustration wls-dr-adb.png

wls-dr-adb-oracle.zip

La topologie est typique des éléments utilisés par les environnements de récupération après sinistre d'Oracle WebLogic Server, d'Oracle SOA ou d'Oracle Fusion Middleware dans OCI. Pour le provisionnement du niveau intermédiaire de secours et des opérations de cycle de vie telles que le test secondaire, vous convertissez Oracle Autonomous Database de secours en base de données de secours cliché ou utilisez un clone actualisable à distance.

Lors de l'utilisation d'un clone actualisable à distance, il existe une "base de données auxiliaire" (clone actualisable dans une région distante) pour le provisionnement initial et les opérations de test et de validation dans le secondaire. Dans ce cas, le niveau intermédiaire secondaire est configuré avec des sources de données qui doivent être rétablies à l'adresse de secours lors des événements de permutation et de basculement.

Cette architecture prend en charge les composants suivants :

Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient des centres de données, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres et de grandes distances peuvent les séparer (dans des pays voire des continents).
Domaine de disponibilité
Les domaines de disponibilité sont des centres de données autonomes indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées de celles des autres, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent ni infrastructure (par exemple, alimentation, système de refroidissement), ni réseau de domaine de disponibilité interne. Par conséquent, une panne sur un domaine de disponibilité ne doit pas affecter les autres domaines de disponibilité de la région.
Domaine de pannes
Un domaine de pannes est un regroupement de matériel et d'infrastructures au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines de pannes avec une alimentation et un matériel indépendants. Lorsque vous distribuez des ressources sur plusieurs domaines de pannes, vos applications peuvent tolérer les pannes de serveur physique, de maintenance du système et d'alimentation au sein d'un domaine de pannes.
Réseau cloud virtuel (VCN) et sous-réseau
Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux de centres de données traditionnels, les réseaux cloud virtuels vous donnent un contrôle total sur votre environnement réseau. Un VCN peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, qui peuvent être ciblés vers une région ou un domaine de disponibilité. Chaque sous-réseau se compose d'une plage contiguë d'adresses qui ne chevauchent pas les autres sous-réseaux du VCN. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
Programme d'équilibrage de charge
Le service Oracle Cloud Infrastructure Load Balancing fournit une répartition de trafic automatisée à partir d'un point d'entrée unique vers plusieurs serveurs du back-end.
Domaine Oracle WebLogic
Un domaine est l'unité d'administration de base pour les instances de serveur WebLogic. Un domaine comprend une ou plusieurs instances de serveur WebLogic (et les ressources associées) que vous gérez dans un seul serveur d'administration. Le domaine Oracle WebLogic est configuré conformément aux meilleures pratiques Oracle Maximum Availability Architecture (MAA) en matière de haute disponibilité.
Dynamic routing gateway (DRG)
Le DRG est un routeur virtuel qui fournit un chemin pour le trafic réseau privé entre les réseaux cloud virtuels de la même région, entre un VCN et un réseau en dehors de la région, tel qu'un VCN dans une autre région Oracle Cloud Infrastructure, un réseau sur site ou un réseau dans un autre fournisseur cloud.
Liste de sécurité
Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui indiquent la source, la destination et le type de trafic qui doivent être autorisés vers et depuis le sous-réseau.
Oracle Cloud Infrastructure File Storage
Le service Oracle Cloud Infrastructure File Storage offre un système de fichiers réseau durable, évolutif, sécurisé et adapté à l'entreprise. Vous pouvez vous connecter à un système de fichiers du service File Storage à partir de n'importe quelle instance Bare Metal, de machine virtuelle ou de conteneur dans votre réseau cloud virtuel (VCN). Le service File Storage prend en charge le protocole (NFSv3) Network File System version 3.0. Le service prend en charge le protocole NLM (Network Lock Manager) pour la fonctionnalité de verrouillage de fichier.

Oracle Cloud Infrastructure File Storage utilise un stockage répliqué dans 5 directions, dans différents domaines de pannes, pour assurer une redondance résiliente la protection des données. Les données sont protégées par un codage d'effacement. Le service est conçu pour répondre aux besoins des applications et utilisateurs qui ont besoin d'un système de fichiers d'entreprise dans de nombreux cas d'emploi.
Autonomous Database
Oracle Autonomous Database est un environnement de base de données entièrement géré et préconfiguré que vous pouvez utiliser pour le traitement des transactions et l'entreposage de données. Vous n'avez pas besoin de configurer ou de gérer du matériel, ni d'installer un logiciel. Oracle Cloud Infrastructure gère la création de la base de données, ainsi que la sauvegarde, l'application de patches, la mise à niveau et le réglage de la base de données.
Oracle Autonomous Database sur une infrastructure Exadata dédiée
Oracle Autonomous Database on Dedicated Exadata Infrastructure est un Oracle Autonomous Database avec un cloud de base de données privé dans le cloud public. Avec votre base de données dédiée, vous bénéficiez d'un service de calcul, de stockage, de réseau et de base de données entièrement dédié qui vous assure des niveaux de sécurité, d'isolement et de gouvernance maximaux.
Oracle Autonomous Database sans serveur

Oracle Autonomous Database Serverless est une instance Oracle Autonomous Database. Vous disposez d'une base de données entièrement élastique, sur laquelle Oracle exploite en autonomie tous les aspects du cycle de vie de la base de données, du positionnement à la sauvegarde et aux mises à jour.
Data Guard
Oracle Data Guard fournit un ensemble complet de services permettant de créer, de maintenir, de gérer et de surveiller des bases de données de secours pour permettre aux bases de données Oracle de production de rester disponibles sans interruption. Oracle Data Guard conserve ces bases de données de secours en tant que copies de la base de données de production. Ensuite, si la base de données de production devient indisponible en raison d'une panne planifiée ou non planifiée, Oracle Data Guard peut basculer n'importe quelle base de données de secours vers le rôle de production, ce qui réduit le temps d'arrêt associé à la panne.
Oracle Autonomous Data Guard
Oracle Autonomous Data Guard permet à une base de données de secours (homologue) de fournir la protection des données et la récupération après sinistre de votre instance Autonomous Database. Il fournit un ensemble complet de services permettant de créer, de maintenir, de gérer et de surveiller des bases de données de secours pour permettre aux bases de données Oracle de production de rester disponibles sans interruption. Oracle Data Guard conserve ces bases de données de secours en tant que copies de la base de données de production. Ensuite, si la base de données de production devient indisponible en raison d'une coupure planifiée ou non planifiée, vous pouvez basculer n'importe quelle base de données de secours vers le rôle de production, en minimisant le temps d'arrêt associé à la coupure.
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 par la conversion d'une base de données de secours physique en une base de données de secours cliché.

Une base de données de secours instantanée reçoit et archive, mais ne s'applique pas, les données redo d'une base de données principale. Les données redo reçues de la base de données principale sont appliquées une fois qu'une base de données de secours instantanée est reconvertie en base de données de secours physique, après avoir supprimé toutes les mises à jour locales de la base de données de secours instantanée.
Clone pouvant faire l'objet d'une régénération
Oracle Autonomous Database fournit des options de clonage vous permettant de créer un clone complet de l'instance active, un clone de métadonnées ou un clone actualisable. Avec un clone actualisable, le système crée un clone qui peut être facilement mis à jour avec les modifications apportées à la base de données source.

Remarques concernant le niveau intermédiaire

Tous les éléments à prendre en compte dans Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery et SOA Suite on Oracle Cloud Infrastructure Marketplace Disaster Recovery pour le niveau intermédiaire sont applicables dans les scénarios Oracle Autonomous Database décrits dans ce document.

Tenez compte des aspects suivants pour le niveau intermédiaire :

Adresse frontale
L'accès des clients au système Oracle WebLogic Server doit être indépendant du site utilisé comme site principal. Pour cela, le nom d'adresse frontale utilisé pour accéder au système doit être unique et pointer toujours vers le système qui est le système principal pour le moment. Ce nom est généralement appelé URL frontale virtuelle ou URL personnalisée.

Vous pouvez réutiliser l'adresse du nom d'hôte frontal du système existant en tant que système frontal virtuel pour la protection contre les sinistres. Par exemple, si le système d'origine dispose de mywebapps.example.com en tant qu'URL personnalisée pour le système principal, vous pouvez mettre à nouveau en correspondance le même nom d'hôte virtuel avec l'adresse IP de l'équilibreur de charge du deuxième site après une permutation ou un basculement.

Utilisez un service DNS (Domain Name System) approprié pour le nom frontal à mettre en correspondance avec l'un ou l'autre site. Par exemple, (service Oracle Cloud Infrastructure DNS, autre DNS commercial, DNS local ou résolution d'hôtes locaux).
Préfixe de nom d'instance
Indiquez Instance Name Prefix lorsque vous provisionnez Oracle WebLogic Server pour OCI ou Oracle SOA Suite on Marketplace. Cette propriété permet de construire les noms de toutes les ressources, notamment le nom de domaine du serveur WebLogic, le nom de cluster, les noms de serveur WebLogic, les noms d'hôte de la machine virtuelle, etc.

Définissez Instance Name Prefix sur la même valeur dans les systèmes Oracle WebLogic Server principal et secondaire, de sorte que les deux systèmes portent le même nom pour les ressources Oracle WebLogic. L'utilisation du même nom garantit la cohérence et est requise pour la récupération des messages JMS et TLogs. Il simplifie également les personnalisations et les opérations sur les deux sites.

Vous pouvez utiliser le même élément Instance Name Prefix dans plusieurs instances de la même location Oracle Cloud, à condition de les créer dans différentes régions ou compartiments. Chaque instance est uniquement affichée dans sa région et son compartiment spécifiques.

Le processus de provisionnement d'Oracle SOA Suite on Marketplace fournit une fonctionnalité facultative qui vous permet de configurer des noms personnalisés pour le domaine, le cluster, le serveur d'administration, le préfixe du serveur géré, etc. Dans ce cas, les noms ne sont pas dérivés de Instance Name Prefix. Elles prennent les valeurs fournies à la place. Il est possible d'utiliser cette fonctionnalité dans la topologie de récupération après sinistre décrite dans ce document, tant que les noms personnalisés fournis sont les mêmes dans les systèmes principal et de secours.
Fichiers personnalisés
La plupart de la configuration de domaine Oracle WebLogic Server for OCI utilisée par WebLogic Cloud est synchronisée initialement entre les sites en tenant compte des points suivants :

Chaque système WebLogic conserve les URL JDBC d'origine utilisées pour se connecter à sa base de données locale, même une fois la configuration de la récupération après sinistre terminée. Seul le préfixe de schéma est modifié de sorte que les deux emplacements pointent vers les mêmes schémas (schémas principaux).

La fonctionnalité Infrastructure de domaine WebLogic distribue automatiquement la configuration sous le répertoire weblogic_domain_name/config aux autres noeuds du même domaine.

Les déploiements d'application personnalisés (fichiers d'avance/de guerre, plans de déploiement, etc.) et tout ce qui se trouve sous le répertoire de domaine Oracle WebLogic Administration Server (à l'exception des données temporaires) sont initialement synchronisés entre les sites à l'aide des procédures décrites dans ce document. Si Oracle WebLogic Administration Server utilise des données résidant dans d'autres noeuds ou en dehors du répertoire de domaine, vous devez les copier manuellement vers l'emplacement secondaire. Des détails supplémentaires sur la réplication de la configuration sont fournis ultérieurement.

Remarques concernant la base de données de secours instantanée sur Oracle Autonomous Database Serverless

Lors de l'implémentation de cette solution, tenez compte des points suivants lors de l'activation de la base de données de secours instantanée sur une base de données Oracle Autonomous Database Serverless.

Limite de temps pour la base de données de secours instantanée dans une infrastructure sans serveur
Lorsqu'une base de données de secours cliché dans Oracle Autonomous Database Serverless n'est pas reconnectée dans les 48 heures, la base de données de secours cliché se reconnecte automatiquement à la base de données source.
Retour au pair de récupération après sinistre
Oracle recommande de reconvertir une base de données de secours instantanée en un pair de récupération après sinistre dès que vous avez terminé avec les opérations qui nécessitaient que la base de données de secours soit ouverte pour les opérations de lecture-écriture. Lorsque vous effectuez une reconversion vers un pair de récupération après sinistre, les modifications cumulées de la base de données source sont appliquées au pair. Si vous laissez le pair de récupération après sinistre ouvert en tant que base de données de secours d'instantané pendant une période plus longue, en supposant que des modifications sont en cours sur la base de données principale pendant cette période, la conversion en pair de récupération après sinistre prend plus de temps.
Implications sur les coûts de la base de données de secours cliché dans Oracle Autonomous Database Serverless
L'utilisation de l'UC de secours instantanée est facturée en fonction du nombre d'UC de base et de toute utilisation supplémentaire de l'UC si le redimensionnement automatique de calcul est activé. Le nombre d'UC de base est indiqué par le nombre d'UC de base (OCPU si votre base de données utilise des OCPU), comme indiqué dans le champ Nombre d'UC ou Nombre d'OCPU de la console Oracle Cloud Infrastructure.

L'utilisation du stockage de secours cliché est facturée en fonction du stockage de la base de données de secours instantanée plus 1 fois le stockage de la base de données principale source.

Pour plus de détails, reportez-vous à A propos des bases de données de secours cliché de récupération après sinistre.

Remarques concernant la base de données de secours instantanée sur Oracle Autonomous Database on Dedicated Exadata Infrastructure

Lors de l'implémentation de cette solution, tenez compte des points suivants lors de l'activation d'une base de données de secours instantanée sur une instance Oracle Autonomous Database on Dedicated Exadata Infrastructure.

Limite de temps pour la base de données de secours instantanée dans une infrastructure dédiée
Lorsqu'une base de données de secours cliché dans Oracle Autonomous Database on Dedicated Exadata Infrastructure n'est pas convertie en base de données de secours physique dans les 7 jours, la base de données de secours cliché est automatiquement convertie en base de données de secours physique.
Restauration d'une base de données de secours physique
Oracle recommande de reconvertir une base de données de secours instantanée en base de données de secours physique dès que vous avez terminé les opérations qui nécessitent que la base de données de secours soit ouverte pour les opérations de lecture-écriture. Lorsque vous rétablissez la base de données de secours physique, les modifications cumulées de la base de données source sont appliquées à la base de données de secours. Si vous laissez la base de données de secours ouverte en tant que base de données de secours instantanée pendant une période plus longue, en supposant que des modifications sont en cours sur la base principale pendant cette période, la conversion en base de données de secours physique prend plus de temps.
Services de base de données lors de la conversion en base de données de secours instantanée
Dans Oracle Autonomous Database on Dedicated Exadata Infrastructure, la boîte de dialogue Convertir en base de données de secours cliché affiche deux options :
- Utiliser les nouveaux services de base de données : sélectionnez cette option pour vous connecter à une base de données de secours cliché à l'aide des nouveaux services actifs uniquement en mode Base de données de secours cliché.
- Utiliser les services de base de données principale : sélectionnez cette option si vous souhaitez vous connecter à la base de données de secours cliché à l'aide des mêmes services que la base de données principale.
Pour la configuration de la récupération après sinistre, utilisez l'option Utiliser les services de base de données principale lorsque vous convertissez la base de données de secours en base de données de secours physique. Ainsi, le nom d'alias de connexion configuré par Oracle WebLogic Server dans le niveau intermédiaire secondaire est cohérent avec le nom principal.

Pour plus de détails, reportez-vous à A propos d'Autonomous Data Guard.

Remarques concernant les clones actualisables à distance sur Oracle Autonomous Database Serverless

Tenez compte des points suivants lorsque vous utilisez un clone actualisable Oracle Autonomous Database Serverless pour tester et valider un système Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace ou Oracle Fusion Middleware secondaire.

Cycle de vie des clones actualisables
Contrairement à une base de secours Oracle Data Guard classique, les clones actualisables à distance sont activés séparément et gérés séparément d'une base de données principale et d'une base de données de secours. Il s'agit d'une entité distincte avec son propre cycle de vie au-delà des opérations d'actualisation qui la synchronisent avec sa base de données source (principale).
Allocation des ressources UC
Les clones actualisables à distance ne sont pas créés en fonction de l'allocation des ressources CPU du système principal ou de secours. Cela signifie que vous devez spécifier les options d'OCPU pour le clone actualisable séparément. Vous devez configurer manuellement les tests de charge globale sur le clone actualisable distant pour qu'ils correspondent à la capacité du système principal. Dans l'idéal, vous devez créer le clone actualisable distant avec une configuration correspondant à la base de données principale afin que les charges globales de test soient réalistes sur le secondaire. Cependant, les clones actualisables distants "transfèrent" la configuration de stockage utilisée dans le serveur principal.
Application de patches
Les patches sont automatiquement appliqués chaque semaine sur Oracle Autonomous Database Serverless, selon la fenêtre de maintenance hebdomadaire. Il existe donc une synchronisation continue et forcée des patches entre le clone actualisable principal, de secours et distant.
Limites de service
Les clones actualisables à distance sont une entité de première classe. Ils entraînent des coûts supplémentaires en fonction des implications en matière de stockage, d'UC et de licence d'une instance Autonomous Database formelle et sont pris en compte dans les limites de service de la région pour Oracle Autonomous Database Serverless.
Clone actualisable lors de la permutation
Lorsqu'un basculement ou une permutation non immédiatement réversible a lieu, vous devez créer manuellement un clone actualisable sur le serveur principal pour que le système reste prêt pour les opérations de test et de maintenance dans le système secondaire, avec les limites de service, la gestion et d'autres considérations appropriées. Les clones actualisables à distance ne disposent pas du contrôle d'annulation de rôle.

Après une permutation vers le clone secondaire, le clone actualisable créé ne peut plus être actualisé (car sa source est maintenant une base de données de secours) et est marqué comme déconnecté. Après 24 heures, il devient un clone non actualisable et déconnecté.
Fenêtre d'actualisation des clones actualisables
Les clones actualisables à distance doivent être actualisés au moins une fois par semaine. Ensuite, pour être synchronisé avec les données principales, vous devez créer un clone actualisable distant et annuler le clone non actualisé.
Mode d'écriture Clones actualisables
Les clones actualisables distants ne peuvent pas rester en mode écriture (déconnexion de la base principale) pendant plus de 24 heures. Après cette période, la base de données distante des clones actualisables ne peut plus être connectée à sa base principale. Ensuite, pour être synchronisé avec les données de la base principale, vous devez créer un clone actualisable à distance et annuler le clone non actualisé.

Remarques concernant l'emplacement du dossier de configuration `tns_admin`

Tenez compte des points suivants pour le dossier de configuration tns_admin.

Utiliser un emplacement cohérent pour le dossier tns_admin
Les niveaux intermédiaires d'un domaine WebLogic utilisent un dossier pour stocker le portefeuille Oracle Autonomous Database et le fichier tnsnames.ora. La propriété oracle.net.tns_admin pointe vers ce dossier dans les sources de données et les fichiers de configuration JPS. Le chemin de ce dossier doit être le même dans les niveaux intermédiaires principal et de secours. Si le chemin du dossier est différent, modifiez le dossier en tant que dossier principal ou de secours afin qu'il utilise le même dossier avant d'exécuter les scripts de configuration de récupération après sinistre.
Remarque :
Les éléments suivants peuvent entraîner des différences entre l'emplacement principal et l'emplacement de secours dans ce dossier :
- Les instances Oracle SOA Suite on Marketplace provisionnées avant la fin de février 2023 (avant la version 23.1.1) utilisent $DOMAIN_HOME/config/atp pour le dossier tns_admin. A partir de la version 23.1.1, l'emplacement est $DOMAIN_HOME/config/tnsadmin.
Dossier tns_admin sous le dossier config du domaine
Vérifiez l'emplacement du portefeuille Oracle Autonomous Database dans la configuration de source de données WebLogic. Si le portefeuille n'est pas situé sous le répertoire DOMAIN_HOME/config, les modifications apportées au contenu du répertoire de portefeuille NE seront PAS répliquées automatiquement par l'infrastructure Oracle WebLogic Server vers d'autres noeuds. Dans ce cas, vous devez modifier le répertoire du portefeuille (et mettre à jour les configurations de sources de données requises) ou le copier manuellement vers d'autres noeuds lors de sa mise à jour.