- ORS - Optimisation de Requêtes SQL sous Oracle

- ORS - Optimisation de Requêtes SQL sous Oracle G. Mopolo-Moké prof. MS BDP CERAM SOPHIA ANTIPOLIS 2005 / 2006 1

Plan Général 1. Introduction 2. Etapes d optimisations 3. Méthodes d'accès 4. Chemins d'accès 5. Outils d'optimisations 6. Optimiseur Syntaxique 7. Optimiseur Statistique 8. Annexes 9. Plan détaillé 2

1. Introduction PLAN 1.1 Objectifs du cours 1.2 Optimisation et les SI 1.3 Conception optimisée d'une base 1.4 Approches d'optimisation de requêtes 1.5 optimiseur syntaxique 1.6 optimiseur statistique 3

1.1 Objectifs du cours Comprendre le fonctionnement de l optimiseur Oracle afin d améliorer les temps de réponses étudier les méthodes et chemins d'accès Oracle étudier et utiliser les outils d'optimisation étudier l'optimiseur syntaxique et statistique produire et choisir le meilleur plan d'accès écrire soigneusement les requêtes afin de favoriser ou défavoriser un chemin : Optimiseur syntaxique et... Statistique 4

1.2 Etapes d Optimisations d un SI MODELISATION CONCEPTUELLE Et LOGIQUE 1 Info. Données : -Volumes tables -Nbre de lignes... CONCEPTION PHYSIQUE DE LA BD REALISATION TEST 1 2 2 3 3 4 Conception Optimisée(choix Index, cluster, paramètres de stockage : pctfree, pcused, initial,next,initrans,...) Info. sur les modules (Batch, transactionnel, fréquences, volume données traitées,...) Optimisation des modules (requêtes, programmes, procédures,...) Tuning Info. sur le SGBD(optimiseur syntaxique, statistique, tableaux, curseurs,...) Info. sur l environnement (puissance des machines, debit du réseau, nbre de disques,... PRODUCTION ET MAINTENANCE 1 Statitistiques et Observations Reorganisation de la base Information Optimisation 5

1.3 Conception optimisée d'une base Choix d un Index(clé primaire /étrangère, colonne de sélection/partitionnement,...) Colonnes à ne pas indexer(si valeurs de la colonne peu distincts) Index non utilisé (voir optimiseur syntaxique) Choix d'un cluster Redondance calculée Dénormalisation (pour éviter les jointures,...) Partitionnement des tables(vertical, horizontal) Paramètres de stockage(pctfree, pctused,...) 6

1.4 Approches d optimisation de requêtes Oracle propose, à partir de la version 7, deux types d'optimiseurs : l'optimiseur syntaxique basé sur les règles et l'optimiseur statistique basé sur les coûts. Les versions antérieures d'oracle ne proposent que l'optimiseur syntaxique. Optimiseur Syntaxique L'optimiseur syntaxique s'appuie sur un ensemble de règles afin de sélectionner le meilleur chemin d'accès. Il ne tient pas compte des informations tels que le volume des tables. Il peut être influencé par le programmeur!!! Optimiseur Statistique L'optimiseur statistique s'appuie sur un ensemble d'informations concernant la sélectivité des tables (pourcentage de lignes pouvant être ramenées par une requête). Ainsi, l'optimiseur statistique peut décider d'effectuer un balayage séquentiel alors que l'optimiseur syntaxique choisirait d'utiliser l'index!!! 7

2. Etapes d optimisations PLAN 2.1 Démarche générale 2.2 Evaluation des expressions et constantes 2.3 Transformation de requêtes 2.4 Choix d une approche d optimisation 2.5 choix de chemins d accès 2.6 Optimisation de la jointure 8

2.1 Démarche Générale L optimiseur d Oracle suit les étapes suivantes afin d'optimiser une requête SQL : évaluation des expressions et des constantes, transformation des requêtes, fusion des vues, choix de l'approche d'optimisation, choix des chemins d'accès, choix de l'ordre de jointure et des opérations de jointure. Note : Cette liste d'étapes est effectuées indépendamment de la nature de l'optimiseur. 9

2.2 Evaluation des expressions et constantes Evaluation d expressions et constantes Lorsque l'optimiseur Oracle rencontre une expression, il tente de la transformer ou évaluer afin d'éviter la réévaluation à l'exécution. Pré-évaluation des constantes (expr 1) sal > 24000/12 (expr 2) sal > 2000 (expr 3) sal*12 > 24000 expr 1 converti en expr 2 expr 3 pas converti en exp 2 Note : réévaluation perpétuelle de expr 3 il faut éviter les expressions contenants une colonne. 10

2.2 Evaluation des expressions et constantes Transformation de l opérateur LIKE La comparaison d'une colonne avec une constante sans Jocker en utilisant l'opérateur LIKE est convertie en une condition d'égalité. Exemple ename LIKE 'KING' sera converti en ename = 'KING' Transformation de l opérateur IN L'optimiseur transforme une expression contenant l'opérateur IN en condition équivalente utilisant l'opérateur de comparaison '='et l'opérateur OR. Exemple : ename IN ( KING, JONES, BAR ) ename = KING OR ename= JONES OR ename = BAR devient 11

2.2 Evaluation des expressions et constantes Transformation des opérateurs ANYou SOME Comparaison avec une liste de valeurs Une condition avec les opérateurs de comparaison ANY et SOME et une liste de valeurs sera transformée par l'optimiseur en une condition avec les opérateurs d'égalité et les opérateurs logiques OR. Exemple sal > ANY (:sal1, :sal2) se traduit en sal > :sal1 OR sal >:sal2 Note si à la place de ANY ou SOME nous avons l'opérateur ALL. Nous aurons : sal > ALL (:sal1, :sal2) se traduit en sal > :sal1 AND sal >:sal2 12

2.2 Evaluation des expressions et constantes Transformation des opérateurs ANYou SOME Comparaison avec Sous-requête Une condition utilisant ANY ou SOME suivi d'une sous-requête est transformée en une condition avec l'opérateur EXIST. Exemple sal1 > ANY (select sal FROM emp WHERE job = ANALYST ); se traduit en EXISTS (select sal FROM emp WHERE job = ANALYST AND sal1 > sal); Notes : si à la place de ANY ou SOME nous avons l'opérateur ALL. Nous aurons : sal1 > ALL (select sal FROM emp WHERE job = 'ANALYST'); NOT EXISTS (select sal FROM emp WHERE job = 'ANALYST'AND sal1<=sal); 13

2.2 Evaluation des expressions et constantes Transformation de l opérateur BETWEEN Une condition utilisant l'opérateur BETWEEN sera remplacée par une condition équivalente avec les opérateurs '>='et '<='. Exemple sal BETWEEN 2500 AND 3000 sal >= 2500 AND sal <= 3000 se traduit en Transformation de l opérateur NOT Pour réduire une condition contenant NOT l'optimiseur applique la règle qui consiste à remplacer l'opérateur de comparaison par son opposé. Exemple NOT deptno = (select deptno FROM emp...); se traduit en deptno <> (select deptno FROM emp...); 14

2.2 Evaluation des expressions et constantes Transformation par transitivité Si deux conditions dans une clause WHERE sont définies sur la même colonne, elles peuvent inférer une troisième grâce à la règle de transitivité. Cas général WHERE colonne1 op_comp exp3 AND colonne1 = colonne2; se transforme en WHERE colonne 1 op_comp exp3 AND colonne2 op_comp exp3 Note : exp3 doit être une constante mais jamais une autre colonne. Exemple : select * from emp, dept where emp.deptno=10 and emp.deptno=dept.deptno; se traduit en select * from emp, dept where emp.deptno=10 AND dept.deptno=10; Note : l'index sur deptno est utilisé s'il existe. 15

2.3 Transformation de requêtes Requêtes contenant des OR Une requête ayant dans sa clause WHERE un OR peut être transformée en une requête composée utilisant l'opérateur UNION ALL si l'exécution de la requête composée est plus rapide que la requête d'origine. L'utilisation des index peut motiver une telle transformation. Exemple : Select * From emp Where job = CLERK OR deptno=20; deviendrait s il ya un index sur job et deptno (Note : ce choix n est pas toujours vrai avec l optimiseur statistique) Select * From emp Where job = CLERK UNION ALL Select * From emp Where deptno=20; 16

2.3 Transformation de requêtes Transformation de Requêtes complexes Une requête complexe peut être optimisée directement ou transformée en une requête équivalente de jointure. La transformation permet de bénéficier du processus d'optimisation des jointures (cf. chapitre 6 et 7). Exemple Note considérons la requête suivante : Select * From sales Where custid IN (select custid from customer); se transforme en select sales.* from sales, customer where sales.custid = customer.custid; si custid est une clé primaire. s'il est impossible de transformer, la requête parente et les sous-requêtes sont optimisées séparément. 17

2.3 Transformation de requêtes Requêtes accédant à une vue Deux approches de transformation sont possibles : 1. intégrer la requête de la vue à la requête d'accès 2. intégrer la requête d'accès à la requête de la vue. Approche 1 Le nom de la vue dans la requête d'accès est remplacé par le nom de la table de base et la condition de la vue est ajoutée à la clause WHERE de la requête. Exemple Create View emp10 As Select empno, ename, job From emp Where deptno = 10; Select empno From emp10 Where empno >7800; se traduit en Select empno From emp Where empno>7800 And deptno =10 18

2.3 Transformation de requêtes Requêtes accédant à une vue Note L'approche 1 ne peut être utilisée lorsque la requête de la vue contient : des opérateurs ensemblistes (UNION,...), la clause GROUP BY, la clause CONNECT BY, la clause DISTINCT et/ou les opérateurs de groupe (AVG, COUNT, MAX,...). Approche 2 La requête de la vue remplace la requête d'accès. La clause WHERE et les projections appropriées de la requête d'accès sont intégrées à à la requête de la vue. Exemple create view uemp (empno, ename, sal, deptno) select empno, ename, sal, deptno from emp1 ; UNION select empno, ename, sal, deptno from emp2 ; 19

2.3 Transformation de requêtes Requêtes accédant à une vue Approche 2 Exemple requête sur la vue uemp select empno, ename from uemp where deptno=20; est Transformée en Select empno, ename FROM emp1 Where deptno=20 UNION Select empno, ename FROM emp2 Where deptno=20 20

2.4 Choix d une approche d Optimisation Le choix d une approche d optimisation dépend des facteurs suivants : le paramètre d'initialisation OPTIMIZER_MODE les statistiques dans le dictionnaire de données le paramètre OPTIMIZER_GOAL les indications dans la requête. Le Paramètre OPTIMIZER_MODE Ce paramètre modifiable dans le fichier d'initialisation initx.ora indique le choix par défaut de l'approche d'optimisation. Deux valeurs sont possibles : CHOOSE: permet un futur choix de l'optimiseur syntaxique ou statistique (voir optimizer_goal) RULE : choix de l'optimiseur syntaxique même si des statistiques sont présentent 21

2.4 Choix d une approche d Optimisation Le Paramètre OPTIMIZER_MODE Note : la syntaxe dans init.ora est OPTIMIZER_MODE=CHOOSE #ou RULE par défaut sa valeur est CHOOSE il est valable uniquement à partir d'oracle 7 concerne toutes les sessions. Le paramètre OPTIMIZER_GOAL Ce paramètre permet de modifier dynamiquement la valeur du paramètre OPTIMIZER_MODE. OPTIMIZER_GOAL peut prendre les valeurs suivantes : CHOOSE : choix automatique entre les règles et les coûts en fonction de la présence ou non des statistiques. S'il ya des statistiques dans le dictionnaire de données, l'approche utilisée est celle des coûts et le but est d'effectuer un temps minimum pour ramener l'ensemble des lignes. 22

2.4 Choix d une approche d Optimisation Le paramètre OPTIMIZER_GOAL ALL_ROWS : oblige l'optimiseur à utiliser l'approche basée sur les coûts indépendemment de la présence des statistiques. BUT : temps minimum pour ramener l'ensemble des tuples. FIRST_ROWS : cette valeur oblige l'optimiseur à utiliser l'approche basée sur les coûts pour toute requête en présence ou non de statistiques dans le dictionnaire. But : meilleurs temps de réponse. RULE : cette valeur oblige l'optimiseur à utiliser l'approche basée sur les règles qu'ils y aient ou non des statistiques. Notes ces valeurs affectent les procédures stockées ; ces valeurs n'affectent pas les requêtes récursives (requêtes lancées implicitement par Oracle sur le dictionnaire de données). Seules les valeurs de OPTIMIZER_MODE sont déterminantes pour elles ; Exemple sql > Alter Session Set Optimizer_goal=RULE 23

2.5 Choix de chemins d accès Généralités L'accès à un tuple lors de l'exécution d'une requête SQL (indépendance logique/physique) peut se faire à travers plusieurs chemins d'accès. Le rôle de l'optimiseur est de sélectionner le meilleurs d'entre eux. Pour accéder aux données, Oracle s'appuie sur 5 méthodes d'accès de base. Nous survolons ici rapidement : les méthodes d'accès d'oracle la liste des chemins d'accès le mode de choix d'un chemin d'accès 24

2.5 Choix de chemins d accès Les Méthodes d'accès Accès par ROWID Accès par Index (B-arbre, Bitmap (V8) ) Accès par cluster indexé Accès par cluster haché Accès séquentiel Table organisée dans un index (Oracle 8) 25

2.5 Choix de chemins d accès Liste des chemins d accès RANG CHEMIN D ACCES 1 ROWID = constante (1 tuple au plus ramené) 2 clé cluster entièrement renseignée = clé cluster d'une autre table (1 tuple au plus ramené) 3 Clé cluster haché avec index unique ou primaire = constante (1 tuple au plus est ramené) 4 index unique ou clé primaire entièrement renseignée = constante (1 tuple au plus est ramené) 5 clé cluster entièrement renseignée = clé cluster d'une autre table (0 à N tuples sont ramenés) 6 clé cluster hachée avec index unique ou primaire = constante (0 à N tuples sont ramenés) 7 clé cluster indexée = constante 8 Index composé entièrement renseigné <=ou>= constante 9 Index non unique simple = constante 10 Index concatené partiellement renseigné à gauche Index (unique non unique) utilisé avec between ou like 'X%' 11 Index (unique non unique) <ou<= ou > ou >= constante 12 tri fusion (jointure de tables non clusterisées) 13 MAX ou MIN (colonne indexée) 14 Order by colonne indexée 15 Balayage séquentiel 26

2.5 Choix de chemins d accès Mode de choix d un chemin d accès La sélection d'un chemin d'accès se fait en fonction de l'approche d'optimisation choisie : règle ou coûts. Dans l approche règle En présence de plusieurs chemins d'accès, l'optimiseur syntaxique choisit d'abord les chemins de fortes priorités(rang 1 à 15). Exemple select empno from emp where ename='king'and sal >2500; Considérons comme définis : une clé primaire sur empno un index sur ename nommé idx_ename un index sur sal nommé idx_sal chemins d'accès disponibles : Index non unique simple=constante. Ou, ename= constante (rang 9) Index < ou <= ou > ou >= constante : sal > 2500 (rang 11) l'accès séquentiel à toute la table (rang 15). Choix: l'optimiseur choisi le chemin idx_ename de rang 9 27

2.5 Choix de chemins d accès Mode de choix d un chemin d accès Dans l approche coûts. Les étapes pour choisir un chemin d'accès sont les suivantes : 1. déterminer les chemins d'accès valides 2. estimer le coût de chacun des chemins d'accès ou leur combinaison(plan d'accès). 3. Choisir le ou les chemins du plan avec le(s) plus faible coût(s) Les statistiques déterminent les coûts d'un plan : statistiques sur les tables(nombre de tuples, nombre de blocs utilisés, nombre de blocs jamais utilisés,...) statistiques sur les index(niveau d'index, nombre de feuilles,...)... 28

2.5 Choix de chemins d accès Mode de choix d un chemin d accès Dans l approche coûts. Le choix entre deux chemins d accès est déterminé : par le taux de sélectivité et le paramètre db_file_multiblock_read_count. Exemple select * from emp where ename = SCOTT ; 1. Première hypothèse - ename est clé unique - il ya un seul employé au nom de SCOTT Chemins disponibles Choix index unique ou clé primaire entièrement renseignée =constante (chemin n 4) : ename = 'SCOTT' Balayage séquentiel (chemin n 15) le chemin n 4 sera choisit car fort taux de sélectivité 29

2.5 Choix de chemins d accès Mode de choix d un chemin d accès Exemple (suite) 2. Seconde hypothèse ename est clé non unique nombre d'employés=user_tables.num_rows=100 nombre d'employés s'appelant scott = 90 d'où, user_tab_columns.distinct=11 Chemins disponibles Index non unique simple=constante: ename='scott'(chemin 9) balayage séquentiel (chemin n 15) Estimation du coût Avec index 90% des employés sont ramenés si on cherche ename='scott' + recherche dans l'index Balayage séquentiel 100% des employés sont ramenés Choix avec un db_file_multiblock_read_count grand, le balayage séquentiel est raisonnable 30

2.6 Optimisation de la jointure Pour sélectionner un plan d'exécution pour la jointure, l'optimiseur doit effectuer en plus les étapes suivantes : choix de chemins d'accès choix de l'opération de jointure à effectuer : boucle imbriquée, tri-fusion, cluster choix de l'ordre de jointure : déterminer la table directrice, la deuxième table... Note Ces choix dépendent de l'approche d'optimisation quelque soit l optimiseur : les tables ayant des colonnes uniques et clés sont placées en premier dans l'ordre de jointure. 31

PLAN 3. Méthodes d'accès 3.1 Généralités 3.2 Accès séquentiel 3.3 Accès par ROWID 3.4 Accès indexé (B-arbre, Bitmap) 3.5 Table oraganisée dans un index 3.6 Accès par clusters indexés 3.7 Accès par clusters Hachés 3.8 Mesures 32

3.1 Généralités Un SGBD est caractérisé par une indépendance entre la façon dont les données sont stockées et comment y accéder. L accès à un tuple donné peut se faire suivant différentes méthodes ou combinaison de méthodes d'accès. Oracle Offre pour cela plusieurs méthodes d'accès aux données : le la balayage séquentiel (FULL TABLE SCAN) l'accès direct par ROWID l'accès par index (INDEX SEARCH) l'index bitmap (à partir de V8.0) l'accès par cluster indexé table organisée dans un indexe (à partir de V8.0) l'accès par clé de hachage (à partir d'oracle7) 33

La méthode d'accès séquentiel correspond à un balayage complet d'une table (pas d'utilisation d'accélérateurs tels que les index,...). Exemple 3.2 Accès séquentiel select * from emp ; Aucun index n est utilisé ici. Nous verrons plus loin comment l optimiseur décide d'effectuer ou non un balayage séquentielle. Remarque Un des moyens d'accélérer l'accès aux données en accès séquentiel est d'augmenter le facteur de blocage. db_file_multiblock_read_count 34

3.3 Accès par ROWID Un rowid est l identifiant unique d une ligne dans une base Oracle. Toute table Oracle contient une colonne virtuelle appelée rowid. Rowid sous Oracle 7 SQL> select rowid, ename, job from emp; ROWID ENAME JOB 00000012.0002.0002 WARD SALESMAN 00000012.0003.0002 JONES MANAGER 00000012.0004.0002 MARTIN SALESMAN 00000012.0005.0002 BLAKE MANAGER 00000012.0006.0002 CLARK MANAGER 00000012.0007.0002 SCOTT ANALYST 00000012.0008.0002 KING PRESIDENT 00000012.0009.0002 TURNER SALESMAN 00000012.000A.0002 ADAMS CLERK 00000012.000B.0002 JAMES CLERK 00000012.000C.0002 FORD ANALYST 00000012.000D.0002 MILLER CLERK 00000012.000E.0002 SMITH CLERK 35

3.3 Accès par ROWID Rowid sous Oracle 7 ROWID ENAME JOB 00000012.0002.0002 WARD SALESMAN I1 I2 I3 Avec I1 : Identificateur logique d'un bloc (4 caractères) I2 : Identificateur logique d'une ligne (2 caractères) I3 : Identificateur logique d'un fichier(2 caractères) ROWID à partir de la V8 ROWID ENAME JOB AAAAvGAAFAAAACyAAA SMITH CLERK I1 I2 I3 I4 I1: N de Segment (6 caractères) I2 :N de fichier(3 caractères) I3 : N de bloc(6 caractères) I4: N de ligne(3 caractères) 36

3.3 Accès par ROWID Un ROWID est le moyen le plus rapide d accéder à un tuple ou ligne. Exemple Select * From emp Where rowid = '00000012.0002.0002 '; Attention Attention, l'écriture ci-dessus n'est pas portable. 37

3.4 Accès par index Généralités Un index est une structure optionnelle associée à une table ou un cluster afin d accélérer l'accès aux lignes de la table ou du cluster. Un index peut être (depuis Oracle 7) crée implicitement (colonnes clés ou uniques) ou explicitement grâce au langage SQL. Les index sont logiquement et physiquement indépendants des données des tables associées. Un index peut être unique ou non unique. Il peut être mono-colonne ou multi-colonnes. Oracle supporte depuis la version 8 différents types d'index notamment les index de type B-arbre et de type Bitmap 38

3.4.1 Accès par index B-arbre Généralités Un index de type B-arbre est un arbre comprenant une racine, des noeuds intermédiaires et des feuilles. La racine du B-arbre pointe vers les noeuds intermédiaires et les noeuds intermédiaires pointent vers les noeuds feuilles. Les noeuds feuilles pointant eux vers les lignes d'une table. On parle de B-arbre ou arbre balancé qui permet deoracle utilise des arbres dit balancés afin que l'accès à chaque ligne d'une table prenne le même temps. Un index B-arbre garanti que l accès à chaque ligne d'une table prend le même temps quelque soit le chemin choisi de la racine du B-arbre vers les feuilles 39

3.4.1 Accès par index B-arbre Généralités Structure d un B-arbre BLOC D INDEX RACINE BLOC D'INDEX Intermédiaire BLOC D INDEX Intermédiaire BLOC D'INDEX FEUILLE BLOC D'INDEX FEUILLE BLOC D'INDEX FEUILLE BLOC D'INDEX FEUILLE 40

3.4.1 Accès par index B-arbre Généralités Exemple King Blake James Miller Simonth James Jones Miller Simonth Scott Smith Blake Clark Ford Adams Allen King Martin Arbre de Hauteur = 2 A chaque feuille on trouve : la valeur clé et le ROWID (index unique) ou les la liste des ROWID (Index non unique). Par exemple ADAMS '00000012.0002.0002 '. 41

3.4.1 Accès par index B-arbre Structure Interne d un Index B-arbre Condition requis par un B-arbre Oracle Un arbre de recherche est B*arbre Oracle d'ordre N si : chaque bloc est rempli au plus à 100% chaque bloc, sauf la racine, a au moins un taux de remplissage de N% chaque bloc noeud a m+1 successeurs, ou m est le nombre de clés dans la page, tous les blocs feuilles sont au même niveau. PCTFREE N% de remplissage 100% de remplissage à la création 100% de remplissage après la création. 42

3.4.1 Accès par index B-arbre Structure Interne d un Index B-arbre Avantage d un B-arbre Toutes les feuilles de l'arbre ont la même profondeur Le balancement est automatique s'adapte à une variété de requêtes Intéressant pour petites et grandes tables Inconvénient d'un B-arbre consomme de la place, pénalise la modification et l'insertion 43

3.4.1 Accès par index B-arbre Création d'un index Pendant qu'une table est associée lors de sa création à un segment de données, un index lui est associé à un segment d'index. Syntaxe de création d'un Index CREATE [UNIQUE] INDEX nom_index ON nom_table (colonne1[asc DESC] [, colonne2,...]) [INITRANS valeur] [MAXTRANS valeur] [TABLESPACE nom_tablespace] [STORAGE paramètres_de_stockage] [PCTFREE [=] %] [NOSORT] --ASC par défaut [PARTITION clause_de_partionnement] 44

3.4.1 Accès par index B-arbre Création d'un index Mot clé / paramètre Description ASC,DESC Index ascendant ou descendant Initrans Nombre de transactions concurrentes dont les informations sont directement notées dans l'entête du bloc. Maxtrans Nombre de transaction concurrentes maximum sur un, bloc. Tablespace Espace de stockage dans lequel le segement de l'index sera créé. Storage Définition de la taille du segment Partition Clause de partitionnement d'un index. 45

3.4.1 Accès par index B-arbre Création d'un index Exemple création de l'index idx_ename sur la colonne ename de la table emp. CREATE INDEX idx_ename ON emp (ename) TABLESPACE STUDENT95 STORAGE( INITIAL 50K NEXT 50K MINEXTENTS 1 MAXEXTENTS 25 PCTINCREASE 0 ) PCTFREE 30; 46

3.4.1 Accès par index B-arbre Modification d un index Syntaxe ALTER INDEX nom_index [REBUILD { [TABLESPACE nom_tablespace] [STORAGE paramètres_de_stockage] PCTFREE [=] %] [LOGGING] --génération ou non d'entrées Redolog [NOLOGGING] [REVERSE] [NOREVERSE]}] [RENAME TO nouveau_nom_index] [MODIFY DEFAULT ATTRIBUTES { [TABLESPACE nom_tablespace] [STORAGE paramètres_de_stockage] PCTFREE [=] %]}] [MODIFY PARTITION nom_partition] [RENAME PARTITION nom_partition] [DROP PARTITION clause_de_partionnement] [SPLIT PARTITION partion_split_clause] [REBUILT PARTITION partition_name] 47

3.4.1 Accès par index B-arbre Modification d un index Exemple Sql>ALTER INDEX idx_ename REBUILD TABLESPACE ts_cour_temp; 48

3.4.1 Accès par index B-arbre Vues du dictionnaire ALL_INDEXES, ALL_IND_COLUMNS ALL_IND_PARTITIONS, USER_INDEXES, USER_IND_COLUMNS USER_IND_PARTITIONS, USER_PART_INDEXES DBA_INDEXES, DBA_IND_COLUMNS DBA_PART_INDEXES, DBA_IND_PARTITIONS Consultation des vues du dictionnaire sql > select * from all_ind_columns where index_name = IDX_ENAME ; INDEX_OWNER : SCOTT INDEX_NAME : IDX_ENAME TABLE_OWNER : SCOTT TABLE_NAME : EMP COLUMN_NAME : ENAME COLUMN_POSITION : 1 COLUMN_LENGHT : 10 49

3.4.1 Accès par index B-arbre Consultation des vues du dictionnaire sql> select * from all_indexes where index_name = IDX_ENAME ; OWNER : SCOTT INDEX_NAME : IDX_ENAME TABLE_OWNER : SCOTT TABLE_NAME : EMP TABLE_TYPE : TABLE UNIQUENES : NONUNIQUE TABLESPACE_NAME : USERS MAX_TRANS : 255 INITIAL_EXTENT : 51200 NEXT_EXTENT : 51200 MIN_EXTENTS : 1 MAX_EXTENTS : 25 PCT_INCREASE : 0 PCT_FREE : 30 STATUS : Valid 50

3.4.1 Accès par index B-arbre Estimation de la taille d un Index Nbre estimé de valeurs d'index Taille Index = ------------------------------------------- * TBO * 1.1 Taille utile d'un bloc / longueur Moyenne d'une clé Nbre estimé de valeurs d'index=nbre total estimé de valeurs non nulles Taille utile d'un bloc = (TBO - 61 - INITRANS*23 Place PCTFREE)*0,75 Place PCTFREE= (TBO - 61 - INITRANS*23)*0,1 si pctfree vaut 10% Place PCTFREE=194,1 Longueur Moyenne d'une valeur d'index=11 (10 si index unique) + nbre de colonnes de l'index + longueur colonne 1 + longueur colonne 2 + longueur colonne N TBO = Taille d'un Bloc Oracle (2048, 4096, 8192, ) dépend de l'os Note : On multiplie par 1,1 pour tenir compte de la taille des noeuds intermédiaires et racine(environ 10%) Exemple : estimation de taille d'un index concatené de 100000 Noms et prénoms 100.000 Taille Index = --------------------------------------------- * 2048*1.1 (2048-61-23*2-194)*0,75/(11+2+8+8) TAILLE INDEX ENVIRON 5 Mo 51

3.4.2 Index Bitmap Accès par index Bitmap 1. Quand utiliser un index Bitmap 2. Création d'un index Bitmap 3. Paramètres d'initialisations et valeurs par défaut 52

3.4.2 Index Bitmap Quand utiliser un index Bitmap la clause WHERE a plusieurs PREDICAT sur des colonnes de CARDINALITE faible ou moyenne (peut de clés distinctes) Chacun des prédicats sur les colonnes susmentionnées rend un nombre important de lignes Des index Bitmap existent sur une ou plusieurs colonnes sus-mentionnées pour une table de volumétrie forte (PLUS LA TABLE EST VOLUMINEUSE MIEUX ILS SONT) permettent d'economiser L'espace DISQUE Pratique pour les APPLICATIONS de type DataWareHouse (DWH) 53

3.4.2 Index Bitmap Exemple de colonnes candidates Custid# Etat_marital Region Genre 101 célibataire est M 102 marié centre F 103 marié ouest F 104 divorcé ouest M 105 célibataire centre F 106 marié centre F NOTE : Les colonnes Etat_marital, Région et Genre sont de cardinalité faible, donc candidats à index bitmap Index Bitmap sur la colonne Region Custid# Region=est Region=centre region=ouest 101 1 0 0 102 0 1 0 103 0 0 1 104 0 0 1 105 0 1 0 106 0 1 0 54

3.4.2 Index Bitmap Exemple de requête Compter le nombre de clients mariés habitant la région Centre ou Est. Status =marie region=centre region=ouest Résultat 0 0 0 0 1 1 0 1 1 AND ( 0 OR 1 ) = 1 0 0 1 0 0 1 0 0 1 1 0 1 55

3.4.2 Index Bitmap Création d'un index Bitmap Syntaxe général CREATE BITMAP INDEX nom_index ON nom_table (colonne [asc desc] [, colonne [asc desc]] ) [TABLESPACE nomtablespace] [PCTFREE integer] [PCTUSED integer] [INITRANS integer] [MAXTRANS integer] [Storage clause] [LOGGING NOLOGGING] [NOSORT] Exemple SQL>CREATE BITMAP INDEX idx_job_bitmap ON emp(job) TABLESPACE ts_cour_users; 56

3.4.2 Index Bitmap Paramètres d'initialisations et valeur par défaut b_tree_bitmap_plans =FALSE // Force un plan avec Bitmap BITMAP create_bitmap_area_size = 8388608 // espace utile pour créer les Bitmap bitmap_merge_area_size=1048576 // espace utile pour fusionner les Bitmap 57

3.4.2 Index Bitmap Les valeurs nulles Contrairement aux Index B-tree, les valeursnulles sont stockées dans l'index SELECT count(*) FROM emp WHERE comm IS NULL; La requête précédente exploite l'index bitmap s'il existe Limites des index Bitmap Le mélange dans une clause WHERE d'un index B- tree et d'un index Bitmap peut être couteux Adaptés pour des tables à forte volumétrie et aux colonnes à cardinalités faibles 58

3.4.2 Index Bitmap Comparaison B-TREE et BITMAP CRITERE B-TREE BITMAP Cardinalité des colonnes forte faible Coût des MAJ faible fort Requête avec OR inefficace efficace Verrouillage ligne segment Consomation d'espace fort Faible Domaine d application OLTP Décisionnel 59

Notion 3.5 Table organisée dans index Une table organisée dans un index (IOT) est une table dont l'ensemble des lignes est stockée dans les feuilles de l'index L organisation est faite en fonction de la colonne clé. TABLE et INDEX SEPARES INDEX TABLE et INDEX FUSIONNES INDEX + TABLE TABLE Rowid col1 col2 T1 T2... 60

Avantages 3.5 Table organisée dans index pas de duplication de la valeur de la clé l accès aux données via la clé est rapide adpaté pour les applications de type DWH adapté pour les applications de recherche par le contenu (recherche dans un document) adapté pour les applications spatiales 61

3.5 Table organisée dans index Inconvénients impossible d indexer d autres colonnes car la table n a pas d identifiants de lignes (ROWID) : jusqu à Oracle 8.0 ne peuvent être mises en CLUSTER ne peuvent contenir de colonnes LONG ne peuvent être ni partitonnées ni repliquées (V8.0) 62

3.5 Table organisée dans index Syntaxe de création d'une table Organisée dans un index CREATE TABLE nomtable( SpéficationsDesColonnesETdesContraintes ) ORGANIZATION INDEX [segment_attributes_clause] [PCTTHRESHOLD entier] [[INCLUDING nomcolonne] OVERFLOW [segment_attributes_clause]]; segment_attributes_clause ::= [storage(initial entier next entier minextents...)] [TABLESPACE nomtablespace] [LOGGING NOLOGGING] 63

3.5 Table organisée dans index Syntaxe de création d'une table Organisée dans un index Mot clé ou paramètre Organization Description Mot clé indiquant qu'une table est organisée dans un index Pctthreshold entier Spécifie la taille de l'espace réservé à une ligne dans le segment IOT. En cas de dépassement le reste de la ligne sera écrit dans le segment de débordement. Ce paramètre vaut de 0 à 50 Including nomcolonne le reste de la ligne à rediriger vers le segment de débordement commence avec la colonne nomcolonne Overflow les lignes dépassant Pctthreshold sont rejetées dans le segment de débordement spécifié ici 64

Exemple 3.5 Table organisée dans index CREATE TABLE sales( SALESPERSON_ID NUMBER(4), CUSTOMER VARCHAR2(45), PRODUCT VARCHAR2(30), Dachat DATE, AMOUNT NUMBER, PRIMARY KEY(salesperson_id, customer, product, dachat)) ORGANIZATION INDEX TABLESPACE ts_cour_users; 65

3.5 Table organisée dans index Gestion des débordements des lignes trop longues dans le segment IOT entraitement la baisse de performances d'accès Afin de limiter la taille des lignes dans le segment de type IOT, il est possible d orienter une partie d une ligne vers un segment de débordement. Les clauses OVERFLOW, PCTTHRESHOLD et INCLUDING permettent de gérer les débordements. 66

Exemple 3.5 Table organisée dans index CREATE TABLE sales3( SALESPERSON_ID NUMBER(4), CUSTOMER VARCHAR2(45), PRODUCT VARCHAR2(30), Dachat DATE, AMOUNT NUMBER, PRIMARY KEY(salesperson_id, customer, dachat)) ORGANIZATION INDEX TABLESPACE ts_cour_users INCLUDING product PCTTHRESHOLD 20 OVERFLOW TABLESPACE tools; 67

3.5 Table organisée dans index Consultation du dictionnaire Oracle Les informations sur les tables organisées dans l'index sont disponibles dans les vues : *_tables, *_segments, *_indexes Sql>SELECT table_name, tablespace_name, iot_name, iot_type FROM user_tables ORDER BY table_name; Table_name Tablespace_name IOT_name IOT_Type SALES3 IOT SYS_IOT_OVER_2561 TOOLS SALES3 IOT_overflow SQL> SELECT index_name, index_type, tablespace_name FROM user_indexes ORDER BY index_name; INDEX_NAME INDEX_TYPE TABLESPACE_NAME SYS_IOT_TOP_2561 IOT-TOP TS_COUR_USERS 68

3.5 Table organisée dans index Consultation du dictionnaire Oracle Sql> SELECT segment_name, tablespace_name, segment_type FROM user_segments ORDER BY segment_name; SEGMENT_NAME TABLESPACE_NAME SEGMENT_TYPE SYS_IOT_OVER_2561 TOOLS TABLE SYS_IOT_TOP_2561 TS_COUR_USERS INDEX NOTES : SALES3 table organisée dans un index : ts_cour_users : tablespace de sales3 SYS_IOT_TOP_2561 : nom du segment d'index. Le type d index est IOT-TOP. SYS_IOT_OVER_2561 segment de débordement: TOOLS : tablespace de débordement Il est de type TABLE. Son IOT-TYPE est IOT-OVERFLOW. 69

3.5 Table organisée dans index Comparaison avec des tables normales Critères Table normale IOT Identification des lignes rowid clé primaire Présence de ROWID oui non Nombres d index 0 à N 1 Accès séquentiel lignes non ordonnées ordonnées Consommation d espace plus moins Type de segment table index ( table) Réplication/ Partitionnement oui non(v8.0) 70

3.6 Accès par Cluster indexé Généralités Un cluster (concept introduit avec System*R) est un groupe de tables partageant un même bloc de données. Ces tables ont en commun certaines colonnes et sont souvent accédées ensembles. Objectifs des clusters Améliorer les performances des requêtes localisation physique des données de plusieurs tables dans un même bloc. 71

Exemple 3.6 Accès par Cluster indexé l'accès aux tables stockées dans un cluster est efficace seulement si les données sont accédées via la clé du cluster. la requête suivante est par exemple pénalisée Select emp.* From dept, emp Where emp.deptno=dept.deptno; Certaines requêtes de consultation sont pénalisées. La requête ci-dessous par exemple prend plus de temps car on parcours plus de blocs select dept.* from dept ; l insertion et la mise à jour des données peuvent être également pénalisées 72

3.6 Accès par Cluster indexé Création d'un cluster Syntaxe CREATE CLUSTER [schéma.]cluster_name (column datatype [,column datatype]...) [PCTUSED integer] [ PCTFREE integer] [SIZE integer][k M] [INITRANS integer] [MAXTRANS integer] [TABLESPACE tablespace_name] [STORAGE storage_param] [INDEX] [[HAS IS colonne] HASHKEYS integer] Exemple create cluster cluster_emp_dept (deptno number(4)) pctused 80 pctfree 20 size 600 tablespace student95 storage ( initial 200K next 300K minextents 2 maxextents 20 pctincrease 33)); create table emp(...) cluster cluster_emp_dept (deptno); create table dept(...) cluster cluster_emp_dept (deptno); Note Le paramètre SIZE définit la taille d'un bloc logique. 73

3.6 Accès par Cluster indexé Index de cluster Un index peut être crée au niveau d'un cluster afin d'en accélérer l'accès. Exemple create index idx_emp_dept on cluster cluster_emp_dept initrans 2 maxtrans 5 tablespace student95 storage(initial 50K next 50K minextents 2 maxextents 10 pctincrease 33) pctfree 5; 74

3.7 Accès par Cluster haché Généralités La technique de hachage consiste à répartir les, enregistrements d'une ou plusieurs tables dans les mêmes blocs en fonction de la valeur d'une clé. Une fonction de hachage h fait correspondre à une valeur de la clé c un entier e, de 0 à N. La recherche d'un enregistrement va consister à appliquer la fonction de hachage pour retrouver le bloc auquel appartient la clé puis de rechercher l'enregistrement dans ce bloc. Sous Oracle le balayage par hachage est utilisé pour stocker des lignes (enregistrements) dans des clusters dit hachés. 75

Exemple 3.7 Accès par Cluster haché create cluster cluster_dept_emp (deptno number(3)) pctused 80 pctfree 5 SIZE 2K HASHKEYS 1000; create table dept (deptno number(3),...) CLUSTER cluster_dept_emp; Note pour supprimer un cluster haché il faut lancer drop cluster emp_dept; 76

3.7 Accès par Cluster haché Avantages et Utilisation des clusters hachés bien choisir HASH IS, SIZE et HASHKEYS convient pour les requêtes ou il ya souvent l'égalité sur la clé de hachage convient pour des tables dont la taille est statique (pas d'évolution sensible de leur taille) car risque de chaînage un moyen de représenter un tableau de lignes avec HASH IS colonne, HASHKEYS n et SIZE m Inconvénient des Clusters hachés si on accède souvent séquentiellement aux tables si la condition dans la clause where n'est pas '=' si la table croît continuellement si on ne peut prévoir d'avance l'espace que demande le cluster. 77

3.8 Mesures Accès sans index 20 temps 15 10 5 0 NB BLOCS ORACLE 78

3.8 Mesures Accès avec index B-arbre 0.4 temps 0.3 0.2 0.1 0 5 blocs NB BLOCS ORACLE Note : baisses des performances en insertion ou mise à jour avec index 79

4. Les Chemins d accès Tableau récapitulatif des Chemins d'accès RANG CHEMIN D ACCES 1 ROWID = constante (1 tuple au plus ramené) 2 clé cluster entièrement renseignée = clé cluster d'une autre table (1 tuple au plus ramené) 3 Clé cluster haché avec index unique ou primaire = constante (1 tuple au plus est ramené) 4 index unique ou clé primaire entièrement renseignée = constante (1 tuple au plus est ramené) 5 clé cluster entièrement renseignée = clé cluster d'une autre table (0 à N tuples sont ramenés) 6 clé cluster hachée avec index unique ou primaire = constante (0 à N tuples sont ramenés) 7 clé cluster indexée = constante 8 Index composé entièrement renseigné <=ou>= constante 9 Index non unique simple = constante 10 Index concatené partiellement renseigné à gauche Index (unique non unique) utilisé avec between ou like 'X%' 11 Index (unique non unique) <ou<= ou > ou >= constante 12 tri fusion (jointure de tables non clusterisées) 13 MAX ou MIN (colonne indexée) 14 Order by colonne indexée 15 Balayage séquentiel 80

PLAN 5. Outils d optimisation Généralités TKPROF EXPLAIN PLAN ANALYZE INDEX 81

5.1 Généralités Oracle fournit des utilitaires d aide à l'optimisation de requêtes SQL. Ce sont : TKPROF :outil d'analyse de fichiers trace EXPLAIN:donne le plan d'exécution d'un Ordre SQL ANALYZE INDEX:fournit les statistiques sur les Index 82

5.2 TKPROF TKPROF est l outil d Oracle qui permet de fournir des statistiques sur les temps d exécution des requêtes SQL,le nombre de blocs recherchés en mémoire et sur disque ainsi que facultativement le plan d'exécution de l'ordre. Activation du mode trace Paramètres à positionner dans le fichier init.ora TIMED_STATISTICS= TRUE /* default = FALSE*/ MAX_DUMP_SIZE=integer /* default=500k*/ USER_DUMP_DEST=chemin /* default=$oracle_home/rdbms/log sous UNIX*/ SQL_TRACE=TRUE /* default=false :valable sur toute la base*/ /* déconseillé en production*/ 83

5.2 TKPROF Activation du mode trace au niveau session SQL_TRACE peut être activé uniquement pour une session (via la commande SQL alter session) : SQL>alter session set sql_trace = true; ou en exécutant la fonction set_sql_trace du package dbms_session SQL>EXECUTE sys.dbms_session.set_sql_trace(true); Activation du mode trace pour une autre session via l appel de fonction Syntaxe EXECUTE sys.dbms_system.set_sql_trace_in_session( Session_id, serial_id, {true false}) Exemple EXECUTE sys.dbms_system.set_sql_trace_in_session(7, 34, true)/ 84

5.2 TKPROF Analyse d un fichier TKPROF Le positionnement des paramètres précédents provoque à chaque lancement d'une requête, la création d'un fichier trace : *.trc Syntaxe $ TKPROF fichier_trace fichier_sortie [EXPLAIN=username/passwd] [SORT=sortoption] Mots clés / Paramètres fichier_trace fichier_sortie EXPLAIN Description fichier d entrée contenant les traces fichier de sortie oblige tkprof à lancer EXPLAIN sortoption option de tri dans fichier_sortie :... execpu fchcpu exedsk : coût CPU :coût de chargement de tuples : NB de lectures physiques sur disque 85

5.2 TKPROF Résultat de l'analyse Le résultat de l'analyse comporte pour chaque Ordre SQL, les informations sur sa compilation, son exécution et les accès aux données. COUNT CPU Elapsed DISK Querry Current ROWS PARSE EXECUTE FETCH Nbre d analyse Nbre d exec de l ordre Nbre de lectures temps CPU analyse temps CPU Exécution temps CPU accès temps analyse écoulé temps exécution écoulé temps accès écoulé NB lect. disque en parse NB lect. disques à l'exéc. NB lect. disques en l'accès NB Buffers eus en lecture NB Buffers eus en lecture NB Buffers eus en lecture NB buffers eus en maj NB buffers eus en maj NB buffers eus en maj NB lignes rendues NB lignes rendues NB lignes rendues Note : NB = Nombre 86

5.2 TKPROF Résultat de l'analyse Statistique count cpu elapsed disk query current rows Description nombre de fois ou un parse, execute ou fetch a été réalisé temps CPU en seconde pour tous les parse, execute et fetch de la requête temps écoulé en seconde pour tous les parse, execute et fetch de la requête nombre de blocks de données lus sur disque pour tous les parse, execute et fetch nombre total de blocs lu en mode consistant pour tous les parse, execute et fetch (query) nombre total de blocs lu en mode courant pour tous les parse, execute et fetch (usuellement en INSERT, UPDATE et DELETE) nombre total de lignes traitées par la requête (n inclus pas les lignes traitées par les sous-requêtes). En selection le nombre de lignes apparait sur la ligne du FETCH. En UPDATE, DELETE et INSERT apparait sur la ligne du EXECUTE. querry + current : Nombre total de blocs accédés 87

5.2 TKPROF Exemple d activation de tkprof sql> alter session set sql_trace=true; sql> select * from emp where ename = KING ; sql> alter session set sql_trace=false; Sql> select username, spid from v$process where username = nomuser ; sql>exit $ tkprof /admin/udump/ora_spid.trc trc1.prf EXPLAIN=nomuser/passwd SORT = execpu, fchcpu Cette commande lance tkprof sur les statistiques contenues dans le fichier mytrc.trc. tkprof doit générer les statistiques dans un fichier exploitable appelé trc1.prf en ordonnant le résultat selon les valeurs de tri execpu+fchcpu. $ emacs trc1.prf /* consultation dans votre éditeur préféré */ 88

5.2 TKPROF Exemple de fichier résultat TKPROF: Release 8.0.4.0.0 - Production on Wed Jun 23 14:40:38 1999 (c) Copyright 1997 Oracle Corporation. All rights reserved. Trace file: c:\oradata\dbcour\user\ora00161.trc Sort options: default *********************************************************************** count = number of times OCI procedure was executed cpu = cpu time in seconds executing elapsed = elapsed time in seconds executing disk = number of physical reads of buffers from disk query = number of buffers gotten for consistent read current = number of buffers gotten in current mode (usually for update) rows = number of rows processed by the fetch or execute call *************************************************************** alter session set sql_trace=true call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 0 0.00 0.00 0 0 0 0 Execute 1 0.11 0.92 0 0 0 0 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 1 0.11 0.92 0 0 0 0 Misses in library cache during parse: 0 Misses in library cache during execute: 1 Optimizer goal: CHOOSE Parsing user id: 5 ********************************************************************** 89

5.2 TKPROF Exemple de fichier résultat select * from emp where ename = KING call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.01 0.09 0 0 0 0 Execute 1 0.02 0.13 0 0 0 0 Fetch 1 0.05 0.51 0 1 3 1 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 3 0.08 0.73 0 1 3 1 Misses in library cache during parse: 0 Optimizer goal: CHOOSE Parsing user id: 5 ********************************************************************** alter session set sql_trace=false call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.02 0.07 0 0 0 0 Execute 1 0.01 0.01 0 0 0 0 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 2 0.03 0.08 0 0 0 0 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 5 90

5.2 TKPROF Exemple de fichier résultat ********************************************************************** OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 3 0.03 0.17 0 0 0 0 Execute 4 0.14 1.06 0 0 0 0 Fetch 2 0.05 0.51 0 1 3 2 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 9 0.22 1.74 0 1 3 2 Misses in library cache during parse: 1 Misses in library cache during execute: 1 OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 0 0.00 0.00 0 0 0 0 Execute 0 0.00 0.00 0 0 0 0 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 0 0.00 0.00 0 0 0 0 91

5.2 TKPROF Exemple de fichier résultat Misses in library cache during parse: 0 4 user SQL statements in session. 0 internal SQL statements in session. 4 SQL statements in session. ********************************************************************** *********************************************************************** Trace file: c:\oradata\dbcour\user\ora00161.trc Trace file compatibility: 7.03.02 Sort options: default 3 sessions in tracefile. 4 user SQL statements in trace file. 0 internal SQL statements in trace file. 4 SQL statements in trace file. 4 unique SQL statements in trace file. 225 lines in trace file. 92

5.3 La commande Explain Plan La commande EXPLAIN PLAN affiche le plan d exécution d'une requête SQL(select, update, insert et delete). Le plan d exécution est la séquence d'opérations dans l'ordre telque exécuté par Oracle. L'affichage du plan par EXPLAIN permet de voir si les accélérateurs (index, cluster, hash,...) ont été utilisés ou non. Syntaxe sql> EXPLAIN PLAN [SET STATEMENT_ID= BINOMEx ] [INTO PLAN_TABLE] FOR SELECT DISTINCT(ENAME) FROM emp; 93

Syntaxe 5.3 La commande Explain Plan Mot clé/paramètre Description Statement_id Plan_table identifiant d un plan dans la table plan_table table contenant le plan d exécution d'une requête Installation de la table Plan_table sous NT version 9.0 sql>@c:\orant\rdbms\admin\utlxplan.sql sous UNIX sql>@$oracle_home\rdbms\admin\utlxplan.sql 94

5.3 La commande Explain Plan Structure de la table plan_table SVRMGR> desc plan_table Column Name Null? Type STATEMENT_ID VARCHAR2(30) TIMESTAMP DATE REMARKS VARCHAR2(80) OPERATION VARCHAR2(30) OPTIONS VARCHAR2(30) OBJECT_NODE VARCHAR2(128) OBJECT_OWNER VARCHAR2(30) OBJECT_NAME VARCHAR2(30) OBJECT_INSTANCE NUMBER(38) OBJECT_TYPE VARCHAR2(30) OPTIMIZER VARCHAR2(255) SEARCH_COLUMNS NUMBER ID NUMBER(38) PARENT_ID NUMBER(38) POSITION NUMBER(38) COST NUMBER(38) CARDINALITY NUMBER(38) BYTES NUMBER(38) OTHER_TAG VARCHAR2(255) PARTITION_START VARCHAR2(255) PARTITION_STOP VARCHAR2(255) PARTITION_ID NUMBER(38) OTHER LONG 95

5.3 La commande Explain Plan Structure de la table plan_table COLONNES STATEMENT_ID OPERATION OPTIONS LIBELLES Identifiant de l analyse d une requête Nom de l'opération interne détail de l'opérations OBJECT_NAME nom de l'objet accédé (nom table, ) ID PARENT_ID POSITION REMARKS OBJECT_NODE OBJECT_OWNER numéro de l'étape numéro de l'étape précédente ordre d'exécution des étapes par rapport à un noeud TIMESTAMP date et l'heure d'analyse Mise à jour SQL possible nom du lien utilisé pour référencer un objet (table et vue) Nom du propriétaire de l'objet OBJECT_INSTANCE Indique la position originelle de l objet avant analyse OBJECT_TYPE complément d'informations sur l'objet traité SEARCH_COLUMNS Non utilisée pour cette version Partition_id Nr. étape ayant calculée partition_start /_stop Partition_start ou stop Borne d une partition si index partitionné OTHER informations spécifiques à l'exécution d'une étape 96

Exemple 5.3 La commande Explain Plan SQL> EXPLAIN PLAN SET STATMENT_ID= PTEST FOR SELECT distinct(ename) from emp; Le résultat à exploiter se trouve dans PLAN_TABLE Voici comment l'exploiter select LPAD ('', 2*LEVEL) OPERATION, OPTIONS, OBJECT_NAME, ID, PARENT_ID FROM PLAN_TABLE WHERE STATEMENT_ID='PTEST' CONNECT BY PRIOR ID=PARENT_ID AND STATEMENT_ID='PTEST' START WITH ID=1 AND STATEMENT_ID='PTEST' ORDER BY ID; 97

Exemple 5.3 La commande Explain Plan OPERATION OPTIONS OBJECT_NAME ID PARENT SORT UNIQUE 1 TABLE ACCESS FULL EMP 2 1 98

5.3 La commande Explain Plan Liste des opérations Opération Option Description Aggregate group by And-equal Intersection de ROWID Bitmap conversion Conversion d une bitmap vers des rowid TO ROWID ou FROM ROWID index SINGLE VALUE ou RANGE SCAN ou FULL SCAN merge Fusion de plusieurs bitmap en une seule minus Différence entre bitmap or OR entre deux BITMAP Connect by concatenation count filter first row for update stopkey recherche basée sur une arborescence union de toutes les sources compte le nombre de ligne d'une table Comptage limité par rownum restriction sur les lignes ramenées extraction de la première ligne extraction avec verrouillage de lignes 99

5.3 La commande Explain Plan Liste des opérations Opération Option Description Index Unique scan Range scan range scan Descending Inlist iterator concatenated Itère sur l opération précédante selon les valeurs dans Inlist Intersection Merge Join Outer Minus Nested loop outer recherche de lignes de la table1 absentes dans la table2 opération de Jointure imbriquée opération de jointure externe imbriquée partition concatenated concaténation des résultats des patitions accédées single empty une seule partition est accédée. Cette partition est déterminée à l'exécution pas de partition accédée 100

5.3 La commande Explain Plan Liste des opérations Opération Option Description projection extraction d un sous-ensemble de colonnes remote sequence extraction dans une autre base opération avec génération de séquences sort unique tri de lignes avec élimination de duplicats group by tri pour grouper les lignes join tri de lignes avant une jointure par fusion order by tri de lignes avec une clause order by table access full extraction de toutes les lignes (séquentiel) cluster extraction à partir d'une clé cluster+ index hash extraction à partir d'une clé de hachage by index rowid accès à une table de la base par rowid By user rowid By global index rowid accès à partir d'un index global sur des données partitionnées By local index rowid accès à partir d'un local (partition) union extraction(union) sans doublon view extraction à partir d'une vue 101

Exercice 1 5.3 La commande Explain Plan a) Créer un fichier SQL qui : supprime vos enregistrements de la table plan_table exécute EXPLAIN PLAN. b) créer un fichier SQL qui permet d'exploiter la table PLAN_TABLE c) Tester sur l'ordre SQL: select * from emp where empno=10 102

5.3 La commande Explain Plan Le role plus_trace Ce rôle permet en une seule action d'obtenir le plan d'exécution et les temps mis. Contrairement à EXPLAIN PLAN, la réquête est exécutée si on le souhaite. Etape de mise en oeuvre : 1) Création du ROLE sql>connect sys/change_on_install@cour sql>@c:\orant\sqlplus\admin\plustrce.sql 2) activation de la trace sql>set AUTOTRACE ON -- fournit : le résultat, le plan d'exécution et les statistiques 3) si l on ne souhaite pas l exécution alors faire: sql>set AUTOTRACE TRACEONLY 103

5.4 La commande Analyze index Généralités La commande ANALYZE permet de fournir des statistiques sur les objets du schéma d'un utilisateur Oracle. Ces statistiques sont utilisées par l'optimiseur statistique. Nous nous intéressons ici à l'analyse d'index au sens de la commande VALIDATE INDEX (Oracle 6). Objectifs analyser la répartition des doublons d'un index analyser la structure physique d'un index. 104

Syntaxe 5.4 La commande Analyze index ANALYZE {INDEX TABLE CLUSTER} {nom_index nom_table [PARTITION (nom_part)] nom_cluster} VALIDATE STRUCTURE [CASCADE] si table valide aussi les index [INTO [nom_table]] Mot clé / Paramètre Description Nom_index, Nom_table, Nom_cluster, Nom_part Nom de l objet à analyser Cascade Si table valide analyser aussi les index INTO nom_table table de rejet, par défaut : Invalid_rows (script utlvalid.sql) 105

Exemple 5.4 La commande Analyze index SQL> ANALYZE INDEX idx_name VALIDATE STRUCTURE Le résultat de cette commande est stockée dans deux vues : INDEX_HISTOGRAM : distribution des clés. INDEX_STATS : contient les statistiques Note nous reviendrons dans le chapitre Optimiseur statistique sur la commande ANALYZE 106

5.4 La commande Analyze index La vue Index_histogram La vue index_histogram contient des informations sur la répartition des clés (valeur d'une colonne) d'un index. Cette répartition permet de déterminer si un index est pertinent ou non. sql > desc INDEX_HISTOGRAM Name Null? Type Repeat_count Number Keys_with_repeat_count Number Les colonnes de la table Index_histogram Repeat_count : Nombre de fois qu'une clé est répétée Key_with_repeat_count : Nombre de clé répétée "Repeat_count" fois. Le résultat de l'analyse est représenté sur 16 plages de valeurs, chacune représentant le nombre d'occurrences d'une valeur identique. 107

Exemple 5.4 La commande Analyze index Analysant quelques index sur la table emp (4199 lignes). a)considérons l'index unique idx_empno définit sur la colonne empno. SQL>Analyze Index idx_empno validate structure; SQL> Select * from index_histogram; Repeat count Keys_with_repeat_count 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0 10 0 11 0 12 0 13 0 14 0 15 0 108

Exemple 5.4 La commande Analyze index b)considérons maintenant l'index non unique idx_ename sur la colonne ename. SQL>analyze index idx_ename validate structure; SQL>select * from index_histogram; Repeat_count 0 0 4 0 8 0 Keys_with_repeat_count 12 0 16 0 20 0 24 0 28 0 32 0 36 0 40 0 44 0 48 0 52 0 56 1 60 69 109

Exemple 5.4 La commande Analyze index c) Considérons maintenant l'index non unique idx_sal sur la colonne sal. SQL>analyze index idx_sal validate structure; SQL>select * from index_histogram; Repeat_count Keys_with_repeat_count 0 0 32 0 64 0 96 0 128 0 160 0 192 0 224 0 258 0 288 0 320 0 352 0 384 0 416 10 448 0 480 0 110

Exemple 5.4 La commande Analyze index d) Considérons maintenant l'index non unique idx_deptno sur la colonne deptno. SQL>analyze index idx_deptno validate structure; SQL>select * from index_histogram; Repeat_count 0 0 128 0 256 0 384 0 512 0 640 0 768 0 896 0 1024 0 1152 2 1280 0 1408 0 1536 0 1664 0 1792 1 1920 0 Keys_with_repeat_count Note : La moitié de la table est ramenée + 20% coût Index. On peut légitimement se demander si cet Index est pertinent. 111

Exemple 5.4 La commande Analyze index e) Considérons maintenant l'index non unique idx_job sur la colonne job. SQL>analyze index idx_job validate structure; SQL>select * from index_histogram; Repeat_count 0 0 128 0 256 0 384 1 512 0 640 0 768 0 896 0 1024 0 1152 3 1280 0 1408 0 1536 0 1664 0 1792 0 1920 0 Keys_with_repeat_count Note : s'il ya très peu de métiers l'index n'est pas pertinent 112

5.4 La commande Analyze index La vue Index_stats : statistiques sur l index Colonnes HEIGHT BLOCKS* NAME Description hauteur de l arbre Nb de blocs consommés par l'index Nom de l'index PARTITION_NAME Nom d'une partition d'index LF_ROWS NB LF_BLKS LF_ROWS_LEN LF_BLK_LEN BR_ROWS BR_BLKS de clés stockées nombre de blocs feuilles longueur concaténée de toutes clés Longueur concaténée de toutes les clés qu'il est possible de stocker dans une feuille (lf_blks*lf_blk_len >= lf_rows_len) NB de branches NB de blocs pour les niveaux supérieurs 113

5.4 La commande Analyze index La vue Index_stats : statistiques sur l index Colonnes BR_ROWS_LEN BR_BLK_LEN DEL_LF_ROWS distinct_keys Description longueur concaténée de toutes les clés dans les niveaux supérieurs Taille disponible dans un bloc de niveau supérieur (br_blks*lf_blk_len doit être très à br_rows_len) Nbre de clés détruitesdel_lf_rows_len longueur concaténée de toutes les clés détruites Nombre de clés distinctes most_repeated_keys Nbre de répétition de la clé la moins discriminante btree_space used_space rows_per_key* Nbre d'octets alloués pour la gestion de l'index Nbre d'octets utiliséespct_used Taux effectif utilisé Nombre de lignes de la table par clé distincte blk_gets_per_access * NB d'accès en lecture des blocs de l'index pour récupérer le ROWID dans un bloc feuille 114

Exercice 2 5.4 La commande Analyze index a)copier la table Emp en Emp2 b)compter le nombre de fois qu'une profession apparaît dans les lignes de Emp2 c) A partir de la table Emp2 Créer un index sur la colonne job. Etudier l'évolution de l'index avec index_histogram et index_stats, pour chaque étape faire les traitements suivants : changer la profession CLERK en DIRECTOR changer la profession MANAGER en ENGINEER changer la profession ENGINEER en MANAGER 115

PLAN 6. L optimiseur syntaxique 6.1 Généralités 6.2 Règle 1 : Expressions et fonctions 6.3 Règle 2 : Index et valeurs nulles 6.4 Règle 3: Index et inégalité (!=,not) 6.5 Règle 4 : Index et constantes 6.6 Règle 5 : Index concatené 6.7 Règle 6 : Index et tri (Order by) 6.8 Règle 7 : Index et MAX ou MIN 6.9 Règle 8 : Index et AND et/ou OR 6.10 Règle 9 : Opérateurs ensemblistes 6.11 Règle 10 : Jointure 6.12 Règle 11 : Sous-requêtes 6.13 Règle 12 : Vues avec Group By 116

6.1 Généralités Optimiseur syntaxique se base sur des règles syntaxique pour déterminer le meilleur plan d'accès d'une requête données Condition nécessaire d'utilisation d'un Index il doit exister il doit être référencé dans un prédicat et certaines clauses SQL(clause Where,...) la colonne ne doit pas être utilisée avec une fonction et/ou une opération arithmétique Un Index sera utilisé si les conditions d'utilisation ci-dessus sont vérifiées et si Oracle décide qu'il est approprié de l'utiliser 117

6.1 Généralités Activation de l optimiseur de règle pour une session : sql>alter session set optimizer_goal=rule; Sql> Select /*+RULE */. FROM pour toutes les sessions (dans init.ora) : optimizer_mode=rule 118

6.2 Règle 1 : Expressions et Fonctions Les Opérateurs : =, >, <, Between, IN l'utilisation de l'index est identifiée par Oracle Pas d index sur la colonne job sql>select empno, ename FROM emp where job='clerk'; OP OPTIONS OBJECT_NAME ID PARENT_ID Table acces FULL EMP 1 119

6.2 Règle 1 : Expressions et Fonctions Opérateurs: =, >, <, Between, IN Index existe sur la colonne job sql> create index idx_job on emp(job); Index created JOB ROWID ANALYST 00000012.0007.0002 ANALYST 00000012.000C.0002 CLERK 00000012.0000.0002 CLERK 00000012.000A.0002 CLERK 00000012.000B.0002 CLERK 00000012.000D.0002 MANAGER 00000012.0003.0002 MANAGER 00000012.0006.0002 PRESIDENT 00000012.0008.0002 SALESMAN 00000012.0001.0002 SALESMAN 00000012.0002.0002 SALESMAN 00000012.0004.0002 SALESMAN 00000012.0009.0002 120

6.2 Règle 1 : Expressions et Fonctions Opérateurs: =, >, <, Between, IN // Choisir le mode règle. // Ce sera le cas pour toutes requêtes de ce chapitre SQL> alter session set optimizer_goal=rule; Sql>@genreq6 Sql>@affreq Opération Options Object_name ID Père Position Orig_pos TABLE ACCESS BY INDEX ROWIDEMP 1 0 1 1 INDEX RANGE SCA IDX_JOB 2 1 1 121

6.2 Règle 1 : Expressions et Fonctions Opérateurs =, >, <, Between, IN Exercice 3 a)créer un index sur la colonne job de la table emp b) Analyser par EXPLAIN les requêtes suivantes : select * from emp where job='clerk' select * from emp where job>'clerk' select * from emp where job BETWEEN 'CLERK' AND 'PRESIDENT' select * from emp where job IN ('CLERK', 'PRESIDENT', 'MANAGER') 122

6.2 Règle 1 : Expressions et Fonctions Les Opérateurs : LIKE, EXISTS Oracle n'accède pas toujours aux segments de données pour traiter une requête. L'accès aux segments de données dépendra des colonnes de projection. Exemple supposons un index sur empno la requête suivante n'accède qu'au segment d'index sql> select empno from emp where empno > 7789 Cela est vrai aussi avec les opérateurs LIKE et EXIST 123

6.2 Règle 1 : Expressions et Fonctions Les Opérateurs : LIKE, EXISTS Exercice 4 a) Créer un index sur la colonne ename de la table emp lister les noms des employés commençant par 'S'. analyser par explain b)créer un index sur la colonne deptno de dept lister les employés pour lesquels il n'existe pas de département. analyser par explain 124

6.2 Règle 1 : Expressions et Fonctions Les fonctions L'utilisation des fonctions et des calculs modifient les données par rapport à la façon dont elles sont stockées sous Oracle. Dans ces conditions Oracle ne pourra utiliser l'index. Exemple : index non utilisé sql>select * from emp where to_char(hiredate, dd/mm/yy )= 23/01/82 ; OP OPTIONS Table acces FULL EMP 1 OBJECT_NAME ID PARENT_ID Exemple : Index utilisé sql>select * from emp where hiredate=to_date( 23/01/82, dd/mm/yy ); OP OPTIONS OBJECT_NAME ID PARENT_ID table access by Index rowid emp 1 Index range scan idx_hiredate 2 1 125

6.3 Règle 2 : Index et valeurs nulles La logique de l optimiseur Oracle se fonde sur le fait que les colonnes d une table contiennent plus de valeurs renseignées que de valeurs nulles. Règles suivies par l'optimiseur (CBO ou RBO). ne pas utiliser l'index pour une condition IS NOT NULL. ne pas utiliser l'index pour une condition IS NULL puisque les valeurs nulles ne sont pas dans l'index. Amélioration des performances Lorsqu'une colonne contient un grand nombre de valeurs on peut forcer l'utilisation de l'index. Exemple Sql>create index idx_comm on emp(comm); 126

6.3 Règle 2 : Index et valeurs nulles Amélioration des performances Exemple requête sans utilisation de l'index sql>select ename, empno from emp where comm is not null ; OP OPTIONS OBJECT_NAME ID PARENT_ID Table acces FULL EMP 1 requête forcée à utiliser l'index sql>select ename, empno from emp where comm > 0 OP OPTIONS OBJECT_NAME ID PARENT_ID table access by index rowid emp 1 Index range scan idx_com 2 1 127

Exercice 5 6.3 Règle 2 : Index et valeurs nulles a) reprendre l'exemple précédent avec l'opérateur IS NOT NULL puis forcer l'utilisation de l'index. b) analyser les résultats par EXPLAIN 128

6.4 Règle 3 : Index et inégalité Logique de l optimiseur(cbo ou RBO) L'utilisation de la différence (!=) ou de la négation (NOT) implique notre intention de ramener plus de lignes que l'on en rejette. L opérateur!= (<>) Supposons qu'il ya un index sur deptno dans DEPT. sql>select loc from dept where deptno!= 30; OP Options Object_name ID Père Position Pos_orig table access FULL DEPT 1 0 1 1 L opérateur NOT : prédicat simple Supposons un index sur sal dans la table emp sql>select * from emp where not sal!= 2000 OP Options Object_name ID Père Position Pos_orig table access by index rowid emp 1 1 index range scan idx_sal 2 1 1 La double négation provoque l'utilisation de l'index car NOT colonne!= se remplace par col = constante. 129

6.4 Règle 3 : Index et inégalité Exemple : Index non utilisé sql>select * from emp where deptno not in (select deptno from dept where loc= DALLAS ) OP Options Object_name ID Père Position Pos_orig filter 1 table access full emp 2 1 1 1 table access full dept 3 1 2 2 Exemple : Index utilisé car requête reécrite sql>select * from emp where deptno IN (select deptno from dept where loc!= DALLAS ) OP Options Object_name ID Père Position Pos_orig NESTED LOOPS 1 0 VIEW 2 1 1 SORT UNIQUE 3 2 1 TABLE ACCESS FULL DEPT 4 3 1 2 TABLE ACCESS BY ROWID EMP 5 1 2 1 INDEX RANGE SCAN IDX_DEP 6 5 1 TNO 130

6.5 Règle 4 : Index et constantes avec jocker Un index est utilisé seulement si au moins le premier caractère est renseigné. Exemple sans utilisation d'index(cbo ou RBO) sql>select * from emp where ename like %KING ; OP Options Object_name ID Père Position Pos_orig table access full emp 1 1 Exemple avec utilisation d index sql>select * from emp where ename like KING% ; OP Options Object_name ID Père Position Pos_orig table access By index rowid EMP 1 1 INDEX RANGE SCAN IDX_E 2 1 1 NAME 131

6.6 Règle 5 : Index concaténé Un index concaténé est utilisé si la première colonne de l'index est renseignée (au moins le premier caractère de la première colonne). Soit l'index concaténé empno, ename, deptno sur emp. Exemple 1 : utilisation d index Sql>select * from emp where empno=7369 and ename= SMITH and deptno=20 Exemple 2 : utilisation de l index Sql> select * from emp where empno=7369 AND ename= SMITH Exemple 3 : utilisation de l index Sql>select * from emp where empno=7369 AND deptno=10 Exemple 4 : pas d utilisation de l index Sql>select * from emp where ename= SMITH and deptno=10 132

6.7 Règle 6 : Index et tri : order by Logique de L optimiseur Si la colonne indiquée dans la clause ORDER BY n'est pas déclarée dans le dictionnaire de données comme NOT NULL, elle peut contenir des valeurs NULL. Conditions d utilisation d un index : la colonne après ORDER BY doit être NOT NULL un index doit avoir été créé. Pour un index concaténé la première colonne de l'index doit être renseignée pas d'expression dans la clause Order By pas de clause Group by, Distinct et For Upadte pas d'autres chemins plus prioritaires que celui du Order By 133

Exemple 6.7 Règle 6 : Index et tri : order by Sql> SELECT DNAME, DEPTNO FROM DEPT WHERE LOC= DALLAS ORDER BY DNAME S'il ya un index sur LOC et DNAME, il n'y aura pas d'utilisation de l'index sur DNAME. S'il n'y a qu'un seul index sur DNAME alors utilisation de l'index. 134

Exercice 6 6.7 Règle 6 : Index et tri : order by a) pour une table sans mise à jour, construire le traitement qui permet d'ordonner physiquement cette table sur une de ses colonnes. Pour cela il est nécessaire de faire une copie de la table EMP. 135

6.8 Règle 7 : Index et MAX ou MIN La valeur maximale ou minimale est recherchée dans l'index si et seulement si les règles suivantes sont respectées : ce doit être la seule expression dans la liste du select pas d'opérateurs autre que concaténation et addition un seul et unique MAX doit être dans la liste du select ce ne doit pas être une requête de jointure pas de WHERE, pas de GROUP BY si index concaténé la colonne doit être clé primaire 136

6.8 Règle 7 : Index et MAX ou MIN Exemple 1 : index sur SAL non utilisé Select MAX(SAL) FROM emp where deptno=10 OP Options Object_name ID Père Position Pos_orig SORT AGGREGATE 1 0 TABLE ACCESS FULL EMP 2 1 1 1 Exemple 2 : Index sur SAL utilisé Select MAX(SAL) FROM emp OP Options Object_name ID Père Position Pos_orig SORT AGGREGATE 1 0 INDEX RANGE SCAN IDX_SAL 2 1 1 1 137

6.9 Règle 8 : Index et AND et/ou OR Index et AND Conditions => Egalité 1) Index sans doublon (Unique Index): Il sera le seul à être utilisé même s'il y en a d'autres 2) Index avec doublons : Les lignes identifiées par l'index de base sont fusionnées avec les lignes identifiées par les autres index. Jusqu'à 5 index peuvent être utilisés. Note : si l'index contient des doublons, il est trié par ROWID pour chaque valeur de la clé afin de minimiser les comparaisons. l'utilisation de plusieurs index peut décroître les performances. 138

6.9 Règle 8 : Index et AND et/ou OR Index et AND Conditions => Egalité Exemple select ename from emp where job = MANAGER AND deptno = 20 Index sur job et deptno JOB ROWID DEPTNO ROWID CLERK 00000012.0000.0002 10 00000012.0006.0002 SALESMAN 00000012.0001.0002 10 00000012.0008.0002 SALESMAN 00000012.0002.0002 10 00000012.000D.0002 MANAGER 00000012.0003.0002 20 00000012.0007.0002 SALESMAN 00000012.0004.0002 20 00000012.000A.0002 MANAGER 00000012.0005.0002 20 00000012.0000.0002 MANAGER 00000012.0006.0002 20 00000012.000E.0002 ANALYST 00000012.0007.0002 20 00000012.0003.0002 PRESIDENT 00000012.0008.0002 30 00000012.0009.0002 SALESMAN 00000012.0009.0002 30 00000012.0005.0002 CLERK 00000012.000A.0002 30 00000012.0004.0002 CLERK 00000012.000B.0002 30 00000012.000B.0002 139

6.9 Règle 8 : Index et AND et/ou OR Index et AND Conditions => Egalité Exemple Index sur job et deptno OP Options Object_name ID Père Position Pos_orig Table access by rowid emp 1 0 1 and-equal 2 1 1 Index range scan idx_job 3 2 1 Index range scan idx_ 4 2 2 deptno_emp 140

6.9 Règle 8 : Index et AND et/ou OR Index et AND Conditions => Egalité Trop d Index versus Performance : L'utilisation de plus d'un index avec doublons peut entraîner une chute importante des performances. Exemple avec perte de performances Supposons un index sur hiredate, job, deptno, sal. select ename from emp where hiredate = '17-NOV-81'AND job='president' AND deptno= 10 AND sal = 1500 Exemple avec amélioration des performances a)inhiber certains index select ename from emp Where hiredate = 17-NOV-81 AND job = PRESIDENT AND deptno+0= 10 /*pourquoi +0 */ AND sal = 1500 b)utiliser un index unique s il en existe 141

6.9 Règle 8 : Index et AND et/ou OR Index et AND Conditions différentes de l'égalité Mélange avec l'égalité Soient deux colonnes indexées: la condition avec égalité est prioritaire par rapport à la condition sans égalité (path 9 et path 11 dans l'exemple). select ename from emp where job='manager' AND deptno >10 OP Options Object_name ID Père Position Pos_orig TABLE ACCESS BY ROWID EMP 1 0 1 INDEX RANGE SCAN IDX_JOB 2 1 1 Conditions de même niveaux Soient deux colonnes indexées : si deux conditions ont le même niveau, l'optimiseur emploi le dernier index crée. Sql>select ename from emp where sal > 2000 AND deptno >10 OP Options Object_name ID Père Position Pos_orig TABLE ACCESS BY ROWID EMP 1 0 1 INDEX RANGE SCAN IDX_D 2 1 1 EPTNO 142

6.9 Règle 8 : Index et AND et/ou OR Index et AND Exercice 7 Soient les deux requêtes suivantes (index non unique sur hiredate, job, deptno et sal à créer): 1) select ename from emp where hiredate = '17-NOV-81' AND job='president' AND deptno= 10 AND sal = 5000 utilisant tous les index 2) select ename from emp where hiredate = '17-NOV-81' AND job '='PRESIDENT' AND deptno+0= 10 AND sal = 5000 inhibant certains index a) fournir leur plan d'exécution b) à l'aide de tkprof, comparer les temps de réponse 143

6.9 Règle 8 : Index et AND et/ou OR Index et OR L'index n'est utilisé avec OR que si tous les prédicats ont une colonne indexée (unique ou non unique). Exemple : Sql>select ename from emp where empno=7469 OR SAL=2000; Index sur empno et pas d index sur sal OP Options Object_name ID Père Position Pos_orig TABLE ACCESS FULL EMP 1 0 1 Index sur empno et sal OP Options Object_name ID Père Position Pos_orig concatenation 1 0 table access by rowid emp 2 1 1 1 INDEX Range scan idx_sal3 2 1 table access by rowid emp 4 1 2 1 INDEX unique scan emp_ 5 4 1 prim_key 144

6.9 Règle 8 : Index et AND et/ou OR Index et AND / OR 1) évaluation séparée des différentes branches par rapport au OR (y compris appliquer la règle de distributivité sur AND) 2) appliquer les règles d'utilisation d'index en cas de AND Exemple Sql>select ename from emp where deptno = 10 AND (sal = 3000 OR job= CLERK ) 1) index sur sal et job existent : utilisation d index OP Options Object_name ID Père Position Pos_orig concatenation 1 1 table access BY ROWID EMP 2 1 1 1 AND-EQUAL 3 2 1 INDEX RANGE SCAN IDX_JOB 4 3 1 INDEX RANGE SCAN idx_deptno 5 3 2 table access BY ROWID EMP 6 1 2 1 AND-EQUAL 7 6 1 INDEX RANGE SCAN IDX_SAL 8 7 1 INDEX RANGE SCAN IDX_DEPTNO 9 7 2 2) pas d index sur sal ou sur job : pas d utilisation d index. Si deptno est indexé, utilisation de cet index. 145

6.10 Règle 9 : Opérateurs ensemblistes L'optimisation d'une requête contenant des opérateurs ensemblistes (UNION, INTERSECT, MINUS) passe par l'optimisation de chaque partie de la requête résultante. Exemple select * from emp where empno = 7839 UNION select * from emp where sal=3000 1)des index existent sur empno et sal : ils sont utilisés OP Options Object_name ID Père Position Pos_orig PROJECTION 1 0 SORT UNIQUE 2 1 1 UNION-ALL 3 2 1 TABLE ACCESS BY ROWID EMP 4 3 1 1 INDEX unique scan emp_prim_key 5 4 1 TABLE ACCESS BY ROWID EMP 6 3 2 2 INDEX RANGE SCAN IDX_SAL 7 6 1 2) pas d index sur sal => accès full dans la partie de la requête ou la condition sur sal apparaît. 146

Exercice 8 6.10 Règle 9 : Opérateurs ensemblistes 1) Ecrire deux requêtes avec OR et UNION qui permettent d'obtenir le nom des employés commençant par 'S'ou 'T'avec suppression de doublons. 2) déterminer la requête la plus performante 147

6.11 Règle 10 : Jointure Nous récensons sous Oracle trois approches pour pouvoir joindre deux tables : tri-fusion (sans utilisation d'index) boucle imbriquée (avec utilisation d'index) cluster (avec utilisation d'index sur la clé cluster). Jointure : tri-fusion 1. trie des lignes de chaque table à joindre si cela n'a déjà été fait sur la colonne de la condition de jointure 2. fusion des deux sources. Note : valable uniquement si équi-jointure et colonnes de jointures non indexées. Exemple Sql>Select ename, dname From emp, dept Where emp.deptno=dept.deptno 148

6.11 Règle 10 : Jointure Jointure : tri-fusion Exemple Cette requête sera remplacée par : select deptno, ename select deptno, dname from emp from dept order by deptno order by deptno Puis fusion des deux sources : cela sous-entend qu il n y a pas d index sur la colonne de jointure. OP Options Object_name ID Père Position Pos_orig MERGE JOIN 1 0 SORT JOIN 2 1 1 TABLE ACCESS FULL DEPT 3 2 1 2 SORT JOIN 4 1 2 TABLE ACCESS FULL EMP 5 4 1 1 149

6.11 Règle 10 : Jointure Jointure : boucle imbriquée Principales étapes 1. l'optimiseur choisit une des tables comme table directrice (table externe). 2. pour chaque ligne de la table directrice, les lignes de la table interne qui vérifient la condition de jointure sont sélectionnées 3. enfin l'optimiseur combine les lignes et rend le résultat. Distinguons deux cas : la clause WHERE n'a que le prédicat de jointure la clause WHERE a des prédicats multiples. 150

6.11 Règle 10 : Jointure Jointure : boucle imbriquée Jointure avec prédicat de Jointure seul Si l'une ou les deux colonnes de jointure sont indexées, il ya utilisation d'un index. Choix de la table directrice 1) si un seul coté de la condition de jointure à un index, la table directrice est celle ne possédant aucun index. 2) si les deux cotés disposent d'un index (ou aucun), la dernière table de la clause FROM sera choisie comme table directrice. Exemple Sql>Select ename, dname From emp, dept Where dept.deptno=emp.deptno S'il ya un index sur chacune des deux colonnes alors dept sera table directrice. Note : la plus petite table doit être mis en position d'être choisie comme table directrice car elle sera balayée séquentiellement. 151

6.11 Règle 10 : Jointure Jointure : boucle imbriquée Jointure avec prédicats multiples Nous supposons qu'en plus de la condition de jointure, il ya d'autres prédicats sur des colonnes indexées. Choix de la table directrice 1. La table ayant la plus forte priorité sera choisie comme table directrice. 2. En cas d'égalité, c'est la table la plus à droite de la clause From qui est choisie comme table directrice. 152

6.11 Règle 10 : Jointure Jointure : boucle imbriquée Jointure avec prédicats multiples(suite) Exemple Select emp.ename, emp.deptno From emp, dept Where dept.deptno = emp.deptno AND job='president' AND ename='king' AND loc='new YORK'AND dname='accounting' supposons les index suivants actifs : idx_deptno sur deptno dans la table EMP idx_job_ename sur job et ename (index unique) dans la table EMP A partir de la table des priorités, nous pouvons déduire les rangs des tables DEPT et EMP. rang(dept) = 15 rang(emp) = 4 153

6.11 Règle 10 : Jointure Jointure : boucle imbriquée Jointure avec prédicats multiples Exemple OP Options Object_name ID Père Position Pos_orig NESTED LOOP 1 1 Table access by index rowid EMP 2 1 1 1 Index Unique scan id_job_ename 3 2 1 FILTER 4 1 2 TABLE ACCESS FULL DEPT 5 4 1 2 154

6.11 Règle 10 : Jointure Jointure :Cluster Rappel sur les clusters un cluster permet de stocker dans un même bloc les données d'une ou plusieurs tables. Avantages jointure physique (améliore les performances) un cluster peut avoir une clé indexée ou hachée le choix d'un cluster émane de la conception un cluster permet d'économiser la place Inconvénients (perte de performances) : en insertion et mise à jour en interrogation si on accède pas par la clé du cluster. si les données bouges beaucoups (chaînages) 155

6.11 Règle 10 : Jointure Jointure :Cluster Manipulation de Cluster avec clé Indexée create cluster clu_emp_dept (deptno number(4))...; create index idx_clu_emp_dept on cluster clu_emp_dept...; create table emp3(empno number(5) primary key,... deptno number(4) references dept) cluster clu_emp_dept(deptno); create table dept3(deptno number(4) primary key, dname char(20)) cluster clu_emp_dept(deptno); 156

6.11 Règle 10 : Jointure Jointure :Cluster Manipulation des clusters hachés Sql>create cluster clu_emp_dept (deptno number(4)) SIZE 500 HASHKEYS 100; create table emp3(empno number(5) primary key,... deptno number(4) references dept) cluster clu_emp_dept(deptno); create table dept3(deptno number(4) primary key, dname char(20)) cluster clu_emp_dept(deptno); 157

6.11 Règle 10 : Jointure Jointure : Mesures Exercice 9 Mesurer les temps accès aux enregistrements de deux tables (emp3 et dept3), colonne de jointure deptno et produire les plans d'accès : 1) via une jointure 2) via un cluster avec clé indexée 3) via un cluster avec clé hachée. Pour 2) et 3) il est nécessaire de : a)créer un cluster, b)créer deux tables emp3 et dept3 copies conformes de emp et dept. Note : pour les mesures, utiliser TKPROF 158

6.11 Règle 10 : Jointure Jointure externe la table sans le critère de jointure externe (+) est toujours accédée par balayage séquentiel si condition de jointure seule. Soit la requête suivante : SELECT emp.* FROM emp, dept WHERE emp.deptno(+) = dept.deptno Plan d accès avec Index (sur deptno dans emp et dept) OP Options Object_name ID Père Position Pos_orig NESTED LOOPS OUTER 1 0 TABLE ACCESS FULL DEPT 2 1 1 2 INDEX RANGE SCAN IDX_FK_DEPTNO 3 1 2 Plan d accès : sans Index OP Options Object_name ID Père Position Pos_orig MERGE JOIN OUTER 1 0 SORT JOIN 2 1 1 TABLE ACCESS FULL DEPT 3 2 1 2 SORT JOIN 4 1 2 TABLE ACCESS FULL EMP 5 4 1 1 159

6.11 Règle 10 : Jointure Exercice 10 : étude de cas 1 Soit la requête : SELECT emp.ename, emp.deptno FROM emp, dept WHERE dept.deptno = emp.deptno AND job = 'PRESIDENT' AND ename = 'KING' AND loc='new YORK' AND dname='accounting'; Construire le plan d'exécution avec les index suivants: 1) index sur :deptno de dept, dname de dept, deptno de emp, ename de emp 2) index sur : deptno de dept, dname de dept, loc de dept, deptno de emp, ename de emp et job de emp. 160

6.11 Règle 10 : Jointure Exercice 11 : étude de cas 2 Soient trois tables T1, T2,T3 : T1 => 100 enregistrements T2 => 500 enregistrements T3 => 10000 enregistrements Soient les colonnes : "a" pour T1 "b" pour T2 "C" pour T3 Ordonner ces trois requêtes suivant le temps d'exécution. Requête 1 : pas d'index FROM T3, T2, T1 WHERE T1.a = T2.b AND T2.b = T3.c SELECT T1.* 161

6.11 Règle 10 : Jointure Exercice 11 : étude de cas 2 Requête 2 : avec d'index SELECT T1.* FROM T3, T2, T1 WHERE T1.a = T2.b AND T2.b = T3.c sur a, b et c Requête 3 : avec d'index SELECT T1.* FROM T1, T2, T3 WHERE T1.a = T2.b AND T2.b = T3.c sur a, b et c 162

6.12 Règle 11 : Sous-requêtes Sous-Interrogation non synchronisée En cas de sous-interrogation non synchronisée, la table directrice est la table de la sous-requête. Les Index des deux tables peuvent être utilisées. Exemple : SELECT ename FROM emp WHERE deptno = (SELECT deptno FROM dept WHERE dname = PARIS ) (traduit) SELECT ename FROM emp, dept WHERE emp.deptno=dept.deptno AND dname ='PARIS' s'il y a des index sur emp.deptno et dname, il sont utilisés. Note : Pour les requêtes avec plus de 2 tables préférer les jointures. 163

6.12 Règle 11 : Sous-requêtes Sous-Interrogation synchronisée En cas de sous-requête synchronisée, la table directrice (parfois balayée séquentiellement) est celle de la requête principale. Les Index dans la table de la sousrequête pourront être utilisés. Exemple SELECT ename FROM emp WHERE deptno IN (SELECT deptno FROM dept WHERE emp.deptno=dept.deptno) OP Options Object_name ID Père Position Pos_orig FILTER 1 0 TABLE ACCESS FULL EMP 2 1 1 1 INDEX RANGE SCAN idx_pk_deptno 3 1 2 164

6.12 Règle 11 : Sous-requêtes Sous-Interrogation synchronisée SELECT ename FROM emp WHERE ename like SC% AND deptno IN (SELECT deptno FROM dept WHERE emp.deptno=dept.deptno) OP Options Object_name ID Père Position Pos_orig FILTER 1 0 TABLE ACCESS BY Index rowid EMP2 1 1 1 INDEX RANGE SCAN IDX_EMP 3 2 1 INDEX RANGE SCAN idx_deptno 4 1 2 165

6.12 Règle 11 : Sous-requêtes Sous-Interrogation synchronisée Exercice 12 Soit la requête suivante : SELECT * FROM emp X WHERE sal (opérateur) (SELECT sal FROM emp WHERE x.mgr=emp.empno) Produire différents plans d'exécutions en fonction de l'opérateur et de la présence ou non d'index. 1) Pas d'index et opérateur : "=, IN,..." 2) Index sur empno et index sur sal opérateur arithmétique :'=,>,...' 3)Index sur empno et index sur sal, opérateur ensembliste : IN, ANY, ALL 166

Une requête avec GROUP BY vise à former des groupes, l'optimiseur a pour règle de ne pas utiliser l'index en cas d'élimination de groupes (clause HAVING). Note : 6.13 Règle 12 : Vues avec Group By Eliminer par WHERE plutôt que par Having Une vue avec Group By peut être particulièrement pénalisante. 167

Exemple 6.13 Règle 12 : Vues avec Group By Soit la vue suivante : CREATE VIEW V_EMP AS SELECT deptno, ename FROM emp GROUP BY deptno, ename; Interrogation à travers la vue v_emp : SELECT * FROM v_emp WHERE deptno > 10 ; Cette requête est transformée en SELECT deptno, ename FROM emp GROUP BY deptno, ename HAVING deptno >10; Elimination par WHERE => requête plus rapide SELECT deptno, ename FROM emp WHERE deptno >10 GROUP BY deptno, ename ; 168

PLAN 7. L optimiseur statistique 7.1 Généralités 7.2 Etapes de l Optimiseur Statistique 7.3 Activation de l optimiseur statistique 7.4 la Commande ANALYZE 7.5 Critère de choix d'une méthode d'accès 7.8 Critère de choix d'un plan d'accès (jointure) 7.9 Exercices 169

7.1 Généralités A la différence de l'optimiseur Syntaxique (qui se fondent uniquement sur la syntaxique des requêtes SQL), l'optimiseur statistique lui s'appuie sur les statistiques sur les objets du schéma qui permettent de calculer le taux de sélectivité d'une requête. Le choix d un plan d accès se fera en fonction du taux de sélectivité. Avantages de l'optimiseur statistique produit dans de nombreux cas, de meilleurs plans d'exécutions que l'optimiseur syntaxique(surtout pour des requêtes de grandes tailles à jointures multiples). dans la plupart des cas, il n'est pas nécessaire de régler manuellement des requêtes : cela permet d'augmenter la productivité des applications 170

7.1 Généralités Avantages de l optimiseur statistique laisse le choix au développeur de décider de l'approche d'optimisation : les règles et/ou les coûts : l'intérêt est de maintenir la compatibilité ascendante avec les applications développées sous les versions précédentes d'oracle Limites Pas d'informations sur la sémantique des applications une certaine jeunesse 171

7.2 Etapes de l optimiseur statistique Génération des plans Cette génération dépend : des chemins d'accès valides des HINTS ou suggestions pour l'influencer Estimation des coûts Cette estimation se fonde sur : les statistiques sur la distribution des données et les caractéristiques de stockage des tables, clusters et Index la commande ANALYZE permet d'obtenir ces statistiques les statistiques sont stockées dans le dictionnaire. Comparaison des coûts Permet de déterminer le meilleurs plan d'accès. 172

7.3 Activation de l optimiseur statistique Le choix du mode de fonctionnement de l optimiseur d Oracle dépend : du paramètre OPTIMIZER_MODE du paramètre OPTIMIZER_GOAL des HINTS ou suggestions Positionnement de OPTIMIZER_MODE Ce paramètre est positionné dans le fichier INIT.ORA (valable pour toute l'instance Oracle) Il vaut : CHOOSE pour un choix entre règles ou Coûts RULE règles uniquement Exemple OPTIMIZER_MODE = CHOOSE c'est aussi la valeur par défaut. 173

7.3 Activation de l optimiseur statistique Positionnement de OPTIMIZER_GOAL Ce paramètre est activable pour une session, il peut prendre l'une des valeurs suivantes : CHOOSE : se base sur les statistiques si le dictionnaire de données en a ; ALL_ROWS : se base sur les statistiques mais en privilégiant le plus cours temps de traitement FIRST_ROWS : se la base sur les statistiques mais en privilégiant le plus court temps de réponse RULE : utilise les règles de base (optimiseur syntaxique). Les choix CHOOSE, ALL_ROWS, FIRST_ROWS entraînent ou peuvent provoquer l'utilisation de l'optimiseur statistique. Exemple SQL> ALTER SESSION SET OPTIMIZER_GOAL=FIRST_ROWS ; 174

7.3 Activation de l optimiseur statistique HINTS ou Suggestions Le choix du mode de fonctionnement et des chemins d'accès peut être forcé dans un Ordre SQL : SELECT, DELETE, UPDATE. Syntaxe <DELETE SELECT UPDATE] /*+ {HINT [TEXT] }*/ Le commentaire doit venir immédiatement après le DELETE, SELECT ou UPDATE. "+" indique à Oracle d'interpréter le commentaire suivant comme une liste de HINTS TEXT Texte d'explication du ou des HINTS 175

7.3 Activation de l optimiseur statistique HINTS ou Suggestions HINTS Influençant le but (GOAL) ALL_ROWS FIRST_ROWS RULE HINTS Influençant le chemin d'accès FULL(nom_table) -- balayage Full ROWID(nom_table) -- balage via les ROWID CLUSTER(nom_table) -- accès via un cluster HASH(nom_table) -- accès via un cluster haché HASH_AJ(nom_table) -- accès via un Anti join INDEX(nom_table nom_index...) accès via un index INDEX_COMBINE -- pousser à utilier les index bitmap 176

7.3 Activation de l optimiseur statistique HINTS ou Suggestions HINTS Influençant le chemin d'accès INDEX_ASC(nom_table nom_index...) -- accès en ordre descendant dans l'index INDEX_DESC(nom_table nom_index...) -- accès en ordre descendant dans l'index INDEX_FFS(table index) -- Fast Full Index Scan AND_EQUAL(nom_table nom_index...) -- Force le connecteur AND entre les index cités MERGE_AJ(nom_table) -- Force l'accès via un anti join USE_CONCAT -- Force la transformation de condition avec OR -- en UNION ALL 177

7.3 Activation de l optimiseur statistique HINTS ou Suggestions Suggestions ou Hints pour déterminer l'ordre de jointure ORDERED --joindre les tables dans leur ordre d'apparition STAR -- force une requête en étoile STAR_TRANSFORMATION Suggestions liées aux opérations de jointure USE_NL(nom_table ) -- force la jointure imbriquée. Nom_table est la table -- directrice USE_MERGE(nom_table )-- force le tri-fusion NO_MERGE(nom_table ) -- pas tri-fusion USE_HASH(nom_table )-- force le hash join pour -- les tables spécifiées DRIVING_SITE(table) -- force le site de traitement -- de la jointure 178

7.3 Activation de l optimiseur statistique HINTS ou Suggestions Exemple Forcer le But (GOAL) de l optimiseur SELECT /*+FIRST_ROWS */ empno, ename, sal, job FROM emp WHERE empno=7566; Forcer l usage d un Index SELECT /*+ INDEX(emp idx_sex) Utilisation de l index sur la colonne sex car peu de Masculin*/ FROM emp WHERE sex= M ; Forcer l optimiseur de Règles SELECT --+RULE * FROM emp WHERE empno=7566 179

7.4 La commande Analyze La commande ANALYZE permet pour l Index, la table, le cluster ou la partition : de mettre à jour et supprimer les informations statistiques,. vérifier l'intégrité et la validité des données La commande ANALYZE permet pour la table, le cluster ou la partition d identifier les lignes chaînées. Type d analyse Analyse objet/objet Commande ANALYZE table, index, Analyse d un schéma dbms_utility.analyse_schema( Nom_user, Methode -- compute, estimate, ) Analyse d une base dbms_utility.analyse_database( Methode -- compute, estimate, ) Note : privilège requis pour analyser tout schéma ANALYZE ANY l analysedes statistiques d une table entraine aussi celle de ses index 180

7.4 La commande Analyze Vérification de la structure Syntaxe ANALYZE < INDEX index VALIDATE STRUCTURE[INTO nom_table] <TABLE table CLUSTER cluster PARTITION> VALIDATE STRUCTURE [CASCADE] [INTO nom_table] >. vérifie si la structure d'une table, d'un index ou d'un cluster est corrompue,. ANALYZE INDEX index VALIDATE STRUCTURE correspond à l'ancien VALIDATE INDEX, permet de récolter des statistiques sur les index et met à jours les tables : INDEX_HISTOGRAM (distribution des clés) INDEX_STATS (statistiques sur la structure physique d'un index). Exemple sql>analyze INDEX idx_ename VALIDATE STRUCTURE ; 181

7.4 La commande Analyze Vérification de la structure La clause INTO nom_table Cette clause permet en cas d inconsistance de rejeter dans la table nom_table les iditenfiants des lignes en cause. Nom_table par défaut est INVALID_ROWS. Elle est obtenue en exécutant le script UTLVALID.SQL SQL> DESC INVALID_ROWS Name Null? Type OWNER_NAME TABLE_NAME PARTITION_NAME HEAD_ROWID ANALYZE_TIMESTAMP VARCHAR2(30) VARCHAR2(30) VARCHAR2(30) ROWID DATE 182

7.4 La commande Analyze Vérification de la structure Exemple Sql> CREATE TABLE PEMP (EMPNO NUMBER(4) NOT NULL, ENAME VARCHAR2(10), JOB VARCHAR2(9), MGR NUMBER(4), HIREDATE DATE, SAL NUMBER(7,2), COMM NUMBER(7,2), DEPTNO NUMBER(2)) PARTITION BY RANGE(job)( PARTITION p1 VALUES LESS THAN ( CLERK ) TABLESPACE ts_ora_users, PARTITION p2 VALUES LESS THAN ( PRESIDENT ) TABLESPACE tools, PARTITION p3 VALUES LESS THAN (MAXVALUE) TABLESPACE ts_ora_users ); Sql> >@c:\orant\rdbms\admin\utlvalid.sql Sql>ANALYZE TABLE pemp PARTITION (p1) VALIDATE STRUCTURE INTO INVALID_ROWS; Note : - la table et/ou l index doivent être partitionnés 183

7.4 La commande Analyze Identification des chaînages de lignes Le chaînage d'une ligne sur plusieurs blocs physiques d'une table ou d'un cluster peut faire baisser les performances des requêtes. Il est nécessaire d'identifier ces lignes afin de remédier au chaînage. Syntaxe sql>analyze <TABLE table CLUSTER cluster> LIST CHAINED ROWS [INTO nom_table]; les numéros de lignes chaînées sont rejetées dans la table NOM_TABLE. Par défaut son est CHAINED_ROWS. La Table CHAINED_ROWS sql>@c:\orant\rdbms\admin\utlchain.sql SQL> desc chained_rows Name Null? Type OWNER_NAME TABLE_NAME CLUSTER_NAME PARTITION_NAME HEAD_ROWID ANALYZE_TIMESTAMP VARCHAR2(30) VARCHAR2(30) VARCHAR2(30) VARCHAR2(30) ROWID DATE 184

7.4 La commande Analyze Identification des chaînages de lignes Exemple 1) sql>analyze TABLE emp LIST CHAINED ROWS INTO chained_rows; 2) sql>create TABLE emp2 as SELECT emp.* FROM emp, chained_rows WHERE emp.rowid=head_rowid; -- sauvegarde des lignes chaînées 3) DELETE FROM emp WHERE rowid in (SELECT header_rowid FROM chained_rows); -- suppression des lignes chaînées 4) INSERT INTO emp SELECT * FROM emp2; -- réinsertion des lignes dans emp 185

7.4 La commande Analyze Mise à jour des statistiques Syntaxe ANALYZE<<INDEX index TABLE table>[partition(nom)] CLUSTER cluster> <COMPUTE STATISTICS [for_clause] ESTIMATE STATISTICS [for_clause] [SAMPLE valeur <ROWS PERCENT> DELETE> STATISTICS Signifacation des clauses COMPUTE = analyse complète sur toutes les données ESTIMATE = analyse sur un échantillon avec : ROWS : NB lignes de l'échantillon PERCENT : pourcentage de lignes de l'échantillon PARTITION (nom) : nom d une partition Exemple : Sql>ANALYZE TABLE EMP COMPUTE STATISTICS; -- calcule les stats sur la table emp et ses index Sql>DBMS_UTILITY.analyze_schema('sadm','compute'); -- analyze du schéma complet du USER sadm 186

7.4 La commande Analyze Mise à jour des statistiques Note : produit des statistiques sur la structure physique et la distribution de l'index, la table ou le cluster Par défaut, l'analyse estimée se fait sur 1064 lignes. Si ce nombre dépasse la moitié des lignes ou des clés, l'estimation se fait sur la table entière. La clause FOR Permet d affiner l analyse sur une TABLE. Syntaxe For-clause ::= [FOR TABLE statistique sur la table seule FOR ALL [INDEXED] COLUMNS [SIZE entier] FOR COLUMNS [SIZE entier] colonne1 [SIZE entier FOR ALL [LOCAL] INDEXES] SIZE : donne la plage de distribution dans *_histograms LOCAL: Lié à une partition 187

7.4 La commande Analyze Mise à jour des statistiques La clause FOR Exemple SQL>ANALYZE TABLE emp COMPUTE STATISTICS FOR TABLE; -- calcule les statistiques de la table emp seule -- sans celles sur ses index SQL>ANALYZE TABLE emp COMPUTE STATISTICS FOR ALL INDEXED COLUMNS; -- calcule les statistiques pour toutes les colonnes indexées SQL>ANALYZE TABLE emp COMPUTE STATISTICS FOR COLUMNS sal SIZE 20; -- SIZE Permet de fournir à l optimiseur des informations sur la distributivité de l index sur 20 Plages. UTILE UNIQUEMENT EN CAS D UNE MAUVAISE REPARTITION DES CLES. 188

7.4 La commande Analyze Résultat de l'analyse d'un Index Le résultat se retrouve dans les vues, User_Indexes, dba_indexes et all_indexes. Les colonnes mis à jour sont : NOM COLONNE DESCRIPTION BLEVEL Hauteur de l arbre * LEAF_BLOCKS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR Nombre de blocs feuilles Nbre de clés distincts Nbre moyen de blocs feuilles par clés Nombre de blocs de données moyens pointés par une clé Dimensionnement des données Toujours évalué exactement Exemple sql>analyze INDEX idx_deptno COMPUTE STATISTICS ou sql>analyze INDEX idx_deptno ESTIMATE STATISTICS SAMPLE 600 ROWS STATISTICS; 189

7.4 La commande Analyze Résultat de l'analyse d'une table Le résultat de l'analyse d'une table se trouvent dans *_tables et *_tab_columns, *_tab_partition, *_part_col_statistics (ou * représente user, all et dba) Dans les vues *_tables Nom colonne num_rows Blocks ayant empty_blocs table avg_space chain_cnt avg_row_len Désignation Nombre de lignes Dans les vues *_tab_columns Nom colonne num_distinct low_value High_value Nombre de blocs alloués à la table des données Nombre de blocs vides alloués à la Moyenne de l'espace libre/bloc Nbre de lignes chaînées Moyenne de la longueur des lignes Désignation NB de valeurs distinctes pour chaque colonne. Valeur la plus petite (2ème si plus 3 lignes) Valeur plus grande (avant dernière si plus de 3 lignes) 190

7.4 La commande Analyze Résultat de l'analyse d'un cluster L'information importante pour un cluster est la moyenne du nombre de blocs pour une clé cluster. Le résultat de l'analyse d'un cluster se trouve dans les vues : *_CLUSTERS Dans les vues *_CLUSTERS Nom colonne AVG_BLOCKS_PER_KEY Désignation Moyenne du nombre de blocs pour une clé de cluster. 191

7.5 Critères de choix d'un chemin d'accès Le choix d un chemin d accès se fera en fonction : de la sélectivité de la lecture multiple de blocs des HINTS (Suggestions) : ils sont intégrés dans les requêtes afin d'obliger l'optimiseur à choisir un autre chemin. La sélectivité La sélectivité est le pourcentage de lignes pouvant être sélectionnées dans une table par une requête. faible pourcentage => bonne sélectivité pour cela l'optimiseur privilégie l'accès par index Critères pour déterminer la sélectivité : les opérateurs utilisés dans la clause WHERE les clés uniques ou primaires utilisées dans la clause WHERE les statistiques sur la table. 192

7.5 Critères de choix d'un chemin d'accès La sélectivité (suite) Exemple 1 SELECT * FROM emp WHERE ename= KING ; cas 1 : Cas 2 : il ya un index unique sur ename alors il ya une forte sélectivité car un tuple seul est ramené. Si la colonne ename n'est ni unique ni clé, l'optimiseur peut utiliser les statistiques pour estimer la sélectivité de la condition. Exemple : RK=user_tables.num_rows/user_tab_columns.num_distinc t avec RK : répartion moyenne des Lignes par Clé TS = (RK/ user_tables.num_rows) * 100 avec TS : Taux de Sélectivité Supposons : *_.tab_columns.num_distinct = 6 *_tables.num_rows = 14 RK=14/6,alors TS = ((14/6)/14)*100 = 16,6% 193

7.5 Critères de choix d'un chemin d'accès La sélectivité Les Colonnes LOW_VALUE et HIGH_VALUE Oracle se sert des colonnes LOW_VALUE et HIGH_VALUE pour décider du choix ou non d'un INDEX. Exemple Sql>alter session set optimizer_goal=rule; Sql> select * from emp Execution Plan Where ename > A ; 0 SELECT STATEMENT Optimizer=RULE 1 0 TABLE ACCESS (BY INDEX ROWID) OF EMP 2 1 INDEX (RANGE SCAN) OF IDX_ENAME (UNIQUE) Sql>analyze table emp compute statistics; Sql>alter session set optimizer_goal=all_rows; Sql> select * from emp Execution Plan Where ename > A ; 0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=1 Card=14 Bytes=560) 1 0 TABLE ACCESS (FULL) OF EMP (Cost=1 Card=14 Bytes=560) 194

7.5 Critères de choix d'un chemin d'accès La sélectivité Lecture de blocs multiples L'optimiseur peut décider d'effectuer un accès séquentiel à une table en fonction du facteur de blocage qui permet à Oracle de charger plusieurs blocs en une lecture. Le paramètre déterminant ici est : DB_FILE_MULTIBLOCK_READ_COUNT. Exemple select * FROM emp WHERE ename='king' Si le balayage complet est plus rapide que le balayage via un Index, l'optimiseur choisira un balayage complet. 195

7.6 Choix de plan d exécution de la jointure Le coût d'une jointure imbriquée est déterminé par: le coût de la lecture séquentielle de la table directrice le coût d'accès aux lignes de la table interne L'optimiseur calcule ces coûts en se basant sur les statistiques. Table directrice => celle ramenant le moins de lignes Coût d'une jointure par tri-fusion : -est déterminé par le coût du chargement et du tri Facteurs supplémentaires pour estimer le coût : une petite zone de tri pénalise le tri-fusion (contrôle via le paramètre SORT_AREA_SIZE dans init.ora) un grand facteur de blocage fait décroître le coût de la jointure par tri/fusion. La valeur de DB_FILE_MULTIBLOCK_READ_COUNT peut provoquer à ce que la table non directrice soit accéder séquentiellement alors qu'un Index existe. 196

Exemple : 7.6 Choix de plan d exécution de la jointure le choix de l'optimiseur statistique n'est pas formcément celui de l'optimiseur syntaxique : Soient les tables Emp et Dept et les index sur ename, deptno dans emp et deptno dans dept SQL> SELECT EMPNO, ENAME, dept.deptno, DNAME FROM dept, emp WHERE emp.deptno=dept.deptno ; SQL>Alter session set optimizer_goal=rule; Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=RULE 1 0 NESTED LOOPS 2 1 TABLE ACCESS (FULL) OF EMP 3 1 TABLE ACCESS (BY INDEX ROWID) OF DEPT 4 3 INDEX (UNIQUE SCAN) OF PK_DEPT (UNIQUE) 197

Exemple : 7.6 Choix de plan d exécution de la jointure SQL> SELECT EMPNO, ENAME, dept.deptno, DNAME FROM dept, emp WHERE emp.deptno=dept.deptno ; SQL>Alter session set Optimizer_goal=first_rows; Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=5 Card=14 Bytes= 784) 1 0 NESTED LOOPS (Cost=5 Card=14 Bytes=784) 2 1 TABLE ACCESS (FULL) OF DEPT (Cost=1 Card=4 Bytes=92) 3 1 TABLE ACCESS (BY INDEX ROWID) OF EMP (Cost=1 Card=14 Bytes=462) 4 3 INDEX (RANGE SCAN) OF IDX_DEPTNO_EMP (NON-UNIQUE) 198

7.6 Choix de plan d exécution de la jointure Exercice 13 Le but de ce travail est de comparer le fonctionnement de l'optimiseur statistique et de l'optimiseur syntaxique. Reprendre les exercices données pour comprendre l'optimiseur de règles (Règle 1 à Règle 12) : 1) générer les statistiques sur les tables, les index et les clusters intervenant dans ces exercices 2) produire les plans d'exécutions de chaque requête. En fixant le but successivement a RULE, FIRST_ROWS et ALL_ROWS 3) utiliser les HINTS pour influencer ces résultats. a) influence le but. Je suis en mode First_rows par exemple et je veux que la requête soit traité en RULE b) influence un chemin : i) suggerer qu'une table est à balayer full ii) suggerer l'index à utiliser iii) suggerer le AND EQUAL 199

8. Annexes Le fichier affreq.sql Ce fichier permet d'afficher le plan d'exécution d'une requête. col operation format a15 col options format a15 col object_name format a12 col id format 99 col pere format 99 col position format 99 col orig_pos format 99 col optimizer format a20 col card format 9999 col cost format 9999 SELECT OPERATION, OPTIONS, OBJECT_NAME, ID, parent_id "PERE", position "pos", OBJECT_INSTANCE "ORIG_POS", optimizer, cost, cardinality "card" FROM PLAN_TABLE WHERE STATEMENT_ID= SCOTT CONNECT BY PRIOR ID=PARENT_ID AND STATEMENT_ID= SCOTT START WITH ID=0 AND STATEMENT_ID= SCOTT ORDER BY ID; 200

8. Annexes Le fichier Genreq.sql Ce fichier permet de supprimer un plan existant identifié par USERNAME et de gérérer un nouveau. Six lignes de requêtes peuvent être saisies d'un trait. DELETE FROM PLAN_TABLE WHERE STATEMENT_ID='USERNAME' / EXPLAIN PLAN SET STATEMENT_ID='USERNAME' INTO PLAN_TABLE FOR &requete1 &requete2 &requete3 &requete4 &requete5 &requete6 / 201

9. Plan détaillé 1. Introduction 1.1 Objectifs du cours 1.2 Etapes d'optimisations d'un SI 1.3 Conception optimisée d'une base 1.4 Approches d'optimisation de requêtes 2. Etapes d optimisations 2.1 Démarche Générale 2.2 Evaluation des expressions et constantes 2.3 Transformation de requêtes 2.4 Choix d'une approche d'optimisation 2.5 Choix de chemins d'accès 2.6 Optimisation de la jointure 3. Méthodes d'accès 3.1 Généralités 3.2 Accès séquentiel 3.3 Accès par ROWID 3.4 Accès par index 3.4.1 Accès par index B-arbre 3.4.2 Index Bitmap 3.5 Table organisée dans index 202

9. Plan détaillé 3. Méthodes d'accès 3.6 Accès par Cluster indexé 3.7 Accès par Cluster haché 3.8 Mesures 4. Les Chemins d accès 5. Outils d'optimisation 5.1 Généralités 5.2 TKPROF 5.3 La commande Explain Plan 5.4 La commande Analyze index 6. L optimiseur syntaxique 6.1 Généralités 6.2 Règle 1 : Expressions et Fonctions 6.3 Règle 2 : Index et valeurs nulles 6.4 Règle 3 : Index et inégalité 6.5 Règle 4 : Index et constantes avec jocker 6.6 Règle 5 : Index concaténé 6.7 Règle 6 : Index et tri : order by 203

9. Plan détaillé 6. L optimiseur syntaxique 6.8 Règle 7 : Index et MAX ou MIN 6.9 Règle 8 : Index et AND et/ou OR 6.10 Règle 9 : Opérateurs ensemblistes 6.11 Règle 10 : Jointure 6.12 Règle 11 : Sous-requêtes 6.13 Règle 12 : Vues avec Group By 7. L optimiseur statistique 7.1 Généralités 7.2 Etapes de l'optimiseur statistique 7.3 Activation de l'optimiseur statistique 7.4 La commande Analyze 7.5 Critères de choix d'un chemin d'accès 7.6 Choix de plan d'exécution de la jointure 8. Annexes 204