Bases de données. Optimisation système d'un SGBD. Olivier Perrin IUT Nancy-Charlemagne Département Informatique Université Nancy 2 Nancy

Transcription

1 Bases de données Optimisation système d'un SGBD Olivier Perrin IUT Nancy-Charlemagne Département Informatique Université Nancy 2 Nancy Olivier.Perrin@loria.fr Optimisation 2006/2007 1

2 Optimisation Plan 1. Stockage Stockage de données Organisation des fichiers Application à Oracle 2. Index Différents types d'index B-Arbre Hachage Application à Oracle 3. Requêtes Introduction et exemple Optimisation logique et physique Application à Oracle Optimisation 2006/2007 2

3 1. Stockage de données Plan Stockage de données: supports, fonctionnement d un disque Organisation des fichiers; champs, enregistrements, blocs, accès Application à Oracle Optimisation 2006/2007 3

4 Mémoires de stockage Un ordinateur possède plusieurs mémoires de stockage mémoire cache mémoire vive disque dur bande Ordres de grandeur Mémoire Taille (Mo) Temps accès (secondes) Cache (10 nanosec.) Vive 10 3 Mo ( nanosec.) Secondaire Mo (Giga) 10-2 (10 millisec.) Tertiaire (Téra) 1 seconde Optimisation 2006/2007 4

5 Impact sur les SGBD Un SGBD doit ranger ses données sur disque (volume important, persistance) Besoin de transférer les données du disque vers la mémoire Les données le plus souvent utilisées devraient résider en mémoire La performance d un SGBD dépend de sa capacité gérer efficacement les transferts disque-mémoire Optimisation 2006/2007 5

6 Organisation physique d un disque Disque surface(s) magnétique stockant des 0 ou des 1 Organisation un disque est divisé en secteurs bloc: ensemble de secteurs, dont la taille est généralement un multiple de 512 piste: ensemble des blocs d une surface lus au cours d une rotation cylindre: ensemble de pistes situées sous les têtes de lecture Optimisation 2006/2007 6

7 Un disque dur Optimisation 2006/2007 7

8 Structure d un disque PISTE BLOCS Tête de lecture Bras Contrôleur DONNÉES CYLINDRE DISQUE Optimisation 2006/2007 8

9 Disque: mémoire à accès direct Adresse = numéro du disque + numéro de la piste + numéro du bloc sur la piste Temps d accès délai de positionnement de la tête sur la piste délai de latence pour attendre que le bloc passe sous la tête temps de transfert pour attendre que le (ou les) bloc(s) soient lus et transférés Attention: on lit toujours au moins un bloc, même si l on veut qu un octet! Optimisation 2006/2007 9

10 Optimisation Première possibilité: le placement des blocs Deuxième possibilité: l ordre des accès Troisième possibilité: la mémoire cache Optimisation 2006/

11 Optimisation: regroupement Exemple: le SGBD doit lire 5 chaînes de 1000 octets position aléatoire des blocs 5 déplacements de tête de lecture + 5 délais de latence position contiguë des blocs 1 déplacement + 1 délai de latence La gain obtenu pour la lecture de d1 et d2 est plus important si les données sont «proches» proximité des données dans le même bloc: 1 seule lecture dans deux blocs consécutifs: 2 lectures successives sur la même piste: 1 rotation du disque sur le même cylindre: pas de déplacement des têtes fonction de l éloignement des pistes: nombre de pistes à parcourir Optimisation 2006/

12 Optimisation: regroupement (2) Pour optimiser la proximité, un SGBD crée un espace disque important à la création d une base Ensuite, il gère lui-même cet espace Par exemple, une table sera stockée sur la même piste ou sur les pistes d un même cylindre Le plus possible, les lectures sont alors séquentielles Optimisation 2006/

13 Optimisation: séquencement Un système doit faire face à plusieurs demandes simultanées l utilisateur A demande la lecture du fichier F1 l utilisateur B demande la lecture du fichier F2 L'entrelacement des demandes entraîne des lectures aléatoires Solution: conserver temporairement dans un cache les demandes, et les réorganiser au mieux Exemple: L(1,16) signifie Lecture du bloc 16 de la piste 1 Optimisation 2006/

14 Optimisation: séquencement (2) Mémoire cache L(1,16) - L(2,23) - L(1,18) - L(2,24) - L(1,17) L(1,16) L(2,23) L(1,18) L(2,24) L(1,17) Contrôleur L(1,16) - L(1,17) - L(1,18) - L(2,23) - L(2,24) Séquenceur Optimisation 2006/

15 Optimisation: buffer Utilisation de mémoires tampon (buffer) Un buffer est un ensemble de blocs en mémoire principale qui sont des copies des blocs sur le disque Lors de la demande d un bloc recherche dans le buffer (accès avec table de hachage) si le bloc est présent, pas de lecture sinon, on effectue la lecture, et on stocke dans le buffer Prefetching: on peut utiliser le buffer pour lire en avance des données (par exemple si on pense que toute une table devra être parcourue lorsqu un bloc est accédé) Optimisation 2006/

16 Organisation des fichiers Optimisation 2006/

17 Les fichiers Une base de données = un ou plusieurs fichiers Un fichier = un ou plusieurs blocs Le SGBD choisit l organisation des fichiers : l espace est-il bien utilisé? est-il facile et efficace de faire une recherche? est-il facile et efficace de faire une mise à jour? les données sont-elles bien représentées, et en sécurité? Tous les SGBD prennent en charge la gestion des fichiers et de leur contenu Optimisation 2006/

18 Les enregistrements Un enregistrement = une suite de champs stockant les valeurs des attributs Exemples: comment stocker un prix, un nom, une date alors que l on ne dispose que des octets Type Taille en octets INTEGER 4 FLOAT 4 DOUBLE PRECISION 8 DECIMAL(M,D) M, (D+2 si M < D) CHAR(M) M VARCHAR(M) L+1 avec L M Optimisation 2006/

19 Taille variable, valeur NULL Si tous les champs sont de taille fixe et ont une valeur: pas de problème En pratique : certains champs ont une taille variable ou peuvent être à (NULL) pour les champs de taille variable : on précède la valeur par la taille exacte pour les valeurs NULL: on peut indiquer une taille 0 (Oracle) La norme n impose pas de choix, mais dans tous les cas il faut gérer une information complémentaire sur les enregistrements Optimisation 2006/

20 Entête d un enregistrement Les informations complémentaires sont stockées dans l entête d un enregistrement Exemple : table Film (id INT, titre VARCHAR(50), année INT) enregistrement (123, vertigo, NULL) ENTÊTE ID TITRE v e r t i g o pointeur taille masque pointeur: adresse du schéma de la table taille: masque: dernier attribut à NULL Optimisation 2006/

21 Blocs et enregistrements On essaie d éviter qu un enregistrement chevauche deux blocs On veut envisager le cas où la taille d un enregistrement varie On veut adresser un enregistrement pour pouvoir y accéder en une seule lecture Comment gérer un déplacement Les deux derniers problèmes sont particulièrement cruciaux pour l indexation des enregistrements Optimisation 2006/

22 Enregistrements de taille fixe Pour une taille de bloc B et d enregistrement E, on a B/E enregistrements par bloc Exemple B = 4096, E = octets pour stocker des informations sur le bloc ( )/84 = 47 enregistrements dans un bloc L enregistrement 563 est dans le bloc 563/47 +1 = 12 Le bloc 12 contient les enregistrements 11*47+1 = 517 à 12*47 = 564 Le 563 est donc l avant-dernier du bloc Optimisation 2006/

23 Enregistrements de taille fixe (2) Référencement d'un enregistrement première solution adresse physique: référencement de l'enregistrement F l'enregistrement est référencé par le fichier + le bloc + la position dans le bloc deuxième solution (pour mieux gérer les déplacements) adresse logique F1 12 ADRESSE LOGIQUE ADRESSE PHYSIQUE 46 #90887 F Optimisation 2006/

24 Solution intermédiaire On a un adressage physique pour le bloc: F1.12 Au sein du bloc on a une indirection (adressage logique) pour adresser les enregistrements Solution adoptée par Oracle Entête Espace libre Bloc F Indirection Enregistrements Optimisation 2006/

25 Enregistrements de taille variable On agrandit deux fois successivement l enregistrement F Bloc F Bloc F Bloc F Agrandissement de 46 Déplacement de 46 Optimisation 2006/

26 Réorganisation du stockage L adressage indirect donne une certaine souplesse : si un enregistrement s agrandit, mais qu il reste de la place dans le bloc : une réorganisation interne suffit sinon on le déplace et on crée un chaînage dans l entête du bloc Mais la création de chaînage pénalise les performances si possible laisser de l espace libre dans un bloc Optimisation 2006/

27 Organisation dans un fichier Pour un SGBD, un fichier, c est une liste de blocs regroupés sur certaines pistes ou répartis aléatoirement et chaînés entre eux Une bonne organisation a pour but de minimiser l espace: peu d espace vide le temps: les opérations (recherche, insertion, mise à jour, suppression) sur le fichier sont efficaces Explications sur un fichier séquentiel Optimisation 2006/

28 Recherche dans un fichier En l absence d index approprié, le seul moyen de rechercher un enregistrement est de parcourir séquentiellement le fichier La performance du parcours est conditionnée par : la bonne utilisation de l espace (idéalement tous les blocs sont pleins) le stockage le plus contigu possible (même piste, même cylindre, ) On peut faire beaucoup mieux si le fichier est trié sur la clé de recherche (recherche par dichotomie) Optimisation 2006/

29 Mise à jour, suppression, insertion Pour les UPDATE et DELETE : on se ramène à une recherche Pour les INSERT, problème! trouver un bloc avec un espace libre suffisant on ne peut pas se permettre de parcourir le fichier à chaque fois! Première solution : liste doublement chaînée des blocs libres pb: pas d indication sur l espace disponible dans le bloc Optimisation 2006/

30 Mise à jour, suppression, insertion (2) Seconde solution : garder une table des blocs libres Libre (O/N) O N Espace 123 Adresse O Avantage : on peut savoir facilement où trouver l espace nécessaire Optimisation 2006/

31 Application à Oracle Optimisation 2006/

32 Oracle Principales structures logiques dans ORACLE : bloc unité d échange entre mémoire et disque la taille d un bloc ORACLE est un multiple de la taille des blocs du système sous-jacent (bloc physique) extension ensemble de blocs contigus contenant un même type d information segment ensemble d extensions stockant un objet logique (une table, un index...) tablespace contient les tables, les index, du schéma et conserve les données dans les datafiles Optimisation 2006/

33 Oracle (2) Il existe quatre types de segments : les segments de données (data segments) les segments d index (index segments) les segments utilisés pour les transactions (rollback segments) les segments temporaires, par exemple pour les tris (temporary segments) Moins il y a d extensions dans un segment, plus il est efficace Le paramétrage du stockage des données (tables et index) est spécifié dans le tablespace Optimisation 2006/

34 Tables, segments, extensions et blocs Table (e.g. Film) Logique Physique Segment Extension Blocs Oracle Disques Select * from DBA_EXTENT; Optimisation 2006/

35 Les blocs Oracle La structure d un bloc repose sur un adressage physique/ logique, chaque enregistrement ayant une adresse interne Entête (@ du bloc, type du segment, ) Tables représentées dans le bloc Bloc Oracle Adresses des enregistrements Espace libre Enregistrements Un chaînage est créé quand il faut déplacer un enregistrement Optimisation 2006/

36 Gestion de l espace PCTFREE donne l espace libre à préserver au moment de la création d une table ou d un index PCTUSED indique à quel moment le bloc est disponible pour des insertions Oracle maintient un répertoire des blocs disponibles pour insertions Exemple : PCTFREE = 30% et PCTUSED = 70% PCTFREE = 10% et PCTUSED = 80% le second choix est plus efficace, mais plus risqué et plus coûteux Optimisation 2006/

37 Stockage et adressage des enregistrements En règle générale un enregistrement est stocké dans un seul bloc L adresse physique d un enregistrement est le ROWID: le numéro du bloc dans le fichier le numéro de l'enregistrement dans le bloc l'identifiant du fichier Exemple : 00000DD est l adresse du premier enregistrement du bloc DD5 dans le premier fichier. Optimisation 2006/

38 Tablespaces Une base est divisée par l administrateur en tablespaces Chaque tablespace consiste en un (au moins) ou plusieurs fichiers de données (datafiles) La notion de tablespace permet : de contrôler l emplacement physique des données (par exemple: le dictionnaire sur un disque, les données utilisateur sur un autre) de régler l allocation de l espace (extensions) de faciliter la gestion (sauvegarde, protection,etc) Optimisation 2006/

39 Exemple de tablespaces Tablespace 1 Tablespace 2 TABLE A INDEX TABLE C TABLE B DICTIONNAIRE Datafile Structure physique associée à un et un seul tablespace Datafile Structure physique associée à un et un seul tablespace Datafile Structure physique associée à un et un seul tablespace Select * from DBA_DATA_FILES; Optimisation 2006/

40 Création de tablespaces CREATE TABLESPACE TB1 DATAFILE fichiertb1.dat SIZE 50M DEFAULT STORAGE ( INITIAL 100K, NEXT 40K, MAXEXTENTS 20, PCTINCREASE 20); CREATE TABLESPACE TB2 DATAFILE fichiertb2.dat SIZE 2M AUTOEXTEND ON NEXT 5M MAXSIZE 500M DEFAULT STORAGE (INITIAL 128K NEXT 128K MAXEXTENTS UNLIMITED); Optimisation 2006/

41 Gestion d un tablespace Quelques actions disponibles sur un tablespace : on peut mettre un tablespace hors-service ALTER TABLESPACE TB1 OFFLINE; on peut mettre un tablespace en lecture seule ALTER TABLESPACE TB1 READ ONLY; on peut ajouter un nouveau fichier ALTER TABLESPACE ADD DATAFILE fichiertb1-2.dat SIZE 300 M; Optimisation 2006/

42 Affectation de tables à un tablespace On peut placer une table dans un tablespace. Elle prend alors les paramètres de stockage de ce dernier On peut aussi remplacer certaines valeurs CREATE TABLE Film (...) PCTFREE 10 PCTUSED 40 TABLESPACE TB1 STORAGE ( INITIAL 50K NEXT 50K MAXEXTENTS 10 PCTINCREASE 25 ); Optimisation 2006/

43 Consultations -- Tablespaces Select * from user_tablespaces; -- place libre dans les tablespaces Select * from user_free_space; -- segments Select * from user_segments; -- extensions Select * from user_extents; Optimisation 2006/

44 2. Indexation Plan Indexation de fichiers: différentes structures d index B Arbres: structure et algorithmes Hachage: principes Application à Oracle Optimisation 2006/

45 Pourquoi indexer? En l absence d un index, les seules solutions sont: un parcours séquentiel (complexité linéaire) la recherche par dichotomie si le fichier est trié (complexité logarithmique) Avec un index : parcours de l index, puis accès direct à l enregistrement mais attention: les mises à jour sont plus coûteuses Optimisation 2006/

46 Exemple Titre Année Titre Année Vertigo 1958 Annie Hall 1977 Brazil 1984 Jurassic Park 1992 Twin Peaks 1990 Metropolis 1926 Underground 1995 Manhattan 1979 Easy Rider 1969 Reservoir Dogs 1992 Psychose 1960 Impitoyable 1992 Greystoke 1984 Casablanca 1942 Shining 1980 Smoke 1995 La table Films, c est : de films un enregistrement = 120 octets un bloc = 4K 34 enregistrements par bloc environ blocs, 120 Mo Optimisation 2006/

47 Concepts Clé (au sens critère) de recherche liste d un ou plusieurs attributs sur lesquels portent les critères de sélection exemple: titre du film (clé primaire), année du film, titre + année Types de recherche recherche par clé: une valeur à chaque attribut de la clé rechercher Vertigo recherche par intervalle: un intervalle de valeurs à chaque attribut de la clé rechercher les films parus entre 1960 et 1975 recherche par préfixe: une valeur à un préfixe de la clé rechercher les films commençant par V Optimisation 2006/

48 Index non-dense Hypothèse: fichier trié sur la clé Un index, c est: un fichier les enregistrements (ou entrées) de l index sont sous la forme <valeur, adresse> valeur est une valeur de la clé adresse est la position du premier bloc du disque contenant un enregistrement avec cette valeur le fichier est trié sur valeur un seul enregistrement par bloc du fichier de données est représenté dans le fichier d index Optimisation 2006/

49 Exemple Annie Hall Annie Hall 1977 Brazil 1984 Casablanca 1942 Easy Rider 1969 Greystoke 1984 Jurassic Park 1992 Impitoyable 1992 Manhattan 1979 Greystoke Metropolis Smoke Metropolis 1926 Psychose 1960 Reservoir Dogs 1992 Shining 1980 Smoke 1995 Twin Peaks 1990 Underground 1995 Vertigo 1958 Recherche: Par clé : par dichotomie sur l index Par intervalle : recherche de la borne inférieure, accès au fichier, parcours séquentiel Par préfixe : cas particulier de la recherche par intervalle Optimisation 2006/

50 Combien ça coûte? Sur notre fichier de 120 Mo en supposant qu un titre occupe 20 octets, une adresse 8 octets, blocs taille de l index : * (20 + 8) = octets Beaucoup plus petit que le fichier! avantages maximum sur la recherche par dichotomie peut tenir en mémoire problèmes maintenir l ordre sur le fichier et sur l index (notamment au cours des insertions et suppressions) ne peut porter que sur une seule clé Optimisation 2006/

51 Index dense Si on veut indexer un fichier non trié? l index est toujours un fichier il est toujours trié sur la clé mais tous les enregistrements sont représentés L index est dit dense Optimisation 2006/

52 Exemple Annie Hall 1977 Brazil 1984 Casablanca 1942 Easy Rider 1969 Greystoke 1984 Jurassic Park 1992 Impitoyable 1992 Manhattan 1979 Metropolis 1926 Psychose 1960 Reservoir Dogs 1992 Shining 1980 Smoke 1995 Twin Peaks 1990 Underground 1995 Vertigo 1958 Recherche: par clé : comme sur un index non-dense par intervalle (exemple [1950, 1979]) : recherche dans l index de la borne inférieure parcours séquentiel dans l index pour chaque valeur, accès au fichier de données coût beaucoup plus élevé Optimisation 2006/

53 Combien ça coûte? Sur notre fichier de 120 Mo une année = 4 octets, une adresse 8 octets taille de l index : * (4 + 8) = 12 Mo Seulement dix fois plus petit que le fichier la taille d un index ne doit pas être négligée Optimisation 2006/

54 Index multi-niveaux Si l index est trop gros? On l indexe à son tour essentiel: l index est trié, donc on peut l indexer par un second niveau non-dense sinon ça ne servirait à rien donc dès le second niveau on diminue drastiquement la taille on peut continuer jusqu à un niveau avec un seul bloc On obtient une structure séquentielle indexée Optimisation 2006/

55 Exemple Annie Hall 1977 Brazil 1984 Casablanca 1942 Easy Rider 1969 Greystoke 1984 Jurassic Park 1992 Impitoyable 1992 Manhattan 1979 Metropolis 1926 Psychose 1960 Reservoir Dogs 1992 Shining 1980 Smoke 1995 Twin Peaks 1990 Underground 1995 Vertigo 1958 Optimisation 2006/

56 Remarques Il ne peut y avoir qu un index non-dense sur un fichier un index non-dense s appuie sur le tri du fichier et le fichier ne peut être trié que d une seule manière Par contre, il peut y avoir autant d index dense que l on veut ils sont indépendants du fichier de données Optimisation 2006/

57 Arbres B Optimisation 2006/

58 Arbre B Aboutissement des structures d index basées sur l ordre des données c est un arbre équilibré (chaque nœud est à égale distance de la racine) chaque noeud est un bloc de <valeur, adresse> il se réorganise dynamiquement Utilisé universellement! Optimisation 2006/

59 Exemple Un arbre, avec trois niveaux, une racine, les enregistrements répartis dans les noeuds Easy Rider Psychose Brazil Jurassic Park Shining Twin Peaks Annie Hall Casablanca Greystoke Manhattan Reservoir Dogs Smoke Underground Impitoyable Metropolis Vertigo Les recherches sont guidées par l ordre dans chaque noeud Optimisation 2006/

60 Nœud d un arbre B Un noeud est un index local, les enregistrements servant de clé (pas de clés aux feuilles), intercalés avec des pointeurs C < C1 C1 E1 C2 E2 Cn En C1 C < C2 P 1 P 2 P n P n+1 Le sous-arbre pointé par P 2 contient tous les enregistrements dont la clé est comprise entre C 1 et C 2 2n clés par bloc, 2n+1 sous-arbres Optimisation 2006/

61 Construction d un arbre B On suppose qu on ne peut mettre que deux enregistrements par bloc (n=1) Voici le premier bloc de l arbre Brazil Vertigo Optimisation 2006/

62 Construction d un arbre B Ici le bloc déborde. On prend l élément du milieu pour le monter dans un nouveau noeud Nouveau nœud Brazil Twin Peaks Vertigo Optimisation 2006/

63 Construction d un arbre B Après répartition des enregistrements Twin Peaks Brazil Vertigo Optimisation 2006/

64 Construction d un arbre B Après insertion de Underground et Easy Rider Twin Peaks Brazil Easy Rider Underground Vertigo Maintenant il faut mettre Psychose Optimisation 2006/

65 Construction d un arbre B Insertion de Psychose: le noeud déborde, et l élément du milieu doit monter Twin Peaks Brazil Easy Rider Psychose Underground Vertigo Optimisation 2006/

66 Construction d un arbre B Après remontée de Easy Rider, et répartition des autres enregistrements Easy Rider Twin Peaks Brazil Psychose Underground Vertigo Optimisation 2006/

67 Construction d un arbre B On insère Greystoke: ça marche Easy Rider Twin Peaks Brazil Greystoke Psychose Underground Vertigo Maintenant il faut mettre Shining Optimisation 2006/

68 Construction d un arbre B On insère Shining : ça déborde Easy Rider Twin Peaks Brazil Greystoke Psychose Shining Underground Vertigo Optimisation 2006/

69 Construction d un arbre B On a remonté Psychose, mais maintenant c est la racine qui déborde Easy Rider Psychose Twin Peaks Brazil Greystoke Shining Underground Vertigo Optimisation 2006/

70 Construction d un arbre B Alors on a créé une nouvelle racine Il faut insérer Annie Hall et Jurassic Park Psychose Easy Rider Twin Peaks Brazil Greystoke Shining Underground Vertigo Optimisation 2006/

71 Construction d un arbre B On a inséré sans problème Annie Hall et Jurassic Park Psychose Easy Rider Twin Peaks Annie Hall Brazil Greystoke Jurassic Park Shining Underground Vertigo Maintenant il faut insérer Metropolis Optimisation 2006/

72 Ça déborde encore Construction d un arbre B Psychose Easy Rider Twin Peaks Annie Hall Brazil Greystoke Jurassic Park Metropolis Shining Underground Vertigo Optimisation 2006/

73 Après réorganisation Construction d un arbre B Psychose Easy Rider Jurassic Park Twin Peaks Annie Hall Brazil Greystoke Metropolis Shining Underground Vertigo Il faut insérer Manhattan, Reservoir Dogs et Impitoyable Optimisation 2006/

74 Construction d un arbre B On a inséré Manhattan, Reservoir Dogs et Impitoyable Psychose Easy Rider Jurassic Park Twin Peaks Annie Hall Brazil Greystoke Impitoyable Manhattan Metropolis Reservoir Dogs Shining Underground Vertigo Au tour de Casablanca Optimisation 2006/

75 Ça déborde à nouveau Construction d un arbre B Psychose Easy Rider Jurassic Park Twin Peaks Annie Hall Brazil Casablanca Greystoke Impitoyable Manhattan Metropolis Reservoir Dogs Shining Underground Vertigo Optimisation 2006/

76 On remonte d un niveau Construction d un arbre B Psychose Brazil Easy Rider Jurassic Park Twin Peaks Annie Hall Casablanca Greystoke Manhattan Reservoir Dogs Underground Impitoyable Metropolis Shining Vertigo Optimisation 2006/

77 On a inséré dans la racine Construction d un arbre B Easy Rider Psychose Brazil Jurassic Park Twin Peaks Annie Hall Casablanca Greystoke Manhattan Reservoir Dogs Underground Impitoyable Metropolis Shining Vertigo Il reste Smoke Optimisation 2006/

78 Construction d un arbre B Ça déborde encore et toujours Easy Rider Psychose Brazil Jurassic Park Twin Peaks Annie Hall Casablanca Greystoke Manhattan Reservoir Dogs Underground Impitoyable Metropolis Shining Vertigo Smoke Optimisation 2006/

79 Le résultat final! Construction d un arbre B Easy Rider Psychose Brazil Jurassic Park Shining Twin Peaks Annie Hall Casablanca Greystoke Manhattan Reservoir Dogs Smoke Underground Impitoyable Metropolis Vertigo Taux de remplissage: 16/(11*2) = 72% Optimisation 2006/

80 Arbre B+ Inconvénient de l arbre B il est plaçant (un seul par fichier) les enregistrements sont déplacés pendant la construction (pb d adressage) suppression compliquée L arbre B+ est une variante non plaçante il est construit uniquement sur les clés toutes les clés sont conservées dans les feuilles dans les feuilles, à chaque clé est associée l adresse de l enregistrement feuilles liées entre elles (recherche par intervalle) Optimisation 2006/

81 Exemple Easy Rider Manhattan Shining Index Annie Hall Brazil Casablanca Easy Rider C Easy Rider Greystoke Impitoyable Jurassic Park Manhattan Easy Rider < C C Manhttan Metropolis Psychose Reservoir Dogs Shining Smoke Twin Peaks Underground Vertigo Données Vertigo 1958 Brazil 1984 Twin Peaks 1990 Underground 1995 Easy Rider 1969 Psychose 1960 Greystoke 1984 Shining 1980 Annie Hall 1977 Jurassic Park 1992 Metropolis 1926 Manhattan 1979 Reservoir Dogs 1992 Impitoyable 1992 Casablanca 1942 Smoke 1995 Optimisation 2006/

82 Autre exemple Index Données Vertigo 1958 Brazil 1984 Twin Peaks 1990 Underground 1995 Easy Rider 1969 Psychose 1960 Greystoke 1984 Shining 1980 Annie Hall 1977 Jurassic Park 1992 Metropolis 1926 Manhattan 1979 Reservoir Dogs 1992 Impitoyable 1992 Casablanca 1942 Smoke 1995 Optimisation 2006/

83 Recherche par clé SELECT * FROM Film WHERE titre = Impitoyable on lit la racine de l arbre: Impitoyable étant situé dans l ordre lexicographique entre Easy Rider et Manhattan, on doit suivre le chaînage situé entre ces deux titres on lit le bloc feuille dans lequel on trouve le titre Impitoyable associé à l adresse de l enregistrement dans le fichier des données il reste à lire l enregistrement Optimisation 2006/

84 Recherche par intervalle SELECT * FROM Film WHERE annee BETWEEN 1960 AND 1975 on fait une recherche par clé pour l année 1960 on parcourt les feuilles de l arbre en suivant le chaînage, jusqu à l année 1975 à chaque fois on lit l enregistrement Attention, les accès aux fichiers peuvent coûter très cher Optimisation 2006/

85 Recherche par préfixe SELECT * FROM Film WHERE titre LIKE M% revient à une recherche par intervalle SELECT * FROM Film WHERE titre BETWEEN MAAAAAA... AND MZZZZZZ... contre-exemple : SELECT * FROM Film WHERE titre LIKE %e Ici l index est inutilisable Optimisation 2006/

86 Capacité d un arbre B+ Avec un niveau d index (la racine seulement), on peut donc référencer 146 films Avec deux niveaux, on indexe 146 blocs de 146 films chacun, soit = films Avec trois niveaux, on indexe = films Enfin avec quatre niveaux, on indexe plus de 450 millions de films. L efficacité d un arbre B+ dépend de la taille de la clé: plus elle est petite, plus l index sera petit et efficace Optimisation 2006/

87 Efficacité de l arbre B+ Il est (presque) parfait! on a très rarement besoin de plus de trois niveaux le coût d une recherche par clé est le nombre de niveaux, plus 1 supporte les recherches par clé, par intervalle, par préfixe dynamique On peut juste lui reprocher d occuper de la place Optimisation 2006/

88 Synthèse arbre B+ Autant d arbres B+ que l on souhaite (titre, année, ) Très rarement besoin de plus de 4 niveaux Coût d une recherche par clé est faible Support des recherches par clé, par intervalle ou par préfixe Dynamique Par contre, taille potentiellement importante Optimisation 2006/

89 Hachage Optimisation 2006/

90 Présentation Un concurrent de l arbre-b+ meilleur pour les recherches par clé n occupe aucune place Mais se réorganise difficilement ne supporte pas les recherches par intervalle Optimisation 2006/

91 Principe On calcule la position d un enregistrement d après la clé une fonction de hachage h associe des valeurs de clé à des adresses de bloc h doit répartir uniformément les enregistrements dans les n blocs alloués à la structure Recherche d un enregistrement calcul de l endroit où il se trouve Simple et efficace! Optimisation 2006/

92 Exemple On veut créer une structure de hachage pour nos 16 films (hypothèse : 4 enregistrements par bloc) on alloue 5 blocs (pour garder une marge de manœuvre) un répertoire à 5 entrées (0 à 4) pointe vers les blocs on définit la fonction h(titre) = rang Alphabet (titre[0]) mod 5 Entrées Répertoire Blocs Jurassic Park 1992 Twin Peaks 1990 Easy Rider 1969 Impitoyable 1992 Shining 1980 Smoke 1995 Annie Hall 1977 Underground 1995 Psychose 1960 Brazil 1984 Vertigo 1958 Greystoke 1984 Manhattan 1979 Metropolis 1926 Casablanca 1942 Reservoir Dogs 1992 Optimisation 2006/

93 Par clé: possible Recherches SELECT * FROM Film WHERE titre = Impitoyable Par préfixe: ici, possible SELECT * FROM Film WHERE titre LIKE M% Par intervalle: non! SELECT * FROM Film WHERE titre BETWEEN Annie Hall AND Easy Rider Optimisation 2006/

94 Mises à jour Plus délicat La structure simple décrite précédemment n est pas dynamique On ne peut pas changer un enregistrement de place Donc il faut créer un chaînage de blocs quand un bloc déborde Et donc les performances se dégradent... Optimisation 2006/

95 Exemple Insertion de Citizen Kane, 1941 Entrées Répertoire Blocs Jurassic Park 1992 Twin Peaks 1990 Easy Rider 1969 Impitoyable 1992 Shining 1980 Smoke 1995 Annie Hall 1977 Underground 1995 Psychose 1960 Brazil 1984 Vertigo 1958 Greystoke 1984 Manhattan 1979 Metropolis 1926 Casablanca 1942 Reservoir Dogs 1992 Citizen Kane 1941 Optimisation 2006/

96 Hachage dynamique Objectif : réorganiser la table de hachage en fonction des insertions et suppressions le nombre d entrées dans le répertoire est une puissance de 2 la fonction h donne toujours un entier sur 4 octets (32 bits) Idée de base: on utilise les n premiers bits du résultat de la fonction, avec n < 32 Optimisation 2006/

97 Exemple Hachage des 16 films titre h(titre) Vertigo Brazil Twin Peaks Underground Easy Rider Psychose Greystoke Shining Optimisation 2006/

98 Construction de la table An départ, on utilise seulement le premier bit de la fonction deux valeurs possibles : 0 et 1 donc deux entrées, et deux blocs l affectation d un enregistrement dépend du premier bit de sa fonction de hachage Pour l instant, on reste dans un cadre classique Optimisation 2006/

99 Avec 5 films Brazil Twin Peaks Vertigo Underground Psychose Underground Easy Rider Vertigo Easy Rider Brazil Twin Peaks Supposons 3 films par bloc L'insertion de Psychose (valeur ) entraîne le débordement du premier bloc on double la taille du répertoire on alloue un nouveau bloc pour l'entrée 01 Les entrées 10 et 11 pointent sur le même bloc On agrandit seulement ce qui est nécessaire Optimisation 2006/

100 Insertions suivantes Plusieurs cas on insère dans un bloc plein, mais plusieurs entrées pointent dessus on alloue un nouveau bloc, et on répartit les pointeurs on insère dans un bloc plein, associé à une entrée on double à nouveau le nombre d entrées Problème : le répertoire peut devenir très grand Optimisation 2006/

101 Exemple On insère Greystoke et Shining Easy Rider Vertigo Underground Psychose Brazil Greystoke Twin Peaks Shining Optimisation 2006/

102 Comparaison hachage/arbre-b La hachage, intéressant quand : le jeux de données est figé les recherches se font par clé Ce sont des situations relativement courantes: le hachage n occupe alors pas de place Sinon l arbre-b est meilleur Optimisation 2006/

103 Index bitmap Optimisation 2006/

104 Le problème Comment indexer une table sur un attribut qui ne prend qu un petit nombre de valeurs? avec un arbre B: pas très bon car chaque valeur est peu sélective avec un hachage : pas très bon non plus car il y a beaucoup de collisions Or situation fréquente, notamment dans les entrepôts de données Optimisation 2006/

105 Exemple Codification des films rang titre genre... 1 Vertigo Suspense... 2 Brazil Science-Fiction... 3 Twin Peaks Fantatisque 4 Underground Drame 5 Easy Rider Drame... 6 Psychose Drame... 7 Greystoke Aventures... 8 Shining Fantastique Optimisation 2006/

106 Principes de l index bitmap Soit un attribut A, prenant n valeurs possibles [v 1,,v n ] on crée n tableaux de bit, un pour chaque valeur v i ce tableau contient un bit pour chaque enregistrement e le bit d un enregistrement e est à 1 si e.a = v i est à 0 sinon Optimisation 2006/

107 Exemple Drame Science-Fiction Comédie Optimisation 2006/

108 Soit la requête Recherche SELECT * FROM Film WHERE genre= Drame on prend le tableau pour la valeur Drame on garde toutes les cellules à 1 on accède aux enregistrements par l adresse très efficace si n, le nombre de valeurs, est petit Optimisation 2006/

109 Autre recherche SELECT COUNT(*) FROM Film WHERE genre IN ( Drame, Comédie ) on compte le nombre de 1 dans le tableau Drame on compte le nombre de 1 dans le tableau Comédie on fait la somme et c est fini! Optimisation 2006/

110 Application à Oracle Optimisation 2006/

111 Les choix d Oracle Oracle propose à peu près toutes les structures d index vues précédemment par défaut l index est un arbre B+ il est possible d organiser une table en arbre B (plaçant) le hachage (non dynamique) existe aussi les index bitmap aussi Optimisation 2006/

112 Arbres B et B+ Dès qu on utilise une commande PRIMARY KEY, Oracle crée un arbre B+ sur la clé primaire l arbre est stocké dans un segment d index On peut organiser la table en arbre B avec l option ORGANIZATION INDEX plus efficace car évite les accès par adresse moins valable pour les enregistrements de grande taille Optimisation 2006/

113 Hachage Structure appelée Hash Cluster Utilisée en deux étapes on crée la structure avec tous ses paramètres on affecte une ou plusieurs tables à la structure Attention, le hachage dans Oracle n est pas dynamique Optimisation 2006/

114 Création d un Hash Cluster CREATE CLUSTER HachFilms (id INT) SIZE 500 HASHKEYS 500; la clé de hachage est de type INTEGER ; Oracle fournit automatiquement une fonction avec de bonnes propriétés nombre de valeurs de la fonction donné par HASHKEYS taille de chaque entrée estimée par SIZE dans l exemple ci-dessus, 8 entrées par bloc Optimisation 2006/

115 Affectation à un Hash Cluster On indique la structure d affectation dans la commande CREATE TABLE CREATE TABLE Film (idfilm INT,... ) CLUSTER HachFilms (idfilm) Assez délicat à paramétrer Demande un contrôle régulier par un DBA Optimisation 2006/

116 Les clusters Le cluster (regroupement) est une structure permettant d optimiser les jointures Par exemple, pour les tables Cinéma et Salle qui sont fréquemment jointes sur l attribut idcinema : on groupe les n-uplets de Cinéma et de Salle ayant même valeur pour l attribut idcinema on stocke ces groupes de n-uplets dans les blocs d un segment spécial de type cluster on crée un index sur idcinema Optimisation 2006/

117 Exemple Clé de regroupement (idcinéma) nomcinéma Adresse 1209 Le Rex 2 Bd Italiens idsalle nomsalle Capacité 1098 Grande Salle Salle Salle nomcinéma Adresse Kino 243 Bd Raspail idsalle nomsalle Capacité 340 Salle Optimisation 2006/

118 3. Optimisation Plan Introduction et exemple Optimisation logique et physique Application à Oracle Optimisation 2006/

119 Que veut-on optimiser? On peut en fait définir plusieurs critères : temps d exécution : temps total d exécution, souvent utilisé comme critère par défaut temps de réponse : temps pour obtenir la première ligne du résultat. À 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 2006/

120 Optimisation d une requête Deux techniques d optimisation algébrique/logique on représente la requête sous forme d arbre on applique les transformations statistique/physique on estime le coût d exécution en prenant en compte les opérations à effectuer (sélections, jointures) les index disponibles la taille des relations On obtient un plan d exécution, composé: du plan d exécution logique (PEL) et du plan d exécution physique (PEP) Optimisation 2006/

121 Étapes Requête SQL analyse Arbre traduction règles Plan d exécution logique exécution Réponse estimation de la taille du résultat PEL amélioré statistiques PEP i sélection du meilleur plan PEL + taille prise en compte des plans physiques estimation des coûts {PEP 1, PEP 2, } PEP: Plan d exécution physique {(PEP 1,C 1 ),(PEP 2,C 2 ), } Optimisation 2006/

122 Un exemple (trop simple) Film (idfilm, titre, année, genre, résumé) Artiste (idartiste, nom, prénom, annéenaissance) Rôle (idartiste, idfilm, nomrôle) SELECT nom FROM Artiste A, Rôle R WHERE R.idArtiste = A.idArtiste AND idfilm=20; On suppose Artiste = 100 n-uplets, et Rôle = 500 n-uplets Optimisation 2006/

123 Exemple (2) Première étape: plan d'exécution logique les stratégies possibles (entre autres) ((A join R) where idfilm=20)[nom] (A join (R where idfilm=20))[nom] π nom π nom σ idfilm=20 idartiste idartiste Artiste σ idfilm=20 Artiste Rôle Rôle Optimisation 2006/

124 Exemple (3) Deuxième étape: plan d'exécution physique les opérations à effectuer les sélections (idfilm = 20) les jointures (idartiste) Troisième étape: coût de l'exécution physique quels sont les index dont on dispose? Optimisation 2006/

125 Évaluation de performances Soient T la taille du résultat intermédiaire T {T} le nombre de n-uplets examinés pour produire T Stratégie 1: ((A join R) where idfilm=20)[nom] T = A join R R = 500 T = T where idfilm=20 = 5 (en moyenne) T = T [nom] 5 {T} 100 * 500 = (boucles imbriquées) {T } = 500 {T } = 5 (en moyenne) Optimisation 2006/

126 Évaluation de performances (2) Stratégie 2: (A join (R where idfilm=20))[nom] T = R where idfilm=20 = 5 (en moyenne) T = A join T T = 5 T = T [nom] 5 {T} 500 {T } 500 {T } 5 Optimisation 2006/

127 Comparaison Stratégie 2 plus efficace que stratégie 1 En ce qui concerne la mémoire taille max stratégie 1: 500 taille max stratégie 2: 5 gain: 99% En ce qui concerne le CPU nombre de n-uplets visités stratégie 1: nombre de n-uplets visités stratégie 2: 1005 gain: 98% Attention, l exemple présenté est très simpliste Optimisation 2006/

128 Optimisation logique et physique Optimisation 2006/

129 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)) 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 2006/

130 Optimisation logique En français séparer les sélections avec plusieurs prédicats en plusieurs sélections à un prédicat descendre les sélections le plus bas possible dans l arbre (pour minimiser les jointures) regrouper les sélections sur une même relation distribuer les sélections sur les jointures, les unions, les différences descendre les projections le plus bas possible regrouper les projections sur une même relation Il en existe d autres fonction d'agrégation, élimination des doublons, composition Optimisation 2006/

131 Exécution logique Chercher tous les films avec James Stewart, parus en 1958 SELECT titre FROM Film f, Role r, Artiste a WHERE a.nom = Stewart AND a.prenom= James AND f.idfilm = r.idfilm AND r.idacteur = a.idartiste AND f.annee = 1958 Optimisation 2006/

132 Exemple Première requête π 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 2006/

133 Optimisation physique Les sélections Les jointures Optimisation 2006/

134 La sélection Deux possibilités pour accéder à un enregistrement Accès séquentiel (balayage): parcours de tous les enregistrements du fichier on lit, bloc par bloc, le fichier quand un bloc est en mémoire, on traite les enregistrements qu il contient opération coûteuse si la table est grosse il faut limiter la taille (compactage, choix de types plus petits) il faut effectuer des lectures contiguës Optimisation 2006/

135 La sélection (2) Accès par adresse: si on connaît l adresse du ou des enregistrements concernés, on peut aller lire directement les blocs et obtenir ainsi un accès optimal opération en deux étapes : on obtient l adresse des enregistrements à rechercher (en général avec un index) avec cette adresse on va chercher le bloc, et on lit l enregistrement très performant : une ou deux lectures suffisent en général (pour un enregistrement) Optimisation 2006/

136 Coût Le fichier fait 500 Mo, une lecture de bloc prend 0,01 s (10 millisecondes) Un parcours séquentiel lira tout le fichier (ou la moitié pour une recherche par clé) soit 5 secondes Une recherche par index implique 2 ou 3 accès pour 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 plus cher Optimisation 2006/

137 Les jointures Jointure sans index le plus simple : jointure par boucles imbriquées le plus courant : jointure par tri-fusion parfois le meilleur : jointure par hachage (pas détaillée ici) Jointure avec index avec un index : jointure par boucles indexées avec deux index : on fait comme si on avait un seul index Optimisation 2006/

138 Jointures sans index Boucles imbriquées: bête et méchant Comparaison Association Vertigo 1958 Annie Hall 1977 Spielberg Jurassic Park Hitchcock Psychose Allen Manhattan Lang Metropolis Hitchcock Vertigo Allen Annie Hall Kubrik Shining Spielberg Jurassic Park Hitchcock Psychose Allen Manhattan Lang Metropolis Hitchcock Vertigo Allen Annie Hall Kubrik Shining Optimisation 2006/

139 Jointures sans index (2) 1. Boucles imbriquées parcours d une table, et pour chaque ligne, parcourir l autre en comparant la jointure est associative: R T = T R, donc mettre à gauche la relation la moins volumineuse bénéfice si on a la possibilité de placer les deux relations en mémoire 2. Jointure par tri fusion plus efficace que les boucles imbriquées pour de grosses tables on trie les deux tables sur les colonnes de jointures on effectue la fusion Remarques le tri coûte cher on ne peut rien obtenir tant que le tri n est pas fini Optimisation 2006/

140 Exemple tri-fusion Jointures sans index (3) Allen Annie Hall 1977 Spielberg Jurassic Park 1992 Allen Manhattan 1979 Fusion Allen Spielberg Allen Lang Hitchcock Kubrik Hitchcock Annie Hall Jurassic Park Manhattan Metropolis Psychose Shining Vertigo Annie Hall 1977 Brazil 1984 Easy Rider 1969 Greystoke 1984 Jurassic Park 1992 Manhattan 1979 Metropolis 1926 Psychose 1960 Tri Tri Réalisateur Film Optimisation 2006/

141 Jointures avec index Avec un index, on utilise les boucles imbriquées indexées on balaye la table non indexée pour chaque ligne, on utilise l attribut de jointure pour traverser l index sur l autre table Avantages très efficace (un parcours, plus des recherches par adresse) favorise le temps de réponse et le temps d exécution Optimisation 2006/

142 Jointures avec index (2) Avec deux index fusionner les deux index : on obtient des paires d adresse pour chaque paire, aller chercher la ligne A, la ligne B Problématique car beaucoup d accès aléatoires En pratique : on se ramène à la jointure avec un index on prend la petite table comme table de parcours Optimisation 2006/

143 Plans d exécution Qu est-ce qu un plan d exécution? un programme combinant des opérateurs physiques (chemins d accès et traitements de données) Il a la forme d un arbre : chaque noeud est un opérateur qui prend des données en entrée applique un traitement produit les données traitées en sortie La phase d optimisation proprement dite : pour une requête, le système a le choix entre plusieurs plans d exécution Optimisation 2006/

144 Plans d exécution (2) Un plan est composé d un plan d exécution logique (PEL) et un plan d exécution physique (PEP) Deux plans diffèrent par l ordre des opérations - PEL (sélection avant jointure, ) les algorithmes - PEP (boucles imbriquées, tri/fusion, ) les chemins d accès - PEP (index disponible ou pas, ) Pour chaque plan on peut estimer : le coût de chaque opération la taille du résultat Objectif : diminuer le plus vite possible la taille des données manipulées Optimisation 2006/

145 Exemple Chercher tous les films avec James Stewart, parus en 1958 SELECT titre FROM Film f, Role r, Artiste a WHERE a.nom = Stewart AND a.prenom= James AND f.idfilm = r.idfilm AND r.idacteur = a.idartiste AND f.annee = 1958 Il y a autant de plans que de «blocs» dans une requête Pas d imbrication: un seul bloc Optimisation 2006/

146 Exemple: un niveau d imbrication SELECT titre FROM Film f, Role r WHERE f.idfilm = r.idfilm AND f.annee = 1958 AND r.idacteur IN (SELECT idartiste FROM Artiste WHERE nom= Stewart AND prenom= James ) Un niveau d imbrication (inutile): moins bon Optimisation 2006/

147 Exemple: deux niveaux d imbrication SELECT titre FROM Film WHERE annee = 1958 AND idfilm IN (SELECT idfilm FROM Role WHERE idacteur IN (SELECT idartiste FROM Artiste WHERE nom= Stewart AND prenom= James )) Mauvais: on force le plan, et il est inefficace on parcourt tous les films parus en 1958 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 2006/

148 Exemples de plans d exécution Sans index sur nom, prénom Projection titre Jointure idfilm=idfilm Jointure idacteur=idartiste Sélection 1958 Sélection James Stewart Rôle Adresse Film Adresse Artiste Séquentiel Index Rôle(idActeur,idFilm) idacteur Index Film(idFilm) idfilm Optimisation 2006/

149 Exemples de plans d exécution (2) Avec index sur nom, prénom Projection titre Jointure idfilm=idfilm Jointure idacteur=idartiste Sélection 1958 Artiste Adresse Rôle Adresse Film Adresse Index Artiste(nom,prénom) James Stewart Index Rôle(idActeur,idFilm) idacteur Index Film(idFilm) idfilm Optimisation 2006/

150 Exemples de plans d exécution (3) Sans aucun index Projection titre Fusion idacteur=idartiste Tri idacteur Fusion idfilm=idfilm Tri idfilm Tri idfilm Tri idartiste Sélection 1958 Sélection James Stewart Film Séquentiel Rôle Séquentiel Artiste Séquentiel Optimisation 2006/

151 Application à Oracle Optimisation 2006/

152 L optimiseur Oracle L optimiseur ORACLE suit une approche classique : génération de plusieurs plans d exécution estimation du coût de chaque plan généré choix du meilleur et exécution Tout ceci est automatique, mais il est possible d influer, voire de forcer le plan d exécution Optimisation 2006/

153 Estimation du coût d un plan d exécution Beaucoup de paramètres entrent dans l estimation du coût les chemins d accès disponibles les opérations physiques de traitement des résultats intermédiaires des statistiques sur les tables concernées (taille, sélectivité) les statistiques sont calculées par appel explicite à l outil ANALYSE les ressources disponibles Optimisation 2006/

154 Optimiseur basé sur les règles Priorité Description 1 Accès à un enregistrement par ROWID 2 Accès à un enregistrement dans un cluster 3 Accès à un enregistrement dans une table de hachage (hash cluster ) 4 Accès à un enregistrement par clé unique (avec un index) Balayage complet de la table Optimisation 2006/

155 Optimiseur basé sur les coûts Principaux paramètres : OPTIMIZER_MODE (RULE, CHOOSE, FIRST_ROW, ALL_ROWS) SORT_AREA_SIZE (taille de la zone de tri) HASH_AREA_SIZE (taille de la zone de hachage) HASH_JOIN_ENABLED considère les jointures par hachage Optimisation 2006/

156 Création des statistiques Calcul de la taille et du nombre de lignes : ANALYSE TABLE Film COMPUTE STATISTICS FOR TABLE Analyse des index : ANALYSE TABLE Film COMPUTE STATISTICS FOR ALL INDEX Analyse de la distribution des valeurs : ANALYSE TABLE Film COMPUTE STATISTICS FOR COLUMNS titre, genre SIZE 20 Optimisation 2006/

157 Chemins d accès Parcours séquentiel (FULL TABLE SCAN) Par adresse (ACCESS BY ROWID) Parcours de regroupement (CLUSTER SCAN) On récupère alors dans une même lecture les n-uplets des 2 tables du cluster Recherche par hachage (HASH SCAN) Parcours d index (INDEX SCAN) Optimisation 2006/

158 Opérations physiques Voici les principales : INTERSECTION : intersection de deux ensembles de n-uplets CONCATENATION : union de deux ensembles FILTER : élimination de n-uplets (sélection) PROJECTION : opération de l algèbre relationnelle D autres opérations sont liées aux algorithmes de jointures Optimisation 2006/

159 Algorithmes de jointure de Oracle ORACLE utilise trois algorithmes de jointures : boucles imbriquées quand il y a au moins un index opération NESTED LOOP tri/fusion 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 2006/