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
disponibles
Optimisation – 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 physique
Optimisation – 2010 121 Optimisation – 2010 122

2. Un exemple (simpliste) Exemple (2)
• Film (idFilm, titre, année, genre, résumé) • Première étape: plan d'exé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ôle
Optimisation – 2010 123 Optimisation – 2010 124
Exemple (3) Évaluation de performances
• Deuxième étape: plan d'exé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 l'exé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. É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 simpliste
Optimisation – 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. 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 d'agrégation, élimination des doublons,…
– composition
Optimisation – 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. 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 cher
Optimisation – 2010 137 Optimisation – 2010 138

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 Film
Optimisation – 2010 141 Optimisation – 2010 142

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écution
Optimisation – 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ées
Optimisation – 2010 145 Optimisation – 2010 146

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 cher
Optimisation – 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)idFilm
Optimisation – 2010 149 Optimisation – 2010 150

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équentiel
Optimisation – 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 disponibles
Optimisation – 2010 153 Optimisation – 2010 154

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 table
Optimisation – 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. 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 JOIN
Optimisation – 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
FILM
Optimisation – 2010 161 Optimisation – 2010 162

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 ARTISTE
Optimisation – 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-ROLE
Optimisation – 2010 165 Optimisation – 2010 166

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 FILM
Optimisation – 2010 167 Optimisation – 2010 168
Conclusion
Optimisation – 2010 169