Génération de code SQL avec le SQL

1

2

3

Génération de code SQL avec le SQL La requête ci-dessus montre comment générer un script de sauvegarde logique avec SQL*Plus. Les chaînes de caractères sont concaténées avec l opérateur. Les métas caractères comme la simple côte sont imprimés littéralement lorsque l on double le caractère générique. 4

Le résultat est affiché ci-dessus. La notation q c texte à encadrer c (c pouvant être n importe quel caractère alpha) permet d extraire les colonnes de la tables qui contiennent des caractères 5

Astuces diverses Il est souvent utile de générer des volumes importants dans la base afin de vérifier les temps de réponse des requêtes SQL. L insertion récursive d une table sur ellemême permet de créer rapidement un nombre de lignes important. L exemple cidessus fonctionne s il n y a pas de contrainte d unicité sur la table BIG_EMP. 6

Extension de l ordre GROUP BY ROLLUP permet de calculer plusieurs niveaux de sous totaux dans un groupe donné de dimensions. Il calcule également un grand total. ROLLUP est une simple extension de la clause GROUP BY, sa syntaxe est extrêmement facile à utiliser. L'extension ROLLUP est très efficace, la surcharge est minime pour une requête données. CUBE regroupe un ensemble spécifié de colonnes et crée des sous totaux pour l'ensemble de toutes les combinaisons possibles. En termes d'analyse multidimensionnelle, CUBE génère tous les sous totaux qui pourraient être calculés pour un cube de données avec les dimensions spécifiées. Si vous avez spécifié CUBE (temps, région, département), le jeu de résultats comprendra toutes les valeurs qui seraient incluses dans une expression ROLLUP équivalente avec des combinaisons supplémentaires. Pour plus d information consulter «Oracle Database Data Warehousing Guide» 7

Vues relationnelles L exemple de la diapositive montre comment masquer la complexité d une requête d agrégation utilisant l extension ROLLUP de la clause GROUP BY. La vue peut être utilisée simplement et il est également possible de filtrer sa sortie avec une clause WHERE. Par exemple il est possible d afficher seulement les totaux de la manière suivante : SQL> select * from Salaires_par_departements where "Type Emploi" like 'Total%' ; 8

9

Vues matérialisées Les vues matérialisées sont des résultats pré calculés de requête SQL qui sont stockés au préalable dans la base de données. Les ordres SQL qui doivent effectuer des calculs assez long peuvent bénéficier de ces résultats en les récupérant sans être obligés de parcourir toute la base de données. les vues matérialisées sont identiques aux tables (en partition ou pas) et se comportent comme des index, elles sont utilisées de manière transparente (Query Rewrite) afin d'améliorer les performances. 10

Syntaxe: materialized view voir le manuel «SQL Reference» et «Warehouse Guide» 11

12

Concepts Oracle fournit un certain nombre d outils pour effectuer les opérations d alimentation et de déchargement des bases de données. Parmi ces produits on compte Oracle Data Integrator anciennement sunopsis acheté par Oracle pour enrichir sa famille de produits d'intégration, il fait partie de la suite: Oracle Fusion Middleware et Oracle Warehouse Builder (OWB). OWB est l outil ETL pour Extract, Transform, Load initialement développé par Oracle en langage JAVA. C est un outil de développement qui permet de concevoir principalement des procédures de traitement écrites en langage SQL, PL/SQL et SQL*Loader pour les chargements. Avant d utiliser Warehouse Builder il est utile de comprendre le principe de fonctionnement et d utilisation des programmes sous jacents que génère l outil ETL. Comme son nom l indique OWB est l outil consacré pour la création de base de données d aide à la décision ou d infocentre que l on nomme communément «Data Warehouse». Les structures logiques de ce type de base de données sont organisées en étoile ou en flocons de neige. On parle en général de «cubes» ou de «star schéma». Ces concepts vont être présentés à la fin de ce chapitre. 13

Extractions et Chargements basiques SQL*Plus est l utilitaire basique que l on utilise pour lancer des ordres SQL avec Oracle Database. Cet outil permet également de produire des états et de sauvegarder les résultats vers des fichiers plats. Il est tout à fait possible de décharger des données de type texte avec cet outil en utilisant l option «spool» tout en formatant la sortie de telle sorte que l on ai que les données brutes dans le fichier résultant. La puissance du langage SQL vous permet ainsi d effectuer toutes les transformations nécessaires avec l ordre SELECT lors de l extraction des données vers le fichier plat. L opération inverse peut être effectuée avec l utilitaire SQL*Loader qui prend les directives de chargement à partir d un fichier de contrôle. La documentation complète de cet outil se trouve dans le manuel «Utilities» que l on peut télécharger sur le site http://otn.oracle.com. Ce principe simple d extraction et de chargement fonctionne sur tous les environnements qui supportent Oracle Database. OWB vous permet de concevoir des programmes similaires avec une interface de conception beaucoup plus conviviale. Le chargement de fichiers plats avec l utilitaire SQL*Loader peut être conçu avec Warehouse Builder. 14

Combinaisons avec les outils du système d exploitation Dans certaines circonstances, il est parfois utile de combiner les utilitaires d Oracle avec les outils du système d exploitation. Par exemple, si vous désirez utiliser des logiciels que l on ne peut interfacer directement avec le serveur Oracle, vous pouvez encapsuler des ordres SQL ou PL/SQL dans des scripts «shell» d Unix afin que ceux-ci puissent être appelés par un logiciel d ordonnancement propriétaire comme l illustre la figure ci-dessus. Il arrive dans certains cas que l on utilise cette technique pour appeler les procédures stockées qui ont été conçues avec OWB. 15

Déchargement des données dans un fichier plat La diapositive ci-dessus vous montre la syntaxe de SQL*Plus qui permet de produire des données brutes dans un fichier de sortie de type texte. OWB permet également d extraire les informations de la base de données dans des fichiers plats. Cependant, l outil ne fait pas appel à SQL*Plus. 16

Chargement de données à partir de fichiers plats L outil SQL*Loader permet le chargement de données externes dans les tables d une base. L utilitaire fonctionne avec un moteur d analyse syntaxique d un langage de directives de chargement qui lui est propre. Ce langage est assez puissant, il permet d effectuer des conversions de type et d exécuter des règles de transformation de données. Les directives sont définies dans un fichier de contrôle qui est lu en entrée avec le fichier de données. En sortie, SQL*Loader écrit les données transformées dans la base de données cible et produit trois fichiers de compte rendu d exécution : un fichier journal du traitement, un fichier des erreurs d exécution et un fichier des enregistrements rejetés. L outil offre de nombreuses possibilités pour optimiser les chargements, notamment le mode DIRECT LOAD. Les données sont stockées directement dans les DATAFILES de la base sans passer par les instructions INSERT du moteur SQL. Ce mode de chargement est beaucoup plus rapide que le mode traditionnel qui utilise le moteur SQL. Il est adapté lorsque l on a à alimenter rapidement une base DATA WAREHOUSE. Warehouse Builder est très pratique pour créer des scripts de chargements SQL*Loader. Un assistant de modélisation de la structure des fichiers plats vous permet de gagner en productivité pendant la phase d import des données métas dans le dictionnaire OWB. 17

Utilisation de SQL*Loader Oracle fournit plusieurs étude de cas d utilisation de l outil dans le répertoire $ORACLE_HOME/rdbms/demo. L une d elles est décrite ci-dessus. Il s agit d un chargement simple de la table EMP. Les directives sont définies dans le fichier de contrôle utlcase2.ctl. Les enregistrements rejetés sont produits dans le fichier utlcase2_rejets.dis et le fichier journal est utlcase2.log. L exécution est assurée par la commande SQLLDR. L outil est documenté dans le manuel «Utilities». Cette documentation est un complément précieux lorsque l on utilise l utilitaire de modélisation de fichiers plats de Warehouse Builder. 18

Création de fichiers de commandes pour SQL*Loader Warehouse Builder est l outil le plus approprié pour créer rapidement et facilement des fichiers de directives de chargement pour SQL*Loader. Cependant, lorsque les besoins ne nécessitent pas de créer des procédures de chargement sophistiquées, vous pouvez créer vous même des fichiers de contrôle simples manuellement ou en développant de petits utilitaires en SQL comme l illustre l exemple ci-dessus. 19

Concept des tables externes Le dispositif des Tables Externes est un complément de la fonctionnalité de chargement SQL*Loader. Il permet d accéder à des informations externes comme si elles étaient stockées dans des tables de la base de données. Avant la version d'oracle 10g, les tables externes étaient inaltérables. A partir de cette version les tables externes sont maintenant en lecture/écriture. Notez que SQL*Loader reste le meilleur choix dans les situations de chargement de données qui exigent l'indexation additionnelle de la table tampon. Pour utiliser les tables externes, vous devez avoir connaissance du format de fichier et des enregistrements sur votre plate-forme si vous utilisez le driver d accès ORACLE_LOADER pour charger du texte. 20

Création de tables externes Les Tables Externes sont créés en utilisant l ordre SQL CREATE TABLE...ORGANIZATION EXTERNAL. Lorsque vous créez une table externe, vous devez spécifier les attributs suivants: TYPE indique le type de table externe. Les deux types disponibles sont ORACLE_LOADER et ORACLE_DATAPUMP. Chaque type est associé à sont propre driver. Le driver d accès ORACLE_LOADER est utilisé par défaut. Il permet seulement d effectuer des chargements, les informations source doivent normalement provenir de fichiers textes. Le driver d accès ORACLE_DATAPUMP peut effectuer soit des chargements soit des déchargements. Les données proviennent de fichiers binaires. DEFAULT DIRECTORY Défini la destination par défaut des fichiers qui sont lus ou écrits. L emplacement est un répertoire logique qui est associé à un répertoire physique du système de fichiers de la machine. ACCESS PARAMETERS décrit la source des données avec les spécificités associées au driver d accès. LOCATION spécifie l emplacement et les noms des fichiers de destination. Si l emplacement n est pas indiqué, c est le répertoire par défaut qui est utilisé. 21

La diapositive ci-dessus montre différents principes et techniques de duplication et de transformation que l on peut effectuer avec le langage SQL. Ce sont ces principes qui sont largement mis en application avec «Warehouse Builder». 22

L instruction SQL MERGE est apparue en version 9i. Elle a été typiquement conçue pour résoudre certaines problématiques de l alimentation des bases de données de type Data Warehouse, en particulier pour gérer les multiples chargements potentiels d informations identiques dans une même base de données. MERGE combine les ordres INSERT et UPDATE en se basant soit sur une contrainte d unicité et/ou sur une condition de la requête d interrogation SELECT. La syntaxe de l instruction MERGE peut s avérer relativement complexe et fastidieuse. L utilisation d OWB permet notamment de simplifier largement la production et l écriture d ordre SQL MERGE et par conséquent de gagner un temps précieux. 23

DML Error Logging Lorsque l on exécute une instruction DML Data Manipulation Language : INSERT, UPDATE, DELETE sur un nombre important d enregistrements, une erreur d exécution, par exemple, la violation d une contrainte d intégrité, peut provoquer l annulation complète de toutes les opérations concernées par la requête SQL DML. Il peut être dommage d avoir à relancer un traitement qui peut mettre plusieurs minutes à s exécuter, surtout si l erreur survient lorsqu il était sur le point de se terminer. Il est possible de résoudre ce type de problème avec une procédure stockée écrite en PL/SQL qui traitera les enregistrements un par un avec un contrôle d erreur approprié. Cependant, les performances d exécution de ce type de procédure sont nettement moins bonnes que celles du traitement des enregistrements en une seule passe. La version 10g offre la possibilité de recueillir les enregistrements en erreur dans une table spéciale et de permettre ainsi au traitement de continuer. Pour mettre en œuvre cette fonctionnalité il faut créer la table des erreurs avec la procédure DBMS_ERRLOG.CREATE_ERROR_LOG et de compléter l ordre SQL avec la clause LOG ERRORS INTO comme le montre la diapositive ci-dessus. 24

Le transfert des informations d une base de données vers une autre peut se faire par l intermédiaire de fichiers plats. C est en général la méthode qui est utilisée, notamment lorsque l on affaire à un environnement hétérogène. Cependant, il est possible de transférer les données directement de base à base, en particulier, si la base source est compatible avec la base cible. C est bien sur le cas quand la source et la cible sont des bases Oracle, cela peut être également le cas si l on utilise l interface «heterogenous services» ou le module «Oracle Transparent Gateway». Le transfert des données de base à base s appuie sur un lien inter bases que l on nomme «database link». La diapositive ci-dessus illustre la mise en œuvre des liens inter base. 25

26

Partitionnement Le partitionnement permet de découper une table et/ou un index sur 1 ou plusieurs critères logiques. La table se comporte alors comme plusieurs tables de tailles plus petites. Les avantages principaux du partitionnement sont : De pouvoir définir des critères de stockage différents pour chacune des partitions. Par exemple, chaque partition peut être créé sur un «Tablespace» indépendant afin d opérer une répartition équitable des entrées/sorties ou bien d obtenir une granularité plus fine concernant les fichiers à sauvegarder ou à restaurer. Le découpage logique de la table permet un accès plus rapide aux informations (moins de lectures disques physiques à effectuer en particulier). Le moteur SQL prend en charge le critère de partitionnement et optimise l accès aux données en éliminant automatiquement les partitions («partition pruning») qui ne sont pas concernées par la requête SQL SELECT. Oracle propose 3 grands types de partitionnements : by range : on définit les partitions par tranche supérieure exclusive. Le critère de partition est en général une date. Exemple: PARTITION P1 VALUES LESS THAN (TO_DATE('01/03/2008','dd/mm/yyyy') by list : on définit une valeur par partition (utilisé lorsque la liste de valeur pour le champ considéré est faible) by hash : la partition de stockage est calculée dynamiquement par un calcul de type hash code (basé sur la fonction modulo du critère de partition choisi), cela permet de répartir équitablement les données sur les différentes partitions. Ce type de partitionnement est vraiment efficace lorsque la volumétrie est très importante. 27

Range Partitionning C est le type de partitionnement le plus utilisé et le plus ancien. La diapositive ci-dessus montre un aperçu de la syntaxe. La clé de partition dans cet exemple est le champ CDATE de type DATE. Les informations sont automatiquement rangées dans la partition correspondant à la date en cours car elle est générée automatiquement via la fonction SYSDATE qui est la valeur par défaut du champ CDATE. Dans le cas où l on insert une information avec une date au-delà du 1 février 2012, l instruction SQL devrait être en erreur. Pour éliminer cet inconvénient il convient d ajouter une partition avec la clé MAXVALUE comme le montre l exemple ci-dessous. ALTER TABLE F_PROXY_SC_5 ADD PARTITION "PDEFAULT" VALUES LESS THAN (MAXVALUE) TABLESPACE STAT_DATA; 28

Il existe 2 façons de partitionner un index sous Oracle : locally partitioned index : pour chaque partition de table créée, il y aura une (et une seule) partition d'index. Les données dans chaque partition d'index pointent sur l'ensemble des données d'une et unique partition de table. Logiquement, si la table a N partitions, l'index aura également N partitions globally partitioned index : l'index est partitionné indépendamment de la table. Une partition d'index peut pointer sur des données dans une ou plusieurs partitions de table. Un index globalement partitionné ne peut être que partitionné by range. Les index sur des tables partitionnées sont, par défaut, des index globaux sur une seule partition (en effet, par défaut, ils ne sont pas partitionnés). Partitionnement composite C'est une méthode de partitionnement hybride. Les données sont d'abord partitionnées by range (et également by list aujourd hui). Ensuite, chaque partition sera sous partitionnée soit by hash ou by list (et maintenant by range). Il n'est pas nécessaire d'avoir exactement le même nombre de sous partitions par partition : par exemple, une partition peut être constituée de 4 sous partitions alors qu'une autre sera composée de 5 sous partitions. Le mécanisme de découpage logique peut être étendu sur plusieurs champs, ainsi que sur 2 niveaux. On parle dans ce cas de sous partitionnement. 29

Composite range range partitioning Il est maintenant possible d effectuer un partitionnement par intervalle à deux niveaux sans faire appel à une clé composée de partition. Par exemple, partitionner par date de commande au premier niveau puis par date de livraison pour le sous-partitionnement. La version 11g supporte également le partitionnement composite avec le type «list» en premier niveau. Composite list-range partitioning Permet le partitionnement par intervalle au sein d une même liste de partitions. Par exemple, le partitionnement par mois sur une liste de régions définie. 30

OWB facilite la création des tables et index en partitions, la syntaxe étant toujours assez complexe à écrire manuellement. Syntaxe: list-range partitioning voir le manuel «SQL Reference» 31

Avantages du partitionnement Optimisation Pour les tables dépassant une certaine taille (plusieurs gigas), le partitionnement permet de distribuer les informations de manière plus efficace en fonction des critères de recherche et de la clé de partitionnement. Cela permet d éliminer certain goulet d étranglement en limitant les conflits d accès simultanés aux mêmes blocs de données et éliminant ainsi les problèmes de verrouillage. L accès aux tables organisées en partition met à profit le «partition pruning» qui consiste à interroger uniquement les partitions concernées en fonction du critère de recherche et de partitionnement. VLDB Dans le cadre des «Very Large Database» le partitionnement est presque incontournable. Lorsque les tables de fait ainsi que les dimensions dépassent en taille plusieurs gigas octets, il convient d utiliser le «Range Partitioning» afin de répartir les informations selon un critère de temps. Cela fait partie des bonnes pratiques, consulter à ce sujet la documentation «Data Warehouse Guide.» Résolution de problème de performances Dans bien des cas, quand la volumétrie des tables augmente considérablement et génère des problèmes de performance sur une base en exploitation, la transformation des tables en partitions peut être une méthode de résolution pour améliorer les temps de réponse. Le package PL/SQL DBMS_REDEFINITION permet de transformer les tables en partition sans avoir à générer de coupure de service pour les bases en production. Ce package est documenté dans le manuel «PL/SQL Packages and Types Reference.» 32

33

34

Démarche d optimisation Durée - doit être évoquée dés le début du projet, et doit être utilisée pendant toute sa durée. Objectifs - Etablir des objectifs quantifiables en éliminant les objectifs flous. Doivent permettre de définir des objectifs acceptés et approuvés par tous les intervenants. Contrôles - Les résultats doivent être contrôlés et communiqués régulièrement. Ces résultats doivent être comparés aux objectifs. Des dérives peuvent amener à corriger les objectifs. Coût du tuning Plus les problèmes de performances sont réglés tardivement et plus leur coût peut être élevé. 35

Gain pouvant être obtenus Il est important de ne pas perdre de vue certains principes en matière de performances et d optimisation des bases de données Oracle : En premier lieu, il est nécessaire de définir ce que l on cherche et de bien poser le problème. L objectif premier est de détecter les points de contention et les éventuels goulets d étranglement. En général, les gains qui peuvent être obtenu pour résoudre des problèmes de performance sont répartis de la manière suivante : - Optimisation du code SQL et des structures logiques 65 % - Réglage des structures physiques, répartition des entrées/sorties 20 % - Réglage de l instance et du moteur SGBD 10 % - Optimisation du système d exploitation 5 % 36

Étapes d optimisation La diapositive ci-dessus montre les étapes principales d une démarche d optimisation. Ces étapes doivent être franchies dans l ordre énoncé. Le résultat en terme de performances de chacune des étapes dépend du résultat des étapes précédentes. Des décisions prises dans une étape influenceront les actions des étapes suivantes. On distingue deux parties en terme d optimisation. Celle de l application et celle qui concerne l instance, la base de données et le système d exploitation. La première partie est la plus importante car on peut espérer dans certains cas, améliorer à plus de 60% les temps de réponse de l ensemble. Les bénéfices les plus importants sont tirés du réglage des requêtes SQL. En général, les problèmes de temps de réponse dans un bloc PL/SQL sont principalement dus à la lenteur d exécution des ordres SQL qu il contient. Les ordres SQL eux même sont difficiles à améliorer si le schéma relationnel est mal conçu. Cela dépend souvent d un modèle conceptuel qui a été négligé ou est absent. La deuxième partie des étapes de réglage dépendent largement de la phase d optimisation de l application. Les réglages de la mémoire sont souvent moins importants voir illusoire que ce que l on peut faire pour optimiser le «entrées/sorties.» 37

38

Curseurs : Architecture d exécution Pour soumettre des instructions SQL à une base de données Oracle, une session doit être établie entre le programme utilisateur (client) et le serveur de base de données. Le programme utilisateur peut être par exemple SQL*Plus, ou une application développée à l'aide d'un outil, tel qu'oracle Forms. Cette application ou cet outil est exécuté en tant que processus utilisateur. Lorsque la session est établie, les ordres SQL peuvent être exécuté. Le contexte d exécution d ordre SQL se nomme un curseur. 39

Comment les ordres SQL sont ils traités et exécutés par le noyau Oracle Le processus serveur alloue un espace de mémoire privé nommé context area afin de traiter les ordres SQL. La commande SQL est alors interprétée syntaxiquement et sémantiquement (parsing) puis exécutée (execute) dans ce contexe area. Les informations nécessaires à l exécution ainsi que les données récupérées (fetch) après le traitement sont stockées dans cet espace. Cet espace d exécution est géré de manière interne par le processus serveur et le programme utilisateur n y a pas de contrôle direct. Un curseur est donc un pointeur vers le context area. Traitement d un ordre SQL 1. Création du curseur. Le «context area» ou «private SQL area» est d abord alloué indépendamment de tout ordre SQL. Il est créé pour maintenir le contexte d exécution d un ordre SQL. Dans la plupart des cas, la création du curseur est automatique, cependant, en programmation avec des langages pré compilés, il est possible de déclarer explicitement un curseur. 2. Analyse de l ordre SQL (Parsing). L ordre SQL est envoyé par le programme client et le processus serveur effectue les opérations suivantes : - L ordre est analysé syntaxiquement et sémantiquement en vérifiant la définition des tables et des colonnes concernées dans le dictionnaire de la base de données («hard parse»). - Les droits d accès sont également contrôlés. Ces opérations donnent lieu à des requêtes SQL sous jacentes pour interroger le dictionnaire appelées : «recursive call». - Le plan d exécution («explain plan») est calculé pour déterminer le chemin d accès aux informations le plus rapide. - L ensemble est ensuite chargé dans l espace SQL partagé («shared SQL area») 40

Oracle exécute le «parsing» seulement s il n y a pas d ordre SQL similaire dans l espace SQL partagé (SQL Area). Dans le cas contraire, l ordre SQL peut être directement exécuté ce qui permet d optimiser («soft parse») le temps d exécution pour un ordre SQL régulièrement utilisé. Les requêtes d interrogation (SELECT notamment) sont différentes des autres ordres SQL car elles retournent un certain nombre de résultats sous forme de lignes au programme utilisateur. 3. Décrire le type de résultats de la requête. Cette étape est nécessaire lorsque le type de résultat n est pas connu à l avance. Par exemple, si les ordres SQL sont saisis en mode interactif comme avec SQL*Plus par exemple. La phase «Describe» consiste à déterminer les caractéristiques (types, longueur et nom) des résultats requis par l ordre SQL. 4. Définition des structures de réception des résultats (Define). Cette phase permet de définir l emplacement, les tailles et le type des variables de réception des informations recueillies (Fetch) par la requête SQL. 5. Relier les variables utilisateur (Bind Variables) à la requête. Lorsque les valeurs pour la clause WHERE sont passées via des variables «hôtes» du programme utilisateur, il est nécessaire d indiquer leurs adresses au serveur Oracle. 6. Exécuter l ordre SQL (Execute). A ce niveau Oracle dispose de toutes les informations pour exécuter l ordre SQL. Pour l exécution des ordres UPDATE et/ou DELETE, des verrous sont implicitement posés sur les lignes concernées par la requête SQL. Ces verrous seront libérés par les ordres de contrôle COMMIT, ROLLBACK ou SAVEPOINT. 7. Fetch. C est la phase ou les lignes des tables sont récupérées et éventuellement triées pour les envoyer au programme utilisateur. Elles sont transmises soit une par une, soit en paquet en fonction de la taille du Buffer de réception (Array Fetch) du programme client. 8. Close. L étape finale est la fermeture du curseur 41

Optimisation SQL : Plan d exécution L art d optimiser un ordre SQL passe par l affichage du plan d exécution afin d évaluer le chemin de recherche des informations dans la base de données. 42

Optimisation heuristique La génération du plan d'exécution est basée sur un ensemble de règles heuristiques définissant un score prédéterminé des méthodes d'accès. Il est possible que la structure de la requête influe sur le plan lorsque plusieurs méthodes ont le même score. L'optimiseur heuristique, basé sur une quinzaine de règles d optimisation, est appelé "Rule Based Optimizer" ou RBO. Les caractéristiques des données et la distribution des tables et index n'affectent pas le plan d'exécution. Les heuristiques peuvent s'avérer mal adaptées au contexte : cela entraîne souvent une génération d'un plan non optimal. Optimisation statistique L'optimisation statistique repose sur un modèle de coût et la connaissance de statistiques sur les objets manipulés. Génération de tous les plans possibles puis sélection du moins cher. Utilisation d'heuristiques pour réduire l'espace de recherche. Possibilité de spécifier des HINT pour privilégier une stratégie. L'optimiseur statistique est appelé "Cost Based Optimizer" ou CBO 43

Scores prédéfinis du Rule Based Optimizer La diapositive ci-dessus montre les 15 règles prédéfinies utilisée par l optimisation RBO. Le temps d accès aux données est proportionnel au rang du score. 44

RBO Versus CBO Le noyau Oracle intègre les deux moteurs d optimisation. Le moteur RBO traditionnel, basé sur les règles, est obsolète et ne sera plus supporté à terme. Cela implique qu il est fondamental d optimiser le code SQL en prenant en compte les résultats obtenus par le moteur CBO. 45

Collecte automatique des informations statistiques Le moteur Oracle à partir de la version 10g, collecte automatiquement des informations statistiques destinées à l optimisation des requêtes SQL et aux mesures de performance. Il y a deux types de statistiques : Les statistiques associées aux segments de la base (Tables et Index) qui permettent au moteur de base de données de déterminer le meilleur Plan d Exécution pour optimiser les temps de réponse des ordres SQL. Par exemple, le nombre de lignes (num_rows), le nombre de blocs (blocks) et la longueur moyenne d un enregistrement (avg_row_len) d une table de la base de données font partie des statistiques que le moteur d optimisation SQL peut exploiter pour améliorer les performances. Les informations statistiques de comportement de l instance de base de données sont collectées régulièrement (toutes les heures par défaut) et ces clichés sont stockés dans le référentiel de charge de travail AWR (Automatic Workload Repository). Ces clichés sont exploités par le moteur d analyse ADDM (Automatic Diagnostic Database Monitor) pour établir des diagnostics et des mesures de performance par comparaison. 46

Démarche d optimisation du code SQL Vous pouvez suivre la démarche présentée ci-dessus pour optimiser le code SQL. L idée est de tirer parti au maximum du moteur d optimisation CBO. Bien sûr, cette démarche part du principe que le modèle de données est propre et cohérent. Dans un premier temps, vous pouvez mettre au point le code SQL à part avant de l intégrer dans les blocs PL/SQL, avec SQL*Plus par exemple. Il est important de tester les requêtes sur des volumétries réalistes par rapport à ce qu il y aura en production. Une erreur classique est de coder du SQL sur une base vide, cela résulte souvent sur des problèmes de performances quelques temps après la mise en exploitation. Pour les requêtes complexes où la distribution des informations est difficile à déterminer pour le CBO, vous pouvez utiliser des HINTs. Ils permettent de privilégier une stratégie de recherche, cependant, il ne faut pas tomber dans l excès inverse en utilisant les indicateurs dans tous les cas de figure. Bien souvent, le moteur CBO détermine le meilleurs plan d exécution possible en fonction du schéma et de l architecture en place. Si malgré tout, les temps de réponses restent mauvais, il faut peut être remettre en question le modèle de données ou utiliser des techniques et astuces comme le partitionnement, la dénormalisation, etc La figure ci-dessus vous donne également la syntaxe pour le calcul des statistiques exploitées par le moteur d optimisation CBO. 47