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

21 2. SPA permet de comparer deux STS. Cette fonctionnalité est utile lorsque vous avez des mécanismes tels que des scripts de test de charge ou Oracle Application Testing Suite que vous pouvez utiliser pour tester les modifications. En capturant la charge de travail dans deux STS distincts (pour avant et après l'exécution de la modification), vous pouvez utiliser SPA pour évaluer l'impact de la modification système. 3. Avec Oracle Enterprise Manager 10g Grid Control Release 5, un mécanisme de transport STS en un clic peut être utilisé pour simplifier le déplacement des charges de travail STS entre les bases de données test et de production. En choisissant la solution adéquate, les administrateurs de bases de données peuvent adopter et gérer les modifications efficacement. L'option Database Replay est conçue pour tester et améliorer les performances système et SQL Performance Analyzer aide les administrateurs de bases de données à améliorer les temps de réponse SQL. Grâce à Oracle 11g Real Application Testing, les administrateurs de bases de données peuvent plus facilement gérer et exécuter les modifications importantes pour l'entreprise, tout en prenant moins de risques. Automatisation des modifications Oracle Enterprise Manager fournit également de nombreuses capacités d'automatisation du dimensionnement et de l'application de correctifs pour les bases de données Oracle. Les administrateurs de bases de données peuvent déployer des correctifs pour la base de données Oracle ou Oracle Enterprise Linux. A travers l'intégration à Oracle MetaLink, ils peuvent télécharger des correctifs directement depuis Oracle Support, les échelonner et les tester, puis, si les tests sont concluants, les déployer en un clic vers plusieurs environnements de bases de données. Imaginez le gain de temps par rapport à l'exécution manuelle de chaque correctif sur chaque base de données Oracle! Les administrateurs de bases de données peuvent également automatiser le déploiement des modifications de schémas en capturant les définitions des objets de schémas d'applications sous forme d'une définition suprême appelée «référence de dictionnaire». Lorsque toutes les modifications de développement ont été appliquées à une base de données en développement ou en zone de transit, les administrateurs de bases de données peuvent les enregistrer dans ces références et les propager vers tout environnement de base de données cible, en quelques clics. Contrairement aux scripts SQL, l'automatisation des modifications de schémas valide intelligemment ces modifications par rapport à la base de données cible pour identifier tout conflit ou divergence (par exemple, non-concordance des types de données ou objets en double). Cela permet aux administrateurs de bases de données d'apporter des corrections de façon proactive avant l'application des modifications. 21

22 Environnements de bases de données configurés en toute sécurité Les administrateurs peuvent exploiter les capacités de configuration d'oracle Enterprise Manager pour déployer des images parfaites normalisées et prétestées des logiciels de bases de données Oracle ou logiciels de systèmes d'exploitation de serveurs. Cela leur permet de passer moins de temps en laboratoire, puisqu'ils n'ont plus à surveiller chaque installation manuellement, puis à appliquer les correctifs pertinents dans le bon ordre. Ces images parfaites peuvent être utilisées pour configurer les systèmes test ou des nœuds supplémentaires dans une base de données Real Application Cluster. Lorsque les entreprises copient des données de production vers des environnements hors production afin de développer ou de tester des applications, elles risquent de ne plus être conformes aux réglementations et de s'exposer à des amendes et pénalités de manquement à ces lois de confidentialité des données. Les capacités de masquage des données mises à la disposition des administrateurs aident les entreprises à rester conformes aux lois grâce au masquage des données sensibles ou confidentielles dans les environnements de développement, de test ou de transit. En utilisant un processus irréversible pour remplacer les données sensibles par des données qui semblent réalistes, mais sont en fait modifiées, les administrateurs de sécurité s'assurent que les données originales ne peuvent être ni extraites, ni récupérées, ni restaurées, tout en préservant l'intégrité de l'application. Administration en continu Gestion des ressources Automatiser les tâches quotidiennes répétitives qui prenaient autrefois trop de temps à un administrateur, tel est l'un des atouts de la base de données autogérée, Oracle 11g. Libérés des tâches de gestion fastidieuses, comme la gestion des allocations de mémoire et des ressources disque, les administrateurs peuvent se concentrer sur des besoins plus stratégiques, comme la sécurité et la haute disponibilité. Gestion automatique de la mémoire (Automatic Memory Management) La mémoire est une ressource système précieuse à laquelle les administrateurs ont, par le passé, consacré beaucoup de temps afin d'en optimiser l'utilisation. L'une des principales améliorations apportées à Oracle Database 11g en matière d'autogestion a été baptisée «Automatic Memory Management». Cette fonctionnalité automatise la gestion de la mémoire partagée utilisée par une instance Oracle Database et libère les administrateurs de la configuration manuelle des composants de mémoire partagée. La fonction Automatic Memory Management repose sur une méthode heuristique sophistiquée, inhérente à la base de données, qui surveille la distribution de la mémoire et la modifie en fonction des demandes de la charge de travail. 22

23 Les structures de mémoire Oracle Database sont essentiellement composées de mémoire partagée ou SGA (System Global Area) et de mémoire privée ou PGA (Program Global Area). Dans Oracle Database 9i, la fonction SQL Execution Memory Management avait été introduite pour automatiser la gestion de la zone PGA. Dans Oracle Database 10g, la même chose a été faite pour la zone SGA, via l'introduction de la fonction Automatic Shared Memory Management. Cela signifiait que les différentes zones SQL de la PGA étaient auto-dimensionnées pour la charge de travail système afin d'offrir les meilleures performances, et que tous les pools de mémoire de la mémoire partagée étaient également dimensionnés pour fournir des performances optimales. L'utilisateur n'avait plus qu'à indiquer les tailles cible PGA et SGA pour qu'oracle alloue la mémoire de façon appropriée dans ces cibles afin de fournir les meilleures performances possibles. Dans Oracle Database 10g, des modules-conseils (PGA Advisor et SGA Advisor) ont également été fournis pour aider l'utilisateur à définir correctement les cibles pour les zones PGA et SGA. O/S Memory O/S Memory SGA SGA PGA PGA Figure 4 : gestion automatique de la mémoire (Automatic Memory Management) Dans Oracle Database 11g, la gestion de la mémoire est davantage automatisée encore. Toute la mémoire, PGA et SGA, est à présent gérée de façon centrale grâce à la fonction Automatic Memory Management. Les administrateurs de bases de données n'ont plus qu'à indiquer un seul paramètre, MEMORY_TARGET, et Oracle dimensionne automatiquement les zones PGA et SGA en fonction de la charge de travail. En utilisant le transfert de mémoire indirect, la base de données transfère la mémoire de la zone SGA à la zone PGA, et inversement, pour satisfaire la charge. Le transfert indirect utilise le mécanisme du système d'exploitation pour libérer de la mémoire partagée et allouer de la mémoire aux autres composants qui en demandent, par exemple de la zone PGA à la zone SGA. L'allocation dynamique de la mémoire est ajustée à intervalles réguliers pour optimiser l'utilisation de la mémoire en fonction des besoins de la charge de travail et éviter les erreurs de mémoire insuffisante. Les utilisateurs peuvent éventuellement définir des cibles SGA et PGA lorsqu'ils utilisent la fonction Automatic Memory Management. En mode d'auto-ajustement, cela permet d'éviter que les tailles SGA et PGA ne descendent en dessous des valeurs indiquées par leur cible de paramètre respective. Cette 23

24 fonctionnalité est actuellement disponible sur les plates-formes Linux, Solaris, HP-UX, AIX et Windows. Apparus pour la première fois dans Oracle Database 10g, les Memory Advisors fournissent des analyses graphiques pour les paramètres cible de la mémoire totale, les paramètres cible des zones SGA et PGA, ou les paramètres de taille des composants SGA. Les administrateurs de bases de données peuvent utiliser ces analyses pour ajuster les performances des bases de données et évaluer des scénarios de planification. Différents modules-conseils sont disponibles selon le mode de gestion de mémoire utilisé avec la base de données. Par exemple, si la fonction Automatic Memory Management est activée, vous pouvez obtenir des conseils pour définir la quantité de mémoire cible à allouer à l'ensemble de la base de données. Ce module-conseil vous aide à définir la cible de mémoire totale pour l'instance. Si la fonction Automatic Shared Memory Management est activée, vous pouvez obtenir des conseils sur la configuration des tailles cible des zones SGA et PGA. Si la fonction Manual Shared Memory Management est activée, vous pouvez obtenir des conseils sur le dimensionnement du pool partagé, du cache des tampons et de la zone PGA d'instance. Gestion de l'espace Pour les administrateurs de bases de données, la gestion de l'espace peut être l'une des tâches les plus chronophages. Heureusement, Oracle Database 11g gère automatiquement sa consommation d'espace, alerte les administrateurs de tout éventuel problème d'espace et recommande des solutions possibles. Gestion proactive de l'espace Oracle Database 11g effectue des contrôles opportuns et non intrusifs concernant l'utilisation de l'espace sur le serveur de bases de données. Oracle Database 11g surveille automatiquement son utilisation de l'espace au cours des opérations normales d'allocation et de désallocation de l'espace, et alerte les administrateurs si l'espace disponible descend en dessous des seuils prédéfinis. La fonctionnalité de surveillance de l'espace d'oracle Database 11g est prête à l'emploi ; elle n'affecte pratiquement pas les performances et peut s'appliquer à tous les types d'espaces de tables. Etant donné que la surveillance est effectuée au moment où l'espace est alloué et libéré sur le serveur de base de données, les informations concernant l'utilisation de l'espace sont immédiatement disponibles pour l'utilisateur qui en aurait besoin. La notification est effectuée à l'aide d'un mécanisme d'alertes générées par le serveur. Les alertes sont déclenchées lorsque certains événements relatifs à l'espace se produisent dans la base de données. Par exemple, lorsque le seuil d'utilisation de l'espace d'un espace de table est franchi, une alerte est levée. Autre exemple : lorsqu'une session Resumable se trouve en situation d'espace insuffisant, une alerte est envoyée à l'administrateur de bases de données pour qu'il prenne des mesures correctives. Il peut alors choisir de recevoir les informations d'alerte et d'ajouter de 24

25 l'espace à l'espace de table pour permettre à l'opération suspendue de reprendre là où elle s'est arrêtée. Un ensemble de seuils d'alerte par défaut est fourni avec la base de données. L'administrateur de bases de données peut remplacer la valeur par défaut pour un espace de table donné ou définir une nouvelle valeur par défaut pour l'ensemble de la base de données, via EM. Récupération d'espace transparente Oracle Database 11g permet de réorganiser les données sur place en les réduisant pour optimiser l'utilisation de l'espace. La réduction d'un segment mettra l'espace non utilisé à la disposition d'autres segments de l'espace de table et pourra améliorer les performances des requêtes et opérations DML. La fonction Segment Shrink permet de compacter l'espace utilisé dans un segment, puis de le désallouer du segment. L'espace désalloué est rendu à l'espace de table et mis à la disposition d'autres objets. Les tables peu remplies peuvent entraîner un problème de performances pour les analyses de tables complètes. En effectuant une réduction, les données de telles tables sont compactées et la borne haute du segment est poussée vers le bas. Ainsi, les analyses de tables complètes lisent moins de blocs et s'exécutent donc plus rapidement. Segment Shrink est une opération en ligne : la table réduite est ouverte aux requêtes et opérations DML tandis que le segment est réduit. De plus, la réduction du segment est effectuée sur place. Cela est bien plus avantageux qu'une redéfinition de table en ligne en vue d'un compactage et d'une récupération d'espace. L'administrateur de bases de données peut planifier la réduction de segment pour un ou pour tous les objets de la base de données de sorte qu'elle s'effectue la nuit, sans avoir à fournir davantage d'espace à la base de données. Afin d'identifier facilement les segments candidats à la réduction, Oracle Database 11g inclut également un Automatic Segment Advisor. L'Automatic Segment Advisor s'exécute chaque nuit au cours d'une fenêtre de maintenance prédéfinie, afin d'identifier proactivement les segments à réduire. Ce module-conseil, appelé manuellement ou exécuté automatiquement, procède à une analyse des tendances de croissance sur les objets individuels afin de déterminer s'il restera de l'espace dans ces objets au bout de 7 jours. Il utilise ensuite la cible de récupération d'espace pour sélectionner les objets candidats à la réduction. Création de segments à la demande L'installation d'une application packagée peut souvent entraîner la création de milliers de tables et d'index de bases de données. La création de ces tables et index peut prendre beaucoup de temps et utiliser une grande quantité d'espace disque. Bon nombre d'entre eux ne vous serviront peutêtre jamais si vous ne possédez pas de licence pour tous les modules de l'application packagée. Dans Oracle Database 11g Release 2, lors de la création de tables et d'index non partitionnés, la base de données par défaut utilise la création de segments différée pour ne mettre à jour que les 25

26 métadonnées de base de données et évite la création initiale de segments utilisateur ; cela permet d'économiser de l'espace disque et d'accélérer l'installation. Lorsqu'un utilisateur insère la première ligne dans une table, la base de données crée des segments pour la table, ses colonnes LOB et ses index. La création de segments à la demande permet donc de gagner du temps, de l'espace et des ressources informatiques. Compression Advisor Dans Oracle Database 11g, la compression de vos données permet d'économiser de l'espace disque, réduit l'utilisation de la mémoire dans le cache des tampons de base de données et accélère considérablement l'exécution des requêtes. La compression entraîne bien une surcharge de l'uc pour le chargement des données et les opérations DML. Toutefois, le coût que cela implique est largement compensé par la réduction des besoins en termes d'e/s. Dans Oracle Database 11g, la compression des tables est totalement transparente pour les applications. Cette opération est particulièrement utile dans les systèmes d'aide à la décision, sujets aux longues opérations en lecture seule et aux vastes quantités de données, mais peut également servir dans les systèmes de traitement des transactions en ligne. Vous pouvez spécifier une compression pour un espace de table, une table ou une partition. Dans Oracle Database 11g Release 2, un module Compression Advisor a été ajouté pour vous aider à choisir le niveau de compression approprié pour vos données. Dans le cadre de la structure Advisor existante dans Oracle Database 11g, le Compression Advisor analyse les objets de la base de données, découvre les taux de compression possibles et recommande des paramètres de compression optimaux. Diagnostic des erreurs Dans cette version 11g, Oracle Database intègre pour la première fois une infrastructure avancée de diagnostic des erreurs afin de prévenir, de détecter, de diagnostiquer et de résoudre les problèmes. Les problèmes ciblés sont surtout les erreurs critiques susceptibles d'affecter l'intégrité de la base de données. Lorsqu'une erreur critique survient, un numéro d'incident lui est attribué et les données de diagnostic de l'erreur (traces, dumps et autres) sont immédiatement capturées et balisées avec ce numéro. Les données sont ensuite stockées dans l'automatic Diagnostic Repository (ADR), un référentiel basé sur des fichiers en dehors de la base de données, d'où elles pourront ensuite être extraites par numéro d'incident et analysées. La profonde amélioration apportée à l'infrastructure de diagnostic des erreurs d'oracle Database 11g vise à offrir les avantages suivants : répondre proactivement aux problèmes mineurs et éviter toute défaillance système sévère en alertant les administrateurs de bases de données via des contrôles d'intégrité (Health Checks) ; 26

27 limiter les dégâts, réparations et interruptions lorsqu'un problème est détecté, en utilisant Data Recovery et SQL Repair Advisor ; réduire le temps de diagnostic des problèmes grâce à l'adr et à Test Case Builder ; simplifier l'interaction entre les clients et Oracle Support à l'aide d'ips et d'oracle Configuration Support Manager. Voici les composants clés de l'infrastructure de diagnostic des erreurs : Automated Health Checks Une structure de contrôles d'intégrité a été ajoutée à Oracle Database 11g afin d'effectuer des contrôles proactifs sur l'intégrité du système. Si une erreur critique est détectée, l'infrastructure de diagnostic des erreurs peut exécuter un ou plusieurs contrôles d'intégrité afin d'analyser l'erreur critique en profondeur. Les résultats d'un contrôle d'intégrité sont stockés dans un rapport consultable sous forme de fichier texte ou au format HTML dans un navigateur. Le rapport peut être ajouté à d'autres données de diagnostic collectées au sujet de l'erreur. Les contrôles d'intégrité distincts recherchent les corruptions de données, les corruptions liées aux annulations et rétablissements, les corruptions du dictionnaire de données et autres. SQL Test Case Builder Pour de nombreux problèmes d'application, obtenir un cas de test reproductible permet d'accélérer la résolution. SQL Test Case Builder permet à un utilisateur de rassembler automatiquement toutes les informations nécessaires pour reproduire le problème, telles que les informations de texte SQL, PL/SQL, DDL, d'environnement d'exécution, etc. Ces informations peuvent ensuite être transmises à Oracle Support pour aider à reproduire le problème. Automatic Diagnostic Repository (ADR) L'ADR est un référentiel basé sur des fichiers, pour les données de diagnostic de base de données telles que les traces, les dumps, le journal d'alerte, les rapports de surveillance d'intégrité et autres. Il possède une structure de répertoire unifiée à travers plusieurs instances et composants d'oracle Database et remplace les USER_DUMP_DEST, BACKGROUND_DUMP_DEST et CORE_DUMP_DEST des versions précédentes. Les données de diagnostic de l'adr sont autogérées et automatiquement supprimées selon un paramètre de conservation prédéfini. L'ADR conserve également les métadonnées de toutes les erreurs critiques de la base de données de sorte qu'un utilisateur puisse exécuter des requêtes sur l'adr pour déterminer le type et le nombre de problèmes critiques survenus sur le système au cours des jours, des mois ou des années précédentes. 27

28 Incident Packaging Service (IPS) Incident Packaging Service automatise le processus de collecte de toutes les données de diagnostic utiles, relatives à un ou plusieurs problèmes. Les utilisateurs n'ont plus à chercher dans différents emplacements de répertoire pour essayer de rassembler tous les fichiers de traces et fichiers dump pertinents qui serviront à Oracle Support pour le diagnostic. Lorsqu'ils appellent IPS, toutes les données de diagnostic (traces, dumps, rapports de contrôle d'intégrité, cas de test SQL et autres) relatives à une erreur critique sont automatiquement regroupées dans un fichier zip, qui peut ensuite être transmis à Oracle Support. Support Workbench Le Support Workbench est un outil pratique d'oracle Enterprise Manager qui vous permet d'interagir avec la nouvelle infrastructure de diagnostic des erreurs d'oracle Database 11g. Grâce à lui, vous pouvez rechercher, signaler et, lorsque cela est possible, réparer les problèmes, le tout via une interface graphique conviviale. Le Support Workbench offre une solution en libre-service pour que vous puissiez regrouper les données de diagnostic à l'aide d'ips, obtenir un numéro de demande d'assistance et transmettre le package IPS à Oracle Support facilement et rapidement, ce qui accélère nettement la résolution des problèmes. Critical Error Automatic Diagnostic Repository 1 Auto Incident Creation First-Failure Capture 2 Alert DBA Targeted Health Checks No Duplicate Bug? 4 EM Support Workbench: Package Incident & Configuration Information Repair Advisors 3 Yes EM Support Workbench: Apply Patch or Workaround Repair Advisors Figure 5 : flux de travail du Support Workbench Le flux de travail du Support Workbench comprend les étapes suivantes : 1. créer automatiquement un incident dans la base de données après la première occurrence d'une défaillance ; 2. alerter l'administrateur de bases de données de la défaillance et exécuter des contrôles d'intégrité dans les zones affectées ; 28

29 3. s'il s'agit d'un problème connu, recommander et appliquer un correctif pour résoudre le problème ; 4. sinon, regrouper les incidents et les informations de configuration pertinentes, les transmettre à Oracle Support, puis exécuter les modules-conseils de réparation pour résoudre le problème. Les problèmes d'une base de données Oracle peuvent être très variés et leurs solutions peuvent l'être tout autant. Le Support Workbench intègre des flux de travail complets qui guident l'utilisateur pour qu'il prenne les mesures appropriées selon le problème rencontré. Quels avantages pouvez-vous en tirer? Le changement est inévitable dans les environnements informatiques modernes. L'idéal est donc qu'il ne complique pas la tâche des administrateurs et responsables de centres de données. Grâce aux capacités de Real Application Testing, les administrateurs de bases de données peuvent s'adapter facilement aux changements, tout en limitant les effets indésirables. Real Application Testing aide les entreprises à faire des économies sur les tests. En effet, les administrateurs de bases de données et administrateurs système disposent désormais d'une solution facile à déployer pour tester et appliquer les modifications aux centres de données, avec des investissements matériels et logiciels réduits. Dans le même temps, les améliorations apportées à Oracle Database 11g en termes de facilité de gestion permettent aux administrateurs de bases de données de maintenir les performances et la disponibilité de leurs systèmes, tout en offrant une meilleure qualité de service aux utilisateurs. Conclusion Les entreprises modernes adoptent les nouvelles technologies à bras le corps pour accroître leur rentabilité et leur compétitivité. Par conséquent, les défis de gestion augmentent sans cesse. Oracle Database 11g permet de relever ces défis. Grâce à elle, les administrateurs de bases de données peuvent maintenir les performances des bases de données au plus haut niveau, adopter les nouvelles technologies rapidement et sans risque, mais aussi accroître leur productivité et la disponibilité du système grâce à l'automatisation des tâches administratives répétitives. Oracle Database 11g est une solution de gestion de bases de données nouvelle génération pour l'administrateur de bases de données nouvelle génération. 29

30 Oracle Database 11g Release 2 : facilité de gestion et présentation de Real Application Testing Août 2009 Auteur : Kurt Engeleiter Contributeurs : Jagan Athreya, Mughees Minhas, Sergey Koltakov Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Demandes de renseignements - International : Tél. : Fax : oracle.fr Copyright 2009, Oracle et/ou ses affiliés. Tous droits réservés. Ce document est fourni à titre informatif uniquement et les informations qu'il contient peuvent faire l'objet de modifications sans préavis. Oracle ne garantit pas que ce document soit exempt d'erreur et exclut toute garantie ou condition, expresse ou implicite, notamment toute garantie et condition implicite de commercialisation ou d'adéquation à un usage particulier. Nous déclinons en particulier toute responsabilité concernant ce document, qui n'implique aucune obligation contractuelle directe ou indirecte. Ce document ne peut être ni reproduit ni transmis à quelque fin, sous quelque forme ou par quelque moyen que ce soit (électronique ou mécanique) sans notre autorisation écrite préalable. Oracle est une marque déposée d'oracle Corporation et/ou de ses affiliés. Tout autre nom mentionné peut correspondre à des marques appartenant à d'autres propriétaires qu'oracle. 0109