Cet article présente un aperçu de la réplication des bases de données Oracle. Il aborde les concepts, les architectures, les étapes de mise en œuvre et les meilleures pratiques opérationnelles. Vous découvrez comment la réplication s’inscrit dans le cadre des objectifs de point de récupération (RPO) et de temps de reprise (RTO), décrits ici. Vous étudiez les méthodes fondamentales : Data Guard, GoldenGate, les vues matérialisées et les solutions héritées. Vous apprenez également à surveiller la réplication, à configurer les alertes et à assurer sa sécurité.
Qu’est-ce que la réplication de base de données Oracle ?
Oracle capture les modifications apportées à une base de données source et les applique sur une ou plusieurs bases de données cibles. Elle prend en charge le mode synchrone, qui attend une confirmation de validation, ainsi que le mode asynchrone, qui transmet les modifications sans attendre. Le mode synchrone permet une perte de données quasi nulle, mais introduit une latence. Le mode asynchrone réduit la latence, mais comporte un risque minimal de lacunes dans les données en cas de défaillance. Selon la méthode utilisée, Oracle recourt au transport des journaux de restauration (redo transport), à l’analyse des journaux de transaction (log mining) ou aux journaux des vues matérialisées (materialized view logs). Les modèles de cohérence varient : immédiate pour le mode synchrone, éventuelle pour le mode asynchrone.
La réplication est liée à l’objectif de point de reprise (RPO, Recovery Point Objective) et à l’objectif de temps de reprise (RTO, Recovery Time Objective). Les modes synchrones permettent d’atteindre un RPO quasi nul. Le mode asynchrone équilibre le RPO en fonction de la distance réseau. Vous choisissez le mode adapté en fonction des besoins métier et de l’infrastructure. Vous définissez également le RTO : la rapidité avec laquelle vous pouvez remettre une réplique en service. Ces objectifs guident le choix de la méthode et sa configuration.
Pourquoi répliquer la base de données Oracle ?
La réplication répond aux priorités opérationnelles fondamentales : reprise après sinistre, haute disponibilité, équilibrage de charge et continuité des activités. Elle facilite également l’analyse des données et les migrations.
Récupération après sinistre et objectifs de point de reprise (RPO)/objectif de temps de reprise (RTO) : La réplication stocke des copies sur des sites distants. En cas de défaillance, vous basculez vers le système de secours. La réplication synchrone permet une perte de données minimale (RPO quasiment nul). La réplication asynchrone convient aux sites éloignés où un RPO modéré est acceptable. Vous mesurez le RTO en fonction de la rapidité avec laquelle vous effectuez le basculement des rôles. Les tests de basculement permettent de vérifier le respect des objectifs RTO.
Haute disponibilité : Une base de données de secours peut prendre le relais via un basculement planifié (switchover) ou non planifié (failover). Data Guard fournit des services gérés d’application pour des transitions rapides. GoldenGate permet de mettre en place des configurations actives-actives dans certains cas. Vous réduisez les temps d’indisponibilité planifiés et non planifiés. Vous respectez vos engagements de niveau de service (SLA) et améliorez la fiabilité du service.
Équilibrage de charge et génération de rapports : Active Data Guard vous permet d’ouvrir une base de données en mode veille en lecture seule. Vous déchargez ainsi les tâches de génération de rapports afin de réduire la charge sur la base primaire. Les vues matérialisées peuvent assurer la génération locale de rapports, avec actualisation périodique. Vous améliorez ainsi les performances pour les utilisateurs finaux et les équipes d’analyse.
Continuité des activités et maintenance : Vous pouvez appliquer des correctifs ou des mises à niveau sur le système de secours pendant que le système principal est en cours d’exécution. Une fois les tests effectués, vous inversez les rôles. Vous réduisez ainsi au minimum les temps d’indisponibilité liés à la maintenance. Vous pouvez migrer vers d’autres plateformes en reproduisant l’environnement dans un nouveau système.
Distribution des données : Vous dupliquez les données vers des bureaux distants ou des zones cloud. Des vues matérialisées ou Oracle GoldenGate peuvent envoyer des sous-ensembles ou des données filtrées. Vous prenez en charge les applications distribuées grâce à des copies locales.
Tests et développement : Vous conservez une copie pour les tests qualité ou le développement. Vous la mettez régulièrement à jour à partir de l’environnement de production. Les équipes peuvent ainsi tester des modifications sans compromettre l’environnement principal.
Types de réplication de base de données dans Oracle
Oracle propose plusieurs méthodes. Chacune convient à des cas d’usage spécifiques et implique des compromis en termes de RPO, de RTO, de complexité et de licences. Le tableau ci-dessous présente une synthèse comparative :
| Method | RPO | RTO | Use Case | Complexity | Licensing | Status | Oracle Version |
|---|
| Data Guard | Data Guard | Fast failover/switchover | HA/DR for Oracle only | Moderate | Included in EE | Current | 11g onwards |
| GoldenGate | Near-zero to configurable | Varies; depends on apply | Logical replication, heterogeneous, migrations, active-active | High | Separate license | Current | 11g onwards |
| Materialized Views | Scheduled lag | Depends on refresh | Reporting, caches, minimal sync | Low | Included in EE | Current | 11g onwards |
| Advanced Replication | Moderate; conflict risk | Slow for conflict resolution | Multi-master legacy | High | Included in EE | Legacy/Superseded | 11g,12c |
| Streams | Near-zero to async | Fast | Deprecated logical replication | High | Included but deprecated | Deprecated | Deprecated in 12c, desupported 19c |
Comment dupliquer une base de données Oracle ?
Les aperçus suivants décrivent la configuration et les opérations. Consultez toujours la documentation Oracle correspondant à votre version et à votre environnement.
Prérequis et planification
Avant toute configuration de réplication : vérifiez la connectivité réseau, assurez-vous d’une bande passante suffisante et sécurisez les liens. Vérifiez que les éditions et licences Oracle autorisent les méthodes retenues. Préparez des sauvegardes à l’aide de RMAN. Attribuez des utilisateurs dédiés disposant des privilèges appropriés. Planifiez l’espace de stockage sur les systèmes secondaires ou les destinations de fichiers journaux. Définissez les objectifs de point de récupération (RPO) et de temps de reprise (RTO). Effectuez d’abord des tests dans un environnement de préproduction. Documentez des procédures opérationnelles pour la configuration, la surveillance et le basculement.
1. Configuration de Data Guard
Data Guard offre une base de secours gérée pour la haute disponibilité et la reprise après sinistre (HA/DR). Vous pouvez utiliser l’agent de gestion (Broker) ou une configuration manuelle. Data Guard actif ajoute une fonctionnalité de lecture seule.
Activez le mode ARCHIVELOG et FORCE LOGGING. Créez des journaux de restauration secondaires : un de plus que le nombre de groupes de journaux de restauration. Définissez DB_UNIQUE_NAME sur la base principale et la base secondaire. Configurez les entrées LOG_ARCHIVE_DEST_n : la base principale envoie les journaux de restauration aux destinations secondaires. Définissez FAL_SERVER et FAL_CLIENT pour la résolution des lacunes. Assurez-vous que les paramètres d’initialisation sont identiques des deux côtés.
Utilisez RMAN pour dupliquer la base de données cible en tant que base de secours à partir de la base principale, ou effectuez une sauvegarde suivie d’une restauration sur l’hôte de secours. Ajustez les paramètres d’initialisation dans le fichier d’initialisation de la base de secours : DB_NAME doit correspondre à celui de la base principale, tandis que DB_UNIQUE_NAME doit être différent. Configurez la sauvegarde automatique du fichier de contrôle. Vérifiez que les entrées réseau dans les fichiers tnsnames.ora et listener.ora sont correctes.
Le Broker (DGMGRL) simplifie la gestion. Vous créez une configuration DG, ajoutez la base primaire et la base de secours, puis définissez le mode de protection (MAXAVAIL, MAXPERFORMANCE ou MAXPROTECTION). Le Broker prend en charge la validation, les transitions de rôle et la surveillance de l’état. La configuration manuelle utilise des commandes SQL et RMAN : vous modifiez les paramètres d’initialisation, puis démarrez la reprise gérée à l’aide de la commande ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT. L’utilisation du Broker est recommandée pour la plupart des configurations.
Le mode SYNC (SYNC ou FASTSYNC) attend la confirmation du système de secours, ce qui permet une perte de données quasi nulle. Le mode ASYNC envoie les informations de reprise sans attendre, tolère la latence réseau mais comporte un risque de perte de données. Configurez le mode de protection en fonction de vos besoins en matière d’objectif de point de récupération (RPO). Surveillez le décalage de transport via les vues V$ARCHIVE_DEST_STATUS et V$DATAGUARD_STATS.
En mode veille, le processus de reprise géré (MRP) applique les opérations de rejeu (redo). Avec Active Data Guard, vous ouvrez la base de données en veille en lecture seule à l’aide de la commande suivante : ALTER DATABASE OPEN READ ONLY. Les requêtes s’exécutent sur la base de données en veille sans affecter l’application des opérations de rejeu. Surveillez le décalage d’application à l’aide de la vue V$ARCHIVE_DEST_STATUS et de la colonne APPLIED_TIME.
Test de basculement : basculement planifié où la base primaire devient la base de secours. Utilisez la commande DGMGRL SWITCHOVER TO standby. Test de basculement d’urgence : basculement non planifié, la base primaire étant inaccessible. Utilisez la commande DGMGRL FAILOVER TO standby. Après la modification des rôles, reconfigurez l’ancienne base primaire en tant que nouvelle base de secours. Documentez les procédures et effectuez régulièrement des tests.
Interrogez les vues V$ARCHIVE_DEST_STATUS et V$DATAGUARD_STATS pour connaître les retards de transport et d’application. Utilisez la commande DGMGRL SHOW CONFIGURATION pour obtenir le statut global. Configurez des alertes lorsque le retard dépasse le seuil défini. Surveillez l’utilisation des journaux de restauration (SRL) et l’espace disponible sur la base de secours. Analysez les erreurs réseau présentes dans les journaux d’alerte. Automatisez les notifications à l’aide de scripts ou d’outils de surveillance.
Les coupures réseau provoquent des écarts de redo. Utilisez FAL_SERVICE pour récupérer les journaux manquants. Résolvez le problème à l’aide de la commande ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL, puis redémarrez la reprise. Un nombre insuffisant de journaux redo en attente ralentit l’application. La rétention des journaux d’archivage doit tenir compte de la consommation par la base de données en attente. Des incohérences de version bloquent l’application ; assurez-vous que les niveaux de correctifs correspondent. Testez le basculement afin de valider la configuration.
2. Configuration de GoldenGate
GoldenGate assure la réplication logique. Il fonctionne sur des systèmes hétérogènes. Il utilise les processus Extract, les fichiers journal (trail files), Pump (facultatif) et Replicat.
Activer la journalisation supplémentaire : ALTER DATABASE ADD SUPPLEMENTAL LOG DATA et ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS, ou exécuter la commande ADD TRANDATA sur les tables. Cette opération garantit que les données de modification nécessaires sont bien présentes dans les fichiers redo. Créez un utilisateur GoldenGate doté des privilèges requis.
Installez les binaires GoldenGate sur les serveurs source et cible. Utilisez des versions compatibles avec la version d’Oracle Database. Configurez le processus Manager avec les paramètres de port.
Créer un groupe d’extractions : définir la base de données source et les tables concernées. Spécifier l’emplacement des fichiers de trace. Utiliser l’extraction intégrée Oracle pour plus d’efficacité. Configurer les tables de points de contrôle dans le schéma cible afin de suivre l’avancement. En option, configurer une extraction de pompe à données pour transférer les fichiers de trace vers les cibles.
Créer un groupe de réplication : définir la base de données cible et les tables. Configurer le magasin d’identifiants ou un alias pour une authentification sécurisée. Utiliser des fichiers de paramètres pour établir la correspondance entre les schémas et les tables sources et cibles. Gérer les transformations ou les filtres dans les fichiers de paramètres.
GoldenGate peut répliquer les instructions DDL avec les paramètres appropriés, mais cela nécessite une planification rigoureuse. Utilisez DDL INCLUDEMAPPING ou des approches basées sur des scripts. Vérifiez que le schéma cible prend en charge les nouvelles structures.
Démarrer les processus Manager, Extract, Pump et Replicat via GGSCI. Utilisez la commande INFO ALL pour vérifier leur état et leur décalage. Consultez les fichiers de rapport afin de détecter d’éventuelles erreurs. Surveillez les métriques de décalage et le débit. Utilisez les tables de signalisation (heartbeat) pour détecter tout blocage.
La réplication bidirectionnelle nécessite la détection et la résolution des conflits. Utilisez la prise en charge de la globalisation pour les jeux de caractères. Pour les cibles hétérogènes, configurez le mappage en conséquence.
Sécurisez les fichiers de trace à l’aide des autorisations au niveau du système d’exploitation. Utilisez des liaisons réseau chiffrées ou des sockets sécurisés pour le transfert. Utilisez le magasin d’identifiants GoldenGate pour les mots de passe. Envisagez l’intégration avec Oracle Key Vault.
Exécutez les requêtes INFO EXTRACT et INFO REPLICAT pour vérifier le décalage et l’état. Analysez les fichiers de rapport afin d’y détecter des erreurs. Définissez des seuils de décalage et déclenchez une alerte en cas de dépassement. Surveillez les tables de points de contrôle pour identifier tout décalage. Utilisez des scripts ou des outils de surveillance pour collecter les métriques.
L’absence de journalisation complémentaire entraîne une perte de données. Des lacunes de capture peuvent survenir si les journaux redo sont écrasés ; planifiez la rétention des journaux d’archivage. Les modifications DDL peuvent échouer en cas de non-correspondance. Les problèmes réseau perturbent la livraison des fichiers de trace. Vérifiez les journaux du gestionnaire pour détecter les erreurs. Surveillez l’espace disque alloué aux fichiers de trace. Testez les scénarios de basculement.
Pour les mises à niveau de GoldenGate, coordonnez l’arrêt/démarrage de l’Extract et du Replicat. Utilisez une mise à niveau progressive afin d’éviter toute interruption de service. Vérifiez la compatibilité avec les nouveaux correctifs Oracle.
3. Configuration des vues matérialisées
Les vues matérialisées copient les données à intervalles réguliers. Elles conviennent aux rapports ou aux caches.
Dans la source, créez des journaux de vues matérialisées sur les tables : CREATE MATERIALIZED VIEW LOG ON schema.table WITH ROWID. Cela permet un rafraîchissement rapide.
Sur la cible, utilisez CREATE MATERIALIZED VIEW mv_name REFRESH FAST ON DEMAND AS SELECT ... FROM schema.table@dblink;. Utilisez ON COMMIT pour un rafraîchissement immédiat à chaque validation sur la source, si cela est acceptable.
Utilisez l’actualisation FAST lorsque des journaux existent ; sinon, effectuez une actualisation COMPLETE. Planifiez l’actualisation via le planificateur Oracle : DBMS_SCHEDULER.CREATE_JOB. Surveillez la colonne LAST_REFRESH_DATE dans DBA_MVIEWS.
Vérifiez l’historique dans DBA_MVIEW_REFRESH_TIMES. Gérez les erreurs d’actualisation dues à des problèmes réseau ou à des incompatibilités de type de données. Assurez-vous de disposer des privilèges requis sur les liens sources. Gérez les données obsolètes en choisissant la fréquence d’actualisation appropriée.
Rapports quasi en temps réel dans les sites distribués. Mise en cache des données de référence. Déchargement des requêtes depuis le système principal.
4. Configuration avancée de la réplication (obsolète)
La réplication avancée utilise des groupes et des travaux de réplication. Elle prend en charge la réplication multi-maître, mais est désormais obsolète. Pour les nouveaux projets, privilégiez Oracle GoldenGate.
Définir le groupe de réplication via DBMS_REPCAT. Ajouter les sites maîtres. Définir les objets répliqués. Configurer les méthodes de résolution des conflits. Planifier les travaux de propagation. Superviser à l’aide de DBA_REPCAT ou des vues fournies par Oracle.
Ne prend pas en charge les nouvelles fonctionnalités Oracle, comme l’architecture multilocataire. Configuration complexe et gestion des conflits difficile. Assistance limitée des éditeurs. Remplacé par GoldenGate.
5. Streams (obsolète)
Oracle Streams assurait la réplication logique. Cette fonctionnalité a été déconseillée à partir de la version 12c et n’est plus prise en charge à partir de la version 19c. Ne l’utilisez pas pour de nouveaux déploiements. Pour des besoins similaires, privilégiez Oracle GoldenGate.
Sauvegarder en toute sécurité la base de données Oracle avec Vinchin
Même avec une réplication en place, les sauvegardes restent essentielles. La réplication garantit la disponibilité, mais ne couvre pas tous les types de défaillances. Vous devez donc toujours effectuer régulièrement des sauvegardes cohérentes. Vinchin Backup & Recovery est une solution professionnelle de sauvegarde de bases de données destinée aux entreprises et prenant en charge la plupart des bases de données grand public — Oracle, MySQL, SQL Server, MariaDB, PostgreSQL et PostgresPro.
Il offre de nombreuses fonctionnalités ; les points forts incluent notamment la sauvegarde dans le cloud et l’archivage sur bande, les sauvegardes complètes et incrémentales avec prise en charge des journaux archivés pour Oracle, les sauvegardes planifiées avec compression des données et déduplication, la restauration sur un nouveau serveur avec récupération à un instant donné, ainsi que la protection contre les rançongiciels, entre autres. Pour Oracle plus particulièrement, il intègre la compression Oracle, la prise en charge du suivi des blocs modifiés, la possibilité de passer outre les fichiers accessibles et celle de passer outre les fichiers hors ligne afin d’optimiser les tâches de sauvegarde.
La console web Vinchin est simple et intuitive. La sauvegarde d’Oracle implique quatre étapes claires :
1. Sélectionnez la base de données à sauvegarder
2. Choisissez le stockage de sauvegarde,
3. Définir la stratégie de sauvegarde
4. Envoyer la tâche
L’interface vous guide à l’aide d’étiquettes claires et d’invitations explicites. Vous pouvez suivre l’avancement des tâches, consulter les journaux et modifier les plannings depuis la console, sans avoir recours à des commandes complexes.
Avec une clientèle mondiale et des évaluations très positives de ses produits, Vinchin propose un essai gratuit de 60 jours doté de toutes les fonctionnalités — cliquez sur le bouton pour télécharger l’installateur et le déployer facilement.
Foire aux questions sur la réplication Oracle Database
Q1 : Comment surveiller le décalage d’application de Data Guard ?
Utilisez la requête SQL suivante : SELECT DEST_ID, DEST_NAME, STATUS, RECEIVED_TIME, APPLIED_TIME FROM V$ARCHIVE_DEST_STATUS WHERE STATUS NOT IN ('DEFERRED','INACTIVE') ; consultez la vue V$DATAGUARD_STATS pour les indicateurs de décalage.
Q2 : Comment résoudre les lacunes lorsque la reprise du transport échoue ?
Exécutez la commande ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL ; puis récupérez les journaux manquants via FAL_SERVER ; redémarrez la récupération à l’aide de la commande ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT.
Q3 : Comment tester le basculement (failover) de GoldenGate ?
Arrêtez l’Extract sur la source ; promouvez la cible en tant que nouvelle source ; ajustez les paramètres de l’Extract pour qu’il capture les données depuis la nouvelle source ; redémarrez les processus ; une fois le problème résolu, reconfigurez l’origine comme cible.
Q4 : Comment la réplication affecte-t-elle les performances du système primaire ?
Le mode SYNCHRONOUS augmente la latence de validation ; le mode ASYNCHRONOUS n’entraîne qu’une augmentation minimale. La capture GoldenGate génère des journaux de restauration (redo) supplémentaires et sollicite davantage le processeur. Surveillez les rapports AWR et les métriques système, et dimensionnez les ressources en conséquence.
Q5 : Comment choisir entre Data Guard et GoldenGate ?
Utilisez Data Guard pour la haute disponibilité (HA) et la reprise après sinistre (DR) au sein d’Oracle. Utilisez GoldenGate pour la réplication logique, les cibles hétérogènes, le filtrage, les migrations sans interruption de service et les scénarios multi-maîtres.
Conclusion
La réplication Oracle améliore la disponibilité, la résilience et l’évolutivité. Data Guard et GoldenGate répondent à la plupart des besoins des entreprises. Les vues matérialisées conviennent aux rapports, tandis que les options héritées restent utilisées dans une mesure limitée. Pour assurer un fonctionnement efficace, il est essentiel de définir clairement les objectifs de RPO et de RTO, de réaliser des tests approfondis et de mettre en place une surveillance proactive. Sécurisez la réplication à l’aide du chiffrement et de crédentiels.
Associez toujours la réplication à des sauvegardes fiables. Vinchin propose une solution de sauvegarde robuste pour Oracle. Essayez sa version d’essai gratuite pour protéger votre environnement.
