Bases de Données Avancées

Transcription

1 /210 Bases de Données Avancées Optimisation Thierry Hamon Bureau H202 Institut Galilée - Université Paris 13 & LIMSI-CNRS hamon@limsi.fr INFO2 BDA

2 2/210 Introduction Optimisation d une Application? Quand décide-t on d optimiser? Optimiser quoi? Qui participe, et Comment? Type de l application (TP ou Batch) Intérêt de l application pour l entreprise

3 3/210 Introduction Quand décide-t on d optimiser? Application Batch L application n est pas disponible à partir d une certaine heure Application transactionnelle L utilisateur constate que le temps de réponse est inacceptable (Agence de voyage, application interne, etc.)

4 4/210 Acteurs Qui participe et pourquoi? Adminstrateurs de DB, Développeurs, Ingénieurs Système (IS), Chef de projet Définition de la puissance de la machine (Nombre de processeurs, Capacité mémoire, Espace disque nécessaire en fonction du type de l application) Type du SGBD (Oracle, DB2, etc.) Type de l application (Batch, TP) Langage de programmation utilisé (Java, PL/SQL, etc.)

5 5/210 Acteurs Rôle d un Administrateur d une Base de Données (ABD ou DataBase Administrator DBA) Double rôle de l administrateur d une Base de Données : rôle organisationnel Définition du schéma conceptuel des données Partage de ces données par les utilisateurs rôle technique Mise en œuvre ce schéma partage à l aide des capacités techniques du SGBD

6 6/210 Acteurs Rôle d un Administrateur d une Base de Données rôle technique Installation du SGBD et des outils associés Création de la BD et ses composants conformément à un schéma conceptuel Surveillance de son évolution en modifiant, en créant ou en supprimant certaines structures Gestion des privilèges d accès Attribution et retrait de privilèges d accès aux données aux différents utilisateurs de la base de données

7 7/210 Acteurs Rôle d un Administrateur d une Base de Données rôle technique Amélioration les performances Choix de l implantation optimale des données de façon à obtenir les meilleures performances Identification et prise en compte des utilisations qui seront faites des données Surveillance de la sécurité et la cohérence des données Mise en place de structures et de procédures permettant de faire face à tous les incidents de retrouver l intégrité et la cohérence des données

8 8/210 Acteurs Rôle d un Administrateur d une Base de Données rôle technique Échange les données entre la BD et le monde extérieur Surveillance de l intégration des données en provenance d autres applications ou BD Migration des données de la base vers d autres applications ou BD Outils à utiliser : SQL*DBA, SQL*Loader, SQLPLUS, etc.

9 9/210 Objectifs Qu est-ce qui reste à faire? Les besoins en puissance machine définis Les acteurs administrateurs BD, (IS), développeurs, etc. au courant du projet (impliqués, responsable de la réussite du projet,..) Optimisation de la base et de l application?

10 10/210 Objectifs Sur quoi doit-on focaliser les efforts d optimisation? Partie N 1 : Conception des systèmes d informations et optimisation des applications Lors de la conception des systèmes d informations (si pas trop tard) Optimisation des applications Partie N 2 : Présentation des outils pour assurer le suivi de la base et garantir sa performance Optimisation de la mémoire Optimisation des entrées/sorties Disque Identifier les contentions dans la base de données

11 11/210 Objectifs Sur quoi doit-on focaliser les efforts d optimisation? Partie N 1 : Conception des systèmes d informations et optimisation des applications Lors de la conception des systèmes d informations : (Si pas trop tard) Système non performant : résultat d une mauvaise définition du modèle conceptuel Modèle conceptuel : au moins sous la 3ème forme Normale (3NF) Sauf dans quelque cas (choix volontaire) où la dé-normalisation apporte une certaine performance au système d information (Dataware house) Lors de la conception : tenir compte l accès aux données Analyse de la répartition des données : réplication de données (sur une ou plusieurs bases, etc.) agrégation des tables, pour les systèmes décisionnels etc.

12 11/210 Objectifs Sur quoi doit-on focaliser les efforts d optimisation? Partie N 1 : Conception des systèmes d informations et optimisation des applications Optimisation des applications : l expérience montre que 80% des problèmes de performances des applications, sont résolus, par une optimisation des requêtes SQL Ordonnancer les Batchs et éviter leur exécution pendant des heures ou l utilisation des machine est intense Dispatcher les Batchs les plus consommateurs en puissance machine à des heures différentes

13 12/210 Objectifs Sur quoi doit-on focaliser les efforts d optimisation? Partie N 2 : Présentation des outils pour assurer le suivi de la base et garantir sa performance Optimisation de la mémoire : déterminer la bonne taille des buffers de la base (shared_pool, buffer cache, log buffer, etc) par l utilisation des outils tels que Utlbstat/Utlestat, ou Statpack, etc.

14 12/210 Objectifs Sur quoi doit-on focaliser les efforts d optimisation? Partie N 2 : Présentation des outils pour assurer le suivi de la base et garantir sa performance Optimisation des entrées/sorties Disque : Bien dimensionner les fichiers de la base de données et placer dans des disques prévus pour le type d application (Batch ou TP), pour assurer un temps de réponse acceptable des requêtes adressées à la Base. Ne pas oublier de recenser les disques les plus sollicités, les tablespaces les plus fragmentés, full table scan, etc.

15 12/210 Objectifs Sur quoi doit-on focaliser les efforts d optimisation? Partie N 2 : Présentation des outils pour assurer le suivi de la base et garantir sa performance Identifier les contentions dans la base de données : Etudier les locks, les latches et les wait events au niveaux de la base de données, et les éliminer si possible

16 13/210 Conception des SI et optimisation des Applications Partie 1 Lors de la conception des systèmes d informations Optimisation des applications : L expérience montre que l optimisation des requêtes SQL résout la majorité des problèmes de performances des applications

17 14/210 Conception des SI et optimisation des Applications Objectifs de l optimisation Clarifier et situer les différents paramètres internes des SGBD (relationnel ; objet-relationnel) afin d améliorer leurs performances. Réécrire les codes SQL ; PL/SQL etc.. Restructurer les données, indexer les données, créer des vues matérialisées Partager les données, dupliquer les données sur plusieurs disques, créer des partitions sur les données

18 15/210 Conception des SI et optimisation des Applications Objectifs de l optimisation Intervenants : Administrateurs de Bases de Données (ABD = DBA) Programmeurs d Applications sur SGBD Objectifs : Optimiser un système existant et connaître les impacts de certains paramètres en fonction du type d application sur le système Choisir un SGBD en ayant comme contrainte les critères de performances

19 16/210 Conception des SI et optimisation des Applications Augmentation des performances Pour augmenter les performances trois grandes solutions apparaissent : 1 Première solution (d ordre logique) : optimiser les schémas conceptuel et logique pour qu il colle aux applications 2 Deuxième solution (d ordre physique) : optimiser les paramètres internes du SGBD 3 Autre solution (de type matérielle) : augmenter la puissance machine ou utiliser des ordinateurs spéciaux dédiés à la gestion des données. Cette approche est plus connue sous le nom Machine Bases de Données

20 17/210 Optimisation logique Optimisation logique de la Base de Données Optimisation du Schéma Relationnel Schéma Conceptuel de Données (SCD), obtenu à la phase d analyse une ensemble d Entités et d Associations ou un ensemble de Classes selon le formalisme utilisé En EA, transformation en schéma relationnel (Schéma Logique de Données SLD), qui permet Implantation du SCD dans une BD relationnelle Exploitation par le SGBD et les modules de programmation

21 18/210 Optimisation logique Optimisation logique de la Base de Données Optimisation du Schéma Relationnel Normalisation : processus permettant de s assurer de la Bonne conception du SLD non redondance de ses données Cadre formel pour effectuer la normalisation : la dépendance fonctionnelle les formes normales (1ère FN, 2ème FN, 3ème FN, FNBC, 4ème FN,...)

22 19/210 Optimisation logique Normalisation Exemple Avant normalisation : R e l a t i o n 1 ( A t t r i b u t 1, A t t r i b u t 2,... ) Décomposition de la relation Relation1, en deux ou plusieurs relations qui contiennent moins d anomalies de mises à jour (peu ou pas du tout) : On parle de Décomposition sans perte d information Décomposition sans perte de dépendance fonctionnelle (DF)... Après normalisation : R e l a t i o n 1 1 ( A t t r i b u t 1 1, A t t r i b u t 1 2,... ) R e l a t i o n 2 1 ( A t t r i b u t 2 1, A t t r i b u t 2 2,... )

23 20/210 Optimisation logique Normalisation Les relations obtenues doivent être en 3ème Forme Normale, au moins bon rapport redondance/espace occupé Clé Primaire Pas de DF entre les attributs de la clé primaire ; Pas de DF entre un sous ensemble d attributs de la clé primaire et les attributs qui n appartiennent pas à la clé primaire Pas de DF entre les attributs qui n appartiennent pas à la clé primaire

24 21/210 Optimisation logique Normalisation Illustration Format d une relation bien conçue

25 22/210 Optimisation logique Normalisation Exemple Soit la relation : ADRESSES ( V i l l e, Numéro, Rue, CodePostal ) Décomposition de la relation ADRESSES ( r e l a t i o n en 3ème FN) en deux relations CPR et CPV (en FN de Boyce et Codd) : CPR ( CodePostal, Rue ) CPV ( CodePostal, V i l l e )

26 23/210 Optimisation logique Normalisation Exemple ADRESSES VILLE NUMERO RUE CODE POSTAL Paris 6 Rue de la Rosière Paris 16 Rue de la Rosière Paris 51 Rue des Entrepreneurs Paris 55 Rue des Entrepreneurs Paris 8 Avenue des Champs Elysées Epinay sur Seine 23 Boulevard Foch CPR CPV CODE POSTAL RUE CODE POSTAL VILLE Rue de la Rosière Paris Rue des Entrepreneurs Paris Avenue des Champs Elysées Epinay sur Seine Boulevard Foch

27 24/210 Optimisation logique Normalisation Exemple Un client a une adresse : SLD version 1 CLIENT ( CodeCli, NomCli, PrénomCli, Numéro, Rue, CodePostal, V i l l e ) SELECT FROM CLIENT ; SLD version 2 CLIENT ( CodeCli, NomCli, PrénomCli, Numéro, A d r C l i ) ADRCPR ( AdrCli, Rue, CodePostal ) ADRCPV ( CodePostal, V i l l e ) SELECT FROM CLIENT, ADRCPR, ADRCPV WHERE CLIENT. A d r C l i=adrcpr. A d r C l i AND ADRCPR. CodePostal=ADRCPV. CodePostal ;

28 25/210 Optimisation logique Bilan Un schéma relationnel normalisé contiendra donc un nombre plus important de relations (de tables) pourra ainsi pénaliser certaines requêtes, qui seront obligées de procéder à des jointures plus nombreuses sur la base Or La jointure est une opération très coûteuse Les opérations binaires (qui portent sur deux tables) peuvent être coûteuses

29 26/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée Technique d optimisation des requêtes d interrogation Introduction volontairement de redondances dans le schéma logique relationnel Cette redondance est dite calculée car elle tient compte des besoins des modules de traitement des données de leurs exigences en terme de temps de réponse

30 27/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée Deux méthodes de réalisation de la redondance calculée : le stockages des données déductibles la dé-normalisation

31 28/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée : stockages des données déductibles Données déductibles les résultats des requêtes les plus fréquentes des statistiques historiques des données issues de calculs complexes

32 29/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée : stockages des données déductibles Dans les trois cas, stockage des données, physiquement dans la base (sous la forme de Tables/Vues ou de Colonnes) Avantage du stockage physique : éviter leur re-génération en cas de besoin Inconvénient de la redondance : 1 Place occupée par les données redondante 2 Nécessité de traitements supplémentaires pour les opérations de mises à jour 3 Risque d incohérence

33 30/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée : stockages des données déductibles Exemple de requête fréquente Base de données SportAct : Adhérents à des centres sportifs CENTRE ( NumC, NomC, V i l l e C, C o u t i n s c ) ESTMEMBRE ( NumA, NumC, D a t e i n s c ) Requête fréquente : Nombre d inscrits dans un centre c? SELECT C.NumC, C.NomC, COUNT(E.NumA) FROM CENTRE C, ESTMEMBRE E WHERE C.NumC = E.NumC AND C.NumC= c GROUP BY C.NumC ;

34 30/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée : stockages des données déductibles Exemple de requête fréquente Création d une nouvelle colonne NbrInscr dans la table CENTRE : CENTRE ( NumC, NomC, VilC, Coutinsc, N b r I n s c r ) Nouvel ordre SQL : SELECT NumC, NomC, N b r I n s c r FROM CENTRE WHERE NumC=c ; Suppression de 2 opérations très coûteuses : Une jointure en moins Un groupement en moins

35 30/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée : stockages des données déductibles Exemple de requête fréquente Impact sur le reste de la base de données Prise en compte de cette nouveauté par les opérations de mises à jours de la table ESTMEMBRE Modification de la colonne NbrInscr à chaque insertion ou suppression d inscription La cohérence est affectée si on ne le fait pas

36 30/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée : stockages des données déductibles Exemple de requête fréquente Chaque opération INSERT / DELETE implique une opération UPDATE INSERT INTO ESTMEMBRE VALUES (...) ; doit être accompagnée par UPDATE CENTRE SET N b r I n s c r=n b r I n s c r+1 ; DELETE FROM ESTMEMBRE WHERE... ; doit être accompagnée par UPDATE CENTRE SET N b r I n s c r=n b r I n s c r 1 ;

37 31/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée : stockages des données déductibles Exemple de Statistiques Historiques Requête : Nombre d inscrits par centre et par mois? Objectif : éviter le recalcul à chaque fois du nombre d inscrits par centre et par mois Solution : création d une nouvelle table/vue STAT_MENS_INSCR STAT MENS INSCR ( NumC, Mois, N b r I n s c r ) Nécessité d un nouveau traitement mensuel pour l actualiser avec les statistiques du mois écoulé

38 32/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée : stockages des données déductibles Résultat de calcul complexe Soit la base de données : CLIENT ( CodeCli, NomCli,... ) ARTICLE ( CodeArt, LibArt,..., P r i x A r t ) COMMANDE ( NumCom, CodeCli, DateCom ) DETAILCOM ( NumCom, CodeArt, QtéComDée ) Requête : Montant de la commande?

39 32/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée : stockages des données déductibles Résultat de calcul complexe Obtention du montant de la commande : SELECT C.NumCom, SUM(D. QtéComDée A. P r i x A r t ) AS Montant FROM COMMANDE C, ARTICLE A, DETAILCOM D WHERE C. NumCom=D. NumCom AND D. CodeArt=A. CodeArt GROUP BY C. NumCom ; Gain d opération avec la création de la colonne Montant dans la table COMMANDE COMMANDE ( NumCom, CodeCli, DateCom, Montant ) SELECT NumCom, Montant FROM COMMANDE ;

40 33/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée : dé-normalisation Autre méthode d optimisation des interrogations Transformer, si besoin est, une table de la 3ème FN en 2ème FN ou en la 1ère FN Objectif : éviter des jointures successives pouvant être coûteuses en performances

41 34/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée : dé-normalisation Exemple Soit la table ARTICLE ( CodeArt, LibArt,..., P r i x A r t ) COMMANDE ( NumCom, CodeCli, DateCom ) DETAILCOM ( NumCom, CodeArt, QtéComDée, P r i x A r t ) DETAILCOM passe de la 3ème FN à la 1ère FN Requête : Montant de la commande? SELECT NumCom, SUM( QtéComDée P r i x A r t ) FROM DETAILCOM GROUP BY NumCom ; AS Montant

42 35/210 Optimisation logique Optimisation logique de la Base de Données Redondance calculée : dé-normalisation Inconvénients de la dé-normalisation : identiques à ceux du stockage des données déductibles Place supplémentaire Pénalisation des traitements d insertion et de suppression Risque d incohérence Nécessite la création de déclencheurs (triggers)

43 36/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Requête SQL : ordre passé au SGBD pour lui demander de rechercher des données spécifiées dans la requête (sans expliciter le comment) SQL est non procédural SELECT / FROM / WHERE / GROUP BY / HAVING / ORDER BY DISTINCT SUM / MIN / MAX / AVG / COUNT IN / NOT IN / LIKE / NOT LIKE / EXISTS / NOT EXISTS / = INSERT / DELETE / UPDATE CREATE / TABLE / VIEW / INDEX

44 37/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Traduction d une requête exprimée en langage naturel en un ensemble d ordres SQL Plusieurs agencements sont souvent possibles : au niveau de l ordre dans lequel les conditions sont exprimées dans la clause WHERE : WHERE c o n d i t i o n 1 AND c o n d i t i o n 2 WHERE c o n d i t i o n 2 AND c o n d i t i o n 1

45 37/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Traduction d une requête exprimée en langage naturel en un ensemble d ordres SQL Plusieurs agencements sont souvent possibles : au niveau des opérations algébriques Possibilité d utiliser plusieurs méthodes différentes pour exprimer la même chose La jointure : possibilité d exprimer l opération de plusieurs manières différentes R = Jointure ( R1, R2, {R1.A=R2.A} ) = Jointure ( R2, R1, {R2.A=R1.A} ) SELECT FROM R1, R2 WHERE R1. A = R2. A ; SELECT FROM R2, R1 WHERE R2. A = R1. A ;

46 38/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Expression de la jointure Méthode prédicative SELECT FROM R1, R2 WHERE R1. A=R2. A ; Méthodes ensemblistes SELECT FROM R1 WHERE A IN (SELECT A FROM R2 ) ; SELECT FROM R1 WHERE A =ANY (SELECT A FROM R2 ) ; SELECT FROM R1 WHERE EXISTS (SELECT FROM R2 WHERE R1. A=R2. A ) ; SELECT FROM R1 WHERE 0 < (SELECT COUNT( ) FROM R2 WHERE R1. A=R2. A ) ;

47 39/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Exemple de durée d exécution SQLPlus SET TIMING ON Exécution de la requête ; SELECT... FROM... Oracle vous donne le temps écoulé Méthode prédicative : s e l e c t from a l l t a b l e s t1, a l l c o n s t r a i n t s t2 where t1. table name = t2. table name ; temps CPU: u n i t é s u n i t é s s e l e c t from a l l c o n s t r a i n t s t1, a l l t a b l e s t2 where t1. table name = t2. table name ; temps CPU: u n i t é s u n i t é s

48 40/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Exemple de durée d exécution SQLPlus Méthodes ensemblistes : s e l e c t from a l l c o n s t r a i n t s where t a b l e n a m e i n ( s e l e c t t a b l e n a m e from a l l t a b l e s ) ; temps CPU: u n i t é s u n i t é s s e l e c t from a l l c o n s t r a i n t s where t a b l e n a m e = any ( s e l e c t t a b l e n a m e from a l l t a b l e s ) ; temps CPU: u n i t é s u n i t é s s e l e c t from a l l c o n s t r a i n t s t1 where e x i s t s ( s e l e c t from a l l t a b l e s t2 where t1. t a b l e n a m e = t2. t a b l e n a m e ) ; temps CPU: u n i t é s u n i t é s

49 41/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Traduction d une requête exprimée en langage naturel en un ensemble d ordres SQL : Plusieurs agencements sont souvent possibles Possibilité d utiliser plusieurs méthodes différentes pour exprimer la même chose La différence : R = Différence ( R1, R2 ) SELECT FROM R1 MINUS SELECT FROM R2 ;

50 42/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Expression de la différence SELECT A FROM R1 MINUS SELECT A FROM R2 ; SELECT A FROM R1 WHERE A NOT IN (SELECT A FROM R2 ) ; SELECT A FROM R1 WHERE NOT EXISTS (SELECT A FROM R2 WHERE R1. A=R2. A ) ; SELECT A FROM R1 WHERE 0 = (SELECT COUNT( ) FROM R2 WHERE R1. A=R2. A ) ;

51 43/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Utilisation des vues Mauvais code : S e l e c t e. from EMP e where e. s a l a r y > ( s e l e c t avg ( s a l a r y ) from EMP i where i. d e p i d = e. d e p i d ) ; Bon code S e l e c t e. from EMP e, ( S e l e c t i. d e p i d DEP, avg ( i. s a l a r y ) SAL from EMP i group by i. d e p i d ) EMP VUE where e. d e p i d = EMP VUE. d e p i d and e. s a l a r y > EMP VUE. SAL ;

52 44/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Vues matérialisées Présentation des vues matérialisées : Création d une vue physique d une table Duplication des données Définition de vues matérialisées à partir de tables, de vues, et de vues matérialisées Possibilité de décalage entre la table maître et la vue matérialisée : gestion de la fraicheur des données de la vue matérialisée (refresh)

53 45/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Vues matérialisées Utilisation des vues matérialisées : Optimisation/amélioration des performances Ré-écriture des requêtes portant sur des tables select particulièrement complexe ou lourd réplication de table

54 46/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Exemple d utilisation de vues matérialisées Soit le schéma logique de données suivant :

55 47/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Exemple d utilisation de vues matérialisées Soit la requête Q : Total des ventes des magasins en France ou en Belgique -pour la période de 2001 à par ville et année s e l e c t ADRVILLEMAG, ANNEET, sum(montantvente) as Montant from VENTES, MAGASINS, TEMPS where VENTES.NUMMAG=MAGASINS.NUMMAG and VENTES. IDTEMPS=TEMPS. IDTEMPS and ( upper (MAGASINS. ADRPAYSMAG)= FRANCE or upper (MAGASINS. ADRPAYSMAG)= BELGIQUE ) and TEMPS. ANNEET between 2001 and 2003 group by ADRVILLEMAG, ANNEET ;

56 48/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Exemple d utilisation de vues matérialisées V1 : Total des ventes des magasins à partir de 2002, par ville et année c r e a t e m a t e r i a l i z e d view v1 ( V i l l e, Annee, Montant1 ) as ( s e l e c t ADRVILLEMAG, ANNEET, sum (MONTANTVENTE) from VENTES, MAGASINS, TEMPS where VENTES.NUMMAG=MAGASINS.NUMMAG and VENTES. IDTEMPS=TEMPS. IDTEMPS and TEMPS. ANNEET >= 2002 group by ADRVILLEMAG, ANNEET ) ;

57 48/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Exemple d utilisation de vues matérialisées V2 : Total des ventes des magasins en France par ville, année et mois c r e a t e m a t e r i a l i z e d view v2 ( V i l l e, Annee, Mois, Montant2 ) as ( s e l e c t ADRVILLEMAG, ANNEET, MOIST, sum (MONTANTVENTE) from VENTES, MAGASINS, TEMPS where VENTES.NUMMAG=MAGASINS.NUMMAG and VENTES. IDTEMPS=TEMPS. IDTEMPS and upper (MAGASINS.ADRPAYSMAG)= FRANCE group by ADRVILLEMAG, ANNEET, MOIST ) ;

58 48/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Exemple d utilisation de vues matérialisées V3 : Total des ventes des magasins en Belgique avant 2001 par ville, année et mois c r e a t e m a t e r i a l i z e d view v3 ( V i l l e, Annee, Mois, Montant3 ) as ( s e l e c t ADRVILLEMAG, ANNEET, MOIST, sum (MONTANTVENTE) from VENTES, MAGASINS, TEMPS where VENTES.NUMMAG=MAGASINS.NUMMAG and VENTES. IDTEMPS=TEMPS. IDTEMPS and upper (MAGASINS.ADRPAYSMAG)= BELGIQUE and TEMPS. ANNEET <= 2001 group by ADRVILLEMAG, ANNEET, MOIST ) ;

59 49/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Exemple d utilisation de vues matérialisées Soit la requête Q qui utilise des vues matérialisées : s e l e c t ADRVILLEMAG, annee, Montant1 from v1, ( s e l e c t d i s t i n c t ADRVILLEMAG from MAGASINS where upper (MAGASINS.ADRPAYSMAG)= FRANCE or upper (MAGASINS.ADRPAYSMAG)= BELGIQUE ) where v1. v i l l e = s1. ADRVILLEMAG and annee <= 2003 s1 union s e l e c t v i l l e, annee, sum ( Montant2 ) from v2 where annee =2001 group by v i l l e, annee union s e l e c t s2. ADRVILLEMAG, Annee, sum ( Montant3 ) from v3, ( s e l e c t d i s t i n c t ADRVILLEMAG from MAGASINS) s2 where v3. v i l l e = s2. ADRVILLEMAG and annee = 2001 group by s2. ADRVILLEMAG, annee ;

60 50/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Utilisation de vues matérialisées Inconvénients : Résultat de la requête stocké et valable à un instant t en fonction des paramètres, la vue matérialisée sera tenue à jour ou non quand la table change Entretien des vues en temps réel : coûteux (et peu souvent mis en œuvre)

61 51/210 Optimisation logique Optimisation logique de la Base de Données Optimisation des ordres SQL Utilisation de vues matérialisées Avantages Simple réécriture de requête et exécution de requêtes imbriquées Lorsqu il n est nécessaire de disposer des données en temps réel, économie d interrogation Exemple : analyse de chiffres économiques de la veille données figées intérêt à stocker des résultats (qui ne changeront plus!) Utilisation dans les datawarehouse : problématique de performances

62 52/210 Optimisation physique Gestion physique des données Adaptation et enrichissement du SLD pour tenir compte des spécificités du SGBD des performances des traitements et de la sécurité A ce stade d élaboration du schéma physique de données, on dispose : du SLD normalisé ou non du schéma physique de traitement (description détaillée des modules)

63 53/210 Optimisation physique Gestion physique des données Résultat : Schéma Physique des Données (SPD) représentation de la structure définitive de la base de données telle qu elle doit être implantée prise en compte des caractéristiques technique du SGBD et du matériel des exigences en interfaces et en performances des modules de programmation Si le matériel ou le SGBD change alors il faut changer le SPD (les exigences changent)

64 54/210 Optimisation physique Gestion physique des données Etat des lieux : des tables en 3ème FN, ou autre etc. bien conçues Objectifs : optimisation des accès en choisissant les colonnes qui doivent être indexées introduction (éventuellement) de redondances calculées définition de vues standards et des vues matérialisées définition des contraintes d intégrité et des déclencheurs sur les tables

65 55/210 Optimisation physique Gestion physique des données création des tables et des colonnes techniques définition des droits d accès aux données répartition des tables sur les sites (en cas de BD réparties) calcul des paramètres de stockage des tables et des index etc.

66 56/210 Optimisation physique Gestion physique des données Colonnes à indexer les clés primaires (concaténées ou pas) pour garantir l unicité et accélérer les recherches INDEX UNIQUE les clés étrangères (concaténées ou pas) pour accélérer les jointures INDEX NOT UNIQUE les colonnes servant de critères de recherche (apparaissent souvent dans la clause WHERE de SQL) INDEX NOT UNIQUE

67 57/210 Optimisation physique Gestion physique des données Colonnes à indexer Remarque : Un vrai SGBD se caractérise par l emploi d un SEUL fichier pour y stocker la BD (ou éventuellement quelques fichiers si la BD est trop importante) Un faux SGBD Relationnel emploie un fichier pour y stocker une table dans ce cas la gestion physique des données est assurée par le système d exploitation, interdisant tout paramètre d optimisation

68 58/210 Indexation Gestion des méthodes d accès aux données Méthodes d accès : Méthode séquentielle Méthodes basées sur les index : Index hiérarchisé, Arbre-B (B-tree), Arbre-B+, Arbre-B+*,... Méthode de hachage Mise en cluster

69 59/210 Indexation Données (110 octets) Index (14 octets) Clé primaire Info. compl. Clé primaire Adresse physique (10 octets) (100 octets) (10 octets) (4 octets) 10 info1 15 info2 20 info3 30 info4 40 info info k 1610 info n

70 60/210 Indexation Données (110 octets) Index (14 octets) Clé primaire Info. compl. Clé primaire Adresse physique (10 octets) (100 octets) (10 octets) (4 octets) 10 info1 15 info2 20 info3 30 info4 40 info5 50 info6 55 info7 77 info8 80 info9 10 info info info k 1610 info n

71 61/210 Indexation Taille d une Table & Taille d un Index Exemple Table (110 octets par enregistrement) : Clé primaire (10 octets), Informations complémentaires (100 octets) Index (14 octets par enregistrement) : Clé primaire (10 octets), Adresse Physique (4 octets) Bloc de 512 octets Nombre d enregistrements de l ordre de

72 62/210 Indexation Taille d une Table & Taille d un Index Exemple Pour les données : Pour un nombre entier d enregistrements par bloc (512/110) Nombre maximal d enregistrements par bloc est 4 Il faudrait donc ( /4) = blocs de données Pour les index : Pour un nombre entier d enregistrements par bloc (512/14) Nombre maximal d enregistrements par bloc est 36 Il faudrait donc ( /36) = 2778 blocs d index

73 63/210 Indexation Index type B-arbre (B-tree) Exemple

74 64/210 Indexation Index Différents types d index : Logique Index simple (sur une colonne) Index concaténé (sur plusieurs colonne) Index unique (colonne ne comportant pas de doublon) Index non unique (colonne comportant des doublons) Physique B-tree Bitmap Hash

75 65/210 Indexation Index Exemples Index simple create index i d x n o f o u r on t t f o u r ( n o f o u r ) Index concaténé create index idx commande on ( n o f o u r, n c l i e n t )

76 66/210 index unique Indexation Index Exemples create unique index i d x u n i q u e on tab ( c o l 1 ) t a b l e s p a c e t b s t a b 1 p c t f r e e 40 p c t u s e d 60 i n i t r a n s 10 maxtrans 100 index non unique create index i d x n o n u n i q u e on tab ( c o l 1 ) t a b l e s p a c e t b s t a b 1 p c t f r e e 40 p c t u s e d 60 i n i t r a n s 10 maxtrans 100 n o l o g g i n g

77 67/210 Indexation Index manipulations Modification d un Index Alter Index schema. name index i n i t r a n s i n t e g e r maxtrans i n t e g e r s t o r a g e ( i n i t i a l 100M next 20M) l o g g i n g n o l o g g i n g Reconstruction d un Index Alter Index p1. IDX FOUR R e b u i l d T ablespace TBS INDEXES

78 68/210 Indexation Index Manipulation Modification d un Index Alter Index schema. name index i n i t r a n s i n t e g e r maxtrans i n t e g e r s t o r a g e ( i n i t i a l 100M next 20M) l o g g i n g n o l o g g i n g Catalogue Oracle pour la gestion des Index et des Clusters Select from s y s. d b a u s e r s ; Select from s y s. d b a i n d e x c o l u m n s ; Select from s y s. d b a c l u s t e r s ; Select from s y s. d b a c l u c o l u m n s ;

79 69/210 Indexation Index Bitmap Création d un index Bitmap (pour faible cardinalité) create bitmap index on t t f o u r ( d t l i v r a i s o n ) t a b l e s p a c e TBS Fournisseur ;

80 70/210 Indexation INDEX HASH Cluster Création du cluster Create c l u s t e r c l i e n t h a s h ( Num cli number ( 9 ) s i z e 512 HASHKEY 500 s t o r a g e ( i n i t i a l 2M next 1M) Mise en cluster d une table Create table C l i e n t ( N c l i number, nom varchar2 ( 5 0 ) ) Cluster c l i e n t h a s h ( N c l i ) ; Création de l index sur le cluster Create index I d x C l i e n t on c l u s t e r c l i e n t h a s h ;

81 71/210 Indexation INDEX B-TREE Préparation de l utilisation de B-Tree (à utiliser dans le cas d une forte cardinalité) SQL> DESC t10man copy NAME NULL? TYPE EMPNO NOT NULL NUMBER ENAME VARCHAR2( 2 0 ) JOB VARCHAR2( 1 8 ) MGR NUMBER( 4 ) HIREDATE DATE SAL NUMBER( 7, 2 ) COMM NUMBER( 7, 2 ) DEPTNO NUMBER( 2 ) EMPNO r a n g e s from 1 to I use t h i s t a b l e to c r e a t e MGR row w i t h c a r d i n a l i t y 4. I use MOD function. MOD (m, n ) f u n c t i o n r e t u r n s a r e m a i n i n g o f m d i v i d e d by n. I a l s o use to char to make column length even. SQL to make data i n MGR row be c a r d i n a l i t y 4 SQL> CREATE TABLE T10MAN COPY 4 AS SELECT EMPNO,ENAME, JOB, to char (mod(empno, 4 ), ) MGR, HIREDATE, SAL,COMM,DEPTNO FROM T10MAN ORG ; Table created , , , and a r e scanned by turns

82 72/210 Indexation INDEX B-TREE Création d un index B-Tree SQL> SELECT MGR FROM T10MAN COPY 4 WHERE ROWNUM < 10 ; MGR SQL> CREATE INDEX BTREE 4 ON T10MAN COPY 4(MGR) STORAGE ( INITIAL 2K NEXT 2K PCTINCREASE 0 MAXEXTENTS UNLIMITED) ;

83 73/210 Optimisation des requêtes Optimisation des requêtes Exemples d optimisation Algorithmique Algorithme des boucles imbriquées de la jointure BI-passe Algorithme Multi-Passes de la jointure MP

84 74/210 Optimisation des requêtes Jointure Bi-passe Hashage de deux tables en paquets de mémoire virtuelle Début A l g o r i t h m e BI : POUR i DE 1 à n1 FAIRE DEBUT LIRE Page de R1 POUR j de 1 à n2 FAIRE DEBUT LIRE Page de R2 S I R1. A=R2. A ALORS C r é e r r é s u l t a t FINSI FIN FIN Fin A l g o r i t h m e BI :

85 75/210 Optimisation des requêtes Jointure Multi-Passe Début A l g o r i t h m e MP : POUR i DE 1 à m FAIRE DEBUT CHARGE MEMOIRE( ) POUR j de 1 à n2 FAIRE DEBUT LIRE Page de R2 S I R1. A=R2. A ALORS C r é e r r é s u l t a t FINSI FIN FIN CHARGER MEMOIRE( ) POUR k DE 1 à m FAIRE DEBUT LIRE Page de R1 FIN Fin A l g o r i t h m e MP :

86 76/210 Optimisation des requêtes Optimisation des requêtes Visualisation : Expression Algébrique Arbre algébrique Plan d exécution de la requête

87 77/210 Plan d exécution Plan d exécution Sous Oracle, possibilité de connaître pour chaque requête son plan d exécution Consultation du plan d exécution selon lequel une instruction SQL sera exécutée par le SGBD Oracle dans une table système Stockage des plans d exécution dans une table PLAN_TABLE dont le script de création (fourni par Oracle) se trouve dans $ORACLE_HOME/rdbms/admin/utlxplan.sql Etapes en vue de la consultation : création la table de nom PLAN_TABLE Eventuellement la détruire et la recréer exécuttion d une commande EXPLAIN PLAN sur une requête Stockage (description) du plan d exécution de cette dernière) dans la table PLAN_TABLE Interrogation de la table PLAN_TABLE

88 78/210 Plan d exécution Exécution d une commande EXPLAIN PLAN sur une requête EXPLAIN PLAN SET s t a t e m e n t i d= exemple1 // i d e n t i f i a n t FOR // exemple de r e q u ê t e SELECT FROM WHERE ; Exemple : EXPLAIN PLAN SET s t a t e m e n t i d = r e q u e t e 1 FOR s e l e c t from e l e v e s where nom l i k e DUPON% ;

89 79/210 Plan d exécution Affichage du plan d exécution Interrogation de la table PLAN_TABLE SELECT LPAD(,2 (LEVEL 1 ) ) o p e r a t i o n o p t i o n s object name Plan d e x é c u t i o n FROM p l a n t a b l e START WITH i d = 0 AND s t a t e m e n t i d = r e q u e t e 1 CONNECT BY PRIOR i d = p a r e n t i d AND s t a t e m e n t i d = r e q u e t e 1 ; Résultat affiché : Plan d exécution SELECT STATEMENT TABLE ACCESS BY INDEX ROWID ELEVES INDEX RANGE SCAN I_NOM

90 80/210 Plan d exécution Remarques et explications Représentation d une requête par un arbre Sous Oracle, possibilité de représentation et de manipulation de données ayant une structure de données récursive (arbre) par une représentation tabulaire et avec la commande SQL : SELECT... FROM...WHERE... CONNECT BY PRIOR c o l o n n e o p é r a t e u r c o l o n n e [CONNECT BY c o l o n n e o p é r a t e u r PRIOR c o l o n n e ] START WITH... LEVEL... Extensible des données quelconques

91 81/210 Plan d exécution Exemples de parcours de structure de données de type récursif Structures de données récursives de type Arbres Exemples : Arbre Généalogique Nomenclature d un produit (Composé, Composant) Oracle offre la commande CONNECT BY SELECT... FROM...WHERE... CONNECT BY PRIOR c o l o n n e o p é r a t e u r c o l o n n e CONNECT BY c o l o n n e o p é r a t e u r PRIOR c o l o n n e START WITH LEVEL

92 82/210 Plan d exécution Structures hiérarchiques, arborescentes Arbre Généalogique Oracle permet la représentation et la manipulation des données ayant une structure arborescente par le modèle relationnel par exemple c r e a t e t a b l e PERSONNES ( NUMERO number ( 7 ), NOM varchar ( 1 5 ), PRENOM varchar ( 1 5 ), DATENAISSANCE date, SEXE char ( 1 ), PERE number ( 7 ), MERE number ( 7 ), c o n s t r a i n t PK PERSONNES p r i m a r y key (NUMERO), constraint FK PERSONNES PERE PERSONNES foreign key (PERE) r e f e r e n c e s PERSONNES, constraint FK PERSONNES MERE PERSONNES foreign key (MERE) r e f e r e n c e s PERSONNES, c o n s t r a i n t CK SEXE PERSONNES check (SEXE i n ( M, F ) ) ) ;

93 83/210 Optimisation des requêtes Optimisation des requêtes Requête simple sur une table non indexée DELETE p l a n t a b l e ; // ( l a t a b l e é t a n t c r é é e une f o i s, i l s u f f i t de l a v i d e r ) EXPLAIN PLAN SET s t a t e m e n t i d = r e q u e t e 1 FOR s e l e c t from e l e v e s where nom l i k e DUPON% ; SELECT LPAD(, 2 ( LEVEL 1 ) ) o p e r a t i o n o p t i o n s o b j e c t n a m e Plan d e x é c u t i o n FROM p l a n t a b l e START WITH i d = 0 AND s t a t e m e n t i d = r e q u e t e 1 CONNECT BY PRIOR i d = p a r e n t i d AND s t a t e m e n t i d = r e q u e t e 1 ; Plan d exécution SELECT STATEMENT TABLE ACCESS BY INDEX ROWID ELEVES INDEX RANGE SCAN I_NOM

94 84/210 Optimisation des requêtes Optimisation des requêtes Requête simple sur une table indexée drop i n d e x i nom ; c r e a t e i n d e x i nom on e l e v e s (nom ) ; EXPLAIN PLAN SET s t a t e m e n t i d = r e q u e t e 1 FOR s e l e c t from e l e v e s where nom l i k e DUPON% ; SELECT LPAD(, 2 ( LEVEL 1 ) ) o p e r a t i o n o p t i o n s o b j e c t n a m e Plan d e x é c u t i o n FROM p l a n t a b l e START WITH i d = 0 AND s t a t e m e n t i d = r e q u e t e 1 CONNECT BY PRIOR i d = p a r e n t i d AND s t a t e m e n t i d = r e q u e t e 1 ; Plan d exécution SELECT STATEMENT TABLE ACCESS BY INDEX ROWID ELEVES INDEX RANGE SCAN I_NOM

95 85/210 Optimisation des requêtes Optimisation des requêtes Comparaison Requête simple sur une table non indexée : Plan d exécution SELECT STATEMENT TABLE ACCESS BY INDEX ROWID ELEVES INDEX RANGE SCAN I_NOM Requête simple sur une table indexée : Plan d exécution SELECT STATEMENT TABLE ACCESS BY INDEX ROWID ELEVES INDEX RANGE SCAN I_NOM

96 86/210 drop i n d e x i nom ; d e l e t e p l a n t a b l e ; Optimisation des requêtes Optimisation des requêtes Requête avec un order by sur une table non indexée EXPLAIN PLAN SET s t a t e m e n t i d = r e q u e t e 2 FOR s e l e c t from e l e v e s where nom l i k e DUPON% o r d e r by nom ; SELECT LPAD(, 2 ( LEVEL 1 ) ) o p e r a t i o n o p t i o n s o b j e c t n a m e Plan d e x é c u t i o n FROM p l a n t a b l e START WITH i d = 0 AND s t a t e m e n t i d = r e q u e t e 2 CONNECT BY PRIOR i d = p a r e n t i d AND s t a t e m e n t i d = r e q u e t e 2 ; Plan d exécution SELECT STATEMENT SORT ORDER BY TABLE ACCESS FULL ELEVES

97 87/210 Optimisation des requêtes Optimisation des requêtes Requête avec un order by sur une table indexée drop i n d e x i nom ; c r e a t e i n d e x i nom on e l e v e s (nom ) ; d e l e t e p l a n t a b l e ; EXPLAIN PLAN SET s t a t e m e n t i d = r e q u e t e 2 FOR s e l e c t from e l e v e s where nom l i k e DUPON% o r d e r by nom ; SELECT LPAD(, 2 ( LEVEL 1 ) ) o p e r a t i o n o p t i o n s o b j e c t n a m e Plan d e x é c u t i o n FROM p l a n t a b l e START WITH i d = 0 AND s t a t e m e n t i d = r e q u e t e 2 CONNECT BY PRIOR i d = p a r e n t i d AND s t a t e m e n t i d = r e q u e t e 2 ; Plan d exécution SELECT STATEMENT SORT ORDER BY TABLE ACCESS BY INDEX ROWID ELEVES INDEX RANGE SCAN I_NOM

98 88/210 Optimisation des requêtes Optimisation des requêtes Comparaison Requête avec un order by sur une table non indexée Plan d exécution SELECT STATEMENT SORT ORDER BY TABLE ACCESS FULL ELEVES Requête avec un order by sur une table indexée Plan d exécution SELECT STATEMENT SORT ORDER BY TABLE ACCESS BY INDEX ROWID ELEVES INDEX RANGE SCAN I_NOM

99 89/210 Optimisation des requêtes Optimisation des requêtes Requête de jointure avec les deux tables indexées d e l e t e p l a n t a b l e ; EXPLAIN PLAN SET s t a t e m e n t i d = r e q u e t e 3 FOR s e l e c t nom, prenom, num cours, p o i n t s from e l e v e s e, r e s u l t a t s r where r. n u m e l e v e = e. n u m e l e v e ; SELECT LPAD(, 2 ( LEVEL 1 ) ) o p e r a t i o n o p t i o n s o b j e c t n a m e Plan d e x é c u t i o n FROM p l a n t a b l e START WITH i d = 0 AND s t a t e m e n t i d = r e q u e t e 3 CONNECT BY PRIOR i d = p a r e n t i d AND s t a t e m e n t i d = r e q u e t e 3 ; Plan d exécution SELECT STATEMENT NESTED LOOPS TABLE ACCESS FULL RESULTATS TABLE ACCESS BY INDEX ROWID ELEVES INDEX UNIQUE SCAN PK_ELEVES

100 90/210 Optimisation des requêtes Optimisation des requêtes Requête de jointure avec les deux tables indexées L ordre des 2 tables change d e l e t e p l a n t a b l e ; EXPLAIN PLAN SET s t a t e m e n t i d = r e q u e t e 3 FOR s e l e c t nom, prenom, num cours, p o i n t s from r e s u l t a t s r, e l e v e s e where r. n u m e l e v e = e. n u m e l e v e ; SELECT LPAD(, 2 ( LEVEL 1 ) ) o p e r a t i o n o p t i o n s o b j e c t n a m e Plan d e x é c u t i o n FROM p l a n t a b l e START WITH i d = 0 AND s t a t e m e n t i d = r e q u e t e 3 CONNECT BY PRIOR i d = p a r e n t i d AND s t a t e m e n t i d = r e q u e t e 3 ; Plan d exécution SELECT STATEMENT NESTED LOOPS TABLE ACCESS FULL ELEVES TABLE ACCESS BY INDEX ROWID RESULTATS INDEX RANGE SCAN PK_RESULTATS

101 91/210 Optimisation des requêtes Optimisation des requêtes Comparaison Requête de jointure avec les deux tables indexées Plan d exécution SELECT STATEMENT NESTED LOOPS TABLE ACCESS FULL RESULTATS TABLE ACCESS BY INDEX ROWID ELEVES INDEX UNIQUE SCAN PK_ELEVES Requête de jointure avec les deux tables indexées (L ordre des 2 tables change) Plan d exécution SELECT STATEMENT NESTED LOOPS TABLE ACCESS FULL ELEVES TABLE ACCESS BY INDEX ROWID RESULTATS INDEX RANGE SCAN PK_RESULTATS

102 92/210 Optimisation des requêtes Optimisation des requêtes Requête de jointure avec les deux tables indexées et une sélection d e l e t e p l a n t a b l e ; EXPLAIN PLAN SET s t a t e m e n t i d = r e q u e t e 4 FOR s e l e c t nom, prenom, num cours, p o i n t s from e l e v e s e, r e s u l t a t s r where r. n u m e leve = e. n u m e l e v e and e. n u m e l e v e = 10 ; SELECT LPAD(, 2 ( LEVEL 1 ) ) o p e r a t i o n o p t i o n s o b j e c t n a m e Plan d e x é c u t i o n FROM p l a n t a b l e START WITH i d = 0 AND s t a t e m e n t i d = r e q u e t e 4 CONNECT BY PRIOR i d = p a r e n t i d AND s t a t e m e n t i d = r e q u e t e 4 ;

103 93/210 Optimisation des requêtes Optimisation des requêtes Requête de jointure avec les deux tables indexées et une sélection Plan d exécution SELECT STATEMENT NESTED LOOPS TABLE ACCESS BY INDEX ROWID ELEVES INDEX UNIQUE SCAN PK_ELEVES TABLE ACCESS BY INDEX ROWID RESULTATS INDEX RANGE SCAN PK_RESULTATS

104 94/210 Outils d optimisation Partie 2 Introduction Présentation des outils des méthodes pour assurer le suivi de la base et garantir sa performance

105 95/210 Outils d optimisation Amélioration du Suivi et de la performance de la base 1 Choix de l optimiseur et collecte des statistiques 2 Suivi des indicateurs 3 Outils pour améliorer l optimisation de la base

106 96/210 Optimiseur Oracle Historique de l optimiseur d Oracle Optimiseur Syntaxique Avant la version 7.0 : optimiseur syntaxique (rule-based optimizer) avant la version 7/0 : Hypothèse de base : à partir du moment où une instruction SQL validait une règle, et que le numéro de la règle diminuait, le plan d exécution était réputé meilleur. Fonctionnement : uniquement optimisation du code en utilisant un ensemble de règles internes fixes et en les appliquant à partir d une analyse syntaxique du code

107 97/210 Optimiseur Oracle Historique de l optimiseur d Oracle Optimiseur Syntaxique Limites de l optimiseur syntaxique : incapacité à déterminer la méthode la moins coûteuse Pas usage de type de fonction de coût ou de statistiques Mais, initialement conçu pour les BDD transactionnelles (les Datawarehouses n existaient pas encore)

108 98/210 Optimiseur Oracle Historique de l optimiseur d Oracle Optimiseur Statistique Apparition avec la version 7.0 d Oracle Objectifs : Utilisation d un plus grand nombre d options lors de la construction des plans d exécution du code SQL Mais maturité difficile à atteindre : 7 ans! A partir de Oracle 7.3 : Possibilité de générer et d enregistrer des histogrammes de colonnes Histogrammes de colonnes : Fonctionnalité capable de déterminer la distribution effective des données pour une colonne particulière

109 99/210 Optimiseur Oracle Initialisation des Paramétrage de l Optimiseur Configuration de l instance Oracle à l aide du paramètre OPTIMIZER_MODE Valeur définie dans le fichier init.ora Valeur par défaut : CHOOSE (valeur nécessaire pour l optimisation statistique) Valeur RULE : optimisation syntaxique (rule-based optimizer) Optimisation du code en utilisant un ensemble de règles internes fixes telles que : Accès par l intermédiaire d un index composite avec toutes les clés contenues dans la clause where Accès par l intermédiaire d un index sur une colonne, etc. Autres valeurs possibles (selon les versions d oracle) : FIRST_ROWS, ALL_ROWS

110 100/210 Optimiseur Oracle Initialisation des Paramétrage de l Optimiseur Modification du paramètre au niveau session à l aide de la commande suivante : Alter s e s s i o n set o p t i m i z e r m o d e=f i r s t r o w s ;

111 101/210 Optimiseur Oracle Mode CHOOSE de l Optimiseur Obejectif de l optimiseur : tenter de tout exécuter en mémoire centrale et donc diminuer au maximum les E/S (hit Ratio) Utilisation des calculs statistiques du catalogue Oracle (dba_tables, dba_indexes, les vues V$, etc...) pour générer le plan d exécution des requêtes

112 102/210 Optimiseur Oracle Mode CHOOSE de l Optimiseur En mode CHOOSE, la présence de statistiques dans le dictionnaire détermine si l optimiseur statistique est utilisé Pas de mise à jour régulière des catalogues par Oracle Le DBA qui doit donc s en charger Récupération de la date de dernier calcul des statistiques : Requête dans la vue DBA_TAB_COLUMNS pour afficher l information LAST_ANALYZED s e l e c t owner, table name, l a s t a n a l y z e d from d b a t a b c o l u m n s where l a s t a n a l y z e d > 01 JAN 00 ;

113 103/210 Statistiques Collecte des statistiques Calcul des statistiques d objets : Utilisation de la commande ANALYZE pour : collecter ou supprimer des statistiques des tables (ou partition de table), d index (ou partition d index), cluster,... valider la structure des tables (ou partition de table), d index (ou partition d index), cluster,... identifier des lignes migrées ou chainées d une table d un cluster,...

114 104/210 Statistiques Collecte des statistiques d une table Analyse statistique d une partition (estimation sur la totalité de la partition) ANALYZE TABLE emp PARTITION ( p1 ) COMPUTE STATISTICS ; Analyse statistique et validation de la structure d une table ANALYZE TABLE emp VALIDATE STRUCTURE; Analyse statistique d une partie d une table (exemple 33 %) ANALYZE TABLE emp ESTIMATE STATISTICS SAMPLE 33 p e r c e n t ; Analyse statistique d une table ainsi que de ses indexes ANALYZE TABLE emp COMPUTE STATISTICS FOR ALL INDEXED COLUMNS;

115 105/210 Statistiques Collecte des statistiques d une Index Analyse statistique et validation de la structure d un index ANALYZE INDEX p a r t s i n d e x VALIDATE STRUCTURE; Analyse statistique ( sur la totalité de l index) ANALYZE INDEX i n d x 1 COMPUTE STATISTICS ; Analyse statistique d une partie d un index (exemple 44 %) ANALYZE INDEX p a r t s i n d e x ESTIMATE STATISTICS SAMPLE 44 p e r

116 106/210 Statistiques Suppression des statistiques d une table et des index ANALYZE TABLE emp DELETE STATISTICS

117 Statistiques Quelle est la quantité optimale des statistiques nécessaire? 107/210 Si estimation des statistiques des objets en se fondant sur un échantillon (estimate) : La taille de celui-ci doit être appropriée Élément essentiel pour fournir à l optimiseur des statistiques dotées d un bon intervalle de confiance Un niveau de 20% est souvent utilisé et semble approprié Si choix de calculer les statistiques (compute) : Niveau de confiance : 100% Et les statistiques doivent être parfaitement précises Nécessite des ressources et du temps pour réaliser ces calculs

118 Statistiques Quelle est la quantité optimale des statistiques nécessaire? 108/210 S il s agit d Oracle 8i ou supérieur, le package DBMS_STATS pourra analyser les tables en parallèle Si exécution d une commande analyze estimate sur une taille d échantillon > 49% : le module calculera les statistiques sur l ensemble de la table