Oracle Database 11g Release 2 : facilité de gestion et présentation de Real Application Testing

Transcription

1 Livre blanc Oracle Août 2009 Oracle Database 11g Release 2 : facilité de gestion et présentation de Real Application Testing

2 Introduction... 3 Problèmes liés à la gestion... 3 Gestion des performances... 4 Diagnostic des performances... 4 Automatic Workload Repository... 4 Automatic Database Diagnostics Monitor... 5 AWR Baselines et Adaptive Thresholds... 7 Ajustement des applications... 7 SQL Tuning Advisor et SQL Access Advisor... 8 Ajustement SQL automatique Real Time SQL Monitoring SQL Plan Management Gestion des modifications Détection des modifications Test des modifications Real Application Testing Database Replay SQL Performance Analyzer Automatisation des modifications Environnements de bases de données configurés en toute sécurité Administration en continu Gestion des ressources Gestion automatique de la mémoire (Automatic Memory Management) Gestion de l'espace Diagnostic des erreurs Automated Health Checks SQL Test Case Builder Automatic Diagnostic Repository (ADR) Incident Packaging Service (IPS) Support Workbench Quels avantages pouvez-vous en tirer? Conclusion... 29

3 Introduction La base de données Oracle est leader du marché. Elle est, en outre, la base de données préférée de centaines de milliers d'entreprises, de développeurs d'applications et d'administrateurs de bases de données du monde entier. Au fil du temps, les entreprises se sont de plus en plus appuyées sur la base de données Oracle pour obtenir des performances et une fiabilité sans précédent. Avec la version 10g de la base de données, Oracle proposait une base de données autogérée, présentant une facilité de gestion exceptionnelle qui permettait de réduire considérablement les coûts de gestion. Avec la version Oracle Database 11g, Oracle place la barre encore plus haut. Conçue pour les environnements de centres de données qui évoluent rapidement et changent pour s'adapter aux besoins de l'entreprise, la version Oracle Database 11g permet aux entreprises d'adopter rapidement de nouvelles technologies, tout en limitant les risques. De plus, forte de ses capacités d'autogestion, la version Oracle Database 11g vous fera bénéficier de ses importantes améliorations en termes de facilité de gestion et de diagnostic des pannes. Problèmes liés à la gestion Trois domaines continuent de poser de réels problèmes de gestion aux administrateurs de bases de données : Les performances : comment faire pour que les bases de données de production fournissent des performances maximales afin de respecter les niveaux de service? La gestion des modifications : comment apporter des modifications (modifications de routine ou introduction d'innovations technologiques) dans les environnements de bases de données Oracle à moindre coût, tout en limitant les risques? L'administration en continu : comment automatiser les tâches quotidiennes répétitives pour que le personnel en soit libéré et se concentre sur des besoins plus stratégiques, tels que la sécurité et la haute disponibilité? Pour résoudre ces problèmes, Oracle Database 11g présente d'importantes améliorations en termes de performances, d'introduction des modifications et d'autogestion, de sorte que les bases de données Oracle sont encore plus faciles à gérer. 3

4 Gestion des performances De tous temps, la gestion des performances a représenté un véritable défi pour les administrateurs de bases de données. Grâce aux capacités d'autogestion d'oracle Database 11g, la gestion des performances des bases de données est plus simple que jamais. De plus, Oracle Database 11g voit ses capacités d'autogestion s'étendre à tous les domaines, tels que les deux principaux axes de gestion des performances des bases de données : le diagnostic des performances et l'ajustement des applications. Diagnostic des performances Les étapes qui permettent d'obtenir de bonnes performances consistent à recueillir les données appropriées, à effectuer une analyse en bonne et due forme, puis à trouver un plan d'action efficace. La structure d'autogestion d'oracle Database 11g effectue ces tâches pour l'administrateur de bases de données, ce qui facilite et banalise le diagnostic des performances. L'Automatic Workload Repository recueille les données requises et l'automatic Database Diagnostics Monitor les analyse, puis formule des recommandations ciblées, concrètes et applicables. Découvrons ces éléments en détail. Automatic Workload Repository L'Automatic Workload Repository (AWR) est un référentiel intégré à chaque base de données Oracle Database 11g, qui contient des statistiques d'exploitation concernant cette base de données en particulier et d'autres informations connexes. A intervalles réguliers, Oracle Database 11g prend un instantané de toutes ses statistiques vitales et informations de charge de travail, puis les stocke dans l'awr. Par défaut, les instantanés sont pris toutes les 60 minutes, puis stockés dans l'awr pendant 8 jours ; après quoi, ils sont automatiquement supprimés. L'administrateur peut facilement modifier ces paramètres par défaut. AWR est un élément léger et autogéré qui ne demande aucun effort de gestion supplémentaire aux administrateurs. Les données capturées peuvent faire l'objet d'analyses au niveau du système et de l'utilisateur, ce qui évite d'avoir à répéter la charge de travail pour diagnostiquer les problèmes. AWR a été optimisé pour que la capture des données soit effectuée le plus efficacement possible afin de réduire la surcharge. AWR constitue la base sur laquelle reposent toutes les fonctionnalités d'autogestion d'oracle Database 11g. Grâce à cette source d'informations, Oracle Database 11g dispose d'un historique sur la façon dont elle est utilisée, ce qui lui permet de prendre des décisions précises et adaptées à l'environnement dans lequel elle fonctionne. 4

5 Automatic Database Diagnostics Monitor Oracle Database 11g inclut un moteur d'autodiagnostic, baptisé Automatic Database Diagnostic Monitor (ADDM), qui s'appuie sur les données capturées dans l'awr. ADDM permet à Oracle Database 11g de diagnostiquer ses propres performances et de trouver une solution aux problèmes identifiés. ADDM s'exécute automatiquement après chaque capture de statistiques par AWR et met immédiatement à disposition les données du diagnostic des performances. ADDM examine les données capturées dans AWR et effectue une analyse pour déterminer les principaux problèmes sur le système de façon proactive, recommande des solutions et quantifie les avantages attendus. ADDM adopte une approche holistique en matière de performances système et utilise le temps comme critère commun aux composants. L'objectif d'addm est d'identifier les zones du système qui consomment le plus de «temps de base de données». ADDM explore le système en profondeur pour identifier la cause des problèmes (plutôt que de s'en tenir aux symptômes) et signale l'impact qu'ils ont sur l'ensemble du système. S'il fait une recommandation, il indique également les avantages qui peuvent en découler, toujours en termes de temps. En prenant le temps comme critère commun, il est possible de comparer l'impact potentiel de plusieurs problèmes ou recommandations. Auparavant, de nombreux problèmes étaient identifiés en termes de jugements de valeur et d'expérience, plutôt qu'en termes d'impacts quantifiables. Prenons, par exemple, un système faisant l'objet d'un taux de connexion élevé. En règle générale, un taux de connexion supérieur à 10 par secondes serait considéré comme un problème et imposerait une correction. Toutefois, de nombreux systèmes sont capables de supporter des taux de connexion plus élevés sans que cela n'affecte leurs performances outre mesure. En utilisant les données de distribution du temps d'awr, ADDM peut signaler quantitativement que les connexions prennent 20 % du temps passé dans la base de données. Cette valeur quantifiée et explicite peut aider à convaincre la personne concernée de la nécessité de résoudre le problème, au lieu de simplement lui dire : «Je pense que vous vous connectez trop souvent». ADDM commence son analyse en se concentrant sur les activités sur lesquelles la base de données passe le plus de temps, puis suit un cheminement sophistiqué de classification des problèmes. Ce cheminement utilisé par ADDM est le résultat de dizaines d'années d'expérience en matière d'ajustement des performances du Server Technologies Performance Group acquises par Oracle et d'autres experts du domaine. Lors du développement de l'arborescence de classification, le principal objectif était de gérer les problèmes les plus fréquents et de remonter jusqu'à leur cause profonde, au lieu de s'en tenir à signaler les symptômes. Voici quelques-uns des problèmes courants détectés par ADDM : Goulots d'étranglement au niveau de l'uc Mauvaise gestion des connexions Analyse excessive 5

6 Conflit de verrouillage Capacité d'e/s Sous-dimensionnement des structures de mémoire Oracle (PGA, cache des tampons, tampon du journal) Instructions SQL à charge élevée Temps PL/SQL et Java élevé Charge de point de vérification élevée et cause, par exemple, petits fichiers journaux Problèmes propres à RAC En plus de signaler les éventuels problèmes de performances, ADDM documente également les zones saines du système. Les sous-composants tels que les E/S, la mémoire et autres, qui n'affectent pas les performances du système de façon significative, sont retirés de l'arborescence de classification dès le départ et répertoriés pour que l'administrateur de bases de données voie rapidement qu'il est inutile de prendre des mesures à ce niveau. Cela permet de gagner du temps et d'économiser des ressources humaines et matérielles. Oracle Database 11g étend ADDM en améliorant considérablement l'analyse des performances à l'échelle du cluster pour les bases de données Real Application Clusters (RAC). Pour les environnements RAC, ADDM analyse le cluster RAC et signale les problèmes qui affectent l'ensemble de la base de données, ainsi que ses instances individuelles. Les administrateurs de bases de données peuvent désormais utiliser ADDM pour analyser les ressources globales à l'échelle de la base de données (instructions SQL à charge élevée, trafic d'interconnexion du cache global, problèmes de latence du réseau, de temps de réponse d'une instance et capacité d'e/s). Oracle Database a été le premier produit de base de données à introduire une telle fonctionnalité révolutionnaire d'autodiagnostic et a complètement redéfini le concept d'administration des bases de données. Les administrateurs n'ont plus besoin de recueillir de vastes quantités de données de diagnostic, ni de passer des heures à les analyser afin de trouver des réponses aux problèmes de performances. Grâce à Oracle Database 11g, ils peuvent simplement demander à la base de données quels sont les problèmes de performances et ADDM se charge du reste. Ils peuvent retrouver un maximum de sérénité et suivre les recommandations faites par ADDM en quelques clics. 6

7 AWR Baselines et Adaptive Thresholds L'utilité et la valeur de l'awr prennent de plus en plus d'ampleur dans Oracle Database 11g. La nouvelle fonction AWR Baselines permet aux administrateurs de bases de données de capturer et d'enregistrer des données de performances système sur des périodes dont les charges de travail sont représentatives ou présentent un intérêt particulier. Le rapport AWR Compare Periods est fourni pour faciliter les comparaisons entre des périodes posant problème et les Baselines (références) enregistrées afin d'identifier les éventuelles sources des variations de performances. Outre les mesures de performances, le rapport recueille également des informations de configuration, telles que la quantité totale de mémoire et le nombre d'uc, qui peuvent permettre d'identifier des sources externes de problèmes susceptibles d'être à l'origine de la baisse des performances. En cas de modifications hors bande apportées à des paramètres stratégiques, tels que COMPATIBLE, susceptibles d'affecter les performances SQL, le rapport capture également les informations du système de base de données, telles que les paramètres d'initialisation. De plus, la fonction AWR Baselines peut également être utilisée pour définir des seuils d'alerte sur les mesures de performances système. La plupart des mesures peuvent être consultées dans Oracle Enterprise Manager et comparées à des agrégats statistiques de ces mêmes mesures observées sur la période de référence. Cela permet aux utilisateurs de définir des seuils en fonction des références plutôt que de les sélectionner sans tenir compte du contexte des données réelles. De plus, des seuils adaptables (Adaptive Thresholds) sont disponibles pour certaines mesures de performances clés. Les seuils adaptables sont des seuils d'alerte définis de façon automatique et ajustés de façon régulière par le système en fonction des données System Moving Window Baseline. Pour les clients qui souhaitent commencer à utiliser ces seuils adaptables immédiatement, la nouvelle option «Quick Configure» peut configurer, en quelques clics, un premier ensemble de seuils reposant sur des profils de charge de travail courants. AWR Baselines fournit de puissantes capacités pour la définition de références dynamiques et futures, et simplifie largement le processus de création et de gestion des données de performances qui serviront à faire des comparaisons. Ajustement des applications Les problèmes de conception des applications sont la principale cause de problèmes de performances. L'expérience des développeurs, des administrateurs de bases de données et des administrateurs système en matière d'ajustement ne peut malheureusement rien contre le ralentissement provoqué par les problèmes de conception et d'architecture d'une application. Par conséquent, une part importante de l'ajustement des performances système des bases de données consiste à ajuster les instructions SQL. 7

8 L'optimiseur de requête prend des décisions cruciales qui affectent largement les performances d'une requête (faut-il utiliser un index ou non, quelles techniques de jointure utiliser si la requête implique de joindre plusieurs tables, etc.). C'est pourquoi Oracle a fait des efforts considérables en matière de développement pour donner naissance à l'optimiseur de requête le plus avancé, le plus sophistiqué et le mieux testé de l'industrie, baptisé Cost-Based Optimizer. Le Cost-Based Optimizer est également largement utilisé par les principales applications packagées telles qu'oracle ebusiness Suite, SAP, PeopleSoft, etc. Etant donné que la base de données Oracle est la plate-forme employée par la majorité des clients qui utilisent ces applications, cela prouve le succès de l'optimiseur d'oracle dans un très grand nombre de paramètres d'applications réels. Ainsi, depuis Oracle Database 10g, le Rule-Based Optimizer (RBO) n'est plus disponible et le Cost-Based Optimizer est le seul optimiseur pris en charge. Alors qu'oracle Database fournit la meilleure technologie d'optimisation de requête possible, capable de maximiser les performances application/requête sans nécessiter l'intervention de l'administrateur dans la plupart des cas, il peut subsister quelques cas où la nature de l'application ou le caractère unique de la distribution des données peut obliger certaines instructions SQL à consommer un pourcentage exceptionnellement élevé du total des ressources système. Dans ces rares cas, le processus d'ajustement SQL implique trois étapes de base : identifier les instructions SQL les plus exigeantes ou à charge élevée responsables d'une grande partie de la charge de travail applicative et de l'utilisation des ressources système, en consultant l'historique d'exécution SQL disponible dans le système (par exemple, les statistiques du cache de curseurs stockées dans la vue dynamique V$SQL) ; vérifier que les plans d'exécution produits par l'optimiseur de requête pour ces instructions affichent des performances raisonnables ; prendre d'éventuelles mesures correctives pour produire de meilleurs plans d'exécution pour les instructions SQL qui affichent de piètres performances. Ces trois étapes sont répétées jusqu'à ce que les performances système atteignent un niveau satisfaisant ou jusqu'à ce qu'il n'y ait plus d'instruction à ajuster. Outre le fait qu'il prend énormément de temps, le processus d'ajustement SQL décrit ci-dessus requiert également une haute expertise. Seule une personne disposant de connaissances approfondies sur l'application et le système de base de données peut s'y atteler. SQL Tuning Advisor et SQL Access Advisor Depuis Oracle Database 10g, le processus d'ajustement SQL est entièrement automatisé. ADDM identifie les instructions SQL qui consomment une quantité anormalement élevée de ressources système et posent donc des problèmes de performances. De plus, les instructions SQL qui consomment le plus de capacités de traitement et de mémoire partagée sont automatiquement capturées dans AWR. Ainsi, dans la nouvelle structure d'ajustement, l'identification des 8

9 instructions SQL à charge élevée est automatique et ne requiert aucune intervention de l'administrateur. Une fois que les instructions SQL les plus gourmandes en ressources ont été identifiées, Oracle Database peut les analyser automatiquement et recommander des solutions en utilisant la fonction d'ajustement automatique récemment ajoutée à l'optimiseur de requête, baptisée Automatic Tuning Optimizer. L'ajustement SQL automatique (Automatic SQL Tuning) est exposé via un module-conseil baptisé SQL Tuning Advisor. Le SQL Tuning Advisor prend une ou plusieurs instructions SQL et produit des plans adaptés comportant des conseils d'ajustement. Il suffit à l'administrateur d'appeler le SQL Tuning Advisor pour qu'il recommande une solution. Il est important de garder à l'esprit que la solution émane directement de l'optimiseur, et non d'outils externes utilisant une méthode heuristique prédéfinie. Cela présente plusieurs avantages : a) l'ajustement est fait par le composant système responsable des plans d'exécution, b) le processus d'ajustement est basé sur les coûts et justifie les modifications et améliorations apportées à l'optimiseur de requête, c) le processus d'ajustement tient compte des précédentes statistiques d'exécution d'une instruction SQL et personnalise les paramètres de l'optimiseur pour cette instruction, et d) il recueille des informations auxiliaires aux statistiques régulières en fonction de ce que l'optimiseur de requête juge utile. La recommandation de l'automatic Tuning Optimizer fera partie de l'une des catégories suivantes : Analyse statistique : l'automatic Tuning Optimizer vérifie les statistiques manquantes ou obsolètes de chaque objet de requête et formule des recommandations pour recueillir des statistiques pertinentes. Il collecte également des informations auxiliaires pour fournir les statistiques manquantes ou corriger les statistiques obsolètes au cas où les recommandations ne seraient pas mises en œuvre. Profilage SQL : l'automatic Tuning Optimizer vérifie ses propres estimations et collecte des informations auxiliaires pour éliminer les erreurs d'estimation. Il recueille également des informations auxiliaires sous forme de paramètres d'optimiseur personnalisés (par ex., premières lignes contre toutes les lignes), en fonction de l'historique d'exécution de l'instruction SQL. Il génère un profil SQL (SQL Profile) en utilisant les informations auxiliaires et fait une recommandation pour le créer. Lorsqu'un profil SQL est créé, il permet à l'optimiseur de requête (en mode normal) de générer un plan adapté. Le principal atout des profils SQL est qu'ils permettent d'ajuster les requêtes sans modification syntaxique. Ainsi, les administrateurs Oracle disposent d'une solution pour ajuster les instructions SQL incorporées aux applications packagées. Analyse de chemin d'accès : l'automatic Tuning Optimizer détermine si un nouvel index peut être utilisé pour améliorer l'accès à chaque table de la requête et, si nécessaire, fait des recommandations pour créer ces index. 9

10 Analyse de structure SQL : ici, l'automatic Tuning Optimizer essaie d'identifier les instructions SQL qui se prêtent à de mauvais plans et fait des suggestions pertinentes pour les restructurer. Les restructurations suggérées peuvent être des modifications syntaxiques ou sémantiques à apporter au code SQL. Les analyses de chemin d'accès et de structure SQL peuvent s'avérer extrêmement utiles lors de l'ajustement des performances d'une application en cours de développement ou d'une application de production «maison» pour laquelle les administrateurs/développeurs ont accès au code. SQL Access Advisor est également un composant clé de la facilité de gestion d'oracle Database. Il peut analyser automatiquement la conception de schéma pour une charge de travail donnée et recommander des index, des vues matérialisées et des journaux de vues matérialisées à créer, à conserver ou à déplacer selon les besoins de la charge de travail. Lors de la génération des recommandations, SQL Access Advisor tient compte de l'impact que pourrait avoir l'ajout de nouvelles structures d'accès sur les activités de manipulation de données (insertion, mise à jour et suppression), en plus des améliorations qu'elles devraient offrir aux requêtes en termes de performances. SQL Access Advisor propose une interface très conviviale et requiert très peu de connaissances système. Il peut également être exécuté sans affecter les systèmes de production, car les données peuvent être recueillies auprès du système de production et transférées sur une autre machine sur laquelle SQL Access Advisor peut être exécuté. Dans Oracle Database 11g, SQL Access Advisor a été amélioré pour offrir des conseils sur les partitions dans le cadre des recommandations de structures d'accès SQL. Ajustement SQL automatique Dans Oracle Database 11g, le processus d'ajustement SQL a également été amélioré et automatisé pour que les bases de données puissent fournir des performances maximales. SQL Tuning Advisor s'exécute désormais automatiquement pendant les fenêtres de maintenance du système, en tant que tâche de maintenance. A chaque exécution, il sélectionne automatiquement dans le système les requêtes SQL à charge élevée et génère des recommandations pour les ajuster. Dans Oracle Database 11g, pour valider la recommandation, SQL Tuning Advisor effectue une exécution test des instructions SQL avec le nouveau plan d'exécution pour lequel un profil SQL est recommandé. De ce fait, la précision et la fiabilité des recommandations de profil SQL sont considérablement accrues. Automatic SQL Tuning Advisor peut être configuré pour mettre en œuvre automatiquement les recommandations de profil SQL. Si vous activez la mise en œuvre automatique, le moduleconseil créera des profils SQL uniquement pour les instructions SQL dont les performances pourraient être améliorées et multipliées par trois, au moins. Les autres types de recommandations, comme celles indiquant de créer de nouveaux index ou d'actualiser les statistiques de l'optimiseur ou celles qui restructurent le code SQL, ne peuvent être mises en œuvre que manuellement. Les instructions DML ne sont pas prises en compte par l'automatic 10

11 SQL Tuning Advisor pour l'ajustement. Par défaut, l'automatic SQL Tuning Advisor est configuré pour s'exécuter de nuit et faire des recommandations, mais pas pour les mettre en œuvre. Vous pouvez voir un résumé des résultats de l'ajustement SQL automatique pour une période précise (par ex., pour les 7 jours précédents) et afficher un rapport détaillé des recommandations faites pour toutes les instructions SQL traitées. Vous pouvez ensuite choisir les recommandations à mettre en œuvre, en procédant manuellement. Vous pouvez également voir les recommandations qui ont été mises en œuvre automatiquement. L'Automatic SQL Tuning Advisor peut être configuré pour s'exécuter pendant les fenêtres de maintenance ou peut être totalement désactivé. Real Time SQL Monitoring La fonction Real Time SQL Monitoring d'oracle Database 11g permet de surveiller les performances des instructions SQL en cours d'exécution. Les plans d'exécution en direct des longues instructions SQL sont automatiquement affichés sur la page SQL Monitor d'enterprise Manager à l'aide de nouvelles statistiques détaillées, prêtes à l'emploi. Par défaut, SQL Monitoring démarre automatiquement lorsqu'une instruction SQL s'exécute en parallèle ou lorsque celle-ci a consommé au moins 5 secondes du temps UC ou E/S en une seule exécution. L'administrateur de bases de données peut observer les étapes des instructions SQL tout au long du plan d'exécution, en affichant les statistiques de chaque étape en cours. A chaque étape du plan d'exécution, les informations de contenu sont suivies via des mesures de performances clés, telles que le temps écoulé, le temps UC, le nombre de lectures et d'écritures, les attentes d'e/s et autres temps d'attente. SQL Monitoring permet à l'administrateur de bases de données de savoir quelles étapes les instructions SQL longues sont en train d'exécuter, ce qui lui permet de déterminer si des ajustements supplémentaires sont nécessaires. Dans Oracle Database 11g Release 2, Real Time SQL Monitoring a été amélioré pour prendre en charge les plans d'exécution dont une partie du traitement incombe à la machine Oracle Database, Exadata. 11

12 Figure 1 : plan d'exécution Real Time SQL Monitoring Dans Oracle Database 11g Release 2, en plus de pouvoir surveiller les instructions SQL en temps réel, l'administrateur de bases de données peut également enregistrer tous les détails d'exécution dans un rapport actif, c'est-à-dire un rapport interactif qui peut être utilisé pour l'analyse hors connexion. Ce dernier offre le même niveau d'interactivité que les écrans en direct, avec des possibilités d'exploration vers divers niveaux de détail. SQL Plan Management SQL Plan Management empêche les régressions de performances liées aux modifications soudaines du plan d'exécution d'une instruction SQL, en fournissant des composants permettant de capturer, sélectionner et faire évoluer les plans d'exécution SQL. En effet, les performances SQL peuvent être affectées par diverses modifications telles qu'une nouvelle version de l'optimiseur, de nouvelles statistiques et/ou nouveaux paramètres d'optimiseur, ou encore la création de profils SQL. SQL Plan Management est donc un mécanisme préventif qui enregistre et évalue les plans d'exécution des instructions SQL dans le temps, et génère des références de plans SQL à partir d'un ensemble de plans existants jugés efficaces. Les références de plans SQL sont ensuite utilisées pour maintenir les performances des instructions SQL correspondantes, quelles que soient les modifications apportées au système. Voici quelques scénarios d'utilisation courants dans lesquels SQL Plan Management peut améliorer ou maintenir les performances SQL : Une mise à niveau de base de données qui installe une nouvelle version d'optimiseur entraîne généralement des modifications de plan pour un faible pourcentage 12

13 d'instructions SQL ; la plupart de ces modifications de plan n'ayant aucun effet sur les performances ou entraînant plutôt une amélioration. Toutefois, certaines modifications de plan peuvent faire baisser les performances. L'utilisation des références de plans SQL a permis de réduire considérablement les éventuelles baisses de performances résultant d'une mise à niveau de base de données. Les modifications en cours apportées aux données et au système peuvent également affecter les plans de certaines instructions SQL et donc éventuellement faire baisser les performances. L'utilisation des références de plans SQL peut également aider à limiter les baisses de performances dans ce cas et à les stabiliser. Le déploiement de nouveaux modules d'applications suppose d'introduire de nouvelles instructions SQL dans le système. Le logiciel d'application peut utiliser les plans d'exécution SQL appropriés, développés selon une configuration test standard, pour les nouvelles instructions SQL. Les références de plans SQL évoluent dans le temps pour fournir de meilleures performances. Au cours de la phase d'évolution des références de plans SQL, Oracle Database 11g évalue régulièrement les performances des nouveaux plans et intègre ceux qui affichent les meilleures performances aux références de plans SQL. La vérification d'un nouveau plan consiste à comparer ses performances à celles d'un plan sélectionné à partir de la référence de plans SQL et à s'assurer qu'il est plus performant. Migration des structures stockées vers les références de plans SQL Avant l'apparition des références de plans SQL dans le cadre de SQL Plan Management, les structures stockées jouaient un rôle similaire. Toutefois, elles ne sont pas aussi souples et adaptables. Par exemple, les structures stockées ne peuvent pas évoluer de façon automatique dans le temps. De ce fait, une structure stockée peut être appropriée au moment de sa création, mais devenir obsolète en cas de modification de la base de données et faire baisser les performances. Une indication dans une structure stockée peut devenir incorrecte (cas d'une indication d'index sur un index déplacé, par exemple). Dans ces cas-là, la base de données utilise toujours les structures, mais exclut les indications incorrectes, ce qui fait que le plan est souvent pire que l'original ou que le plan actuel généré par l'optimiseur pour obtenir le meilleur coût. Pour une instruction SQL, l'optimiseur peut uniquement choisir le plan défini dans la structure stockée de la catégorie actuellement indiquée. L'optimiseur ne peut pas choisir parmi d'autres structures stockées de différentes catégories, ni opter pour le plan actuel basé sur les coûts, même si les performances devaient en être améliorées. 13

14 Oracle Database 11g Release 2 permet de migrer les structures stockées vers les références de plans SQL. Les avantages de la migration vers les références de plans SQL sont les suivants : Les références de plans SQL permettent à l'optimiseur d'utiliser le même plan approprié et de le laisser évoluer dans le temps. Pour une instruction SQL particulière, vous pouvez ajouter de nouveaux plans en tant que références de plans SQL, après avoir vérifié qu'ils n'affectent pas les performances. Les références de plans SQL empêchent toute mauvaise utilisation liée à des indications incorrectes. En effet, si des indications stockées dans une référence de plan deviennent incorrectes, le plan pourra ne pas être reproduit par l'optimiseur. Dans ce cas, l'optimiseur sélectionne une autre référence de plan reproductible ou le plan actuel généré par l'optimiseur pour obtenir le meilleur coût. Pour une instruction SQL spécifique, la base de données peut conserver plusieurs références de plans. Pour une instruction SQL spécifique, l'optimiseur peut effectuer son choix à partir d'un ensemble de plans appropriés au lieu d'être limité à un plan par catégorie, comme pour les structures stockées. Grâce aux possibilités de migration d'oracle Database 11g Release 2, les anciennes applications utilisant les structures stockées peuvent être migrées de façon transparente et profiter immédiatement des fonctionnalités améliorées de SQL Plan Management. Gestion des modifications Dans les environnements de bases de données Oracle, trois composants interviennent dans la gestion des modifications : Détection des modifications : détecte les modifications non planifiées ou les environnements de bases de données mal configurés. Test des modifications : teste les modifications planifiées dans des environnements de test et corrige les baisses de performances avant d'appliquer les modifications en production. Automatisation des modifications : automatise le déploiement des modifications à travers plusieurs environnements. Détection des modifications A l'aide d'oracle Enterprise Manager, les administrateurs peuvent voir tous leurs actifs de bases de données Oracle dans l'entreprise. En utilisant la collecte de données par période et en temps réel, les administrateurs peuvent obtenir tous les détails requis pour gérer leurs bases de données, comme le numéro de version, l'emplacement de base Oracle, les niveaux de correction, etc. Oracle Enterprise Manager fournit également automatiquement un score de conformité en 14

15 évaluant chaque base de données par rapport aux quelque 300 stratégies prêtes à l'emploi, ce qui permet aux administrateurs de combler les failles de sécurité de façon proactive. Alors que les modifications apportées aux applications constituent la principale cause de temps morts, les entreprises sont confrontées au problème de l'identification des modifications non planifiées apportées aux environnements de production. En capturant l'état optimal du schéma de base de données de production dans une référence, les administrateurs de bases de données peuvent facilement détecter les modifications ad hoc apportées aux bases de données de production (modifications des paramètres d'initialisation, nouveaux index ou changements malveillants dans la logique métier) en comparant l'environnement de production actuel à la référence or établie. Dans Oracle Database 11g, les administrateurs de bases de données peuvent suivre les modifications apportées au schéma en temps réel en donnant au paramètre d'initialisation ENABLE_DDL_LOGGING la valeur TRUE. Test des modifications Real Application Testing Aujourd'hui, les entreprises doivent considérablement investir dans des ressources matérielles et logicielles afin de déployer les modifications d'infrastructure. Par exemple, un centre de données peut souhaiter déplacer des bases de données vers une plate-forme informatique à bas coût, telle qu'oracle Enterprise Linux. Normalement, cela impliquerait que l'entreprise investisse dans du matériel en double pour l'ensemble de la pile applicative (comprenant le serveur Web, le serveur d'applications et la base de données) afin de tester les applications en production. De ce fait, les entreprises considèrent qu'il est très onéreux d'évaluer et d'appliquer des modifications à leur infrastructure de centre de données. De plus, malgré des tests approfondis, lorsqu'une modification est finalement apportée à un système de production, il est fréquent que des problèmes inattendus surviennent. En effet, les charges de travail test sont généralement simulées et ne représentent pas complètement ni fidèlement les charges de travail réelles. Les responsables de centres de données rechignent donc généralement à adopter de nouvelles technologies et à adapter leurs activités face aux pressions de la concurrence en constante évolution. L'option Real Application Testing d'oracle Database 11g résout tous ces problèmes grâce à deux nouvelles solutions : Database Replay et SQL Performance Analyzer. Database Replay Grâce à Database Replay, les administrateurs de bases de données et administrateurs système peuvent réexécuter, dans des environnements test, de façon fidèle, précise et réaliste les charges de travail de production réelles, notamment les charges de travail par lots et d'utilisateurs en ligne. En capturant la charge de travail de base de données complète des systèmes de production, notamment tous les accès simultanés, toutes les dépendances et les minutages, Database Replay vous permet de tester les modifications système de façon réaliste en recréant simplement les 15

16 charges de travail de production sur le système test ; ce qu'un ensemble de scripts ne pourra jamais faire. Avec Database Replay, les administrateurs de bases de données et administrateurs système peuvent tester : les mises à niveau des bases de données, les correctifs, les modifications apportées aux paramètres, aux schémas, etc. ; les modifications de configuration telles que la conversion d'une instance simple en RAC, ASM, etc. ; les modifications apportées au stockage, au réseau, aux interconnexions ; les modifications apportées aux systèmes d'exploitation, à leurs paramètres, les migrations matérielles, correctifs et mises à niveau. Coût d'infrastructure test réduit Les administrateurs de bases de données disposent à présent d'une infrastructure test pour tester leurs modifications sans avoir à dupliquer une infrastructure d'application complète. Database Replay évite d'avoir à recréer une couche intermédiaire ou une couche de serveur Web. Par conséquent, les administrateurs de bases de données et administrateurs système peuvent rapidement tester et mettre à niveau les composants d'infrastructures de centres de données en toute confiance, puisque les modifications ont été testées et validées à l'aide de scénarios de production. Déploiement plus rapide Un autre atout majeur de Database Replay est qu'il évite aux administrateurs de bases de données de passer des mois à comprendre le fonctionnement de l'application et à développer des scripts de test. En quelques clics, en effet, les administrateurs de bases de données disposent d'une charge de travail de production complète pour tester et déployer toute modification. Les cycles de test qui s'étendaient auparavant sur plusieurs mois sont désormais réduits à quelques jours ou semaines et permettent ainsi aux entreprises de réaliser d'importantes économies. Database Replay implique quatre grandes étapes : 1. Capture de la charge de travail Lorsque la capture de la charge de travail est activée, toutes les demandes client externes soumises à Oracle Database sont suivies et stockées dans des fichiers binaires appelés «fichiers de capture», sur le système de fichiers. Oracle recommande d'effectuer une sauvegarde complète de la base de données avant la capture de la charge de travail. L'utilisateur indique l'emplacement des fichiers de capture, ainsi que les heures de début et de fin de la capture de la charge de travail. Au cours de ce processus, toutes les informations émanant d'appels externes à la base de données sont écrites vers des fichiers de capture. 16

17 2. Traitement de la charge de travail Une fois la charge de travail capturée, les informations écrites vers les fichiers de capture doivent être traitées. Ce traitement transforme les données capturées en fichiers de relecture et crée toutes les métadonnées requises pour la relecture de la charge de travail. Les fichiers de capture devraient généralement être copiés vers un autre système pour leur traitement. Cette copie doit être faite une fois pour chaque charge de travail capturée pour que les fichiers de capture puissent être relus. Une fois la charge de travail capturée traitée, elle peut être relue de façon répétée sur un système de relecture. Etant donné que le traitement de la charge de travail peut demander du temps et de nombreuses ressources, il est généralement recommandé d'effectuer cette étape sur le système test sur lequel la charge de travail sera relue. 3. Relecture de la charge de travail Une fois la charge de travail capturée traitée, elle est prête à être relue. Un programme client, baptisé Replay Client, traite les fichiers de relecture et soumet les appels à la base de données selon le même minutage et la même simultanéité que dans le système de capture. En fonction du volume de la charge de travail capturée, vous pourrez avoir besoin d'un ou de plusieurs clients de relecture pour relire correctement la charge de travail. Un outil de calibrage est fourni pour vous aider à déterminer le nombre de clients de relecture requis pour une charge de travail. Attention : étant donné que l'ensemble de la charge de travail est relu (requêtes SQL et DML incluses), il est important que les données du système de relecture soient identiques à celles du système de production (à partir duquel la charge de travail a été capturée) afin de permettre une analyse fiable en vue de la génération de rapports. 4. Analyse et génération de rapports Des rapports complets sont fournis pour permettre l'analyse détaillée de la capture et de la relecture. Toute erreur rencontrée au cours de la relecture est signalée. Toute divergence dans les lignes retournées par DML ou les requêtes est indiquée. Les performances de base sont comparées entre la capture et la relecture. Pour l'analyse avancée, Replay Compare Period et d'autres rapports AWR sont disponibles. Ils permettent de comparer en détail diverses statistiques de la capture et des relectures. Les processus de capture et de relecture de la charge de travail prennent tous deux en charge une fonctionnalité de filtrage très utile pour cibler les charges de travail présentant un intérêt particulier (par service, par action, par module, etc.). Oracle Enterprise Manager 10g Release 5 améliore considérablement la valeur de Real Application Testing en prenant en charge l'automatisation Database Replay de bout en bout. Cela simplifie le processus d'enregistrement et de transfert de la capture de la charge de travail et des données de performances vers le système test, permet de configurer correctement le système test et les clients de relecture et d'organiser la relecture intégrale à travers l'interface Grid Control. 17

18 Figure 2 : flux de travail de la relecture de la base de données SQL Performance Analyzer Les modifications qui affectent les plans d'exécution SQL peuvent gravement impacter les performances et la disponibilité des applications. Par conséquent, les administrateurs de bases de données passent beaucoup de temps à identifier et à corriger les instructions SQL ayant régressé suite à des modifications système. SQL Performance Analyzer (SPA) peut prédire et prévenir les problèmes de performances d'exécution SQL liés aux modifications de l'environnement. SQL Performance Analyzer fournit une vue détaillée de l'impact des modifications apportées à l'environnement sur les statistiques et plans d'exécution SQL, en exécutant les instructions SQL en série avant et après les modifications. SQL Performance Analyzer génère un rapport indiquant les avantages apportés par la modification système à la charge de travail, ainsi que l'ensemble des instructions SQL ayant régressé. Pour ces instructions SQL, SQL Performance Analyzer fournit 18

19 les détails appropriés concernant les plans d'exécution, ainsi que des recommandations pour les ajuster. SQL Performance Analyzer s'intègre parfaitement aux fonctionnalités SQL Tuning Set (STS), SQL Tuning Advisor et SQL Plan Management existantes. SQL Performance Analyzer automatise intégralement et simplifie le processus manuel et chronophage de l'évaluation de l'impact des modifications sur des charges de travail SQL extrêmement lourdes (représentant des milliers d'instructions SQL). Les administrateurs de bases de données peuvent utiliser SQL Tuning Advisor pour corriger les instructions SQL ayant régressé dans des environnements test et générer de nouveaux plans. Ces plans sont ensuite intégrés aux références SQL Plan Management, puis réexportés en production. Ainsi, à l'aide de SQL Performance Analyzer, les entreprises peuvent s'assurer, à moindre coût, qu'une modification système apportée à un environnement de production entraîne bien des améliorations. Voici quelques exemples de modifications système courantes pour lesquelles vous pouvez utiliser SQL Performance Analyzer : mise à niveau de base de données, correctifs, modifications des paramètres d'initialisation ; modifications de configuration du système d'exploitation, du matériel ou d'une base de données ; modifications de schémas (ajout de nouveaux index, partitionnement ou vues matérialisées) ; collecte de statistiques d'optimiseur ; actions d'ajustement SQL (création de profils SQL, par exemple). L'utilisation de SQL Performance Analyzer implique les 5 étapes principales suivantes : 1. Capturer la charge de travail SQL à analyser avec SPA. La base de données Oracle offre diverses méthodes pour capturer la charge de travail SQL à partir de diverses sources, comme le cache de curseurs et l'automatic Workload Repository, dans un STS (SQL Tuning Set, jeu d'ajustement SQL). Cette capture se fait généralement sur un système de production, puis le STS est transporté vers le système test où l'analyse SPA est effectuée. 2. Mesurer les performances de la charge de travail avant une modification en exécutant SPA sur le jeu d'ajustement SQL. De très courtes requêtes sont exécutées plusieurs fois et une moyenne est faite à partir de leurs statistiques pour éliminer les variations dues à l'état du cache des tampons et autres facteurs parasites. 3. Apporter la modification : mettre à niveau la base de données ou actualiser les statistiques d'optimiseur, par exemple. 4. Mesurer les performances de la charge de travail une fois la modification apportée en réexécutant SPA sur le STS, comme pour l'étape 2. 19

20 5. Comparer les performances des deux exécutions du STS pour identifier les instructions SQL ayant régressé, ayant été améliorées ou étant inchangées. Figure 3 : rapport SQL Performance Analyzer Ce rapport de comparaison SPA présente les principales améliorations de performances de la charge de travail SQL globale après la modification système proposée, mais avec quelques régressions du plan d'exécution. SQL Performance Analyzer prend en compte le nombre d'exécutions d'une instruction SQL lorsqu'il mesure son impact. En effet, une instruction SQL qui s'exécute en quelques secondes, mais fréquemment, peut avoir davantage d'impact sur le système qu'une instruction plus longue qui ne s'exécute qu'une seule fois. SPA prend ces facteurs en compte lorsqu'il prédit les améliorations et régressions de performances globales. Si des régressions sont constatées, SPA permet à l'utilisateur de les corriger à l'aide de SQL Tuning Advisor ou de SQL Plan Baselines, une nouvelle fonctionnalité de stabilité de plan ajoutée à Oracle Database 11g. SPA prend en charge de nombreuses autres fonctionnalités qui aident à évaluer les modifications système. En voici une brève description : 1. SPA aide à estimer la réduction d'e/s qui peut être obtenue en effectuant une migration vers le serveur Exadata, mais sans avoir à configurer le matériel. Cette fonctionnalité peut être utilisée pour identifier les charges de travail/systèmes susceptibles d'être de bons candidats à la migration vers Exadata. 20