Options de reprise après sinistre pour les charges de travail des bases de données Oracle
Ce guide décrit les options de reprise après sinistre disponibles pour les utilisateurs qui exécutent des charges de travail de base de données Oracle critiques dans un environnement solution Bare Metal.
Ce guide suppose que vous exécutez Oracle Enterprise Edition. Certaines des fonctionnalités décrites dans ce guide sont concédées sous licence distincte de la licence Enterprise Edition. Voici quelques exemples de fonctionnalités disponibles (liste non exhaustive) :
- Oracle Real Application Clusters
- Oracle Active Data Guard
- Oracle Advanced Compression
- Oracle GoldenGate
Consultez vos contrats de licence Oracle pour déterminer les fonctionnalités que vous êtes autorisé à utiliser lorsque vous planifiez la reprise après sinistre et la haute disponibilité.
RTO et RPO de l'application
La reprise après sinistre pour les technologies de base de données Oracle doit être déterminée en fonction de l'objectif de temps de récupération (RTO) et de l'objectif de point de récupération (RPO) d'une application. En général, le RTO décrit la durée d'arrêt acceptable pour un système, et le RPO décrit la quantité de perte de données acceptable. Le coût et la complexité d'un système augmentent à mesure que chacune de ces valeurs diminue. Pour en savoir plus sur le RTO et le RPO, consultez la section Principes de base d'un plan de reprise après sinistre.
Les architectures libellées "RPO = 0" ou "aucune perte de données" nécessitent que les données soient écrites à plusieurs endroits avant d'être considérées comme "committées" dans la base de données. La latence devient un problème lorsque le RPO se rapproche de zéro.
Si elle n'est pas correctement prise en compte lors de la phase de conception, l'implémentation d'une architecture sans perte de données peut avoir des effets négatifs sur les performances globales de l'application.
Haute disponibilité par rapport à la reprise après sinistre
La haute disponibilité et la reprise après sinistre sont des concepts complémentaires lors de la conception d'architectures de base de données fiables. Dans le contexte de ce guide, la haute disponibilité désigne la capacité d'un système à se rétablir automatiquement en cas de défaillances individuelles ou en cascade. En revanche, la reprise après sinistre fait partie d'un plan de continuité d'activité global et s'applique aux défaillances plus importantes qui peuvent rendre des groupes entiers de systèmes indisponibles. La reprise après sinistre couvre un champ d'application plus large en raison du nombre de composants intégrés qui doivent être récupérés en cas de sinistre.
La haute disponibilité doit être considérée comme la "première ligne de défense" lors de la conception d'un système fiable. Une architecture de base de données disponibilité élevée doit pouvoir faire face aux défaillances individuelles et continuer à s'exécuter sans entraîner de temps d'arrêt pour l'application. Les composants de haute disponibilité d'un système doivent inclure, mais sans s'y limiter, les éléments suivants:
- Alimentation redondante sur le serveur, le réseau ou le matériel de stockage
- Plusieurs interfaces réseau, commutateurs et câbles
- Des fabrics, des contrôleurs et des dispositifs de stockage redondants
- Interconnexions partenaires tolérantes aux pannes entre Google Cloud et l'extension de région de la solution Bare Metal
- Oracle RAC pour éviter que les défaillances du serveur ne désactivent une base de données
Une conception de reprise après sinistre doit inclure des processus permettant de récupérer après plusieurs défaillances en cascade qui rendent les composants indisponibles. La planification de la reprise après sinistre doit prendre en compte les éléments suivants:
- Pannes régionales
- Catastrophes naturelles
- Incidents entraînant l'indisponibilité totale d'un ou de plusieurs composants d'une application
Outils Oracle de reprise après sinistre et de haute disponibilité
Voici quelques outils Oracle de reprise après sinistre et de haute disponibilité:
- Oracle Real Application Clusters
- Oracle Recovery Manager
- Oracle Data Guard
- Base de données Flashback
- Oracle GoldenGate
Oracle Real Application Clusters
Oracle Real Application Clusters (RAC) permet de faire évoluer horizontalement les charges de travail de base de données pour qu'elles soient gérées par plusieurs serveurs de base de données. Les bases de données qui utilisent RAC permettent une configuration active/active entre les serveurs d'une extension de région.
RAC est généralement utilisé pour assurer une haute disponibilité aux systèmes qui doivent se protéger contre la défaillance d'un seul serveur. En raison de l'approche "tout partagé" (stockage et réseaux partagés) du clustering, un cluster RAC exécuté dans un environnement de solution Bare Metal doit exister dans un seul pod de solution Bare Metal. RAC est donc une solution aux problèmes de haute disponibilité, mais ne répond pas aux exigences de reprise après sinistre.
Pour découvrir comment configurer RAC pour la solution Bare Metal, consultez la section Installer Oracle RAC sur une solution Bare Metal.
Gestionnaire de récupération de données Oracle
Oracle Recovery Manager (RMAN) est l'outil principal de sauvegarde et de récupération des bases de données Oracle, car il peut lire le format de fichier de données propriétaire d'Oracle. Il peut être utilisé pour effectuer des clones de base de données, une récupération à un moment précis ou même la récupération d'une seule table dans une base de données Oracle.
RMAN est le seul outil qui permet de créer des sauvegardes lorsque la base de données est ouverte. Il permet également de gérer le catalogue des fichiers de sauvegarde disponibles pour la récupération.
Oracle Data Guard
Oracle Data Guard effectue la réplication de la base de données vers des clusters RAC distants ou d'autres installations de base de données. Data Guard est compatible avec les bases de données de secours dans une configuration physique ou logique.
Les bases de données de secours physiques sont des copies bloc par bloc qui permettent d'ouvrir une copie de la base de données en écriture. Toutes les autres sont montées (mais pas ouvertes) pour appliquer les modifications ou ouvertes en lecture seule pour prendre en charge les applications de création de rapports.
Pour découvrir comment configurer Data Guard sur la solution Bare Metal, consultez la section Déployer Oracle Data Guard sur la solution Bare Metal.
FLASHBACK DATABASE
La fonctionnalité FLASHBACK DATABASE d'Oracle Enterprise Edition permet aux administrateurs de revenir rapidement à un point spécifique dans le temps d'une base de données sans avoir à effectuer de restaurations de base de données fastidieuses.
Dans le contexte de la reprise après sinistre, FLASHBACK DATABASE est couramment utilisé avec Data Guard lors des opérations de basculement pour une restauration plus rapide de la base de données. La base de données défaillante est flashée à un moment précis qui est cohérent avec les journaux de la nouvelle instance principale, et la relecture est envoyée afin qu'elle puisse se resynchroniser complètement.
Oracle GoldenGate
Oracle GoldenGate est un outil de réplication logique couramment utilisé pour permettre des déploiements multisites actifs/actifs ou pour déplacer des données entre des plates-formes matérielles. Lorsque vous utilisez GoldenGate, un processus extract sur la base de données source capture les modifications dans les journaux de rétablissement en ligne et les écrit dans les fichiers de trace, qui sont transportés vers la base de données cible. Un processus replicat sur la base de données cible convertit les transactions des fichiers de fin en SQL, puis exécute le code SQL sur la base de données cible.
Cette architecture fait de GoldenGate un outil puissant pour déplacer des données entre des plates-formes de base de données ou transformer des données lors de leur réplication. Contrairement à Data Guard, GoldenGate nécessite l'installation et la maintenance d'un logiciel distinct sur les systèmes source et cible. GoldenGate ne peut pas être utilisé pour la réplication synchrone, car les transactions sont traduites et appliquées en tant que SQL sur la base de données cible. Bien que GoldenGate puisse fournir un temps de latence minimal pour la réplication, il ne peut pas garantir un RPO de zéro.
Modèles de déploiement de reprise après sinistre (base de données uniquement)
Oracle a créé le framework d'architecture de disponibilité maximale (MAA, Maximum Availability Architecture) pour vous fournir des modèles de reprise après sinistre recommandés pour le déploiement de vos applications et bases de données.
Chacun des modèles suivants fournit des cibles RTO et RPO spécifiques:
Les modèles sont mappés à des modèles de déploiement spécifiques qui répondent aux exigences de RPO et de RTO en cas d'indisponibilités planifiées et non planifiées. Chaque charge de travail de base de données doit être évaluée en fonction de ses exigences de disponibilité et conçue avec un modèle correspondant. Il est courant que les bases de données de développement utilisent un modèle avec un niveau de protection inférieur à celui de leurs homologues de production et d'assurance qualité.
Le modèle Bronze est destiné aux bases de données qui n'ont pas besoin d'un RTO mesuré en minutes. Les modèles Silver et supérieurs incluent des bases de données de secours exécutées sur un site distant. Chaque modèle intègre les fonctionnalités des modèles de niveau inférieur. Par exemple, le modèle Bronze utilise des concepts de sauvegarde et de récupération qui doivent toujours être suivis, même si une base de données de secours est déployée.
Modèle Copper
Le modèle Copper fournit un déploiement minimal pour sauvegarder les bases de données sur des supports de stockage locaux et les copier sur un stockage situé en dehors de l'extension de région. Ce déploiement nécessite une approche en deux étapes, mais peut être scripté pour utiliser Google Cloud SDK afin d'automatiser la transmission des sauvegardes.
L'utilisation de ce déploiement augmente également le RTO en raison de la récupération en deux étapes requise. RMAN ne peut pas accéder directement aux sauvegardes. Elles doivent donc être déplacées vers un emplacement accessible à RMAN avant que la récupération puisse commencer.
| Indisponibilité | Type d'indisponibilité | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance de nœud ou d'instance récupérable | 0 | Temps nécessaire pour redémarrer l'instance |
| Catastrophes: corruptions | Dernière sauvegarde d'archivelog, incrémentielle ou complète transférée hors de la RE | Heures, en fonction de la taille de la base de données et de la bande passante attribuée à interconnexion partenaire | |
| Catastrophes: défaillances de l'extension de région | Dernière sauvegarde complète, incrémentielle ou archivelog transférée hors de la RE | Jours / semaines, selon le temps nécessaire pour remettre en ligne l'extension régionale | |
| Planifié | Correctifs de base de données, mises à jour de l'OS / du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures |
Modèle Bronze
Le modèle de bronze propose deux options de déploiement. Ils utilisent tous deux le stockage natifGoogle Cloudpour conserver les sauvegardes de la base de données.
Déploiement de niveau bronze 1: sauvegarde sur un stockage régional
Dans ce déploiement, les sauvegardes sont écrites directement sur des supports hors site. Dans la plupart des cas, la destination de sauvegarde privilégiée est Cloud Storage avec Cloud Storage FUSE, qui présente un bucket Cloud Storage comme un système de fichiers.
Vous trouverez les recommandations d'utilisation de Cloud Storage FUSE dans les sauvegardes Oracle avec NFS et Cloud Storage. Google Cloud Filestore, qui présente des partages NFS aux instances de la solution Bare Metal, peut également être utilisé.
Le schéma suivant illustre un exemple de déploiement.
| Indisponibilité | Type d'indisponibilité | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance de nœud ou d'instance récupérable | 0 | Temps nécessaire pour redémarrer l'instance |
| Catastrophes: corruptions | Dernière sauvegarde complète, incrémentielle ou archivelog | Heures, en fonction de la taille de la base de données et de la bande passante attribuée à interconnexion partenaire | |
| Catastrophes: défaillances de l'extension de région | Dernière sauvegarde complète, incrémentielle ou journal d'archivage | Jours / semaines, selon le temps nécessaire pour remettre la fonctionnalité en ligne | |
| Planifié | Correctifs de base de données, mises à jour de l'OS/du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures |
Déploiement de niveau bronze 2: sauvegarde à l'aide de Backup and DR
Dans ce déploiement, le service de sauvegarde et de reprise après sinistre permet de stocker des sauvegardes dansGoogle Cloud. La sauvegarde et la DR offrent une approche incrémentielle permanente pour les sauvegardes, qui sont stockées sur des supports hautes performances compatibles avec Cloud Storage pour une conservation à long terme.
La sauvegarde et la reprise après sinistre offrent également un temps de récupération plus rapide que le stockage de sauvegardes sur Filestore ou Cloud Storage, car elles peuvent mettre immédiatement les images des fichiers de base de données à la disposition de l'instance Oracle. La fonctionnalité d'installation et de migration met rapidement une base de données en ligne tout en la copiant sur le support de stockage de production, ce qui réduit considérablement le RTO.
Le schéma suivant illustre un exemple de déploiement.
| Indisponibilité | Type d'indisponibilité | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance de nœud ou d'instance récupérable | 0 | Temps nécessaire pour redémarrer l'instance
Secondes si vous utilisez RAC |
| Catastrophes: corruptions | Dernière sauvegarde complète, incrémentielle ou journal d'archivage | De quelques minutes à plusieurs heures, en fonction des exigences de performances, de la taille de la base de données et de la bande passante attribuée à l'interconnexion partenaire | |
| Catastrophes: défaillances de l'extension de région | Dernière sauvegarde complète, incrémentielle ou journal d'archivage | En jours ou en semaines, selon le temps nécessaire pour remettre en ligne l'extension de région ou la possibilité pour le client de passer à une autre extension de région. | |
| Planifié | Correctifs de base de données, mises à jour de l'OS / du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures |
Noir et blanc
Le modèle Silver introduit la réplication de base de données à l'aide d'Oracle Data Guard. Data Guard fournit une réplication de base de données en temps réel avec une ou plusieurs bases de données servant de base de données de secours. Étant donné que Data Guard s'appuie sur le transport et l'application des modifications de la base de données à mesure qu'elles se produisent, la RPO peut être proche de zéro. Le modèle Silver repose sur la réplication asynchrone. L'utilisation de la réplication synchrone garantit l'absence de perte de données, mais le temps nécessaire pour envoyer des données entre les régions dépasse généralement les limites acceptables du temps de réponse de l'application.
La fonctionnalité de basculement rapide de Data Guard peut effectuer des opérations de basculement automatique si une base de données principale devient indisponible pendant une période définie par l'utilisateur. La configuration est surveillée par un processus d'observateur Data Guard, qui peut s'exécuter.
Le modèle Silver présente l'avantage de s'assurer que la base de données est disponible en cas de défaillance régionale totale, mais les opérations de basculement et de transfert peuvent avoir un impact sur les performances de l'application à mesure que la latence réseau entre les serveurs d'application et la base de données augmente. Il est rarement recommandé d'exécuter des applications et des bases de données associées dans différentes régions. Bien que le RTO de la base de données puisse être inférieur à une minute, le basculement des applications peut prendre des minutes, voire des heures, avant que les services ne soient entièrement opérationnels. Dans la plupart des cas, l'exécution de plans de basculement de reprise après sinistre interrégionaux implique généralement des processus manuels en raison du nombre de composants déplacés.
Avec le modèle Silver, vous pouvez toujours avoir des temps d'arrêt ou des intervalles de maintenance lors des activités de mise à jour trimestrielles. L'introduction d'Oracle RAC peut réduire les temps d'arrêt en cas de correctif ou de défaillance du serveur.
Le schéma suivant illustre un exemple de configuration.
L'exemple de configuration du diagramme montre des bases de données RAC exécutées dans les régions us-west2 et us-east4. La réplication est configurée à l'aide de Data Guard asynchrone. Tout le trafic entre la solution Bare Metal et Google Cloudtransite par une interconnexion partenaire, et le trafic interrégional passe par le réseau principal de Google. Les serveurs d'applications sont configurés dans chaque région, mais ils sont généralement arrêtés dans la région de reprise après sinistre jusqu'à ce qu'un événement de basculement soit déclaré.
| Indisponibilité | Type d'indisponibilité | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance de nœud ou d'instance récupérable | 0 | Temps nécessaire pour redémarrer l'instance
Secondes si vous utilisez RAC |
| Catastrophes: corruptions | < 60 s | De quelques minutes à plusieurs heures, en fonction du basculement de l'application. | |
| Catastrophes: défaillances de l'extension de région | < 60 s | De quelques minutes à plusieurs heures, en fonction du basculement de l'application. | |
| Planifié | Correctifs de base de données, mises à jour de l'OS / du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance.
Secondes si vous utilisez RAC |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures
En minutes si vous utilisez |
Modèle Gold
Si vous êtes préoccupé par la perte de données dans le modèle Silver, vous pouvez opter pour le modèle Gold, qui utilise une instance de synchronisation à distance pour fournir une réplication synchrone à une instance exécutée dans Google CloudCompute Engine.
Une instance de synchronisation à distance inclut un fichier de contrôle de base de données et un ensemble de journaux de redo de secours qui s'exécutent géographiquement à proximité de la base de données principale. Cette instance est configurée pour recevoir le rétablissement de manière synchrone avec une faible latence, ce qui permet d'enregistrer toutes les modifications en dehors de l'extension de région de la base de données principale. L'instance de synchronisation à distance transfère ensuite la nouvelle exécution à la base de données de secours de la région distante pour l'appliquer de manière asynchrone.
Une instance de synchronisation à distance n'est pas une copie complète de la base de données et ne peut donc pas gérer le trafic de l'application. L'instance de synchronisation à distance permet de fournir un emplacement tolérant aux pannes pour que les modifications de la base de données soient écrites de manière synchrone, ce qui permet d'obtenir une solution sans perte de données. Lors de la réplication synchrone vers l'instance de synchronisation à distance, les transactions ne sont pas validées dans la base de données principale tant que les modifications n'ont pas été reçues et validées dans l'instance de synchronisation à distance.
Les instances Compute Engine sont généralement sélectionnées comme candidates pour héberger une instance de synchronisation à distance. Placer l'instance de synchronisation à distance dans une zone Compute Engine à proximité immédiate de la base de données principale ajoute une latence minimale (généralement inférieure à 1,5 ms) et protège contre les défaillances dans l'extension de région.
Le schéma suivant illustre un exemple de déploiement.
L'exemple de configuration du diagramme montre une base de données RAC principale exécutée dans us-west2 avec des applications exécutées dans Compute Engine. Une instance Compute Engine dans us-west2 exécute une instance de synchronisation à distance, qui reçoit une nouvelle exécution de manière synchrone. L'instance de synchronisation à distance est configurée pour envoyer de manière asynchrone des redo à une base de données RAC exécutée dans la région us-east4. Les instances d'application sont configurées dans la région us-east4 sur Compute Engine pour gérer le trafic des applications en cas de sinistre.
| Indisponibilité | Type d'indisponibilité | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance de nœud ou d'instance récupérable | 0 | Temps nécessaire pour redémarrer l'instance
Secondes si vous utilisez RAC |
| Catastrophes: corruptions | 0 | De quelques minutes à plusieurs heures, en fonction du basculement régional de l'application. | |
| Catastrophes: échecs de l'extension de région | 0 | De quelques minutes à plusieurs heures, en fonction du basculement régional de l'application. | |
| Planifié | Correctifs de base de données, mises à jour de l'OS / du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance.
Secondes si vous utilisez RAC |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures
En minutes si vous utilisez |
Modèle Platinum
Le modèle Platinum propose deux options de déploiement. Chaque option de déploiement offre une protection à l'aide d'une technologie différente et présente des caractéristiques de RTO et de RPO différentes.
Déploiement Platinum 1: Data Guard avec basculement rapide
Le déploiement Platinum 1 s'appuie sur le déploiement du modèle Gold en ajoutant une deuxième base de données de secours Data Guard dans la région locale qui s'exécute sur une instance Compute Engine. Cette configuration utilise la réplication synchrone entre la base de données principale et la base de données de secours exécutée dans Compute Engine, ce qui garantit l'absence de perte de données dans la région principale.
La création d'une base de données de secours dans la région permet de basculer et de basculer les bases de données sans affecter les applications. Lors des modifications de rôle de base de données, les applications configurées conformément aux considérations client d'Oracle se reconnectent automatiquement à la nouvelle base de données principale sans intervention manuelle. Les applications correctement configurées subissent moins de deux minutes d'indisponibilité lors d'un événement de basculement.
Bien que la base de données de secours dans Compute Engine n'exécute pas RAC, elle doit être dimensionnée pour prendre en charge le trafic d'application normal lorsqu'elle s'exécute en tant que base de données principale. Cette instance peut s'exécuter avec une forme plus petite lorsqu'elle fonctionne en mode veille et être mise à l'échelle lors des événements de basculement, ou s'exécuter à pleine capacité en permanence. La redimensionnement de l'instance lors d'un événement de basculement a un impact négatif sur le RTO, car l'instance doit être redémarrée pendant l'opération de redimensionnement.
Le basculement rapide est configuré sur une instance Compute Engine exécutant le courtier Data Guard avec un observateur. L'observateur exécute un client Oracle de base avec des connexions à toutes les bases de données principales et de secours. Si l'observateur détecte une défaillance dans la base de données principale, il déclenche un basculement vers l'une des bases de données de secours. La base de données de secours exécutée sur Compute Engine doit être configurée comme cible de basculement préférée lorsque vous utilisez le niveau Gold.
Oracle recommande de placer l'observateur dans une région distincte des bases de données principale et de secours. Cette approche offre la meilleure protection contre les défaillances régionales et les événements de partitionnement réseau. Si une troisième région n'est pas possible, l'observateur doit être installé dans la région principale, dans une zone différente de celle de la région de secours proche du site.
Le schéma suivant illustre un exemple de déploiement.
L'exemple de déploiement présenté dans le schéma se compose des éléments suivants:
- Une base de données principale exécutant RAC sur un serveur de solution Bare Metal dans la région
us-west2 - Une base de données de secours proche du site exécutée sur une instance Compute Engine dans la région
us-west2. - Une base de données de secours distante exécutée sur un serveur de solution Bare Metal dans la région
us-east4. - L'observateur Data Guard s'exécutant sur l'instance Compute Engine dans la région
us-central1.
La réplication synchrone est configurée pour la base de données de secours dans la région exécutée sur l'instance Compute Engine, et la réplication asynchrone est configurée pour la région distante. Dans chaque cas, le rétablissement est envoyé de la base de données principale à la base de données de secours. Il n'est pas transféré d'une base de données de secours à l'autre. L'observateur est configuré dans une troisième région et maintient la connectivité avec toutes les bases de données de la configuration. Les instances d'application sont configurées dans la région principale et se connectent à la base de données principale sur le serveur de solution Bare Metal (ou à la base de données sur l'instance Compute Engine lors des opérations de basculement et de transfert). Les instances d'application sont configurées dans la région us-east4 sur Compute Engine pour gérer le trafic des applications en cas de sinistre.
| Indisponibilité | Type d'indisponibilité | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance de nœud ou d'instance récupérable | 0 | Temps nécessaire pour redémarrer l'instance
Secondes si vous utilisez RAC |
| Catastrophes: corruptions | 0 | < 60 s | |
| Catastrophes: défaillances de l'extension de région | 0 | < 60 s | |
| Planifié | Correctifs de base de données, mises à jour de l'OS / du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance.
Secondes si vous utilisez RAC |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures
En minutes si vous utilisez |
Déploiement Platinum 2: GoldenGate pour la réplication
Le déploiement Platinum 2 repose sur Oracle GoldenGate pour la réplication. Étant donné que GoldenGate ne réplique pas au niveau des blocs. Il permet à chaque base de données de gérer les sessions d'application de lecture et d'écriture indépendamment. Il réplique les modifications de manière bidirectionnelle, ce qui permet une configuration de base de données active/active.
Les applications doivent être validées de manière approfondie avant de s'engager dans un déploiement actif/actif. Vous devez également tenir compte de la détection et de la résolution des conflits.
Contrairement à Data Guard, GoldenGate nécessite l'installation et la maintenance de logiciels supplémentaires sur les serveurs de base de données Oracle. Les déploiements actifs/actifs nécessitent généralement une conception de schéma et d'application sophistiquée pour tirer parti d'un déploiement de base de données multisite. De nombreuses applications préemballées ne sont pas compatibles avec ce type d'architecture.
Les déploiements qui dépendent de GoldenGate pour toute la réplication ne peuvent pas prendre en charge un RPO sans perte de données en raison de la nature asynchrone de la réplication logique. Vous pouvez déployer des bases de données de secours locales exécutées dans Compute Engine à l'aide de Data Guard pour obtenir un RPO de zéro avec une réplication synchrone.
Le schéma suivant illustre un exemple de déploiement.
| Indisponibilité | Type d'indisponibilité | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance de nœud ou d'instance récupérable | 0 | Temps nécessaire pour redémarrer l'instance |
| Catastrophes: corruptions | Secondes en minutes
0 si vous utilisez Data Guard dans chaque emplacement |
0 | |
| Catastrophes: échecs de l'extension de région | Secondes en minutes
0 si vous utilisez Data Guard dans chaque emplacement |
0 | |
| Planifié | Correctifs de base de données, mises à jour de l'OS / du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance.
Secondes si vous utilisez RAC |
| Mise à niveau majeure de la base de données | 0 | 0 |