Un livre blanc technique Oracle Septembre Oracle Data Guard avec Oracle Database 11g Release 2

Transcription

1 Un livre blanc technique Oracle Septembre 2009 Oracle Data Guard avec Oracle Database 11g Release 2

2 Livre blanc Oracle Oracle Data Guard avec Oracle Database 11g Release 2 Introduction... 2 Oracle Data Guard 11g - Présentation... 3 Fonctionnement de Data Guard Détails techniques... 5 Services de transport Data Guard... 6 Modes de protection... 7 Services d'application Data Guard... 8 Résolution automatique des décalages Validation de données Oracle Gestion d'une configuration Data Guard Services de gestion des rôles Maintenance planifiée Comparaison entre Data Guard et la mise en miroir à distance Data Guard et Exadata Data Guard et Oracle Real Application Clusters Architecture de disponibilité maximale Clients Data Guard Conclusion Annexe : récapitulatif des nouvelles fonctions de Data Guard 11g... 20

3 Introduction Afin d'assurer des opérations commerciales performantes, un service à la clientèle de haut niveau, la conformité aux législations gouvernementales et la protection des données de l entreprise, il est indispensable de disposer du niveau le plus élevé possible de protection et de disponibilité des données. Il n'est donc pas surprenant que la protection et la disponibilité des données fassent partie des principales priorités des entreprises de toute taille et de tout secteur. La sauvegarde et la récupération sur bande, la mise en miroir à distance sur des unités de stockage ou le transfert des informations de journalisation de la base de données constituent les solutions classiques de récupération après sinistre et de protection des données. Ces solutions ne permettent malheureusement pas d'atteindre de façon fiable des objectifs élevés pour ce qui est de minimiser les pertes de transactions avant un sinistre (Recovery Point Objective - protection des données) et minimiser le temps de remise en service après un sinistre (Recovery Time Objective - disponibilité des données). Elles ne permettent pas non plus de réaliser un retour sur investissement approprié en raison des coûts d'acquisition élevés et d'une utilisation médiocre des systèmes de secours qui restent en veille jusqu'à ce qu'ils soient requis pour assurer un rôle de système principal. Oracle Data Guard 11g Release 2 se démarque en redéfinissant les attentes des utilisateurs à l'égard de telles solutions. Data Guard fait partie d'oracle Database Enterprise Edition et offre les logiciels d administration, de surveillance et d'automatisation permettant de créer et de gérer une ou plusieurs bases de données de secours synchronisées destinées à protéger les données contre les défaillances, les sinistres, les erreurs et les corruptions. Cette solution permet de répondre à la fois aux besoins de haute disponibilité mais aussi de récupération après sinistre ; elle est le complément idéal d Oracle Real Application Clusters. Data Guard intègre les informations requises relatives à la base de données Oracle afin de fournir un niveau de protection optimal pour les données Oracle. Data Guard est simple à implémenter et à gérer. Les administrateurs savent qu'une base de données de secours peut parfaitement assurer le rôle de production, éliminant ainsi tout risque pour l'entreprise en cas de basculement. Enfin, à une époque où toutes les entreprises doivent

4 «Active Data Guard 11g permet de réaliser des gains rapides! Nous avons pu aisément dédier notre base de données de secours de dix téraoctets à deux usages : la protection contre les sinistres et un accès en lecture seule sécurisé pour nos applications de commerce électronique accessibles au public. Après avoir envisagé de nombreuses autres solutions, nous avons réalisé avec satisfaction que l'utilisation de la base de données de secours Data Guard dont nous disposions déjà était le moyen le plus simple de permettre à nos clients d'accéder de façon continue aux informations en cours.» Sue Merrigan, Intermap Technologies réduire leurs dépenses, les bases de données de secours Data Guard offrent un retour sur investissement élevé dans le cas des requêtes, des rapports, des sauvegardes, des tests ou des mises à jour de base de données actives et d'autres opérations de maintenance, tout en offrant également une protection contre les sinistres. Oracle Data Guard 11g - Présentation Oracle Data Guard procure les infrastructures logicielles d administration, de surveillance et d'automatisation nécessaires à la création et à la gestion d'une ou plusieurs bases de données de secours destinées à protéger les données Oracle contre les défaillances, les sinistres, les erreurs et la corruption des données. Il existe deux types de bases de données de secours. Une base de données de secours physique fait appel au mode Redo Apply pour maintenir une réplique exacte, bloc pour bloc, de la base de données Primaire. Une base de données de secours logique fait appel au mode SQL Apply et contient les mêmes informations logiques que la base de données principale, bien que l'organisation et la structure physiques des données puissent être différentes. Figure 1 : présentation de Data Guard

5 Les administrateurs peuvent choisir un basculement manuel ou automatique de la production vers un système de secours si le système Primaire échoue, afin de conserver une haute disponibilité pour les applications stratégiques. L'architecture de Data Guard est illustrée par la Figure 1. Data Guard fait partie des nombreuses fonctionnalités de haute disponibilité intégrées dans Oracle Database et répertoriées dans la Figure 2. Elles garantissent la continuité de service tout en réduisant l'impact des arrêts planifiés et non planifiés. Figure 2 : fonctionnalités de haute disponibilité d'oracle Database Les bases de données de secours Data Guard offrent un retour sur investissement élevé grâce à la prise en charge des interrogations spécifiques, de la création d'états, des sauvegardes ou des tests, tout en assurant une protection contre les sinistres. Plus spécifiquement : L'option Active Data Guard, disponible depuis Oracle Database 11g, permet l'utilisation d'une base de données de secours physique pour des applications en lecture seule parallèlement à la réception de mises à jour provenant de la base de données Primaire. Les interrogations exécutées sur une base de données de secours active utilisent des résultats à jour. La fonctionnalité Snapshot Standby permet l'ouverture d'une base de données de secours physique en lecture-écriture à des fins de test ou pour toute activité nécessitant une copie des données de production en lecture-écriture. Cette base de données Standby continue de recevoir les mises à jour générées par la base Primary, mais ne les applique pas. Ces mises à jour seront appliquées automatiquement sur la base de données Snapshot Standby dès qu elle sera reconvertie en base de secours physique en annulant

6 toutes les modifications effectuées depuis son ouverture en lecture-écriture. Les données Primaires sont protégées à tout moment. Une base de données de secours logique procure une souplesse accrue, car elle peut être ouverte en lecture-écriture. Bien que les données gérées par SQL Apply ne puissent pas être modifiées, vous pouvez ajouter des tables locales supplémentaires à la base de données. En outre, vous pouvez créer des index localement pour optimiser la création d'états, utiliser la base de données de secours en tant qu'entrepôt de données ou convertir les informations utilisées afin de charger les Datamarts. Vous pouvez utiliser les bases de données de secours pour effectuer une maintenance planifiée en ligne. La maintenance est d'abord effectuée sur une base de données de secours. La production est transférée vers la base de données de secours une fois les tâches de maintenance achevées. Le seul arrêt correspond au délai pour effectuer une opération de basculement planifié. Cela permet d'accroître la disponibilité et de réduire les risques pendant la maintenance du matériel, du système d'exploitation ou du site. Cela est également le cas lors de l installation de nouveaux jeux de patchs de base de données, de nouvelles versions de la base de données ou lors de l'implémentation d'autres modifications importantes dans les bases de données. En tant que copie exacte de la base de données principale, une base de données de secours physique peut aussi permettre de décharger la base principale des tâches de sauvegarde. Fonctionnement de Data Guard Détails techniques Une configuration Data Guard comporte une base de données de production, appelée base Primaire, et jusqu'à 30 bases de données de secours. Les bases de données Primaire et de secours se connectent en TCP/IP via Oracle Net Services. L'emplacement des bases de données importe peu, tant qu'elles peuvent communiquer entre elles. Une base de données de secours est initialement créée à partir d'une copie de sauvegarde de la base Principale. Data Guard synchronise automatiquement la base de données Primaire et toutes ses bases de secours en transmettant les informations de journalisation de la base de données principale (les données utilisées par Oracle pour récupérer des transactions) et en les appliquant à la base de données de secours.

7 «Nous utilisons Oracle Data Guard au lieu de la réplication de «SAN à SAN» directe, car cela nous permet de contrôler les coûts de communication et d'alléger la charge supportée par le matériel réseau.» Craig Gibbons, NRMA Motoring & Services Services de transport Data Guard Au fur et à mesure que les utilisateurs valident des transactions dans la base de données principale (COMMIT), Oracle génère des enregistrements de journalisation et les écrit dans un fichier journal en ligne local. Les services de transport Data Guard transmettent les données de journalisation à une base de données de secours de façon synchrone ou asynchrone, où elles sont écrites dans un fichier de journalisation de secours (première étape de la Figure 3). Les données de journalisation peuvent être transmises au format compressé pour réduire les besoins en matière de bande passante à l'aide de l'option Oracle Advanced Compression. Transport des informations de journalisation synchrone (SYNC) : la base de données Primaire attend de la base de données de secours la confirmation que les données de journalisation ont été sauvegardées sur disque avant d'indiquer le succès de la validation à l'application, empêchant ainsi toute perte de données. Les performances de la base de données Primaire sont affectées par le délai requis pour l'achèvement des opérations d'e/s du fichier de journalisation de la base Standby et le temps de round-trip du réseau. Data Guard 11g Release 2 est conçue pour limiter l'impact du transport synchrone sur les performances de la base Primaire. Les données de journalisation sont désormais transmises à la base de secours distante simultanément avec l'e/s du fichier journal en ligne local sur la base de données Primaire, supprimant ainsi toute répercussion de l'e/s de secours sur le temps de round-trip total. Cela permet un éloignement géographique plus important entre les bases de données Primaire et de secours dans le cadre d'une configuration synchrone sans perte de données. Sur les réseaux à faible temps d'attente, l'impact de la réplication SYNC sur les performances de la base de données principale peut être pratiquement nul ; dans ce cas, il peut être intéressant d'associer une base de secours ASYNC distante à une base de secours SYNC locale pour une protection Haute Disponibilité, garantissant l'absence de perte de données, contre les défaillances au niveau des composants et des bases de données (défaillance du SAN, par exemple).

8 Figure 3 : services Data Guard de transport et d'application des informations de journalisation Transport d'informations de journalisation asynchrone (ASYNC) : évite l'impact sur les performances de la base de données Primaire, car celle-ci indique le succès de la validation à l'application sans attendre de confirmation que les données de journalisation ont été reçues par la base de données de secours. Les améliorations de Data Guard 11g ont pratiquement éliminé tout impact sur les performances de la base principale grâce au transfert direct depuis le LOG BUFFER Primaire (et non depuis un fichier de journalisation en ligne) et à l'amélioration du débit des réseaux étendus (WAN) ayant une latence élevée. Toutefois, le gain de performances d'async s'accompagne de la possibilité de perte d'une petite quantité de données, car il n'existe aucune garantie que toutes les données de journalisation ont été reçues par la base de données de secours. Modes de protection Data Guard propose trois modes de protection des données afin d'équilibrer les coûts, la disponibilité, les performances et la protection des données. Chaque mode fait appel à une méthode de transport d'informations de journalisation spécifique et établit des règles qui régissent le comportement de la configuration Data Guard au cas où la base de données Primaire perdrait contact avec sa base de secours. Le tableau ci-après présente les caractéristiques de chaque mode.

9 MODES DE PROTECTION DATA GUARD MODE RISQUE DE PERTE DE DONNEES TRANSPORT EN CAS D'ABSENCE D ACQUITTEMENT DE LA BASE DE DONNEES DE SECOURS : Protection maximale Double défaillance de la protection Zéro perte de données SYNC Blocage de la base de données principale jusqu'à réception d'un acquitement de la base de secours. Disponibilité maximale Défaillance simple de la protection Zéro perte de données SYNC Blocage de la base de données principale jusqu'à réception d'un acquitement ou expiration de la valeur du délai d'attente (NET_TIMEOUT), puis reprise du traitement. Performances maximales Potentiel de perte de données minimale ASYNC La base principale n'attend jamais d acuitement de la base de secours. Services d'application Data Guard Les services d'application (Apply Services) lisent les données de journalisation à partir d'un fichier de journalisation de secours, les valident, puis les appliquent à la base de secours (deuxième étape de la Figure 3) par le biais du mode Redo Apply (base de secours physique) ou SQL Apply (base de secours logique). Notez que les services de transport et d'application sont totalement indépendants. L état ou les performances de l'application de la journalisation dur la base de secours n'ont aucune incidence sur le transport des informations de journalisation ni sur les performances de la base de données principale. Cet isolement est crucial. Le transport des informations de journalisation est le principal facteur déterminant du point de récupération maximum, facteur de risque potentiel de pertes de données. Tout impact négatif sur le transport augmente le risque de pertes de données. Le transport des informations de journalisation dans des configurations synchrones est également crucial dans la détermination de l'impact sur le temps de réponse et le débit de la base de données Primaire. Tout impact négatif sur le transport dans une configuration synchrone peut réduire le débit et augmenter le temps de réponse de la base de données Primaire. L'isolement des opérations de transport et d'application a pour but d'optimiser les performances de la base, son temps de réponse et la protection des données. Redo Apply - Base de secours physique Une base de secours physique applique les données de journalisation reçues de la base Primaire via le processus MRP (Managed Recovery Process), une extension compatible avec Data Guard de la restauration physique Oracle standard utilisée par chaque base de données Oracle. Une base Standby physique est identique à la base Primaire, bloc pour bloc ; par conséquent, les schémas

10 de base de données, notamment les index, sont les mêmes. Le processus MRP est hautement parallèlisé pour permettre des performances maximales. Des tests de performances de Data Guard 11g menés par Oracle ont abouti à des taux de restauration de plus de 50 Mo/s pour une charge de travail de type transactionnel et à plus de 100 Mo/s pour les chargements de données par chemin direct (voir la section Exadata plus bas dans ce document, dans laquelle sont indiquées les données de performances spécifiques au stockage Exadata). Redo Apply est la méthode la plus simple, la plus rapide et la plus fiable de pour maintenir une copie synchronisée d'une base de données Primaire. Redo Apply et Active Data Guard L'option Active Data Guard inclut des fonctionnalités qui étendent les capacités de Redo Apply et des bases de données de Standby physiques. Ces fonctionnalités sont les suivantes : Real-time Query permet un accès en lecture seule à une ou plusieurs bases de données de secours physiques pour, notamment, les requêtes, le tri, la création d'états ou l'accès Web, pendant que Redo Apply applique de façon continue les modifications reçues de la base de données de production. Dans les cas où la charge de travail en lecture seule peut être isolée des transactions en lecture-écriture, Active Data Guard peut véritablement doubler la capacité de production en utilisant une base de données de secours physique existante, jusque-là en état de veille dans le cadre de son rôle de secours. (Vous pouvez ajouter des bases de secours actives supplémentaires à la configuration pour augmenter la capacité de traitements en lecture seule sans impact sur les transactions en lectureécriture). L'option Active Data Guard offre des performances exceptionnelles ; elle peut être utilisée pour des applications à haut débit, pour lesquelles toute autre méthode de réplication ne peut faire face au volume de transactions généré par la base de données source. Vous pouvez implémenter les contrats de niveau de service Active Data Guard à l'aide du paramètre de session STANDBY_MAX_DATA_DELAY. La valeur de ce paramètre spécifie une limite relative au délai (en secondes) pouvant s'écouler entre la validation des modifications sur la base principale et leur disponibilité via des requêtes effectuées sur une base de données de secours active (nouveauté de Data Guard 11g Release 2). La base de secours active renvoie un code d'erreur ORA-3172 si le délai est dépassé. Les applications peuvent répondre à cette erreur de la même façon que pour une déconnexion et rediriger l'interrogation vers une autre base de secours active ou vers la base principale pour se conformer au contrat de niveau de service requis.

11 «Active Data Guard va permettre à MorphoTrak d'économiser jusqu'à dollars sur les coûts associés à nos systèmes stratégiques les plus volumineux. Son utilisation est plus simple que les disques en miroir ou la réplication. Les nouvelles fonctionnalités d'active Data Guard 11g Release 2 garantissent qu'il est possible de satisfaire aux conditions des contrats de niveau de service concernant la précision de la création d'états.» Aris Prassinos, MorphoTrak Active Data Guard 11g Release 2 permet la réparation automatique de blocs corrompus. La perte de données au niveau des blocs résulte généralement d'erreurs d'e/s intermittentes et aléatoires, ainsi que de corruption de mémoire écrites sur le disque. Quand Oracle détecte une corruption, le bloc est marqué comme étant corrompu physiquement, est écrit sur disque et une erreur ORA-1578 est généralement envoyée à l'application. Aucune lecture ultérieure du bloc n'aboutira tant qu'il n'aura pas été restauré manuellement. Toutefois, si l'altération se produit sur une base de données Primaire associée à une base de secours Active Data Guard, la restauration physique de bloc est effectuée automatiquement, de façon transparente vis-à-vis de l'application, en faisant appel à une copie saine du bloc provenant de la base de données de secours. Inversement, les blocs altérés sur la base de secours sont automatiquement restaurés à l'aide de la version saine à partir de la base Primaire. SQL Apply - Base de secours logique Une base de données de secours logique contient les mêmes informations logiques que la base Primaire, bien que la structure et l'organisation physiques des données puissent être différentes. SQL Apply permet de conserver la synchronisation d'une base de secours logique en transformant les données de journalisation reçues de la base principale en instructions SQL, puis en exécutant ces dernières sur une base de secours ouverte en lecture-écriture. SQL Apply comporte quelques restrictions relatives aux types de données, de tables et d'opérations LDD et LMD (voir la documentation sur les types de données et les attributs de stockage non pris en charge). Vous pouvez utiliser SQL Apply si vous remplissez les conditions requises et dans les cas suivants : Vous souhaitez exécuter des applications de création d'états nécessitant un accès en lecture-écriture dans la base de secours. Notez que vous ne pouvez pas modifier les données gérées par SQL Apply. Vous souhaitez ajouter à votre base de données de secours des tables, des schémas, des index et des vues matérialisées qui n'existent pas sur votre base Primaire. Vous allez effectuer une mise à jour active d'une base de données à partir d'une base sous Oracle Database 10g ou réaliser d autres opérations de maintenance sur une base de

12 «Data Guard Logical Standby est un élément important d'une plate-forme matérielle et logicielle stratégique à long terme qui accroît considérablement la capacité et la scalabilité au bénéfice de nos utilisateurs. Après avoir implémenté cette solution complète, nous avons réalisé des gains de performances de 50 % à 95 % dans la plupart des traitement batchs.» David Sink, e-rewards Market Research façon non simultanée (Rolling Mode) pour réduire les risques et l indisponibilité. Si votre base de données fonctionne sous Oracle Database 11g ou une version plus récente, vous pouvez envisager d'utiliser une base de secours physique et le processus de mise à jour utilisant une base Logical Standby de façon transitoire (transient logical standby rolling upgrade). Pour obtenir plus d'informations, consultez la section Maintenance planifiée. Résolution automatique des décalages Lorsque les bases de données Primaire et de secours ne sont plus connectées entre elles (défaillances du réseau ou du serveur de secours), et selon le mode de protection utilisé, la base Primaire va continuer à traiter les transactions et à accumuler une série de données de journalisation qui ne peuvent pas être transférées vers la base de secours tant qu'une nouvelle connexion réseau n'est pas établie. Dans cet état, Data Guard contrôle continuellement le statut de la base de secours, détecte le rétablissement de la connexion et resynchronise automatiquement la base de secours avec la base principale (quatrième étape de la Figure 3). Aucune action humaine n'est requise tant que les fichiers de journalisation archivés nécessaires à la resynchronisation de la base de secours sont disponibles sur disque au niveau de la base principale. En cas de panne prolongée rendant difficile la conservation des fichiers de journalisation archivés nécessaires, une base de secours physique peut être resynchronisée via une sauvegarde incrémentale rapide RMAN de la base principale. Validation de données Oracle L'un des avantages importants de Data Guard est la possibilité d'utiliser des processus Oracle pour valider les données de journalisation avant leur application à la base de secours. Data Guard est une architecture de type «couplage lache» (loosely coupled) dans laquelle les bases de données de secours restent synchronisées par l'application de blocs de journalisation ; elle n'est pas impactée par d'éventuelles corruptions de fichiers de données pouvant se produire au niveau de la base de données Primaire. Les données de journalisation sont également transmises directement depuis la mémoire (SGA - System Global Area) et ne sont pas impactées par une quelconque corruption d'e/s sur les fichiers de journalisation de la base Primaire. Des détections de corruption sont réalisées au niveau de plusieurs interfaces clés au cours du transport et de

13 l'application des informations de journalisation. Le chemin d'accès au code logiciel exécuté sur la base de données de secours est aussi fondamentalement différent de celui de la base principale, ce qui isole la base de secours des erreurs liées au firmware et aux logiciels susceptibles d'affecter la base principale. La base de secours physique fait également appel au paramètre DB_LOST_WRITE_PROTECT, disponible avec Oracle Database 11g Release 1. Une «écriture perdue» survient quand un soussystème d'e/s indique qu'une écriture est terminée alors qu'elle n'a pas eu lieu dans l'unité de stockage persistante. Lors d'une lecture de bloc ultérieure, le sous-système d'e/s renvoie la version obsolète du bloc de données, qui peut être utilisée pour mettre à jour d'autres blocs de la base de données, entraînant sa corrupton. Quand le paramètre d'initialisation DB_LOST_WRITE_PROTECT est défini, la base de données enregistre dans le fichier de journalisation une information sur les blocs lus dans dans le cache de tampons et ces informations sont utilisées par Redo Apply pour déterminer si une «écriture perdue» s'est produite, afin d'éviter toute indisponibilité et perte de données. Gestion d'une configuration Data Guard Les bases de données principale et de secours et leurs diverses interactions peuvent être gérées par l'intermédiaire de SQL*Plus. Data Guard offre également une infrastructure de gestion répartie appelée Data Guard Broker, qui automatise et centralise la création, la maintenance et la surveillance d'une configuration Data Guard. Les administrateurs peuvent interagir avec le Broker via Enterprise Manager Grid Control ou l'interface de ligne de commande de Broker (DGMGRL). Enterprise Manager Grid Control comporte des assistants qui simplifient davantage encore la création d'une configuration Data Guard. Les mesures clés de Data Guard telles que le retard d'application, le retard de transport, le débit de journalisation et l'état de configuration, sont inclus dans une nouvelle Console Haute Disponibilité (HA) consolidée (voir la Figure 4). Enterprise Manager permet d'analyser la tendance historique sur les mesures de performances Data Guard qu'il surveille ; par exemple, l'évolution des mesures de performances dans les dernières 24 heures ou depuis 5 jours, etc. En outre, par l'intermédiaire d'enterprise Manager, il est possible de configurer des alarmes de notification de sorte que les administrateurs soient informés si la mesure dépasse la valeur seuil configurée.

14 «Fast-Start Failover offre un système de basculement simple, rapide et automatique pour notre système de gestion des coupures sur lequel repose PPL pour fournir des services client stratégiques 24h/24 et particulièrement en cas d'urgences. Bien que nous ayons utilisé Data Guard pour la récupération après sinistre depuis Oracle9i, Fast-Start Failover répond à la fois aux besoins en termes de haute disponibilité et de récupération après sinistre, ce qui nous permet de bénéficier de ces deux fonctionnalités dans une seule et même solution.» Chris Carter, PPL Services Corporation Figure 4 : Enterprise Manager Grid Control ( ) Console Haute Disponibilité (HA) Services de gestion des rôles Les services de gestion des rôles de Data Guard permettent d'attribuer rapidement le rôle Primaire à une base de données de secours désignée. Une permutation (SWITCHOVER) est une opération planifiée utilisée pour réduire les temps d'arrêt au cours d'une maintenance planifiée, comme les mises à niveau du système d'exploitation ou du matériel, les Mises à jour actives de la base de données Oracle (Rolling Upgrade) et d'autres tâches de maintenance sur les bases de données. Quel que soit le service de transport (SYNC ou ASYNC) ou le mode de protection utilisé, une permutation est une opération n'entraînant jamais de perte de données. Une bascule (FAILOVER) met une base de données de secours en ligne en tant que nouvelle base Primaire durant une interruption de service non planifiée de la base principale. Une opération de bascule ne nécessite pas un redémarrage de la base de secours afin qu'elle prenne le rôle de base primaire. De plus, tant que les fichiers de la base de données principale d'origine sont intacts et que la base peut être montée, la base principale d'origine peut être rétablie et resynchronisée en tant que base de secours pour la nouvelle base Primaire via Flashback Database ; elle n'a pas à être restaurée depuis une sauvegarde.

15 La bascule manuelle est lancée par l'administrateur via l'interface graphique d'oracle Enterprise Manager, l'interface de ligne de commande de Data Guard Broker ou directement via SQL*Plus. Facultativement, Data Guard peut effectuer une bascule automatique de façon très contrôlée par le biais de Fast-Start Failover. Fast-Start Failover Fast-Start Failover permet à Data Guard d'effectuer une bascule (FAILOVER) automatique vers une base de données de secours préalablement choisie sans qu'aucune intervention manuelle ne soit requise pour lancer cette opération. Un processus de contrôle (Data Guard Observer) surveille en continu l'état d'une configuration Fast-Start Failover. Si l'observateur et la base de secours perdent simultanément la connexion avec la base principale, l'observateur tente de se reconnecter à la base principale pendant une durée configurable, avant de lancer un basculement Fast-Start Failover. Fast-Start Failover est conçu pour s'assurer que sur ses trois membres (la base Primaire, la base de secours et l'observateur) au moins deux sont en accord sur les changements d'états importants pour éviter tout scénario de dissociation («split-brain»). Une fois la base principale réparée et montée, elle doit établir une connexion avec le processus de l'observateur avant de pouvoir s'ouvrir. Une fois ouverte, elle est informée qu'une bascule (FAILOVER) s'est déjà produite et la base principale d'origine est automatiquement rétablie en tant que base de secours de la nouvelle base Primaire. L'architecture simple mais élégante de Fast-Start Failover en fait un excellent choix lorsque la haute disponibilité et la protection des données sont requises simultanément. Automatisation de la bascule de clients La capacité à réaliser rapidement une bascule de base de données n'est que la première des conditions de la haute disponibilité. Les applications doivent aussi pouvoir se déconnecter rapidement d'une base de données principale défaillante, puis se reconnecter rapidement à la nouvelle base Primaire. Une bascule de clients efficace dans un contexte Data Guard comporte trois composants : Bascule de base de données rapide Démarrage rapide des services de base de données sur la nouvelle base Primaire Notification rapide des clients et reconnexion rapide à la nouvelle base Primaire Dans les versions précédentes d'oracle, il fallait un ou plusieurs déclencheurs de base de données écrit par l'utilisateur pour automatiser la bascule de clients, en fonction de la configuration. Data Guard 11g Release 2 simplifie beaucoup la configuration ; les déclencheurs écrits par l'utilisateur ne sont plus nécessaires pour automatiser la bascule de clients. Les changements de rôles gérés par l'interface Data Guard Broker peuvent permettre une bascule automatique de la base de données, le lancement des services appropriés sur la nouvelle base principale, la

16 «Nous avons démontré que le processus de mise à niveau différée des bases de données par le biais d'une base de secours logique transitoire fonctionne. Le temps d'arrêt de l'application lors du passage à une nouvelle version d'oracle est désormais de seulement 4 minutes. Les mises à niveau différées de Data Guard nous ont permis de répondre aux conditions de notre contrat de niveau de service tout en gardant de la marge.» Kenny Snell, United Parcel Service déconnexion des clients de la base défaillante et leur redirection vers la nouvelle base principale. Aucune intervention manuelle n'est requise. Maintenance planifiée Vous pouvez utiliser une base de données de secours Data Guard afin de réduire les temps d'arrêt et les risques pour de nombreux types de maintenances planifiées. L'approche générale consiste à implémenter les modifications dans la base de secours, à réaliser des tests, puis à procéder à la permutation. Toute maintenance n'impliquant pas de différences dans les versions d'oracle ni de modifications de la structure logique de la base de données peut faire appel à Redo Apply. La mise à jour vers de nouvelles versions ou de nouveaux jeux de patches d'oracle Database ou la modification de la structure logique d'une base de données peuvent être réalisées de façon non simultanée par le biais de SQL Apply, soit à l'aide d'une base de données de secours logique, soit à l'aide d'une base de données de secours physique transformée en base de secours logique de façon transitoire. Le seul temps d'arrêt requis pour ce type de maintenance est celui nécessaire pour effectuer une permutation (SWITCHOVER). Les permutations effectuées par le biais de Redo Apply peuvent s'achever en moins de 60 secondes. Pour plus d'informations, consultez le document concernant les meilleures pratiques MAA, Data Guard Switchover and Failover Best Practices (Meilleures pratiques concernant la permutation et le basculement). Les permutations effectuées via SQL Apply sont encore plus rapides étant donné qu'une base de secours logique est déjà ouverte en lecture-écriture. SQL Apply est doté d'un paramètre «GUARD» qui empêche tout changement des données répliquées à partir de la base principale pendant que le rôle de secours lui a été affecté. Une permutation SQL Apply affecte officiellement le rôle de base principale à la base de secours en modifiant simplement le paramètre GUARD. Bien que les durées puissent varier d'un environnement à un autre, le basculement de base de données par l'intermédiaire de SQL Apply peut s'effectuer en moins de 10 secondes. Pour plus d'informations, consultez le document Oracle Japan GRID Center Performance Validation: Data Guard SQL Apply on IBM Power Systems (Validation des performances d'oracle Japan GRID Center : mode SQL Apply d'oracle Data Guard sur IBM Power Systems). Les sections ci-après décrivent de façon détaillée les divers types de maintenances planifiées pouvant être effectuées par le biais d'une base de données de secours Data Guard.

17 Maintenance système,, actualisation technologique, sélection de migrations Les temps d'arrêt et les risques liés à l'exécution de certaines migrations de plates-formes sont réduits grâce à la souplesse de Redo Apply, qui peut prendre en charge des configurations où les systèmes Primaires et de secours peuvent disposer d'architectures processeur, de systèmes d'exploitation (par exemple, Windows et Linux), de fichiers binaires de système d'exploitation (32 bits/64 bits) et de fichiers binaires de base de données Oracle (32 bits/64 bits) différents. Toutefois, les restrictions définies dans la MetaLink Note doivent être prises en compte. Redo Apply sert aussi à effectuer la migration vers Automatic Storage Management (ASM), depuis des bases de données Oracle à instance unique vers Oracle RAC, depuis des anciens systèmes vers des nouveaux en cas d'actualisation technologique ou de passage d'un centre de données au suivant. Mises à niveau non simultanée de bases de données Les mises à niveau du logiciel Oracle Database pour les versions et les jeux de patches principaux ( et suivants) peuvent être effectuées de façon non simultanée tout en bénéficiant d'un temps d'arrêt quasi nul de la base de données à l'aide de SQL Apply. Vous pouvez aussi convertir temporairement des bases de données de secours physiques Data Guard 11g en une base de secours logique transitoire et l'utiliser pour mettre à niveau vers une nouvelle version de base de données de façon non simultanée. Le processus logique transitoire est intéressant, car une seule mise à jour de catalogue est requise pour effectuer la migration des bases Primair et de secours vers la nouvelle version d'oracle. A l'issue du processus de mise à jour, la configuration reprend son état d'origine, à savoir une base Primaire avec une base de secours physique. SQL Apply de Data Guard 11g Release 2 permet d'implémenter une prise en charge étendue des types de données, rendant ainsi possible la réplication d'objet de colonne (avec des types définis par l'utilisateur simples ou imbriqués), des éléments VARRAY et le type spatial SDO_GEOMETRY fourni par Oracle, en cas d'utilisation de SQL Apply pour les migrations et les Mises à jour actives de bases de données. Maintenance des bases de données SQL Apply de Data Guard 11g Release 2 inclut également la prise en charge d'oracle Advanced Compression (OLTP Table Compression), d'oracle SecureFiles et d'online Redefinition. Les bases de données de secours logiques peuvent désormais être utilisées pour implémenter ces fonctions ou effectuer d'autres types de maintenance de base de données sans risque d'incidence sur la production.

18 «Collectivement, l'utilisation des fonctionnalités de haute disponibilité d'oracle et leur implémentation par le biais des meilleures pratiques de l'architecture de disponibilité maximale d'oracle ont permis à Fidelity National Financial de garantir le respect des accords de niveau de service au coût le plus bas.» Charles Kim, Fidelity Information Services Comparaison entre Data Guard et la mise en miroir à distance De nombreux processus de base de données génèrent des E/S sur une base de données Oracle active. Le processus Database Writer met continuellement à jour les fichiers de données, tandis que les mises à jour de fichiers de contrôle et l'archivage local des fichiers de journalisation en ligne génèrent des E/S supplémentaires. Chaque processus est conçu pour fournir des performances et des possibilités de reprise optimales, mais ils peuvent être problématiques pour les solutions de mise en miroir à distance basées sur l OS ou l unité de stockage, l'alternative historique à Data Guard. De telles solutions doivent répliquer chaque écriture effectuée dans chaque fichier, en respectant l'ordre d'écriture, afin de conserver une synchronisation en temps réel d'une réplique à distance. Data Guard est un processus compatible Oracle qui réplique uniquement les écritures effectuées dans le fichier de journalisation en ligne. Des tests internes ont montré que la mise en miroir à distance basée sur une unité de stockage peut transmettre jusqu'à 7 fois le volume et 27 fois plus d'opérations d'e/s réseau que requis par Data Guard. Pour plus d'informations, consultez la section Comparaison de Data Guard avec la mise en miroir à distance. Data Guard propose également les avantages de la validation de données Oracle de bout en bout et une base de données de secours ouverte capable d'endosser rapidement le rôle de base Primaire. Ce que la mise en miroir à distance ne peut assurer, étant donné qu'oracle ne peut pas être monté sur la base de secours pendant la réplication en mode miroir. Data Guard et Exadata Data Guard est la seule technologie capable de gérer une réplique physique et complètement indépendante d'une base de données Oracle résidant sur une unité de stockage Exadata, afin d'assurer une protection contre les défaillances de la base de données ou du site. De plus, la base de secours physique Data Guard étant la solution la plus simple et la plus performante pour la gestion d'une copie indépendante synchronisée de la base de données Oracle, elle est la seule technologie capable de prendre en charge les volumes très élevés générés par une Oracle Database Machine. Dans le cadre de tests Oracle Database 11g Release 2 internes menés sur une Oracle Database Machine, Redo Apply a pu appliquer des modifications à une base de données de secours à un rythme supérieur à 500 Mo/s. Pour plus d'informations, veuillez consulter la page d'accueil MAA sur le site Oracle Technology Network.

19 Data Guard et Oracle Real Application Clusters Data Guard et Oracle RAC sont des technologies complémentaires fournissant le niveau le plus élevé possible en matière d'évolutivité, de disponibilité et de protection de données. On peut utiliser toute combinaison d'oracle RAC et de bases de données mono-instance pour assurer tout rôle dans une configuration Data Guard. Oracle RAC constitue la solution Haute Disponibilité idéale de protection contre toute défaillance du serveur tout en fournissant des fonctions uniques dans le monde logiciel qui permettent d'assurer la gestion de la charge de travail et la scalabilité. Data Guard fournit un niveau supplémentaire de disponibilité et de protection des données grâce à une redondance complète qui réduit les temps d'arrêt dus aux facteurs suivants : défaillance d'unités de stockage, erreurs d'opérateur, maintenances planifiées spécifiques ne pouvant pas être effectuées de façon non simultanée sur des nœuds Oracle RAC, défaillances multiples et corrélées pouvant aboutir à une défaillance de la base de données (par exemple, défaillance d'une unité de stockage SAN) ou du site (par exemple, incendie, inondation, ouragan ou tremblement de terre). Architecture de disponibilité maximale L'architecture de disponibilité maximale (MAA, Maximum Availability Architecture) est un modèle de meilleures pratiques testé par Oracle et validé par les clients pour le déploiement de technologies haute disponibilité Oracle. L'architecture MAA a pour objectif de simplifier et d'accélérer la courbe d'apprentissage du client en matière de conception et d'utilisation de l'architecture haute disponibilité optimale. Les meilleures pratiques MAA comportent des recommandations sur divers aspects d'une configuration Data Guard, comme une configuration avec Oracle RAC, l'optimisation du transport des informations de journalisation, les opérations de permutation/basculement, le basculement de clients, les performances de Redo Apply, la configuration et le réglage de SQL Apply, ainsi que l'utilisation du stockage Exadata et d'oracle Database Machine.

20 «Notre stratégie de récupération a toujours reposé sur les sauvegardes sur bande. Nous avons également installé Oracle Data Guard en vue d'y avoir éventuellement recours un jour. Et puis un SAN a subi une panne totale, suivie deux mois plus tard par une altération grave des disques sur un autre SAN. Ces deux incidents étaient le résultat indirect de coupures de courant. Dans ces deux cas, Data Guard nous a permis de récupérer nos données sans aucune perte. Je me rends compte à présent que cette solution n'est pas un «recours éventuel», mais qu'elle est véritablement indispensable!» Rachel Slade, Oxford Brookes University Clients Data Guard La fonctionnalité Data Guard a d'abord été disponible avec Oracle Version 7. Elle n'a cessé de s'enrichir et est devenue une technologie plus évoluée à chaque nouvelle version d'oracle. Elle est déployée pour les applications stratégiques dans les infrastructures de clients du monde entier. Plusieurs études de cas d'implémentation détaillées figurent sur le site Oracle Technology Network. Conclusion Oracle Data Guard 11g modifie fondamentalement les concepts de récupération après sinistre classiques en offrant une solution intégrée combinant haute disponibilité et récupération après sinistre qui inclut un niveau de protection des données inégalé et grâce à laquelle les systèmes de secours prennent simultanément en charge des fonctions de production ou de test lorsque le rôle de secours leur est affecté. Data Guard est une solution complète assurant la protection et la disponibilité des données, ainsi que la récupération après sinistre pour Oracle Database. Elle offre une infrastructure souple et simple à gérer permettant de faire face aux pannes de courant planifiées ou non. Les bases de données de secours physiques et logiques garantissent une protection des données de haut niveau tout en déchargeant les bases de données primaires. Les divers modes de protection de données sont suffisamment souples pour s'adapter à différents niveaux de besoins en matière de protection, de performances et d'infrastructure. L'interface Data Guard Broker, combinée à Oracle Enterprise Manager, offre une infrastructure de configuration et de gestion conviviale. Quel que soit le degré d'intégration antérieur de la haute disponibilité dans une infrastructure informatique faisant appel aux clusters, aux disques en miroir et à diverses stratégies de sauvegarde et de récupération, il est indéniable que la protection, la disponibilité des données et le retour sur vos investissements informatiques sont globalement améliorés par l'intégration de Data Guard dans votre architecture informatique.

21 Annexe : récapitulatif des nouvelles fonctions de Data Guard 11g DATA GUARD 11G RELEASE 1 DOMAINE FONCTION Oracle Active Data Guard La base de données de secours physique s'ouvre en lecture seule lorsque l'opération d'application est active. Obtention de résultats à jour pour les interrogations de la base de secours Suivi de modification de bloc par RMAN pour des sauvegardes incrémentielles rapides sur une base de secours physique Active Data Guard Snapshot Standby Ouverture temporaire d'une base de données de secours en lecture-écriture tout en offrant une protection contre les sinistres Complément idéal d'oracle Real Application Testing Fast-Start Failover Transport asynchrone et performances maximales ; seuil configurable pour atteindre la quantité minimum de perte de données acceptable, voire aucune pert (Recovery Point Objective)Lancement d'un basculement automatique selon des conditions de vérification d'état définies préalablement ou à la demande de l'application Observateur à tolérance de panne pour Fast-Start Failover ; redémarrage automatique de l'observateur défaillant sur un second hôte Transport des informations de journalisation Transport des informations de journalisation asynchrone pour un débit supérieur sur les réseaux étendus à latence élevée Compression des informations de journalisation transportées lors de la résolution des décalages des journaux d'archivage Performances de Redo Apply Amélioration des performances de Redo Apply, doublement des performances de Data Guard 10g Diverses améliorations au niveau des performances de SQL Apply ; application de LDD parallèle en parallèle sur la base de secours Arrêt planifié Mises à jour actives de bases de données à l'aide de bases de secours physiques (base standby logique transitoire)souplesse accrue pour les configurations principale/de secours mixtes afin de faciliter les possibilités de migrations Protection Protection contre les «écritures perdues» à l'aide d'une base de secours physique Sécurité L'authentification SSL peut être utilisée à la place du fichier de mots de passe pour authentifier la transmission d'informations de journalisation

22 Changements de rôles Travaux de planificateur spécifiques aux rôles sur une base de données de secours logique via DBMS_SCHEDULER Les permutations SQL Apply ne nécessitent plus l'arrêt préalable de toutes les instances sauf une dans chaque cluster Oracle RAC, principal ou de secours Travaux et seuils de mesure Enterprise Manager propagés vers la nouvelle base de données principale lors du changement de rôle Data Guard Broker fonctionne de façon transparente avec des solutions Cold Cluster Failover contrôlées par Oracle Clusterware Types de données SQL Apply Prise en charge de SQL Apply pour XMLType (en cas de stockage en tant que CLOB), Transparent Data Encryption (TDE), DBMS_FGA (Fine Grained Auditing), DBMS_RLS (Virtual Private Database) Facilité de gestion Statspack de secours pour le réglage des performances d'application sur une base de secours Active Data Guard Histogramme de temps de réponse du transport d'informations de journalisation utilisé pour déterminer la valeur appropriée pour NET_TIMEOUT Paramètres SQL Apply de Data Guard définis dynamiquement via DBMS_LOGSTDBY.APPLY_SET Création de bases de secours directement à partir de la base principale à l'aide de RMAN, sans stockage ponctuel Conversion de bases de secours à instance unique vers Oracle RAC par le biais de l'assistant Enterprise Manager DATA GUARD 11G RELEASE 2 DOMAINE FONCTION Oracle Active Data Guard Application automatique des objectifs au niveau des services pour l'obtention d'un délai maximal relatif aux données en cas d'interrogation d'une base de secours active Réparation en ligne automatique de blocs altérés à l'aide d'une base de secours active Transport des informations de journalisation Améliorations du transport des informations de journalisation synchrone réduisant la surcharge de la base principale Compression du transport des informations de journalisation synchrone et asynchrone Prise en charge de 30 bases de secours au maximum pour une base principale (la limite précédente était 9) Performances de Redo Apply Amélioration de Redo Apply, portant la vitesse d'application soutenue maximale à plus de 500 Mo/s sur Oracle Database Machine avec une unité de stockage Exadata Arrêt planifié Prise en charge transparente pour la redéfinition basée sur Oracle Edition, Redo et SQL Apply

23 SQL Apply peut être utilisé pour une migration sans risque et avec arrêts minimum, lors de l'implémentation d'oracle SecureFiles, Warehouse Compression, OLTP Table Compression ou Online Redefinition Protection Les données de journalisation non envoyées dans les configurations asynchrones par le biais de performances maximales peuvent être envoyées vers une base de secours avant le basculement, afin d'éviter toute perte de données (en considérant que la base principale puisse passer à l'état montée) Changements de rôles Les permutations Redo Apply ne nécessitent plus l'arrêt d'instances de secours L'interface Data Guard Broker utilise les services de base de données fondés sur des rôles pour automatiser le basculement de clients Les changements de rôles gérés de l'interface Data Guard Broker fonctionnent de façon transparente avec Oracle Restart Types de données SQL Apply Oracle SecureFiles, Warehouse Compression et OLTP Table Compression Meilleure prise en charge des types de données étendues par SQL Apply pour la réplication des objets de colonne (avec des types définis par l'utilisateur simples ou imbriqués), VARRAYS et le type spatial fourni par Oracle SDO_GEOMETRY Facilité de gestion Performances accrues pour des transactions très volumineuses (plus de 8 millions de lignes) lors de l'utilisation de SQL Apply Une base de données de secours logique peut être une base source dans une configuration Oracle Streams Des déclencheurs peuvent être définis sur une base de secours logique en vue de réaliser des traitements locaux indépendants de la base principale. L'interface Data Guard Broker a amélioré la détection des statuts et des erreurs. La fonction Data Recovery Advisor va utiliser la base de secours disponible pour Intelligent Data Repair