RAC, Data Guard et Stream sont trois outils dans le système de haute disponibilité d'Oracle. Chaque outil peut être utilisé indépendamment ou en combinaison. Ils ont des domaines de concentration différents et sont applicables dans différents scénarios.
Le RAC excelle dans la gestion des points d'échec unique et de l'équilibrage de charge. Par conséquent, le RAC est couramment utilisé dans les systèmes critiques fonctionnant 24/7. Cependant, dans la solution RAC, les données existent en une seule copie. Bien que les pannes de stockage puissent être évitées grâce à des mécanismes comme RAID, les données elles-mêmes manquent de redondance, ce qui les rend vulnérables aux points d'échec unique.
Data Guard fournit une protection des données grâce à des données redondantes. En utilisant des mécanismes de synchronisation des journaux, Data Guard assure la synchronisation entre les données redondantes et les données principales. Cette synchronisation peut être réalisée sous différentes formes telles que temps réel, différé, synchrone ou asynchrone. Data Guard est couramment utilisé dans les solutions de reprise après sinistre distante et les solutions haute disponibilité pour les petites entreprises. Bien qu'il permette d'exécuter des requêtes en lecture seule sur la machine de secours pour réduire la pression de performances sur la base de données principale, Data Guard n'est pas conçu principalement comme une solution de performance.
Streams, basé sur Oracle Advanced Queue, permet la synchronisation des données et offre des configurations flexibles à plusieurs niveaux. Comme Oracle fournit un large soutien au développement, y compris des API riches, Streams est plus adapté pour le partage de données au niveau de l'application.
Qu'est-ce que Data Guard ?
Dans un environnement Data Guard, il y a au moins deux bases de données : l'une est en état ouvert fournissant des services externes, appelée la Base de Données Principale, et l'autre est en mode récupération, appelée la Base de Données Secondaire. Lors de l'exécution, la Base de Données Principale sert les clients et les opérations utilisateur sont enregistrées dans les journaux en ligne et archivés, qui sont ensuite transmis à la Base de Données Secondaire via le réseau. Ces journaux sont rejoués sur la Base de Données Secondaire pour assurer la synchronisation des données entre les deux.
Oracle Data Guard optimise encore davantage ce processus, en automatisant et en simplifiant les tâches de transmission de journaux et de récupération, tout en offrant une gamme de paramètres et de commandes pour faciliter le travail des administrateurs de bases de données (DBAs).
S'il existe des facteurs prévus nécessitant l'arrêt de la Base de Données Principale, comme des mises à jour logicielles ou matérielles, la Base de Données de Secours peut être basculée pour devenir la Base de Données Principale et continuer à servir les clients. Cela minimise les temps d'arrêt du service et garantit l'intégrité des données. En cas de problèmes inattendus rendant la Base de Données Principale indisponible, la Base de Données de Secours peut être basculée de force pour devenir la Base de Données Principale et continuer à servir les clients. Le niveau de perte de données dans ces cas dépend du niveau de protection des données configuré. Par conséquent, les bases de données Principale et de Secours sont des rôles conceptuels qui ne sont pas fixés à des bases de données spécifiques.
Architecture Data Guard
L'architecture Data Guard peut être divisée en trois parties fonctionnelles :
1) Réexpédition des redos :
Pendant l'exécution de la Base de Données Principale, les journaux redo sont continuellement générés et doivent être envoyés à la Base de Données Secondaire. Cette action d'envoi peut être effectuée par les processus LGWR ou ARCH de la Base de Données Principale. Différentes destinations d'archivage peuvent utiliser différentes méthodes, mais pour une destination spécifique, seule une méthode peut être sélectionnée. Le choix du processus a un impact significatif sur les capacités de protection des données et la disponibilité du système.
2) Réception à nouveau :
Le processus RFS (Remote File Server) dans la Base de Données de Secours reçoit les journaux et les écrit soit dans les fichiers Standby Redo Log, soit dans les fichiers Archived Log, en fonction de la méthode de transport des journaux de la Base de Données Principale et de l'emplacement de la Base de Données de Secours. Si les journaux sont écrits dans les fichiers Standby Redo Log, alors lorsque bascule de journal se produit sur la Base de Données Principale, cela déclenche une bascule de journal sur le Standby Redo Log de la Base de Données de Secours et archive ce Standby Redo Log. Si les journaux sont écrits dans les Logs Archivés, cette action peut être considérée comme une opération d'archivage en soi.
3) Réappliquer :
Le service de réapplication est responsable de la relecture des journaux de la base de données principale sur la base de données secondaire, permettant ainsi une synchronisation des données entre les deux bases de données.
En fonction de la manière dont la base de données en attente réapplique les journaux, il existe deux types : Physical Standby et Logical Standby.
En fonction de quand a lieu l'application Redo, il existe également deux types :
a) Application en temps réel : Cette méthode nécessite l'utilisation du Standby Redo Log. Chaque fois qu'un journal est écrit dans le Standby Redo Log, il déclenche la récupération. L'avantage de cette méthode est qu'elle réduit le temps nécessaire pour basculer la base de données, car les journaux restants sont déjà récupérés en temps réel.
b) Appliquer à l'archivage : Cette méthode applique les journaux lorsqu'un basculement de journal se produit sur la Base de Données Principale et déclenche l'archivage sur la Base de Données Secondaire. La récupération est initiée après que le processus d'archivage soit terminé. C'est également le mode de récupération par défaut.
Standby Physique vs. Standby Logique
Il existe deux types de bases de données standby : standby physique et standby logique.
1. Base de données en mode Standby Physique :
Une base de données en mode Standby Physique est identique à une base de données Principale. Data Guard maintient la base de données en mode Standby Physique via l'application des REDO. En général, lorsque le Standby Physique n'applique pas les REDO, il peut être ouvert en mode LECTURE SEULE. Si une zone de Flashback est définie dans la base de données, elle peut même être temporairement basculée en mode LECTURE/ECRITURE pour effectuer des opérations. Une fois les opérations nécessaires terminées, la base de données peut être restaurée à son état antérieur au mode LECTURE/ECRITURE grâce à la fonctionnalité Flashback Database, permettant ainsi la reprise de l'application des données REDO depuis la base de données Principale.
Note : Les fonctionnalités de l'application Physical Standby ont été améliorées dans Oracle 11g. Dans cette version, Physical Standby peut continuer à appliquer les données REDO en restant en mode OUVERT EN LECTURE SEULE. Cela améliore considérablement l'utilisabilité des bases de données Physical Standby.
Fonctionnalités du site de secours physique :
1) Rétablissement après sinistre et haute disponibilité : Physical Standby fournit une solution robuste et efficace pour le rétablissement après sinistre et la haute disponibilité. Elle simplifie la gestion du basculement/prise en charge en cas de panne et réduit les temps d'arrêt planifiés ou non planifiés.
2) Protection des données : Avec une base de données Standby Physique, Data Guard garantit que la perte de données est minimisée, même en cas de disasters imprévus.
3) Réduction de la charge de travail de la base de données principale : En déléguant certaines tâches, comme les sauvegardes et les requêtes en lecture seule, à la base de données de secours physique, les ressources CPU et E/S de la base de données principale peuvent être préservées.
4) Amélioration des performances : Le mécanisme d'application REDO utilisé dans les bases de données Physical Standby fonctionne au niveau le plus bas de la récupération, en contournant l'exécution du code SQL. Cela entraîne la meilleure efficacité et performance.
2. Base de données Logical Standby :
Une base de données Logical Standby est également créée à partir de la base de données Principale (ou de ses sauvegardes ou répliques, comme une base de données Physical Standby). Par conséquent, initialement, elle est similaire à une base de données Physical Standby au départ. Cependant, étant donné qu'une base de données Logical Standby applique les données REDO via l'exécution de SQL, sa structure de fichiers physiques et même la structure logique des données peuvent être différentes de celles de la base de données Principale.
Contrairement au standby physique, un standby logique est généralement ouvert en mode READ WRITE, permettant aux utilisateurs d'y accéder à tout moment. Autrement dit, l'exécution SQL a lieu alors que le standby logique est dans un état OUVERT. Cela présente des avantages et des inconvénients. En raison de la nature de l'exécution SQL, il existe des limitations opérationnelles sur certains types de données et certaines instructions DDL/DML dans un standby logique. Vous pouvez vérifier les types de données non pris en charge dans la vue DBA_LOGSTDBY_UNSUPPORTED. Si de tels types de données sont utilisés, il ne peut pas être garanti une cohérence complète dans la base de données.
L'ouverture en mode LECTURE/ECRITURE d'un standby logique le rend approprié pour être utilisé comme système de reporting, soulageant ainsi la charge de travail du système.
Fonctionnalités du Logical Standby :
En plus des caractéristiques mentionnées précédemment pour le Site de Secours Physique, telles que la reprise après sinistre, la haute disponibilité et la protection des données, le Site de Secours Logique présente les fonctionnalités suivantes :
1) Utilisation efficace des ressources matérielles sur le serveur de secours : Une base de données Logical Standby peut être utilisée pour créer des index supplémentaires, des vues matérialisées et répondre à des besoins commerciaux spécifiques. Elle peut également créer de nouveaux schémas (qui n'existent pas dans la base de données principale) et exécuter des opérations DDL ou DML qui ne sont pas appropriées sur la base de données principale.
2) Délester le travail de la base de données principale : En gardant la base de données Logical Standby ouverte tout en restant synchronisée avec la base de données principale, elle peut assurer à la fois la protection des données et les opérations de reporting. Cela libère la base de données principale des tâches de reporting et de requête, économisant ainsi des ressources CPU et E/S précieuses.
3) Mises à niveau fluides : Le standby logique peut être utilisé pour des opérations telles que les mises à jour inter-versions et le correctif de la base de données.
Modes de protection des données
Data Guard permet trois modes de protection des données : Protection Maximale, Disponibilité Maximale et Performance Maximale.
1. Protection Maximale :
Ce mode garantit une perte totale de données égale à zéro. Pour atteindre cet objectif, toutes les transactions doivent non seulement être écrites dans les journaux de réécriture en ligne locaux avant la validation, mais aussi simultanément écrites dans les journaux de réécriture de secours dans la base de données secondaire. Les données REDO doivent être accessibles dans au moins une base de données secondaire (si plusieurs existent) avant qu'elles puissent être validées sur la base de données principale. En cas d'indisponibilité de la base de données secondaire due à un incident (par exemple, une interruption réseau), la base de données principale sera arrêtée pour éviter toute perte de données.
Activer ce mode nécessite que la Base de Données en Veille soit configurée avec des Journaux Redo en Veille, et que la Base de Données Principale utilise le mode LGWR, SYNC, AFFIRM pour l'archivage vers la Base de Données en Veille.
2. Disponibilité maximale :
Ce mode offre le plus haut niveau de stratégie de protection des données sans affecter la disponibilité de la base de données principale. Il repose sur une mise en œuvre similaire à celle de Protection maximale, où les transactions locales doivent être écrites dans les journaux de réécriture de la base de données secondaire avant validation. Cependant, la différence réside dans le fait que si un incident survient rendant la base de données secondaire inaccessibles, la base de données principale passera automatiquement en mode Performance maximale au lieu de s'arrêter. Une fois que la base de données secondaire est récupérée, la base de données principale reviendra automatiquement en mode Disponibilité maximale.
Bien que ce mode vise à minimiser la perte de données, il ne peut pas garantir une cohérence de données absolue. Comme le mode Protection Maximale, ce mode nécessite que la Base de Données de Secours soit configurée avec des Journaux de Redo de Secours, et que la Base de Données Principale utilise le mode LGWR, SYNC, AFFIRM pour l'archivage vers la Base de Données de Secours.
3. Performance Maximale :
Ce mode offre le plus haut niveau de stratégie de protection des données sans affecter les performances de la base de données principale. Les transactions peuvent être validées à tout moment, et les données REDO de la base de données principale actuelle doivent être écrites dans au moins une base de données de secours, bien que cela puisse se faire de manière asynchrone. Dans des conditions de réseau idéales, ce mode peut fournir une protection des données similaire à celle du mode Disponibilité Maximale tout en ayant seulement un impact minime sur les performances de la base de données principale. C'est le mode de protection par défaut lors de la création d'une base de données de secours. Il peut être réalisé à l'aide des processus LGWR ASYNC ou ARCH, et les journaux REDO de secours ne sont pas nécessaires pour la base de données de secours.
Étapes pour modifier le mode de protection des données :
1. Arrêtez la base de données et redémarrez-la en état Mount. Si c'est une configuration RAC, arrêtez toutes les instances et démarrez uniquement une instance en état Mount.
2. Modifiez le mode en utilisant la syntaxe suivante :
ALTERER LA BASE DE DONNÉES POUR RÉGLER LA BASE DE DONNÉES DE SECOURS SUR MAXIMISER {PROTECTION | DISPONIBILITÉ | PERFORMANCE};
Par exemple : SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3. Ouvrir la base de données : ALTER DATABASE OPEN;
4. Confirmez le mode de protection des données modifié :
SQL>select mode_de_protection,niveau_de_protection from v$database;
Services d'Application de Journal
Data Guard garantit la cohérence entre la base de données principale et les bases de données secondaires en appliquant le REDO. Derrière la scène, en soutenant discrètement ce processus, se trouvent les célèbres Services d'Application de Journal. Il existe deux types de Services d'Application de Journal :
1. REDO Appliquer : Exclusif aux bases de données Standby physiques, il les maintient synchronisées avec la base de données Principale grâce à la récupération par média.
2. Application SQL : Exclusif aux bases de données Standby logiques, sa fonctionnalité principale consiste à analyser les instructions SQL via LogMiner et à les exécuter côté Standby.
Ainsi, lors de l'application des données REDO, la base de données Standby physique doit être dans un état MOUNT, tandis que la base de données Standby logique est ouverte en mode READ WRITE pour l'application des données REDO. Cependant, les objets en cours de maintenance sont définis par défaut en lecture seule et ne peuvent pas être modifiés directement du côté de la Standby logique.
Protégez votre base de données Oracle avec une solution professionnelle
Oracle Data Guard est une solution robuste pour la haute disponibilité, la protection des données et la reprise après sinistre. C'est un outil crucial pour les entreprises qui ne peuvent pas se permettre des temps d'arrêt significatifs ou la perte de données. Cependant, pour protéger encore davantage votre environnement de base de données, il est recommandé de sauvegarder votre base de données Oracle avec une solution de sauvegarde et de reprise après sinistre professionnelle.
Vinchin Backup & Recovery offre des fonctionnalités puissantes pour protéger vos bases de données dans les machines virtuelles et les serveurs physiques, de manière très automatique, flexible et efficace. Il fournit une protection multi-type des bases de données pour Oracle DB, MySQL, SQL Server, Postgres Pro et MariaDB, avec prise en charge de la compression des bases de données, gestion centralisée des tâches, stratégies de sauvegarde intelligentes, sauvegarde de base de données en direct et support avancé pour SQL Server/Oracle. De plus, il prend également en charge la fonction de protection contre le ransomware et la migration V2V sur plus de 10 plates-formes virtuelles.
Vinchin Backup & Recovery a été sélectionné par des milliers d'entreprises et vous aussi pouvez commencer à utiliser ce puissant système avec un essai complet de 60 jours ! De plus, contactez-nous et indiquez vos besoins, et vous recevrez une solution adaptée à votre environnement informatique.
Conclusion
Oracle Data Guard est un composant essentiel pour toute déploiement de base de données Oracle à niveau d'entreprise, offrant une solution complète pour la reprise après sinistre, la haute disponibilité, la protection des données et l'équilibrage de charge. Son architecture flexible et ses différents modes de fonctionnement le rendent adaptable à une large gamme de besoins commerciaux et exigences opérationnelles.
Vous pouvez choisir Vinchin Backup & Recovery pour sauvegarder et restaurer facilement vos bases de données Oracle. N'oubliez pas d'essayer la version d'essai gratuite !
