Optimisation2010 request

421 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
421
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
2
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Optimisation2010 request

  1. 1. 3. Optimisation Que veut-on optimiser ? • Plan • On peut en fait définir plusieurs critères : – Introduction et exemple – temps d’exécution : temps total d’exécution, souvent utilisé comme critère par défaut – Optimisation logique et physique – temps de réponse : temps pour obtenir la première ligne du résultat. À – Application à Oracle considérer pour les traitements en tâche de fond – débit transactionnel : recherche de la fluidité des traitements concurrents – transfert réseau : pour les applications distribuées • Un module du SGBD, l’optimiseur, est chargé de : – prendre en entrée une requête, et la mettre sous forme d’opérations – se fixer comme objectif l’optimisation d’un certain paramètre (en général le temps d’exécution) – construire un programme s’appuyant sur les index existants, et les opérations disponiblesOptimisation – 2010 119 Optimisation – 2010 120 Optimisation d’une requête Étapes • Deux techniques d’optimisation Requête SQL – algébrique/logique analyse • on représente la requête sous forme d’arbre • on applique les transformations Arbre – statistique/physique traduction on estime le coût d’exécution en prenant en compte Plan d’exécution logique Réponse • les opérations à effectuer (sélections, jointures) • les index disponibles règles exécution • la taille des relations PEL amélioré statistiques PEPi • … estimation de la sélection du • On obtient un plan d’exécution, composé: taille du résultat meilleur plan – du plan d’exécution logique (PEL) PEL + taille {(PEP1,C1),(PEP2,C2),…} – et du plan d’exécution physique (PEP) prise en compte estimation des plans physiques des coûts {PEP1, PEP2,…} PEP: Plan d’exécution physiqueOptimisation – 2010 121 Optimisation – 2010 122
  2. 2. Un exemple (simpliste) Exemple (2) • Film (idFilm, titre, année, genre, résumé) • Première étape: plan dexécution logique • Artiste (idArtiste, nom, prénom, annéeNaissance) – les stratégies possibles (entre autres) • ((A join R) where idFilm=20)[nom] • Rôle (idArtiste, idFilm, nomRôle) • (A join (R where idFilm=20))[nom] ! SELECT nom FROM Artiste A, Rôle R " " nom nom ! WHERE R.idArtiste = A.idArtiste ! AND R.idFilm=20; ! ! ! idArtiste idFilm=20 • On suppose Artiste = 100 n-uplets, et Rôle = 500 n-uplets Artiste ! idFilm=20 idArtiste Artiste Rôle RôleOptimisation – 2010 123 Optimisation – 2010 124 Exemple (3) Évaluation de performances • Deuxième étape: plan dexécution physique • Soient – les opérations à effectuer – |T| la taille du résultat intermédiaire T • les sélections (idFilm = 20) – {T} le nombre de n-uplets examinés pour produire T • les jointures (idArtiste) • Stratégie 1: ((A join R) where idFilm=20)[nom] • Troisième étape: coût de lexécution physique – |T = A join R| ! |R| = 500 – quels sont les index dont on dispose ? – |T’ = T where idFilm=20| = 5 (en moyenne) – |T’’ = T’ [nom]| ! 5 – {T} ! 100 * 500 = 50 000 (boucles imbriquées) – {T’} = 500 – {T’’} = 5 (en moyenne)Optimisation – 2010 125 Optimisation – 2010 126
  3. 3. Évaluation de performances (2) Comparaison • Stratégie 2: (A join (R where idFilm=20))[nom] • Stratégie 2 plus efficace que stratégie 1 – |T = R where idFilm=20| = 5 (en moyenne) • En ce qui concerne la mémoire – |T’ = A join T| ! |T| = 5 – taille max stratégie 1: 500 – |T’’ = T’ [nom]| ! 5 – taille max stratégie 2: 5 – gain: 99% – {T} ! 500 • En ce qui concerne le CPU – {T’} ! 500 – nombre de n-uplets visités stratégie 1: 50505 – {T’’} ! 5 – nombre de n-uplets visités stratégie 2: 1005 – gain: 98% • Attention, l’exemple présenté est très simplisteOptimisation – 2010 127 Optimisation – 2010 128 Optimisation logique: les propriétés • Commutativité des jointures: R ⋈ S # S ⋈ R • Associativité des jointures: (R ⋈ S) ⋈ T # R ⋈ (S ⋈ T) • Regroupement des sélections: !A=a’$B=b (R) # !A=a (!B=b (R)) Optimisation logique et physique • Commutativité de la sélection et de la projection πA1,A2,…Ap(!Ai=a (R)) # !Ai=a (πA1,A2,…Ap(R)) • Distributivité de la sélection sur l’union (ou différence) !A=a (R % S) # !A=a (R) % !A=a (S) • Commutativité de la projection et de la jointure πA1…ApB1…Bq(R ⋈Ai=Bj S) # πA1…Ap(R) ⋈Ai=Bj πB1…Bq(S) • Distributivité de la projection sur l’union πA1A2…Ap(R % S) # πA1A2…Ap(R) % πA1A2…Ap(S)Optimisation – 2010 129 Optimisation – 2010 130
  4. 4. Optimisation logique Exécution logique • En français • Chercher tous les films avec James Stewart, parus en – séparer les sélections avec plusieurs prédicats en plusieurs sélections à 1958 un prédicat ! SELECT titre – descendre les sélections le plus bas possible dans l’arbre (pour ! FROM Film f, Role r, Artiste a minimiser les jointures) ! WHERE a.nom = ’Stewart’ AND a.prenom=’James’ – regrouper les sélections sur une même relation ! AND f.idFilm = r.idFilm – distribuer les sélections sur les jointures, les unions, les différences ! AND r.idActeur = a.idArtiste – descendre les projections le plus bas possible ! AND f.annee = 1958 – regrouper les projections sur une même relation • Il en existe d’autres – fonction dagrégation, élimination des doublons,… – compositionOptimisation – 2010 131 Optimisation – 2010 132 Exemple Optimisation physique • Première requête • Les sélections • Les jointures "titre(!année=1958 and nom=‘Stewart’ and prénom=‘James’(Film ⋈idFilm=idFilm(Rôle ⋈ Artiste))) • On sépare les sélections "titre(!année=1958 (!nom=‘Stewart’ (! prénom=‘James’(Film ⋈idFilm=idFilm(Rôle ⋈ Artiste))))) • On les descend dans l’arbre "titre(!année=1958(Film) ⋈idFilm=idFilm (Rôle ⋈ !nom=‘Stewart’ (! prénom=‘James’(Artiste))))Optimisation – 2010 133 Optimisation – 2010 134
  5. 5. La sélection La sélection (2) • Deux possibilités pour accéder à un enregistrement • Accès par adresse: si on connaît l’adresse du ou des • Accès séquentiel (balayage): parcours de tous les enregistrements concernés, on peut aller lire directement les enregistrements du fichier blocs et obtenir ainsi un accès optimal – on lit, bloc par bloc, le fichier – opération en deux étapes : – quand un bloc est en mémoire, on traite les enregistrements qu’il – on obtient l’adresse des enregistrements à rechercher (en général avec contient un index) – opération coûteuse si la table est grosse – avec cette adresse on va chercher le bloc, et on lit l’enregistrement – il faut limiter la taille (compactage, choix de types plus petits) – très performant : une ou deux lectures suffisent en général (pour un – il faut effectuer des lectures contiguës (cf. première partie sur le enregistrement) stockage)Optimisation – 2010 135 Optimisation – 2010 136 Coût Les jointures • Le fichier fait 500 Mo, une lecture de bloc prend 0,01 s (10 • Jointure sans index millisecondes) – le plus simple : jointure par boucles imbriquées • Un parcours séquentiel lira tout le fichier (ou la moitié pour – le plus courant : jointure par tri-fusion une recherche par clé) – parfois le meilleur : jointure par hachage (pas détaillée ici) soit 5 secondes • Jointure avec index • Une recherche par index implique 2 ou 3 accès pour – avec un index : jointure par boucles indexées – avec deux index : on fait comme si on avait un seul index parcourir l’index, et un seul accès pour lire l’enregistrement soit 4 x 0,01 = 0,04 s (4 millisecondes) • En gros, c’est mille fois moins cherOptimisation – 2010 137 Optimisation – 2010 138
  6. 6. Jointures sans index Jointures sans index (2) • Boucles imbriquées: bête et méchant 1. Boucles imbriquées – parcours d’une table, et pour chaque ligne, parcourir l’autre en comparant Comparaison Vertigo 1958 Spielberg Jurassic Park – la jointure est associative: R ⋈ T = T ⋈ R, donc mettre à gauche la relation la Association Hitchcock Psychose moins volumineuse Allen Manhattan – bénéfice si on a la possibilité de placer les deux relations en mémoire Lang Metropolis Hitchcock Vertigo Allen Annie Hall 2. Jointure par tri fusion Kubrik Shining – plus efficace que les boucles imbriquées pour de grosses tables Annie Hall 1977 Spielberg Jurassic Park – on trie les deux tables sur les colonnes de jointures Hitchcock Psychose – on effectue la fusion Allen Manhattan Lang Metropolis • Remarques Hitchcock Vertigo Allen Annie Hall – le tri coûte cher Kubrik Shining – on ne peut rien obtenir tant que le tri n’est pas fini …Optimisation – 2010 139 Optimisation – 2010 140 Jointures sans index (3) Jointures avec index • Exemple tri-fusion • Avec un index, on utilise les boucles imbriquées indexées Allen Annie Hall 1977 – on balaye la table non indexée Spielberg Jurassic Park 1992 – pour chaque ligne, on utilise l’attribut de jointure pour traverser Allen Manhattan 1979 … l’index sur l’autre table • Avantages Fusion – très efficace (un parcours, plus des recherches par adresse) – favorise le temps de réponse et le temps d’exécution Allen !!Annie Hall Annie Hall 1977 Spielberg !!Jurassic Park Brazil 1984 Allen !!Manhattan Easy Rider 1969 Lang !!Metropolis Greystoke 1984 Hitchcock !!Psychose Jurassic Park 1992 Kubrik !!Shining Manhattan 1979 Hitchcock !!Vertigo Metropolis 1926 Psychose 1960 Tri Tri Réalisateur FilmOptimisation – 2010 141 Optimisation – 2010 142
  7. 7. Jointures avec index (2) Plans d’exécution • Avec deux index • Qu’est-ce qu’un plan d’exécution ? – fusionner les deux index : on obtient des paires d’adresse – un programme combinant des opérateurs physiques (chemins d’accès – pour chaque paire, aller chercher la ligne A, la ligne B et traitements de données) • Problématique car beaucoup d’accès aléatoires • Il a la forme d’un arbre : chaque noeud est un opérateur qui • En pratique : – prend des données en entrée – applique un traitement – on se ramène à la jointure avec un index – produit les données traitées en sortie – on prend la petite table comme table de parcours • La phase d’optimisation proprement dite : – pour une requête, le système a le choix entre plusieurs plans d’exécutionOptimisation – 2010 143 Optimisation – 2010 144 Plans d’exécution (2) Exemple • Un plan est composé • Chercher tous les films avec James Stewart, parus en 1958 – d’un plan d’exécution logique (PEL) ! SELECT titre – et un plan d’exécution physique (PEP) ! FROM Film f, Role r, Artiste a • Deux plans diffèrent par ! WHERE a.nom = ’Stewart’ AND a.prenom=’James’ – l’ordre des opérations - PEL (sélection avant jointure,…) ! AND f.idFilm = r.idFilm – les algorithmes - PEP (boucles imbriquées, tri/fusion,…) ! AND r.idActeur = a.idArtiste – les chemins d’accès - PEP (index disponible ou pas,…) ! AND f.annee = 1958 • Pour chaque plan on peut estimer : – le coût de chaque opération • Il y a autant de plans que de «blocs» dans une requête – la taille du résultat • Pas d’imbrication: un seul bloc • Objectif : diminuer le plus vite possible la taille des données manipuléesOptimisation – 2010 145 Optimisation – 2010 146
  8. 8. Exemple: un niveau d’imbrication Exemple: deux niveaux d’imbrication ! SELECT titre ! SELECT titre FROM Film ! FROM Film f, Role r ! WHERE annee = 1958 AND idFilm IN ! WHERE f.idFilm = r.idFilm ! ! (SELECT idFilm FROM Role ! AND f.annee = 1958 ! ! ! WHERE idActeur IN ! ! ! ! (SELECT idArtiste FROM Artiste ! AND r.idActeur IN ! ! ! ! WHERE nom=’Stewart’ ! ! (SELECT idArtiste FROM Artiste ! ! ! ! AND prenom=’James’)) ! ! ! WHERE nom=’Stewart’ ! ! ! AND prenom=’James’) • Mauvais: on force le plan, et il est inefficace – on parcourt tous les films parus en 1958 • Un niveau d’imbrication (inutile): moins bon – pour chaque film, on cherche les rôles du film (pas d’index disponible) – pour chaque rôle on regarde si c’est James Stewart • Bilan: ça va coûter cherOptimisation – 2010 147 Optimisation – 2010 148 Exemples de plans d’exécution Exemples de plans d’exécution (2) Projectiontitre Projectiontitre Sans index sur nom, prénom Avec index sur nom, prénom JointureidFilm=idFilm JointureidFilm=idFilm JointureidActeur=idArtiste Sélection1958 JointureidActeur=idArtiste Sélection1958 SélectionJames Stewart RôleAdresse FilmAdresse ArtisteAdresse RôleAdresse FilmAdresse ArtisteSéquentiel Index Rôle(idActeur,idFilm)idActeur Index Film(idFilm)idFilm Index Artiste(nom,prénom)James Stewart Index Rôle(idActeur,idFilm)idActeur Index Film(idFilm)idFilmOptimisation – 2010 149 Optimisation – 2010 150
  9. 9. Exemples de plans d’exécution (3) Projectiontitre Sans aucun index FusionidActeur=idArtiste Application à Oracle TriidActeur FusionidFilm=idFilm TriidFilm TriidFilm TriidArtiste Sélection1958 SélectionJames Stewart FilmSéquentiel RôleSéquentiel ArtisteSéquentielOptimisation – 2010 151 Optimisation – 2010 152 L’optimiseur Oracle Estimation du coût d’un plan d’exécution • L’optimiseur ORACLE suit une approche classique : • Beaucoup de paramètres entrent dans l’estimation du coût – génération de plusieurs plans d’exécution – les chemins d’accès disponibles – estimation du coût de chaque plan généré – les opérations physiques de traitement des résultats intermédiaires – choix du meilleur et exécution – des statistiques sur les tables concernées (taille, sélectivité) • Tout ceci est automatique, mais il est possible d’influer, voire – les statistiques sont calculées par appel explicite à l’outil ANALYSE de forcer le plan d’exécution – les ressources disponiblesOptimisation – 2010 153 Optimisation – 2010 154
  10. 10. Optimiseur basé sur les règles Optimiseur basé sur les coûts Priorité Description • Principaux paramètres : 1 Accès à un enregistrement par ROWID – OPTIMIZER_MODE (RULE, CHOOSE, FIRST_ROW, ALL_ROWS) 2 Accès à un enregistrement dans un cluster – SORT_AREA_SIZE (taille de la zone de tri) 3 Accès à un enregistrement dans une table de – HASH_AREA_SIZE (taille de la zone de hachage) hachage (hash cluster ) – HASH_JOIN_ENABLED considère les jointures par hachage 4 Accès à un enregistrement par clé unique (avec un index) ... ... 15 Balayage complet de la tableOptimisation – 2010 155 Optimisation – 2010 156 Création des statistiques Chemins d’accès • Calcul de la taille et du nombre de lignes : • Parcours séquentiel (FULL TABLE SCAN) – ANALYSE TABLE Film COMPUTE STATISTICS FOR TABLE • Par adresse (ACCESS BY ROWID) • Analyse des index : • Parcours de regroupement (CLUSTER SCAN) – ANALYSE TABLE Film COMPUTE STATISTICS FOR ALL On récupère alors dans une même lecture les INDEX n-uplets des 2 tables du cluster • Analyse de la distribution des valeurs : • Recherche par hachage (HASH SCAN) – ANALYSE TABLE Film COMPUTE STATISTICS FOR COLUMNS titre, genre SIZE 20 • Parcours d’index (INDEX SCAN)Optimisation – 2010 157 Optimisation – 2010 158
  11. 11. Opérations physiques Algorithmes de jointure de Oracle • Voici les principales : ORACLE utilise trois algorithmes de jointures : – INTERSECTION : intersection de deux ensembles de n-uplets • boucles imbriquées – CONCATENATION : union de deux ensembles – quand il y a au moins un index – FILTER : élimination de n-uplets (sélection) – opération NESTED LOOP – PROJECTION : opération de l’algèbre relationnelle • tri/fusion • D’autres opérations sont liées aux algorithmes de jointures – quand il n’y a pas d’index – opération SORT et MERGE • jointure par hachage – quand il n’y a pas d’index – opération HASH JOINOptimisation – 2010 159 Optimisation – 2010 160 L’outil EXPLAIN Exemples • L’outil EXPLAIN donne le plan d’exécution d’une requête • Sélection sans index EXPLAIN PLAN • La description comprend : SET STATEMENT_ID=’SelSansInd’ FOR – le chemin d’accès utilisé SELECT * FROM Film WHERE titre = ’Vertigo’ – les opérations physiques (tri, fusion, intersection,…) • Le résultat de EXPLAIN : 0 SELECT STATEMENT – l’ordre des opérations   1 TABLE ACCESS FULL FILM • Il est représentable par un arbre • Plan PROJECTION PARCOURS SÉQUENTIEL FILMOptimisation – 2010 161 Optimisation – 2010 162
  12. 12. Exemples (2) Exemples (3) • Sélection avec index • Jointure avec index EXPLAIN PLAN EXPLAIN PLAN SET STATEMENT_ID=’SelInd’ FOR SET STATEMENT_ID=’JoinIndex’ FOR SELECT * FROM Film WHERE idFilm=21; SELECT titre, nom, prenom FROM Film f, Artiste a • Le résultat de EXPLAIN : WHERE idActeur = idArtiste; 0 SELECT STATEMENT • Le résultat de EXPLAIN :   1 TABLE ACCESS BY ROWID FILM 0 SELECT STATEMENT     2 INDEX UNIQUE SCAN IDX-FILM-ID   1 NESTED LOOPS • Plan: accès à l’index, puis à la table     2 TABLE ACCESS FULL FILM PROJECTION     3 TABLE ACCESS BY ROWID ARTISTE PROJECTION       4 INDEX UNIQUE SCAN IDXARTISTE BOUCLES IMBRIQUÉES • Plan ACCÈS DIRECT PARCOURS SÉQUENTIEL ACCÈS DIRECT TRAVERSÉE INDEX RECHERCHE PAR CLÉ FILM FILM idArtiste=idActeur ARTISTE Index FILM Index ARTISTEOptimisation – 2010 163 Optimisation – 2010 164 Exemples (4) Exemples (5) • Jointure avec index et sélection • Plan EXPLAIN PLAN SET STATEMENT_ID=’JoinSelIndex’ FOR SÉLECTION SELECT nomRole FROM Role r, Artiste a WHERE r.idActeur = a.idArtiste JOINTURE AND nom = ’Pacino’; • Le résultat de EXPLAIN : ACCÈS DIRECT ACCÈS DIRECT 0 SELECT STATEMENT   1 NESTED LOOPS RECHERCHE INTERVALLE RECHERCHE INTERVALLE     2 TABLE ACCESS BY ROWID ARTISTE nom=‘Pacino’ ARTISTE idActeur ROLE       3 INDEX RANGE SCAN IDX-NOM     4 TABLE ACCESS BY ROWID ROLE Index NOM Index ROLE       5 INDEX RANGE SCAN IDX-ROLEOptimisation – 2010 165 Optimisation – 2010 166
  13. 13. Exemples (6) Exemples (7) • Jointure sans index • Plan EXPLAIN PLAN SET STATEMENT_ID=’JoinSansIndex’ FOR SELECT nom, prenom SÉLECTION FROM Film f, Artiste a WHERE f.annee = a.anneeNaiss FUSION AND titre = ’Vertigo’; TRI TRI • Le résultat de EXPLAIN : annéeNaissance année 0 SELECT STATEMENT   1 MERGE JOIN PARCOURS SÉQUENTIEL PARCOURS SÉQUENTIEL     2 SORT JOIN       3 TABLE ACCESS FULL ARTISTE ARTISTE FILM     4 SORT JOIN       5 TABLE ACCESS FULL FILMOptimisation – 2010 167 Optimisation – 2010 168 ConclusionOptimisation – 2010 169

×