Cours 4. Gestion de la performance. DBA - Maîtrise ASR - Université Evry

Transcription

1 Cours 4 Gestion de la performance 1

2 Performance? De quelles performance parle-t on? Quels sont les éléments actifs et quels sont leurs rôles respectifs? Quels sont les mesures de performance significatives sur ces éléments? Quels sont les optimisations possibles, comment les mettre en œuvre? 2

3 Critères de performance (1/3) La notion de performance d un système indique sa capacité à répondre dans les délais prévus aux questions prévues dans le contexte prévu la question essentielles est : «qu est-ce qui est prévu?» 3

4 Critères de performance (2/3) Questions principales : Combien d utilisateurs sont prévus? Comment les utilisateurs interagiront-ils? Où sont positionnés les systèmes? Quelle est la vitesse du réseau? Quelle quantité de données seront accédées par les utilisateurs et quelle proportion l est en principalement en lecture seule? Quel est le temps de réponse exigé par les utilisateurs? Le système doit-il être disponible 24/24? Tous les changements doivent-ils être répercutés en temps réel? 4

5 Critères de performance (3/3) Questions plus liées à un impact budgétaire et de complexité que de tunning : Quelle sera la taille de la base de données? Quelle est le format de sortie des transactions? Quelles sont les conditions de disponibilité? Les qualifications (RH) sont-elles disponibles pour construire et administrer et optimiser cette application? Quels sorte de compromis sera édicté par des contraintes budgétaires? 5

6 Quoi regarder? 1) Code applicatif : Design de la base de données Codage de l application Efficience du code Bonne ordonnancement des taches 2) l instance de la base : Réglage des paramètres de mémoire et de buffers Élimination des blocages Surveillance des IO sur les données 3) l infrastructure sous jacente Système d exploitation Ressources matérielles (contention des IO) 6

7 Éléments critiques de la performance de l application «Si les DBA peuvent identifier les points et problèmes qui sont les causes de ralentissement, les développeurs peuvent les résoudre.» 80 % des gains de performances sont dues à une optimisation du code de l application Par son modèle, Par le codage des requêtes SQL. Mais, la performance est dynamique et la performance d une requête dans un contexte (base de dev) ne sera pas représentatif d une performance dans un autre (prod) ni dans la durée. Le rôle du DBA est d apporter au développeur la vue sur le comportement dynamique de son application. 7

8 Outillage de la mesure de la performance Mise en place de statistiques dynamiques sur le fonctionnement de la base : Observation du fonctionnement des process internes de la base, Observation du fonctionnement des applications (SQL) et du modèle de données (accès aux tables/indexes/enregistrements). Demande un temps d exécution minimal pour être pertinents, Processus récurent «d administration» de la base de données. 8

9 Outillage Oracle pour la performance : AWR Le tuning de performance nécessite un outillage complet et complexe Oracle fournis un ensemble d outils AWR (Automatic Workload Repository) de mesure dynamique de la performance (charge). Les résultats de ces outils sont les points d entré de l analyse du comportement de la base de données 9

10 Outillage Oracle pour la performance : AWR AWR permet de collecter les statistiques sur la performance du système et inclus : Les attentes (wait) provoquées par des vérous sur des ressources La vue sur l historique du temps de BD associée à un processus (vues V$SESS_TIME_MODEL et V$SYS_TIME_MODEL). Les statistiques historisées sur les sessions actives (V$ACTIVE_SESSION_HISTORY) Statistiques système et de session (vues V$SYSSTAT et V$SESSTAT) Statistiques sur l utilisation des objets La liste des requêtes SQL consommatrices de ressource Est une source de données pour les outils externes (existent depuis la 10g) : Automatic Database Diagnostic Monitor SQL Tuning Advisor Undo Advisor Segment Advisor 10

11 Outillage Oracle pour la Fonctionnement : performance : AWR Prise d un «snapshot» du comportement (statistiques diverses) de la base de données pendant à intervals donnés pendant un temps limité (consommation de temps de calcul et d espace). Analyse des statistiques produites Le choix du temps de prise du snapshot est déterminant Analyse des différentes phase de production (plan de charge de la production). 11

12 Analyse des statistiques : les causes possible de perte de performance Les attentes (wait) sont la cause des pertes (ou baisses de performances). Elles sont classifiées selon leur cause principale : Actions d administration : commandes réalisées par un utilisateur privilégié qui induit une attente des autres utilisateurs (la reconstruction d un indexe par exemple). Application : tous les défauts induits par le modèle qui induisent des blocages (mise en attente) du fait de l accès concurent sur une donnée pour une cause explicite ou implicite (modification) Architecture cluster : cach global, synchronisation des noeuds, Actions liées à un commit : évennements d attentes liées au redolog Accès concurrent par beaucoup de sessions vers une même ressource (parsing SQL, verrou sur des buffers, ) Configuration : construction de ressources (log, logfile, buffer, ) de taille insuffisante Idle : sessions inactives Réseau : attente de données envoyée par le réseau Scheduler : attente liée à une priorisation du manager de ressources System I/O : attente sur les I/O système pour les processus en arrière plan (autre que ceux liés à la gestion des données utilisateur). User I/O : attente de lecture de bloc (processus SMON, or MMON). 12

13 Analyse des statistiques : exemples de préconisation ADDM ADDM_REPORT DETAILED ADDM REPORT FOR TASK 'ADDM: _1_198' WITH ID 310 Analysis Period: 10-DEC-2003 from 20:30:51 to 21:00:36 Database ID/Instance: /1 Snapshot Range: from 197 to 198 Database Time: 1119 seconds Average Database Load:.6 active sessions FINDING 1: 100% impact (7136 seconds) SQL statements were found waiting for row lock waits. RECOMMENDATION 1: Application Analysis, 100% benefit (7136 seconds) ACTION: Trace the cause of row contention in the application logic. Use given blocked SQL to identify the database objects involved. Investigate application logic involving DML on these objects. RATIONALE: The SQL statement with SQL_ID 18n2c85u5p8zf was blocked on row locks. RELEVANT OBJECT: SQL statement with SQL_ID 18n2c85u5p8zf update emp set ename = ename RATIONALE: The SQL statement with SQL_ID 275zcmg41cx02 was blocked on row locks. RELEVANT OBJECT: SQL statement with SQL_ID 275zcmg41cx02 RATIONALE: The SQL statement with SQL_ID 5dhfmtds8m5qs was blocked on row locks. RELEVANT OBJECT: SQL statement with SQL_ID 5dhfmtds8m5qs RATIONALE: The SQL statement with SQL_ID 872zuyfy72zs5 was blocked on row locks. RELEVANT OBJECT: SQL statement with SQL_ID 872zuyfy72zs5 SYMPTOMS THAT LED TO THE FINDING: Wait class "Application" was consuming significant database time. (100% impact [7136 seconds]) FINDING 2: 100% impact (1790 seconds) PL/SQL execution consumed significant database time. RECOMMENDATION 1: SQL Tuning, 100% benefit (1790 seconds) ACTION: Tune the PL/SQL block with SQL_ID fjxa1vp3yhtmr. Refer to the "Tuning PL/SQL Applications" chapter of Oracle's "PL/SQL User's Guide and Reference" RELEVANT OBJECT: SQL statement with SQL_ID fjxa1vp3yhtmr BEGIN EMD_NOTIFICATION.QUEUE_READY(:1, :2, :3); END; 13

14 Analyse des statistiques : exemples de préconisation ADDM FINDING 1: 100% impact (18758 seconds) Hard parses due to an inadequately sized shared pool were consuming significant database time. RECOMMENDATION 1: DB Configuration, 100% benefit (11945 seconds) ACTION: Increase the shared pool size by setting the value of parameter "shared_pool_size" to 1712 M. ADDITIONAL INFORMATION: The value of parameter "shared_pool_size" was "1552 M" during the analysis period. SYMPTOMS THAT LED TO THE FINDING: SYMPTOM: Hard parsing of SQL statements was consuming significant database time. (4.3% impact [405 seconds]) FINDING 3: 100% impact (58925 seconds) The throughput of the I/O subsystem was significantly lower than expected. RECOMMENDATION 1: Host Configuration, 100% benefit (58925 seconds) ACTION: Consider increasing the throughput of the I/O subsystem. Oracle's recommended solution is to stripe all data file using the SAME methodology. You might also need to increase the number of disks for better performance. Alternatively, consider using Oracle's Automatic Storage Management solution. RATIONALE: During the analysis period, the average data files' I/O throughput was 4.3 M per second for reads and 22 K per second for writes. The average response time for single block reads was 1 milliseconds. FINDING 2: 4.1% impact (385 seconds) Session connect and disconnect calls were consuming significant database time. RECOMMENDATION 1: Application Analysis, 4.1% benefit (385 seconds) ACTION: Investigate application logic for possible reduction of connect and disconnect calls. For example, you might use a connection pool scheme in the middle tier. RECOMMENDATION 2: Host Configuration, 11% benefit (716 seconds) ACTION: The performance of file /oracle/temp/pwcis/temp_03.dbf was significantly worse than other files. If striping all files using the SAME methodology is not possible, consider striping this file over multiple disks. RELEVANT OBJECT: database file "/u01/app/oracle/oradata/temp_3.dbf RATIONALE: The average response time for single block reads for this file was 91 milliseconds. 14

15 Tuning MySQL Approche différente puisque 2 moteurs coexistent : MyISAM et InnoDB MyISAM, moteur par défaut, stocke les tables sous la forme de 3 fichiers : 1 pour le format de la table, 1 pour les données, 1 pour les indexes. Indexation textuelle plus performante, insertion, lecture et modification plus efficiente dans la plus part des cas. Mais : par de dépendance fonctionnelle entre table (contraintes sur les FK), lock sur l ensemble de la table en cas d insertion. InnoDB, stocke les tables dans un espace de stockage comparable à un TableSpace Oracle. Permet le lock au niveau des enregistrements et les contraintes sur les clés etrangères. Table de choix : Critère Est-ce que la table va être beaucoup plus modifiée (RWUD) que sélectionnée (Transaction Safe) Recherche en texte plein Modélisation et contrôle relationnel Espace de stockage ou RAM limitée Moteur InnoDB MyISAM InnoDB MyISAM Dans le doute MyISAM 15

16 Tuning MySQL via MySQLTuner (1/2) Contrôle via des outils de diagnostic (comme on est dans le monde libre, à chacun de trouver «sa» bonne recette). Par exemple : MySQLTuner (script perl de diagnostic de MySQL) # mysqltuner >> MySQLTuner Major Hayden <[email protected]> >> Bug reports, feature requests, and downloads at >> Run with '--help' for additional options and output filtering [OK] Logged in using credentials passed on the command line General Statistics [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version a-3ubuntu5.2-log [OK] Operating on 64-bit architecture Storage Engine Statistics [--] Status: +Archive -BDB -Federated -InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 1G (Tables: 724) [!!] Total fragmented tables: 2 16

17 Tuning MySQL via MySQLTuner (2/2) Performance Metrics [--] Up for: 6d 14h 35m 43s (4M q [7.336 qps], 89K conn, TX: 4B, RX: 970M) [--] Reads / Writes: 59% / 41% [--] Total buffers: 5.5M per thread and 1.0G global [OK] Maximum possible memory usage: 1.2G (40% of installed RAM) [OK] Slow queries: 0% (1/4M) [OK] Highest usage of available connections: 33% (10/30) [OK] Key buffer size / total MyISAM indexes: 512.0M/70.0K [OK] Key buffer hit rate: 98.4% [OK] Query cache efficiency: 94.1% [OK] Query cache prunes per day: 0 [OK] Sorts requiring temporary tables: 0% [OK] Temporary tables created on disk: 5% [OK] Thread cache hit rate: 99% [!!] Table cache hit rate: 7% [OK] Open file limit used: 71% [OK] Table locks acquired immediately: 99% Recommendations General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance Increase table_cache gradually to avoid file descriptor limits Variables to adjust: table_cache (> 1024) 17

18 Optimisation des requêtes Une fois la configuration est les problèmes les plus flagrants traités, reste l identification des optimisations «applicatives» via les requêtes les plus coûteuses en temps de calcul. Les plus jouées Les plus consommatrices de ressources Les moteurs enregistrent des statistiques sur les requêtes les plus jouées / consommatrices. 18

19 Optimisation des requêtes But de l optimisation : Réduction du temps de réponse Réduction des ressources nécessaires à la réponse Moyen de l optimisation : Réduire la charge de travail Organiser la charge de travail Paralléliser la charge de travail 19

20 Optimisation des requêtes = comprendre le fonctionnement du moteur sous jacent Dans Oracle, le moteur est CBO (Cost based Optimisation) et se base sur les statistiques pour estimer la méthode optimale pour réaliser une requêtes. Il est aussi possible de «forcer» l utilisation de telle ou telle méthode (Hints) et de bypasser l optimiser. 20

21 Optimisation des requêtes = comprendre le fonctionnement du moteur sous jacent Pour déterminer le meilleur plan d exécution pour chaque ordre SQL, l optimiser : évalue toutes les stratégies possibles utilise des règles préétablies utilise un système de notation des clauses WHERE et utilise des statistiques pour calculer les coûts relatifs d exécution des plans Son savoir-faire repose sur les informations disponibles dans le dictionnaire de données, quelques règles de bases et les HINTS («conseils» donnés par le programmeur SQL).Le dictionnaire de données lui retourne par exemple : quels sont les index unique et non-unique? quelles sont les enveloppes de données (CLUSTERS) qui existent? quelles sont les colonnes NOT NULL? à quoi ressemblent les données (nombre d enregistrements, nombre de valeurs distinctes, nombre de blocs, etc...). 21

22 Optimisation des requêtes = comprendre le fonctionnement du moteur sous jacent Par contre, les informations suivantes ne lui sont pas accessibles : quelle est la distribution des données (sauf avec le mode d analyse par histogrammes)? quelle est la distribution des valeurs des clés d index? combien de d enregistrements sont NULL et dans quelles colonnes? Il se peut donc que le plan généré ne soit pas optimal. Dans ces conditions, l optimiseur peut être aidé voir influencé : en créant des index «accélérateurs» des accès aux données en créant des enveloppes de données de type CLUSTER (HASHED ou INDEX) en analysant les tables pour établir des statistiques en fournissant des conseils (HINTS) à l optimiseur 22

23 Optimisation des requêtes Optimiseur : stratégie globale L optimiseur Oracle à deux stratégies globales possibles : minimiser les ressources pour obtenir TOUTES les lignes ( best throughput) minimiser le temps de réponse pour obtenir LA PREMIER ligne de résultat ( best response time) Le choix de la stratégie peut être configuré à 3 niveaux : au niveau base ( ALTER SYSTEM SET OPTIMIZER_MODE = ) au niveau session ( ALTER SESSION SET OPTIMIZER_MODE= ) au niveau de l ordre SQL ( HINT ) Les différentes valeurs de OPTIMIZER_MODE sont les suivantes : FIRST_ROWS (déconseillé par Oracle) FIRST_ROWS_n (avec n= 1, 10, 100, ou 1000) -> temps réponse minimal ALL_ROWS -> ressources minimales (c est de défaut! Il est bien évidement relatif au type de besoin (requêtes) réalisées! 23

24 Optimisation des requêtes Optimiseur : méthode d accès aux données Oracle à deux méthodes d accès aux données : full table scan : parcours TOUTES les lignes de la table et pour chacune vérifie si elle satisfait aux conditions de recherche exprimées dans les clauses WHERE index scan : parcours l index en fonction des critères des recherche des clauses WHERE et accèdent les seuls enregistrements qui correspondent. L utilisation de telle ou telle méthode est fonction décidée en fonction des statistiques de sélectivité des indexes. 24

25 Optimiseur : Condition d utilisation des indexes Il n y a pas que les statistiques qui amène le choix de l utilisation d un indexe. La formulation de la requête a également un impact déterminant : L index est utilisé... pour une recherche d égalité, par exemple si un index existe sur EMPNO (IEMP1) : SELECT ENAME FROM EMP WHERE EMPNO = 7936 pour une recherche bornée : SELECT ENAME FROM EMP WHERE EMPNO BETWEEN 7000 AND 8000 pour une recherche non bornée : SELECT ENAME FROM EMP WHERE EMPNO > 7000 L index n est pas utilisé si la colonne est modifiée de quelques manière que ce soit... par exemple l index sur SQL n est pas utilisé dans : SELECT ENAME FROM EMP WHERE SAL*12 = 2400 mais il l est avec : SELECT ENAME FROM EMP WHERE SAL = 2400 / 12 25

26 Optimiseur : Condition d utilisation des indexes l index sur ENAME n est pas utilisé dans : SELECT ENAME FROM EMP WHERE SUBSTR (ENAME, 1, 1) = 'S mais il l est dans : SELECT ENAME FROM EMP WHERE ENAME LIKE 'S% Les index ne sont également pas utilisés quand une opération est appliquée sur la colonne comme par exemple : WHERE CHARACTER_COLUMN = SMITH ou WHERE NUMBER_COLUMN + 0 = 10 ou encore WHERE DATE_COLUMN + 0 = SYSDATE. 26

27 Optimiseur : Condition d utilisation des indexes Une conversion de type de données peut désactiver l utilisation d un index. Par exemple, l index sur HIREDATE n est pas utilisé sur : SELECT ENAME FROM EMP WHERE TO_CHAR(HIREDATE, 'DD-MON-YYYY HH24:MI:SS' ) = '01-JAN :00:00' mais il est utilisé avec : SELECT ENAME FROM EMP WHERE HIREDATE = TO_DATE( '01-JAN :00'00', 'DD- MON-YYYY HH24:MI:SS' ) il n est pas utilisé pour : SELECT ENAME FROM EMP WHERE TO_CHAR ( HIREDATE, DD-MON-YY ) = 01-JAN-89 mais il est requis pour : SELECT ENAME FROM EMP WHERE HIREDATE >= TO DATE('01-JAN-89 ) AND HIREDATE < TO_DATE (' 02-JAN-89 ) 27

28 Optimiseur : Impact du type de données Quel que soit le SGBD, uniquement des types de données identiques peuvent être comparés. S ils diffèrent, une conversion est réalisé automatiquement, invalidant alors l usage des index. Les conversions implicites effectuées par le serveur sont les suivantes : character et number : character converti en number (avec to_number) character et date : character converti en date (avec to_date) character et rowid : character converti en rowid (avec char_to_rowid) Pour ne pas tomber dans ce piège, il est recommandé de convertir explicitement les colonnes de types différents en utilisant les fonctions to_char, to_date, to_number, char_to_rowid et rowid_to_char. Essayer également de ne pas stocker des numbers et des dates dans un VARCHAR2 ou CHAR car cela peut aboutir à des conversions implicites et des erreurs de comparaison et de tri. 28

29 Optimiseur : Utilisation des indexes avec LIKE Un index est utilisé pour une clause LIKE si et seulement si la colonne est de type CHAR (ou VARCHAR2) et si la chaîne de comparaison débute avec un caractère. Par exemple, l index sur ENAME est utilisé pour : SELECT ENAME FROM EMP WHERE ENAME LIKE 'S%' mais pas pour : SELECT ENAME FROM EMP WHERE ENAME LIKE '%S% Dans le cas où la colonne est un number ou une date, une conversion implicite est effectuée avec la fonction correspondante et l index n est pas utilisé. Par exemple : SELECT ENAME FROM EMP WHERE EMPNO LIKE '7%' devient : SELECT ENAME FROM EMP WHERE TO_CHAR(EMPNO) LIKE '7%' 29

30 Optimiseur : Condition d utilisation des indexes concaténés Un index concaténé est utilisé si sa première colonne est référencée dans la clause WHERE. Par exemple, l index sur EMPNO, ENAME et SAL est utilisé dans: SELECT ENAME FROM EMP WHERE EMPNO = 7936 Il l est également dans : SELECT ENAME FROM EMP WHERE EMPNO = 7936 AND ENAME = SMITH Et la totalité de l index est même utilisé dans : SELECT ENAME FROM EMP WHERE EMPNO = 7936 AND ENAME = SMITH AND SAL = 5000 L index concaténé est aussi utilisé dans : SELECT ENAME FROM EMP WHERE EMPNO = 7936 AND SAL = 5000 Mais il ne l est pas dans : SELECT ENAME FROM EMP WHERE ENAME = 'SMITH AND SAL =

31 Optimiseur : Utilisation des indexes avec NOT ou NOT NULL Quand il rencontre une clause NOT ou NOT NULL, l optimiseur suppose que la plupart des enregistrements vont être balayés et il n utilise pas les index. Par exemple, l index sur COMM n est pas utilisé dans : SELECT ENAME FROM EMP WHERE COMM IS NOT NULL mais on peut forcer son utilisation par : SELECT ENAME FROM EMP WHERE COMM > -9.99E125 L index sur DEPTNO n est pas utilisé dans : SELECT ENAME FROM EMP WHERE DEPTNO! = 10 Mais il l est pour : SELECT ENAME FROM EMP WHERE DEPTNO < 10 OR DEPTNO > 10 31

32 Optimiseur : Utilisation des indexes avec ORDER BY Un index est directement utilisé (pas de phase finale de tri) pour les clauses ORDER BY dans les cas suivants : l index est pertinent : pas de fonction appliquée sur les colonnes de l ORDER BY et les colonnes de l ORDER BY sont dans les colonnes de tête d un index concaténé, au moins une des colonnes de l index est définie comme NOT NULL l index est déjà utilisé dans les clauses WHERE pas d opérateur UNION, UNION ALL, MINUS, INTERSECT, DISTINCT ni GROUP BY l index porte sur la table directrice (en cas de jointure, cf. plus bas) Si aucune index n est utilisable, une phase de tri est alors effectuée. 32

33 Optimiseur : Utilisation des indexes avec MAX et MIN Un index est utilisé pour les fonctions MAX et MIN dans les cas suivants : l index est pertinent : pas de fonction appliquée sur les colonnes du MAX ou MIN et les colonnes du MAX ou MIN sont dans les colonnes de tête d un index concaténé, il n y a pas de clause WHERE ni de GROUP BY la requête ne possède pas de jointure il n y a pas d autres expressions dans la requête pas d opérateurs autres que et + n est utilisé à l intérieur de la fonction MIN ou MAX la fonction porte sur une seule colonne. Par exemple, l index sur SAL est utilisé dans : SELECT MAX(SAL+1000) *2 FROM EMP il ne l est pas dans : SELECT MAX(SAL*2) FROM EMP 33

34 Optimiseur : Utilisation des indexes unique L optimiseur donne sa préférence à l index qui retourne un enregistrement unique. Il n en utilisera aucun autre défini sur la table. Une fois l enregistrement unique retourné via l index sélectionné, les autres conditions de la requête sont appliquées à cet enregistrement. Par exemple : SELECT ENAME FROM EMP WHERE EMPNO = 7936 AND ENAME = SMITH CREATE UNIQUE INDEX IEMP1 ON EMP (EMPNO) CREATE INDEX IEMP2 ON EMP ( ENAME) utilisera seulement l index sur EMPNO car il est unique. Execution Plan SELECT STATEMENT Optimizer=RULE 1 0 TABLE ACCESS (BY ROWID) OF 'EMP' 2 1 INDEX (UNIQUE SCAN) OF 'IEMP1' (UNIQUE) Si un ROWID est précisé, c est lui qui a la préférence de l optimiseur, même si un index unique existe. 34

35 Optimiseur : Utilisation du dernier indexe créé Si deux index équivalents existent, l optimiseur choisira celui retourné par la requête récursive soumise au dictionnaire de données du serveur Oracle (généralement le dernier index créé). Ceci peut être la cause de dysfonctionnements difficiles à tracer du genre : cela marchait hier et plus ajourd hui. En conséquence, ne jamais écrire des requêtes qui dépendent de cet ordre plus ou moins aléatoire. Par exemple, les index suivants sont équivalents mais leur choix dépend de leur ordre de création : SELECT ENAME FROM EMP WHERE EMPNO = 7936 AND ENAME = SMITH CREATE INDEX IEMP1 ON EMP (EMPNO) CREATE INDEX IEMP2 ON EMP (ENAME) Execution Plan SELECT STATEMENT Optimizer=RULE 1 0 AND-EQUAL 2 1 INDEX (RANGE SCAN) OF 'IEMP1' (NON-UNIQUE) 3 1 INDEX (RANGE SCAN) OF 'IEMP2' (NON-UNIQUE) 35

36 Optimiseur : Utilisation de plusieurs indexes L optimiseur utilisera simultanément plusieurs index sur une même table si : les index sont définis comme non-unique ils portent sur une seule colonne les prédicats sont des égalités. Par exemple : CREATE INDEX IEMP1 ON EMP (JOB) CREATE INDEX IEMP2 ON EMP (DEPTNO) SELECT ENAME FROM EMP WHERE JOB = MANAGER AND DEPTNO = 20 réunira les deux index. Le serveur Oracle procède alors par comparaison successive des ROWID stockés dans les index pour retrouver les enregistrements. Un maximum de 5 index peuvent être fusionnés. S il y en a plus, les 5 premières colonnes des clauses WHERE décideront des 5 index à utiliser. La fusion d index n est utilisée uniquement pour des égalités. Si des opérations de comparaison (> ou <) sont mélangées aux égalités, la fusion n aura pas lieu et l index portant sur la colonne de l égalité sera utilisé. 36

37 Optimiseur : Utilisation des indexes en cas de comparaison Les combinaisons d égalité et de comparaisons utilisent pleinement les index concaténés. Par exemple : SELECT ENAME FROM EMP WHERE DEPTNO = 10 AND SAL > 3000 l index sur EMP (DEPTNO, SAL) est utilisé. Egalement : SELECT ENAME FROM EMP WHERE DEPTNO > 10 AND SAL > 3000 permet d utiliser l index sur EMP (DEPTNO,SAL). 37

38 Optimiseur : Pas besoin de créer des indexes si Il n est pas nécessaire de prévoir des index pour : l exécution d un UNION ALL (ils sont évidemment utilisés pour les clauses WHERE) : les enregistrements de la première table sont simplement retournés suivis des enregistrements de la seconde table. pour un UNION : en fait, le UNION est transformé en UNION ALL et un tri est effectué pour supprimer les doublons. Pour un DISTINCT : Oracle effectue d abord deux tris pour supprimer les doublons et ensuite un MINUS ou un INTERSECT. Oracle effectue un tri et il n est donc pas nécessaire de prévoir des index spécifiques 38

39 Optimiseur : Pas besoin de créer des indexes si Il n est pas nécessaire de prévoir des index pour : Pour un GROUP BY : Oracle effectue un tri pour grouper les enregistrements et il n est donc pas nécessaire de prévoir des index spécifiques Il est par contre important d utiliser une clause WHERE autant que possible à la place du HAVING. Le but est de limiter le nombre d enregistrements qui seront triés en vu pour être ensuite groupés.. Par exemple, il est préférable d écrire : SELECT DEPTNO, AVG ( SAL) FROM EMP WHERE DEPTNO = 10 GROUP BY DEPTNO qui effectuera un regroupement des enregistrements dont DEPTNO = 10 (et qui utilise l index sur DEPTNO) que : SELECT DEPTNO, AVG(SAL) FROM EMP GROUP BY DEPTNO HAVING DEPTNO = 10 39

40 Optimiseur : Indexes et jointures externes Cas des jointures externes, la table non-externe (celle qui n est pas suivie du (+)) est la table directrice. Pour l utilisation des index, plusieurs cas sont possibles : Les clauses WHERE ne portant pas sur la jointure mais sur la table nonexterne sont appliquées AVANT la jointure et les éventuels index existants peuvent être utilisés. Les clauses WHERE ne portant pas sur la jointure mais sur la table externe et qui sont suivies par un (+) sont appliquées AVANT la jointure et les éventuels index existants peuvent être utilisés. Les clauses WHERE ne portant pas sur la jointure mais sur la table externe et sans le (+) sont appliquées APRES la jointure et les éventuels index existants ne peuvent pas être utilisés. 40

41 Optimiseur : Indexes et jointures externes Par exemple : SELECT DNAME, ENAME FROM DEPT, EMP WHERE DEPT.DEPTNO = EMP.DEPTNO(+) AND DNAME = 'ACCOUNTING' CREATE INDEX IDEPT1 ON DEPT(DNAME) La table directrice est DEPT et l index sur DNAME sert à y accéder. Dans le cas : SELECT DNAME, ENAME FROM DEPT, EMP WHERE DEPT.DEPTNO = EMP.DEPTNO(+) AND SAL(+) = 5000 CREATE INDEX IEMP1 ON EMP (SAL) La table directrice est toujours DEPT et un FTS est utilisé pour y accéder. La condition sur SAL est appliquée AVANT (grace au (+)) et l index IEMP1 est utilisé pour accéder à EMP. Execution Plan SELECT STATEMENT 1 0 NESTED LOOPS (OUTER) 2 1 TABLE ACCESS (FULL) OF 'DEPT' 3 1 TABLE ACCESS (BY ROWID) OF 'EMP' 4 3 INDEX (RANGE SCAN) OF 'IEMP1' (NON-UNIQUE) 41

42 Optimiseur : Indexes et jointures externes Egalement : SELECT DNAME, ENAME FROM DEPT, EMP WHERE DEPT.DEPTNO = EMP.DEPTNO ( + ) AND SAL = 5000 CREATE INDEX IEMP1 ON EMP (SAL) Idem que pour précédemment, mais l index IEMP1 n est plus utilisé. Execution Plan SELECT STATEMENT 1 0 FILTER 2 1 MERGE JOIN (OUTER) 3 2 SORT (JOIN) 4 3 TABLE ACCESS (FULL) OF 'DEPT' 5 2 SORT (JOIN) 6 5 TABLE ACCESS (FULL) OF 'EMP' 42

43 Optimiseur : Indexes et OR Il est possible d éviter un FTS dans les requêtes contenant des OR. L objectif de l optimiseur est de découper la requête en plusieurs sous-requêtes et de les réunir avec un UNION ALL. La condition est qu un index existe pour chacune des colonnes du OR (des deux côtés). Par exemple : SELECT ENAME FROM EMP WHERE DEPTNO= 20 OR JOB = 'MANAGER' CREATE INDEX IEMP1 ON EMP (DEPTNO) CREATE INDEX IEMP2 ON EMP (JOB) devient : SELECT ENAME FROM EMP WHERE DEPTNO =20 UNION ALL SELECT ENAME FROM EME WHERE JOB = MANAGER' Execution Plan SELECT STATEMENT 1 0 CONCATENATION 2 1 TABLE ACCESS (BY ROWID) OF 'EMP' 3 2 INDEX (RANGE SCAN) OF 'IEMP2' (NON-UNIQUE) 4 1 TABLE ACCESS (BY ROWID) OF 'EMP' 5 4 INDEX (RANGE SCAN) OF 'IEMP1' (NON-UNIQUE) 43

44 Optimiseur : Indexes et IN série limitée de valeur La même optimisation (OR en UNION ALL) peut également être utilisée avec les IN. Par exemple : SELECT ENAME FROM EMP WHERE DEPTNO IN (10,20) CREATE INDEX IEMP1 ON EMP (DEPTNO) devient : SELECT ENAME FROM EMP WHERE DEPTNO = 10 UNION ALL SELECT ENAME FROM EMP WHERE DEPTNO = 20 Execution Plan SELECT STATEMENT 1 0 CONCATENATION 2 1 TABLE ACCESS (BY ROWID) OF 'EMP' 3 2 INDEX (RANGE SCAN) OF 'IEMP1' (NON-UNIQUE) 4 1 TABLE ACCESS (BY ROWID) OF 'EMP' 5 4 INDEX (RANGE SCAN) OF 'IEMP1' (NON-UNIQUE) 44

45 Optimiseur : sous requêtes IN Dans le cas de sous requêtes, de manière générale, la requête principale et la sous-requête sont traitées séparément et les index sont utilisés en suivant les mêmes règles vues jusqu à présent. L optimiseur transforme le IN en une jointure. Si les colonnes retournées par la sous-requête ne possèdent pas d index, les enregistrements retournés sont d abord triés pour supprimer les doublons. La sous-requête fait office de table directrice. Par exemple : SELECT ENAME FROM EMP WHERE DEPTNO IN ( SELECT DEPTNO FROM DEPT) Les lignes de DEPT sont triées et ensuite jointes à EMP. Les éventuels index sont utilisés. Execution Plan SELECT STATEMENT 1 0 NESTED LOOPS 2 1 VIEW 3 2 SORT (UNIQUE) 4 3 TABLE ACCESS (FULL) OF 'DEPT' 5 1 TABLE ACCESS (BY ROWID) OF 'EMP' 6 5 INDEX (RANGE SCAN) OF 'IEMP1' (NON-UNIQUE) 45

46 Optimiseur : sous requêtes NOT IN Dans le cas d un NOT IN, la sous-requête est exécutée pour chaque enregistrement de la requête principale. Dans ce cas, la table directrice est donc la requête principale. Les index ne sont pas utilisés pour le traitement de l opérateur lui-même. Par exemple : SELECT ENAME FROM EMP WHERE DEPTNO NOT IN ( SELECT DEPTNO FROM DEPT) Un FTS est utilisé pour accéder EMP et pour chaque enregistrement retourné un FTS est effectué sur DEPT. Execution Plan SELECT STATEMENT Optimizer=RULE 1 0 FILTER 2 1 TABLE ACCESS (FULL) OF 'EMP' 3 1 TABLE ACCESS (FULL) OF 'DEPT' 46

47 Optimiseur : sous requêtes exists ou not exists Dans le cas d une sous requêtes via les opérateurs EXISTS ou NOT EXISTS, la sousrequête est d abord exécutée et la requête principale est lancée uniquement si EXISTS ou NOT EXISTS retourne TRUE. Par exemple : SELECT ENAME FROM EMP WHERE EXISTS Execution Plan ( SELECT DEPTNO FROM DEPT WHERE DEPTNO = 10) SELECT STATEMENT 1 0 FILTER 2 1 TABLE ACCESS (FULL) OF 'EMP' 3 1 TABLE ACCESS (FULL) OF 'DEPT' La différence entre EXISTS et NOT EXISTS et que la requête contenant EXISTS s arrête dès qu un enregistrement est retourné alors que NOT EXISTS déroule la sous-requête jusqu au bout. 47

48 Optimiseur : sous requêtes = ou!= Dans le cas d une sous requêtes via les opérateurs = ou!=, la sous-requête est exécutée en premier et la requête principale est lancée avec les resultats obtenus de la sousrequête. Par exemple : SELECT ENAME FROM EMP WHERE DEPTNO = ( SELECT DEPTNO FROM DEPT WHERE DEPTNO = 10) La sous-requête est exécutée via l index sur DEPTNO et la requête principale est ensuite exécutée la valeur retournée. Execution Plan SELECT STATEMENT Optimizer=RULE 1 0 TABLE ACCESS (BY ROWID) OF 'EMP' 2 1 INDEX (RANGE SCAN) OF 'IEMP1' (NON-UNIQUE) 3 2 TABLE ACCESS (FULL) OF 'DEPT' 48

49 Optimiseur : sous requêtes corrélées Ici, les deux requêtes possèdent des colonnes en commun dans leur clauses WHERE respectives. La sous-requête est exécutée pour chaque enregistrement de la requête principale. Dans ce cas, la table directrice est donc la requête principale. Les index ne sont pas utilisés pour le traitement de l opérateur lui-même. Par exemple : SELECT ENAME FROM EMP WHERE DEPTNO IN ( SELECT DEPTNO FROM DEPT WHERE EMP.DEPTNO = DEPT.DEPTNO) La table directrice EMP est accédée via un FTS et pour chaque enregistrement retourné la sous-requête sur DEPT est exécutée. Execution Plan SELECT STATEMENT 1 0 FILTER 2 1 TABLE ACCESS (FULL) OF 'EMP' 3 1 TABLE ACCESS (FULL) OF 'DEPT' 49

50 Pour conclure sur l optimiseur : quelques règles Quelques règles générales sur la façon d écrire des requêtes SQL efficaces avec le serveur Oracle. un index sera utilisé uniquement si ces colonnes sont dans une clause WHERE. Il peut être utile d ajouter des clauses WHERE «bidons» pour forcer son utilisation pas de fonctions ni d expressions sur les colonnes des clauses WHERE contrôler explicitement les conversions de type définir autant que possible les colonnes comme NOT NULL créer de préférence des index UNIQUE préférer des index concaténés pour les recherches non bornées (<, >...) 50

51 Pour conclure sur l optimiseur : quelques règles ne pas hésitez à inhiber un index si : plus de 5% des enregistrements sont retournés par la requête la table est petite (moins de 5 blocs) plus de 5 index simples sont fusionnés l optimiser doit être influencé pour choisir une table directrice particulière éviter d utiliser les sous-requêtes : souvent une jointure peut s y substituer attention aux opérateurs!=, IS NULL, IS NOT NULL et NOT IN qui ne peuvent profiter des index attention aux restrictions d utilisation des index dans les ORDER BY et les fonctions MIN et MAX 51

52 Pour conclure sur l optimiseur : quelques règles préférer une clause WHERE à la place d un HAVING dans les GROUP BY attention au tris implicitement générés par les opérations UNION, MINUS, INTERSECT, DISTINCT et GROUP BY. se rappeler les conditions d optimisation des OR ne pas hésiter à créer plusieurs index redondants (sauf si des mises à jour sont fréquentes sur ces tables). 52

53 Les HINTS Si on veux se passer de l optimiseur, il est possible d utiliser les HINTS qui sont des directives explicites données à l optimiseur. À utiliser avec autant de précaution que la dénormalisation car cela demande de bien maîtriser ce qui se passe et, plus encore, ce qui se passera en cas de montée de version du moteur. Les HINTS sont intégrés dans les requêtes sous la forme de commentaires : SELECT /* + hint(table) */ column1, column2 FROM table WHERE condition; 53

54 Les HINTS Pour l optimisation des resultats : ALL_ROWS, FIRST_ROW Pour les chemins d accès : FULL : parcours complet ROWID : recherche des lignes via les ROWID INDEX(indexe) : force l utilisation d un index INDEX : force le calcul du coût de chaque indexe pour choisir le meilleur INDEX_ASC, INDEX_COMBINE, INDEX_DESC, INDEX_FFS, INDEX_JOIN, NO_INDEX, 54

55 Les HINTS Pour les transformations de requêtes : FACT, MERGE, NO_EXPAND, NO_EXPAND_GSET_TO_UNION, NO_FACT, NO_MERGE, NOREWRITE, REWRITE, STAR_TRANSFORMATION, USE_CONCAT. Pour les opérations de SQL join : DRIVING_SITE, HASH_AJ, HASH_SJ, LEADING, MERGE_AJ, MERGE_SJ, NL_AJ, NL_SJ, USE_HASH, USE_MERGE, USE_NL. pour l'exécution parallèle: NOPARALLEL, PARALLEL, NOPARALLEL_INDEX, PARALLEL_INDEX, PQ_DISTRIBUTE. 55

56 Les HINTS supplémentaires : ANTIJOIN, APPEND, BITMAP, BUFFER, CACHE, CARDINALITY, CPU_COSTING,DYNAMIC_SAMPLING, INLINE, MATERIALIZE, NO_ACCESS, NO_BUFFER, NO_MONITORING, NO_PUSH_PRED, NO_PUSH_SUBQ, NO_QKN_BUFF, NO_SEMIJOIN, NOAPPEND, NOCACHE, OR_EXPAND, ORDERED, ORDERED_PREDICATES, PUSH_PRED, PUSH_SUBQ, QB_NAME, RESULT_CACHE, SELECTIVITY, SEMIJOIN, SEMIJOIN_DRIVER, STAR, SWAP_JOIN_INPUTS, USE_ANTI, USE_SEMI. 56

57 EXPLAIN MySQL (1/6) Les indications données par MySQL sont différentes : principalement la cardinalité (sélectivité) d accès aux champs d une requête. Tables et indexes de l exemple : Table Colonne Type tt ActualPC CHAR(10) tt AssignedPC CHAR(10) tt clientid CHAR(10) et EmployID CHAR(15) do Custnmbr CHAR(15) Table tt tt tt et do Index ActualPC AssignedPC ClientID EmployID (clé primaire) Cutnmbr (clé primaire) 57

58 EXPLAIN MySQL (2/6) EXPLAIN SELECT tt.ticketnumber, tt.timein, tt.projectreference, tt.estimatedshipdate, tt.actualshipdate, tt.clientid, tt.servicecodes, tt.repetitiveid, tt.currentprocess, tt.currentdpperson, tt.recordvolume, tt.dpprinted, et.country, et_1.country, do.custname FROM tt, et, et AS et_1, do WHERE tt.submittime IS NULL AND tt.actualpc = et.employid AND tt.assignedpc = et_1.employid AND tt.clientid = do.custnmbr; 58

59 EXPLAIN MySQL (3/6) table type possible_keys key key_len ref rows Extra et ALL PRIMARY NULL NULL NULL 74 do ALL PRIMARY NULL NULL NULL 2135 et_1 ALL PRIMARY NULL NULL NULL 74 tt ALL AssignedPC, NULL NULL NULL 3872 ClientID, ActualPC range checked for each record (key map: 35) 59

60 EXPLAIN MySQL (4/6) mysql> ALTER TABLE tt MODIFY ActualPC VARCHAR(15); Table type possible_keys key key_len ref rows Extra tt ALL AssignedPC, NULL NULL NULL 3872 Using ClientID, where ActualPC do ALL PRIMARY NULL NULL NULL 2135 range checked for each record (key map: 1) et_1 ALL PRIMARY NULL NULL NULL 74 range checked for each record (key map: 1) et eq_ref PRIMARY PRIMARY 15 tt.actualpc 1 60

61 EXPLAIN MySQL (5/6) mysql> ALTER TABLE tt MODIFY AssignedPC VARCHAR(15), -> MODIFY ClientID VARCHAR(15); table type possible_keys key key_len ref rows Extra et ALL PRIMARY NULL NULL NULL 74 tt ref AssignedPC, ActualPC 15 et.employid 52 Using ClientID, where ActualPC et_1 eq_ref PRIMARY PRIMARY 15 tt.assignedpc 1 do eq_ref PRIMARY PRIMARY 15 tt.clientid 1 61

62 EXPLAIN MySQL (6/6) mysql> ANALYZE TABLE tt; table type possible_keys key key_len ref rows Extra tt ALL AssignedPC NULL NULL NULL 3872 Using ClientID, where ActualPC et eq_ref PRIMARY PRIMARY 15 tt.actualpc 1 et_1 eq_ref PRIMARY PRIMARY 15 tt.assignedpc 1 do eq_ref PRIMARY PRIMARY 15 tt.clientid 1 62