Vous êtes sur la page 1sur 177

Administration de Bases de Données

Optimisation

Thierry Hamon

Bureau H202
Institut Galilée - Université Paris 13
&
LIMSI-CNRS
hamon@limsi.fr
https://perso.limsi.fr/hamon/Teaching/P13/BDA-AIR3-2016-2017/

AIR3 – ABD

1/169
Optimisation des performances
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

2/169
Optimisation des performances
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.)

3/169
Optimisation des performances
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.)

4/169
Optimisation des performances
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 ?

5/169
Optimisation des performances
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

6/169
Optimisation des performances
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.

7/169
Optimisation des performances
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

7/169
Optimisation des performances
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.

8/169
Optimisation des performances
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.

8/169
Optimisation des performances
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

8/169
Optimisation des performances
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

9/169
Optimisation des performances
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

10/169
Optimisation des performances
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

11/169
Optimisation des performances
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’ils  collent  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 

12/169
Optimisation des performances
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

13/169
Optimisation des performances
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, ...)

14/169
Optimisation des performances
Optimisation logique

Normalisation
Exemple

Avant normalisation :
Relation1 ( Attribut1 , Attribut2 , . . . )

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 :
Relation11 ( Attribut11 , Attribut12 , . . . )
Relation21 ( Attribut21 , Attribut22 , . . . )

15/169
Optimisation des performances
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

16/169
Optimisation des performances
Optimisation logique

Normalisation
Illustration

Format d’une relation  bien conçue 

17/169
Optimisation des performances
Optimisation logique

Normalisation
Exemple

Soit la relation :
ADRESSES ( V i l l e , Numéro , Rue , C o d e P o s t a l )

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 ( C o d e P o s t a l , Rue )
CPV ( C o d e P o s t a l , V i l l e )

18/169
Optimisation des performances
Optimisation logique

Normalisation
Exemple

ADRESSES
VILLE NUMERO RUE CODE POSTAL
Paris 6 Rue de la Rosière 75015
Paris 16 Rue de la Rosière 75015
Paris 51 Rue des Entrepreneurs 75015
Paris 55 Rue des Entrepreneurs 75015
Paris 8 Avenue des Champs Elysées 75008
Epinay sur Seine 23 Boulevard Foch 93800

CPR CPV
CODE POSTAL RUE CODE POSTAL VILLE
75015 Rue de la Rosière 75008 Paris
75015 Rue des Entrepreneurs 75015 Paris
75008 Avenue des Champs Elysées 93800 Epinay sur Seine
93800 Boulevard Foch

19/169
Optimisation des performances
Optimisation logique

Normalisation
Exemple
Un client a une adresse :
SLD version 1
CLIENT ( C o d e C l i , NomCli , PrénomCli ,
Numéro , Rue , C o d e P o s t a l , V i l l e )

SELECT ∗ FROM CLIENT ;


SLD version 2
CLIENT ( C o d e C l i , NomCli , PrénomCli ,
Numéro , A d r C l i ∗ )
ADRCPR ( A d r C l i , Rue , C o d e P o s t a l ∗ )
ADRCPV ( C o d e P o s t a l , 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 . C o d e P o s t a l=ADRCPV . C o d e P o s t a l ;

20/169
Optimisation des performances
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

21/169
Optimisation des performances
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

22/169
Optimisation des performances
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

23/169
Optimisation des performances
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

24/169
Optimisation des performances
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énients 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

25/169
Optimisation des performances
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 ;

26/169
Optimisation des performances
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, V i l C , C o u t i n s c , 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

26/169
Optimisation des performances
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

26/169
Optimisation des performances
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 ;

26/169
Optimisation des performances
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é

27/169
Optimisation des performances
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 ( C o d e C l i , NomCli , . . . )
ARTICLE ( CodeArt , L i b A r t , . . . , P r i x A r t )
COMMANDE ( NumCom, C o d e C l i ∗ , DateCom )
DETAILCOM ( NumCom∗ , CodeArt ∗ , QtéComDée )

Requête : Montant de la commande ?

28/169
Optimisation des performances
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, C o d e C l i , DateCom , Montant )

SELECT NumCom, Montant


FROM COMMANDE ;

28/169
Optimisation des performances
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

29/169
Optimisation des performances
Optimisation logique

Optimisation logique de la Base de Données


Redondance calculée : dé-normalisation
Exemple

Soit la table
ARTICLE ( CodeArt , L i b A r t , . . . , P r i x A r t )
COMMANDE ( NumCom, C o d e C l i ∗ , 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 ) AS Montant
FROM DETAILCOM
GROUP BY NumCom ;

30/169
Optimisation des performances
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)

31/169
Optimisation des performances
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

32/169
Optimisation des performances
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

33/169
Optimisation des performances
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 ;

33/169
Optimisation des performances
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 ) ;

34/169
Optimisation des performances
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 t 2
where t 1 . t a b l e n a m e = t 2 . t a b l e n a m e ;

temps CPU : 1 091 480 u n i t é s 451 100 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 t 2
where t 1 . t a b l e n a m e = t 2 . t a b l e n a m e ;

temps CPU : 976 790 u n i t é s 690 690 u n i t é s

35/169
Optimisation des performances
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 : 138 350 u n i t é s 139 230 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 : 139 630 u n i t é s 139 890 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 t 1 where e x i s t s
( s e l e c t ∗ from a l l t a b l e s t 2 where
t1 . table name = t2 . table name ) ;

temps CPU : 177 580 u n i t é s 181 360 u n i t é s

36/169
Optimisation des performances
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 ;

37/169
Optimisation des performances
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 ) ;

38/169
Optimisation des performances
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 ;

39/169
Optimisation des performances
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)

40/169
Optimisation des performances
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

41/169
Optimisation des performances
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)

42/169
Optimisation des performances
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

43/169
Optimisation des performances
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)

44/169
Optimisation des performances
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)

45/169
Optimisation des performances
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

46/169
Optimisation des performances
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.

47/169
Optimisation des performances
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

48/169
Optimisation des performances
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

49/169
Optimisation des performances
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

50/169
Optimisation des performances
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 100 000

51/169
Optimisation des performances
Indexation

Taille d’une Table & Taille d’un Index


Exemple

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 10 @1
15 info2 10 @2
20 info3 10 @3
30 info4 10 @4
40 info5 10 @5
50 50
55 55
77 77
80 80
10 10
150 150

250 info k 250 @k

1610 info n 1610 @n

52/169
Optimisation des performances
Indexation

Taille d’une Table & Taille d’un Index


Exemple
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 30 @Bloc1
15 info2 77 @Bloc2
20 info3 150 @Bloc3
30 info4 1610 @Bloc4
40 info5
50 info6
55 info7
77 info8
80 info9
10 info10
150 info11

250 info k

1610 info n

53/169
Optimisation des performances
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 (100 000/4) = 25000 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 (100 000/36) = 2778 blocs d’index

54/169
Optimisation des performances
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

55/169
Optimisation des performances
Indexation

Index
Exemples

Index simple
c r e a t e i n d e x i d x n o f o u r on t t f o u r ( no four )

Index concaténé
c r e a t e i n d e x idx commande on ( no four , n c l i e n t )

56/169
Optimisation des performances
Indexation

Index
Exemples
index unique
c r e a t e unique i n d e x i d x u n i q u e
on t a b ( 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
m a x t r a n s 100
index non unique
create index i d x n o n u n i q u e
on t a b ( 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
m a x t r a n s 100
nologging

57/169
Optimisation des performances
Indexation

Index
manipulations

Modification d’un Index


A l t e r Index schema . n a m e i n d e x
i n i t r a n s integer
maxtrans integer
s t o r a g e ( i n i t i a l 100M next 20M)
logging | nologging

Reconstruction d’un Index


A l t e r Index p1 . IDX FOUR
R e b u i l d T a b l e s p a c e TBS INDEXES

58/169
Optimisation des performances
Indexation

Index
Manipulation

Modification d’un Index


A l t e r Index schema . n a m e i n d e x
i n i t r a n s integer
maxtrans integer
s t o r a g e ( i n i t i a l 100M next 20M)
logging | nologging

Catalogue Oracle pour la gestion des Index et des Clusters


S e l e c t ∗ from s y s . d b a u s e r s ;
S e l e c t ∗ from s y s . d b a i n d e x c o l u m n s ;

S e l e c t ∗ from s y s . d b a c l u s t e r s ;
S e l e c t ∗ from s y s . d b a c l u c o l u m n s ;

59/169
Optimisation des performances
Indexation

Index Bitmap

Création d’un index Bitmap (pour faible cardinalité)


c r e a t e bitmap i n d e x on t t f o u r
( dt livraison )
tablespace TBS Fournisseur ;

60/169
Optimisation des performances
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
( N u m c l i 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 t a b l e 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 i n d e x 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 ;

61/169
Optimisation des performances
Indexation

INDEX B-TREE
Préparation de l’utilisation de B-Tree
(à utiliser dans le cas d’une forte cardinalité)
SQL> DESC t 1 0 m a n c o p y
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 t o 1 0 0 0 0 0 . I u s e t h i s t a b l e t o 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 u s e MOD f u n c t i o n .
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 u s e t o c h a r t o make column l e n g t h e v e n .

∗∗∗∗∗∗∗∗∗∗ SQL t o make d a t a 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 , t o c h a r ( mod (EMPNO, 4 ) , ’ 0000000 ’ ) MGR,
HIREDATE , SAL ,COMM,DEPTNO
FROM T10MAN ORG ;

T a b l e c r e a t e d 0 0 0 0 0 0 0 , 0 0 0 0 0 0 1 , 0 0 0 0 0 0 2 , and 0000003 a r e s c a n n e d by t u r n s

62/169
Optimisation des performances
Indexation

INDEX B-TREE

Création d’un index B-Tree


SQL> SELECT MGR FROM T10MAN COPY 4 WHERE ROWNUM < 10 ;

MGR
−−−−−−−−
0000001
0000002
0000003
0000000
0000001
0000002
0000003
0000000
0000001

∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
SQL> CREATE INDEX BTREE 4 ON T10MAN COPY 4 (MGR)
STORAGE ( I N I T I A L 2K NEXT 2K PCTINCREASE 0 MAXEXTENTS UNLIMITED ) ;

63/169
Optimisation des performances
Optimisation des requêtes

Optimisation des requêtes

Visualisation :
Expression Algébrique
Arbre algébrique
Plan d’exécution de la requête

64/169
Optimisation des performances
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

65/169
Optimisation des performances
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= ’ e x e m p l e 1 ’ // i d e n t i f i a n t
FOR // e x e m p l e 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%’ ;

66/169
Optimisation des performances
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
| | ’ ’ | | o b j e c t n a m e ” P l a n 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

67/169
Optimisation des performances
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

68/169
Optimisation des performances
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

69/169
Optimisation des performances
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 v a r c h a r ( 1 5 ) , PRENOM v a r c h a r ( 1 5 ) ,
DATENAISSANCE date , SEXE c h a r ( 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) ,
c o n s t r a i n t FK PERSONNES PERE PERSONNES f o r e i g n key (PERE) r e f e r e n c e s PERSONNES ,
c o n s t r a i n t FK PERSONNES MERE PERSONNES f o r e i g n 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 c h e c k ( SEXE i n ( ’M’ , ’ F ’ ) ) );

70/169
Optimisation des performances
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 , il 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 ” P l a n 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

71/169
Optimisation des performances
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 n o m 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 ” P l a n 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

72/169
Optimisation des performances
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

73/169
Optimisation des performances
Optimisation des requêtes

Optimisation des requêtes


Requête avec un order by sur une table non indexée
drop i n d e x i nom ;

delete plan table ;

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 ” P l a n 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

74/169
Optimisation des performances
Optimisation des requêtes

Optimisation des requêtes


Requête avec un order by sur une table indexée
d r o p i n d e x i n o m ; c r e a t e i n d e x i n o m on e l e v e s ( nom ) ;
delete plan table ;

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 ” P l a n 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

75/169
Optimisation des performances
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

76/169
Optimisation des performances
Optimisation des requêtes

Optimisation des requêtes


Requête de jointure avec les deux tables indexées
delete plan table ;
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 co urs , p o i n t s from e l e v e s e ,
resultats 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 ” P l a n 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

77/169
Optimisation des performances
Optimisation des requêtes

Optimisation des requêtes


Requête de jointure avec les deux tables indexées
L’ordre des 2 tables change
delete plan table ;
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 co urs , p o i n t s from r e s u l t a t s r ,
eleves 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 | | ’ ’ | | options | | ’ ’ | |


o b j e c t n a m e ” P l a n d ’ e x é c u t i o n ” FROM plan table
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 id =’ requete3 ’ ;

Plan d’exécution
----------------------------------------------
SELECT STATEMENT
NESTED LOOPS
TABLE ACCESS FULL ELEVES
TABLE ACCESS BY INDEX ROWID RESULTATS
INDEX RANGE SCAN PK_RESULTATS

78/169
Optimisation des performances
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

79/169
Optimisation des performances
Optimisation des requêtes

Optimisation des requêtes


Requête de jointure avec les deux tables indexées et une sélection

delete plan table ;


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 co urs , p o i n t s from e l e v e s e ,
resultats r
where r . n u m e l e v e = 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 ” P l a n 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 ’ ;

80/169
Optimisation des performances
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

81/169
Optimisation des performances
Outils d’optimisation

Partie 2
Introduction

Présentation
des outils
des méthodes
pour assurer le suivi de la base et garantir sa performance

82/169
Optimisation des performances
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

83/169
Optimisation des performances
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

84/169
Optimisation des performances
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)

85/169
Optimisation des performances
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

86/169
Optimisation des performances
Optimiseur Oracle

Initialisation des Paramétrages 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 : ALL ROWS (valeur nécessaire pour
l’optimisation statistique)
Valeurs possibles (selon les versions d’oracle) : RULE (existant,
mais obsolète depuis 11g), FIRST_ROWS, ALL_ROWS,
FIRST_ROWS (1|10|100|1000), CHOOSE (existant, mais
obsolète depuis 11g)

Modification du paramètre au niveau session à l’aide de la


commande suivante :
A l t e r s e s s i o n s e t o p t i m i z e r m o d e= f i r s t r o w s ;

87/169
Optimisation des performances
Optimiseur Oracle

Mode RULE de l’Optimiseur

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.

88/169
Optimisation des performances
Optimiseur Oracle

Optimiseur statistique

Objectif de l’optimiseur statistique :


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

89/169
Optimisation des performances
Optimiseur Oracle

Optimiseur statistique

Remarques :
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 , t a b l e n a m e , 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 ’ ;

90/169
Optimisation des performances
Optimiseur Oracle

Modes de l’optimiseur statistique

Mode FIRST_ROWS : Utilisation des statistiques pour déterminer le


meilleur plan d’exécution permettant de retrouver rapidement les
premières lignes
Mode ALL_ROWS : Utilisation des statistiques pour déterminer le
meilleur plan d’exécution permettant de retrouver rapidement toutes
les lignes
Mode FIRST_ROWS (1|10|100|1000) : Utilisation des statistiques
pour déterminer le meilleur plan d’exécution permettant de
retrouver rapidement les n lignes
Mode CHOOSE : la présence de statistiques dans le dictionnaire
détermine si l’optimiseur statistique est utilisé (mode ALL_ROWS,
sinon RULE)

91/169
Optimisation des performances
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, ...

92/169
Optimisation des performances
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 ;

93/169
Optimisation des performances
Statistiques

Collecte des statistiques d’un 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

94/169
Optimisation des performances
Statistiques

Suppression des statistiques d’une table et des index

ANALYZE TABLE emp DELETE STATISTICS

95/169
Optimisation des performances
Statistiques

Quelle est la quantité optimale des statistiques nécessaire ?

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

96/169
Optimisation des performances
Statistiques

Quelle est la quantité optimale des statistiques nécessaire ?

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

97/169
Optimisation des performances
Statistiques

Nouveaux packages pour la génération des statistiques

DBMS_UTILITY.ANALYZE_SCHEMA : analyse des schémas


Oracle
DBMS_STATS : (nouveau package) statistique d’objets
d’Oracle8i

98/169
Optimisation des performances
Statistiques

DBMS UTILITY.ANALYZE SCHEMA

Analyse des schémas Oracle


Exécution de la procédure analyze_schema du package
DBMS_UTILITY
Exemple :
Execute d b m s u t i l i t y . a n a l y z e s c h e m a ( ’SCOTT ’ ,
’ e s t i m a t e ’ , e s t i m a t e p e r c e n t =>20) ;

99/169
Optimisation des performances
Statistiques

DBMS STATS

Nouveau package de statistiques d’objets d’Oracle8i


Exécution de calculs avec différentes options
Procédure Description
GATHER_INDEX_STATS Rassemblement de statistiques sur les
index
GATHER_TABLE_STATS Rassemblement de statistiques sur les
index, colonnes et tables
GATHER_SCHEMA_STATS Rassemblement de statistiques sur
tous les objets d’un schéma
GATHER_DATABASE_STATS Rassemblement de statistiques sur
tous les objets d’une base de données

100/169
Optimisation des performances
Statistiques

DBMS STATS

Exemple d’utilisation d’option : Procédure GATHER_TABLE_STATS


DBMS STATS . GATHER TABLE STATS
( ’DEV ’ , −−> Schéma
’ Contrat ’ , −−> T a b l e
NULL, −−> P a r t i t i o n
30 , −−> % de l ’ é c h a n t i l l o n
FALSE , −−> E c h a n t i l l o n de b l o c ?
’FOR ALL COLUMNS ’ , −−> C o l o n n e s
4, −−> Degré de p a r a l l é l i s m e
’DEFAULT ’ , −−> T a b l e e t t o u t e s l e s p a r t i t i o n s
TRUE) ; −−> C a s c a d e v e r s l e s i n d e x

101/169
Optimisation des performances
Statistiques

DBMS STATS

Explications :
La table CONTRAT du user DEV est analysée avec un degré
de parallélisme de 4
Toutes les colonnes sont analysées ainsi que les index
correspondants
L’analyse se fait avec une estimation de 30% au niveau ligne

102/169
Optimisation des performances
Statistiques

DBMS STATS
Syntaxe

BEGIN

DBMS STATS . g a t h e r t a b l e s t a t s ( ’DEV ’ , ’CONTRAT ’ ,


e s t i m a t e p e r c e n t => DBMS STATS . a u t o s a m p l e s i z e ,
CASCADE=>TRUE ) ;

END;

103/169
Optimisation des performances
Statistiques

Restauration des statistiques avec DBMS STATS

Si les statistiques :
semblent fausses
entraine l’Optimiseur à générer des mauvais plans d’exécution
Il faut restaurez les statistiques d’origines comme suit :
BEGIN
DBMS STATS . DELETE TABLE STATS ( ’ s c o t t ’ , ’ emp ’ ) ;
DBMS STATS . IMPORT TABLE STATS ( ’ s c o t t ’ , ’ emp ’ ,
s t a t t a b => ’ s a v e s t a t s ’ ) ;
END;

104/169
Optimisation des performances
Statistiques

Fréquence des statistiques

A quelle fréquence les statistiques doivent être calculées ?

→ Cela dépend
du taux
du volume de changement des données dans la base

105/169
Optimisation des performances
Suivi des Indicateurs

Suivi des Indicateurs

Indicateurs :
Ratios
Alertes (corruption, messages d’erreurs etc.) et les traces
Vues de dépannage et réglage
Tuning des I/O des requêtes couteuses

106/169
Optimisation des performances
Suivi des Indicateurs

Ratios de la base

Buffer cache hit Rate


nombre de fois qu’un block utile à la requête existe dans le
buffer cache
→ il faut que ce pourcentage soit proche de 90%
s e l e c t r o u n d ((1 −( p r . v a l u e / ( bg . v a l u e+cg . v a l u e ) ) ) ∗ 1 0 0 , 2 )
from v $ s y s s t a t pr , v $ s y s s t a t bg , v $ s y s s t a t cg
where p r . name= ’ p h y s i c a l r e a d s ’ −− l e c t u r e s d i s q u e
and bg . name= ’ db b l o c k g e t s ’ −− l e c t u r e s mémoire
and cg . name= ’ c o n s i s t e n t g e t s ’ ; −− l e c t u r e s mémoire

Objectif : avoir en mémoire l’information dont on a besoin


Amélioration de ce ratio : augmenter le db_block_buffers

107/169
Optimisation des performances
Suivi des Indicateurs

Ratio de la base

Library cache get hit Rate


Proportion des requêtes pour obtenir un verrou sur un objet
Les requêtes sont satisfaite en trouvant le descripteur de
l’objet qui doit déjà être en mémoire
ce pourcentage doit être proche de 90%
s e l e c t r o u n d (sum( g e t h i t s ) /sum( g e t s ) ∗ 1 0 0 , 2 )
from v $ l i b r a r y c a c h e ;

Amélioration des performances : Augmentation des valeurs


SHARED_POOL_SIZE, et OPEN_CORSORS dans init.ora

108/169
Optimisation des performances
Suivi des Indicateurs

Ratio de la base

Dictionary Cache Hit Ratio


Mesure du taux de requêtes pour obtenir des informations du
dictionnaire de données, des tables et des vues contenant des
informations sur
la base de données
les structures
les utilisateurs

109/169
Optimisation des performances
Suivi des Indicateurs

Ratio de la base

Remarque :
Au démarrage, le cache du dictionnaire de données est vide
Chaque requête SQL est absente du cache, et entraı̂ne un
défaut
Comme il y devrait y avoir de plus en plus de données lues
dans le cache, le nombre de défaut dans le cache diminuera
La base de données peut atteindre un état stable (steady
state) : les données du dictionnaires les plus fréquemment
utilisées sont dans le cache

110/169
Optimisation des performances
Suivi des Indicateurs

Ratio de la base

Exemple d’utilisation
s e l e c t sum( g e t s −g e t m i s s e s ) ∗ 1 0 0 /sum( g e t s )
from v $ r o w c a c h e ;

Cache du dictionnaire : stocké dans le Shared Pool (partie


du SGA)
Amélioration du ratio : augmentation de la taille du share
pool (SHARED_POOL_SIZE dans init.ora)

NB : A partir de la version 10g, la manipulation du catalogue


est devenue plus  intelligente 

111/169
Optimisation des performances
Suivi des Indicateurs

Ratio de la base

Sorts in Memory
Mesure de la proportion de données triées qui sont en
mémoire plutôt que sur le disque
Exemple :
s e l e c t r o u n d ( (mem . v a l u e / (mem . v a l u e+d s k . v a l u e ) ) ∗ 1 0 0 , 2 )
from v $ s y s s t a t mem, v $ s y s s t a t d s k
where mem . name= ’ s o r t s ( memory ) ’ and
d s k . name= ’ s o r t s ( d i s k ) ’ ;

112/169
Optimisation des performances
Suivi des Indicateurs

Ratio de la base

Remarques :
Le tri sur disque utilise les tablespaces temporaires
La taille maximal du tri en mémoire est défini par la taille de la
zone de tri (sort area size) – taille dans lequel de PGA est
utilisé
Chaque processus Oracle effectuant un tri réserve autant de
mémoire, même s’il n’en a pas besoin.
L’utilisation de cette mémoire réduit celle disponible pour SGA
Optimisation : augmenter le paramètre SORT_AREA_SIZE
dans init.ora

113/169
Optimisation des performances
Alertes

Les alertes

Fichier alert_ORACLE_SID.log
Exemple : alert_bdaINFO2.log
Contenu d’un fichier d’alerte :
des informations utilisées par le DBA de la base pour une
maintenance, un suivi, ... de la base Oracle
Des traces sont rajoutées dans le fichier Log suite à :
un démarrage de la base,
un arrêt de la base,
une création ou la mise à jour d’un tablespace,
une création, ou la mise à jour d’un rollback segment,
etc ...

114/169
Optimisation des performances
Alertes

Les alertes

Fichiers de trace Oracle_Sid_numero.trc


Ces fichiers contiennent des informations :
utile pour l’optimisation de la base : traces générées par les
utilitaires tkprof, statpack, utlbstat, etc.
ou permettent au DBA, de suivre et de corriger des erreurs,
afin d’éviter le plantage, ou un mauvais fonctionnement de la
base Oracle

115/169
Optimisation des performances
Alertes

Exemple de fichier d’alerte


F r i Sep 12 1 1 : 4 6 : 0 1 2003
S t a r t i n g ORACLE i n s t a n c e ( n o r m a l )
LICENSE MAX SESSION = 0
LICENSE SESSIONS WARNING = 0
LICENSE MAX USERS = 0
S t a r t i n g up ORACLE RDBMS V e r s i o n : 8 . 1 . 7 . 0 . 0 .
System p a r a m e t e r s w i t h non−d e f a u l t v a l u e s :
processes = 320
sessions = 357
timed statistics = TRUE
nls territory = FRANCE
nls date format = YYYY−MM−DD
nls numeric characters = .,
control files = ${ORACLE HOME}/ d b s / o r a d a t a 1 / DWH ctl 1 . c t l ,
${HOME}/ dbdc / o r a c l e / d b s / o r a d a t a 8 / DWH ctl 2 . c t l
db block buffers = 65536
db block size = 16384

ORA−1652: u n a b l e t o e x t e n d temp se gme nt by 64 i n t a b l e s p a c e S TBS INDX


Wed Dec 3 1 2 : 2 5 : 4 9 2003
ORA−1652: u n a b l e t o e x t e n d temp se gme nt by 6400 i n t a b l e s p a c e S TBS DATA
Wed Dec 3 1 2 : 2 8 : 5 1 2003
ALTER TABLESPACE S TBS DATA ADD DATAFILE
’ c : \ o r a c l e \ o r a n t \ o r a d a t \ d b s \TBS DWH DATA 1 . d b f ’ SIZE 512M AUTOEXTEND OFF
Wed Dec 3 1 2 : 2 8 : 5 9 2003

116/169
Optimisation des performances
Catalogue Oracle

Catalogue Oracle:Instance et base de données

V$database : description de la base


V$instance : description de l’instance
V$parameter : paramètres de la base
V$process~: nombre de process actifs
V$waitstat~: statistiques relatives aux attentes
V$system_event : attentes totales pour des évènements
particuliers

117/169
Optimisation des performances
Catalogue Oracle

Parametres de la base : v$parameter


S e l e c t Name , Type , Value , description from v $ p a r a m e t e r

NAME TYPE VALUE DESCRIPTION


timed statistics 1 TRUE maintain i n t e r n a l timing s t a t i s t i c s
trace enabled 1 TRUE e n a b l e KST t r a c i n g
sql trace 1 FALSE e n a b l e SQL t r a c e
db name 2 dwh d a t a b a s e name s p e c i f i e d i n
CREATE DATABASE
utl file dir 2 ∗ utl file accessible directories l i s t
instance name 2 BCR D i n s t a n c e name s u p p o r t e d by t h e i n s t a n c e
db block size 3 16384 Size of database block in bytes
open cursors 3 500 max # c u r s o r s p e r s e s s i o n
sort area retained size 3 6000000 s i z e o f i n−memory s o r t work a r e a
r e t a i n e d between f e t c h ca
db file multiblock read count 3 4 db b l o c k t o be r e a d e a c h IO
max enabled roles 3 148 max number o f r o l e s a u s e r can h a v e
enabled
max rollback segments 3 78 max . number o f r o l l b a c k s e g m e n t s i n
SGA c a c h e
sga max size 6 1178569392 max t o t a l SGA s i z e
shared pool reserved size 6 26843545 size in bytes of reserved area of
shared pool
large pool size 6 0 s i z e in bytes of the l a r g e a l l o c a t i o n
pool
java pool size 6 33554432 s i z e i n b y t e s of the Java pool

118/169
Optimisation des performances
Catalogue Oracle

Statistiques relatives aux attentes

S e l e c t ”CLASS” , ”COUNT” , ”TIME” from v $ w a i t s t a t ;

CLASS COUNT TIME

data block 19866 26102


sort block 0 0
s a v e undo b l o c k 0 0
segment he a d e r 5301 4161
s a v e undo h e a d e r 0 0
free l i s t 0 0
e x t e n t map 0 0
1 s t l e v e l bmb 0 0
2 nd l e v e l bmb 0 0
3 r d l e v e l bmb 0 0
bitmap b l o c k 0 0
bitmap index b l o c k 0 0
f i l e header block 0 0
unused 0 0
s y s t e m undo h e a d e r 0 0
s y s t e m undo b l o c k 0 0
undo h e a d e r 1933 397
undo b l o c k 44 3

119/169
Optimisation des performances
Catalogue Oracle

Attentes totales pour des évènements particuliers

s e l e c t event , t o t a l w a i t s , a v e r a g e w a i t from v $ s y s t e m e v e n t ;

EVENT TOTAL WAIT AVERAGE WAIT

latch free 3740 1


pmon t i m e r 1929737 293
enqueue 10937 103
c o n t r o l f i l e s e q u e n t i a l read 596427 0
control f i l e p a r a l l e l write 1870221 3
b u f f e r busy w a i t s 27144 1
log f i l e s e q u e n t i a l read 1571 0
log f i l e s i n g l e write 1562 1
log f i l e p a r a l l e l write 443272 0
LGWR w a i t f o r r e d o c o p y 12490 0
db f i l e s e q u e n t i a l r e a d 173476 0
db f i l e s c a t t e r e d r e a d 1010050 0
db f i l e s i n g l e w r i t e 104 1
db f i l e p a r a l l e l w r i t e 37096 3
db f i l e p a r a l l e l r e a d 1 6
l i b r a r y cache pin 139 285
l i b r a r y cache l o c k 149 11
l i b r a r y cache load l o c k 3 0

120/169
Optimisation des performances
Catalogue Oracle

Catalogue d’Oracle : Disques

V$datafile : liste des fichiers des données


V$filestat : statistiques relatives aux I/O dans les fichiers
de données
V$tempstat : informations sur les statistiques relatives aux
opérations des I/O pour les fichiers de données des TBS
temporaires
V$segment_statistics : statistiques sur les I/O par
segments

121/169
Optimisation des performances
Catalogue Oracle

Catalogue d’Oracle : Contention

V$lock : verrou externe


V$latch : verrou interne d’Oracle
V$rollstat : statistiques sur les segments d’annulation
V$process : nombre de process actifs
V$waitstat : statistiques sur les contention des blocks

122/169
Optimisation des performances
Catalogue Oracle

Catalogue d’Oracle : Mémoire

V$buffer_pool_statistics : statistiques sur buffer pool


V$db_object_cache : objets de la base, dans le cache
V$rowcache : échec et succès dans le dictionnaire
V$sysstat : statistique sur l’instance d’Oracle
V$librarycache : statistiques sur le librarycache

123/169
Optimisation des performances
Catalogue Oracle

Catalogue d’Oracle : Session

V$session : liste des sessions


V$sesstat : statistiques des sessions
V$session_event : informations sur les attentes d’une
session
V$session_wait : attentes des sessions actives
V$waitstat : statistiques relatives aux attentes
V$open_cursor : liste des curseurs ouverts

124/169
Optimisation des performances
Optimisation des applications – Recettes

Comment améliorer le temps de réponse des applications ?

Partitionnement
Exécution parallèle
Tuning des entrées/sorties
Détection des lignes chaı̂nées ou migrées
Détection des Index inutilisés
Réorganisation des index
Utilisation des Hints
Codes SQL à ne pas utiliser

125/169
Optimisation des performances
Optimisation des applications – Recettes

Création d’une table partitionnée sous Oracle

Create t a b l e f a c t u r e
( n u m f a c t number ( 5 ) ,
n u m a r t i c l e number ( 5 ) ,
d a t e v e n t e date
)
P a r t i t i o n by r a n g e ( d a t e v e n t e )
(
p a r t i t i o n p 200312 values l e s s than
( t o d a t e ( ’ 2004−01−01 ’ , ’YYYY−MM−DD ’ ) ) ,
p a r t i t i o n p 200406 values l e s s than
( t o d a t e ( ’ 2004−07−01 ’ , ’YYYY−MM−DD ’ ) ) ,
p a r t i t i o n p 200412 values l e s s than
( t o d a t e ( ’ 2005−01−01 ’ , ’YYYY−MM−DD ’ ) )
)

126/169
Optimisation des performances
Optimisation des applications – Recettes

Exécution parallèle de la création d’index sous Oracle

Create i n d e x i d x t l c n t 1 on t l c n t ( n 0 c n t )
Tablespace tbs index
S t o r a g e ( i n i t i a l 10M next 5M)
parallele 3
Nologging
Local ;

127/169
Optimisation des performances
Optimisation des applications – Recettes

Tuning des Entrées/sorties

Desc V$filestat
file# : numéro du fichier
phyrds : lecture disque
phywrts : écriture disque
phyblkrd : nbre de block disque lus
phblkwrt : nombre de block disque écrits
readtim : temps de lecture
writetim : temps d’écriture

128/169
Optimisation des performances
Optimisation des applications – Recettes

Tuning des Entrées/sorties

Pour les fichiers dont la colonne phyrds est importante :


vérifier si les tables sont accédées en full scan
S e l e c t name , v a l u e from V$SYSSTAT
Where name l i k e ’%t a b l e s c a n ( l o n g% ’

Si la valeur value est importante : vérifier les applications ...


→ Définir les bons index

129/169
Optimisation des performances
Optimisation des applications – Recettes

Détection des lignes chaı̂nées ou migrées

Détection de l’état de chaı̂nage d’une table


Analyze table scott .EMP compute statistics
S e l e c t num rows , c h a i n c n t
from d b a t a b l e s
where t a b l e n a m e = ’EMP ’ ;

→ Augmenter la valeur de pctfree de la table EMP

130/169
Optimisation des performances
Optimisation des applications – Recettes

Détection des lignes chaı̂nées ou migrées

Etat de chaı̂nage au niveau de la base


Détection de l’état de chaı̂nage au niveau de la base :
s e l e c t ∗ from v $ s y s s t a t
where s t a t i s t i c = ’ T a b l e F e t c h C o n t i n u e d Row ’ ;

131/169
Optimisation des performances
Optimisation des applications – Recettes

Détection des Index inutilisés

Alter index nom index monitoring usage;

Select index name , used


From v $ o b j e c t u s a g e
where i n d e x n a m e = ’NOM INDEX ’ ;

Alter index nom index nomonitoring usage;

132/169
Optimisation des performances
Optimisation des applications – Recettes

Stratégies d’indexation

Quand faut-il utiliser les index ?


Construction d’index optimaux
Quelques options d’indexation :
Non-unique index (index avec doublons)
Unique index (index sans doublons)
Bitmap index
Hash partitionned index
Composite partitioned index
Reverse-key index
Function-based index
Descending index
etc.

133/169
Optimisation des performances
Optimisation des applications – Recettes

Stratégies d’indexation

Index de fonction :
Create i n d e x i d x c l t s n o m p r e n
on c l i e n t ( upper ( nom ) , prenom ) ;
Create i n d e x i d x c l t s c a
on c l i e n t ( c a l c u l c a ( i d c l i e n t ) ) ;
−−− c a l c u l c a e s t une p r o c é d u r e PL/SQL

Quand faut-il reconstruire les index ?

134/169
Optimisation des performances
Optimisation des applications – Recettes

Réorganiser/Reconstruire un index ?

EXECUTE d b m s s t a t s . g a t h e r i n d e x s t a t s
( ’SCOTT ’ , ’ INDEX 1 ’ ) ;

→ Équivalent de ANALYZE INDEX VALIDATE STRUCTURE


Desc Index_stats

lf_rows : Nombre de valeurs présentes dans index


lf_rows_len : Longueur de l’index (en octets)
Del_lf_rows : Nombre de valeur supprimées
del_lf_rows_len : Longueur d’index supprimées (en octets)

135/169
Optimisation des performances
Optimisation des applications – Recettes

Réorganiser/Reconstruire un index ?

Quand reconstruire un index ?

S e l e c t name ,
( d e l l f r o w s l e n , / l f r o w s l e n )∗100 moyen del
from i n d e x s t a t s ;

→ si moyen_del > 20% alors reconstruire index


a l t e r index s c o t t . i n d e x 1 r e b u i l d ;

136/169
Optimisation des performances
Optimisation des applications – Recettes

Utilisation des hints


Hint :
indication placée dans une requête pour orienter le plan
d’exécution
ressemble beaucoup à un commentaire, à l’exception du +
après le /*
Exemple :
SELECT /∗+ LE HINT ∗/ c o l o n n e ( s ) FROM t a b l e ( s ) WHERE . . . ;

Remarques :
Il est très important de placer le hint à l’emplacement
approprié du code SQL, idéalement avant la référence à la
première colonne du code SQL
Si le hint inclus est incorrect il sera tout simplement ignoré
par l’optimiseur, sans affichage de la moindre erreur !

137/169
Optimisation des performances
Optimisation des applications – Recettes

Utilisation des hints


Exemple/syntaxe générique :
SELECT /∗+ LE HINT ∗/ c o l o n n e ( s ) FROM t a b l e ( s ) WHERE . . .

Instantiation de LE_HINT :

FULL(table) : Parcours de toute la table (sans utiliser l’index)


INDEX(table, index) : Force l’utilisation de l’index de la table
NO_INDEX(table, index) : Désactivation de l’index de la table
ORDERED : Force l’ordre de jointure des tables, telles qu’elles
apparaissent dans la clause From
FIRST_ROWS : Force Oracle à choisir le plan d’exécution qui re-
tourne les n premières lignes de manière la plus effi-
cace
PARALLEL(table, n) : Spécification des n serveurs concurrent pouvant être
utilisés pour une requête
etc. :
(voir : http://docs.oracle.com/cd/B19306_01/server.102/b14211/hintsref.htm#i8327)

138/169
Optimisation des performances
Optimisation des applications – Recettes

Utilisation des hints

Outils d’aide :
PRECISE : suivi d’une base de production
TOAD : suivi du passage du prototypage à la production
OEM : Oracle Entreprise Manager
etc.

139/169
Optimisation des performances
Optimisation des applications – Recettes

Utilisation des hints

Utilisation ORDERED : impose à l’optimiseur d’utiliser les tables


dans l’ordre d’apparition dans la requête SQL
S e l e c t /∗ + ORDERED ∗/ d . d e p a r t e m e n t n a m e , e . surname
from e m p l o y e e s e , d e p a r t e m e n t d
where d . d e p a r t e m e n t i d=e . d e p a r t e m e n t i d
and d . d e p a r t e m e n t n a m e = : 1 ;

140/169
Optimisation des performances
Optimisation des applications – Recettes

Utilisation des hints

Utilisation INDEX : impose à l’optimiseur d’utiliser les indexes


spécifiés par le Hint INDEX
S e l e c t /∗ + INDEX ( e , e m p l o y e i d x ) ∗/ nom
from e m p l o y e e s e
where e . d e p a r t e m e n t i d = : 1
and e . m a n a g e r i d = : 2 ;

ALTER SESSION SET o p t i m i z e r g o a l= r u l e |


f i r s t r o w s | a l l r o w s | choose ;

141/169
Optimisation des performances
Optimisation des applications – Recettes

Différents types de hints

Optimisation :
FIRST_ROWS, ALL_ROWS : Force Oracle à utiliser les premières
ou toutes les lignes
ORDERED : Accès aux tables dans l’ordrede de la clause FROM
Accès: FULL(tab), ROWID, PARALLEL

142/169
Optimisation des performances
Optimisation des applications – Recettes

Impact des Hints – Exemple

SQL> EXPLAIN PLAN


2 SET s t a t e m e n t i d = ’ r e q u e t e 4 ’
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 , resultats r
4 where r . n u m e l e v e = e . n u m e l e v e and e . n u m e l e v e = 10 ;

SQL> 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 ” P l a n d ’ e x é c u t i o n ”
2 FROM p l a n t a b l e
3 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 ’
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 ’ ;

P l a n d ’ e x é c u t i o n
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
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

6 l i g n e ( s ) s é l e c t i o n n é e ( s ) .

143/169
Optimisation des performances
Optimisation des applications – Recettes

Impact des Hints


Exemple

SQL> EXPLAIN PLAN


2 SET s t a t e m e n t i d = ’ r e q u e t e 4 ’
3 FOR s e l e c t /∗+ FULL ( e l e v e s ) FULL ( r e s u l t a t s ) ∗/ 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
4 where r . n u m e l e v e = e . n u m e l e v e and e . n u m e l e v e = 10 ;
E x p l i c i t é .

SQL> 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 ” P l a n d ’ e x é c u t i o n ”
2 FROM p l a n t a b l e
3 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 ’
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 ’ ;

P l a n d ’ e x é c u t i o n
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
SELECT STATEMENT
HASH JOIN
TABLE ACCESS BY INDEX ROWID ELEVES
INDEX RANGE SCAN PK ELEVES
TABLE ACCESS BY INDEX ROWID RESULTATS
INDEX RANGE SCAN PK RESULTATS

6 l i g n e ( s ) s é l e c t i o n n é e ( s ) .

144/169
Optimisation des performances
Optimisation des applications – Recettes

Impact des Hints


Exemple

Sans le Hint :
P l a n d ’ e x é c u t i o n
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
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

Avec le Hint : FULL(eleves) et FULL(resultat)


P l a n d ’ e x é c u t i o n
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
SELECT STATEMENT
HASH JOIN
TABLE ACCESS BY INDEX ROWID ELEVES
INDEX RANGE SCAN PK ELEVES
TABLE ACCESS BY INDEX ROWID RESULTATS
INDEX RANGE SCAN PK RESULTATS

145/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire


Premier exemple
Eviter l’utilisation des index dans les clauses where
→ Consultation par les instructions SQL d’un plus grand
nombre de blocs de données
en utilisant l’index
plutôt qu’en exécutant un balayage complet de la table
Amélioration :
ajout d’une expression anodine à la colonne d’index
Par exemple :
ajout de +0 à une colonne numérique
concaténation d’une chaı̂ne vide à une colonne alphanumérique
positionnement du hint :
/∗+ FULL s i v o u s u t i l i s e z l ’ o p t i m i s e u r s t a t i s t i q u e .

S e l e c t /∗+ FULL (EMP) PARALLEL (EMP, 2 ) ∗/ from EMP


Where . . . . . .

146/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire


Deuxième exemple

Eviter de mélanger ou de comparer des valeurs et des types de


données de colonnes
→ l’optimiseur ignorera l’index
Améliorations :
Si le type de colonne est NUMBER : ne pas ’utiliser de guillemets
pour encadrer la valeur
Ne pas oublier d’encadrer une valeur avec ses guillemets
lorsqu’elle est définie comme de type alphanumérique

Select ... from EMP where SALARY > ’ 1000 ’ ; −− Mauvais


Select ... from EMP where SALARY > 1000 ; −− Bon
Select ... from EMP where MANAGER = SMITH ; −− Mauvais
Select ... from EMP where MANAGER = ’SMITH ’ ; −− Bon

147/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire


Troisième exemple : Ne pas utiliser l’opérateur IS NULL dans
une colonne indexée
→ l’optimiseur ignorera l’index
SELECT N emp , name , a d r from EMP name i s n u l l ;
NB: ce n’est plus vrai avec Oracle 11g
Quatrième exemple :
En cas d’utilisation de curseurs ou du SQL dynamique : ne pas
coder pas ls instruction avec des valeurs en dur
Empêche la réutilisation du code SQL dans le pool partagé
→ Utiliser des variables liées :
S e l e c t . . . from EMP where EMPNO = 2324 ; −− Mauvais
S e l e c t . . . from EMP where EMPNO = : 1 ; −− Bon
EXECUTE IMMEDIATE ’ D e l e t e from EMP w h e r e EMPNO = 2324 ’ ; −− Mauvais
EXECUTE IMMEDIATE ’ D e l e t e from EMP w h e r e EMPNO = : 1 ’ USING v a r i a b l e ; −− Bon

148/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire

Amélioration de l’utilisation des bind variables à partir de


Oracle 8i
→ Insertion du paramètre CURSOR_SHARING=force dans le
fichier init.ora
NB :
Possibilité de définir le paramètre au niveau session
Mais possibilité d’augmentation des délais d’analyse
Il peut être préférable de réécrire le code

149/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire


Pas d’instruction Insert, update ou delete dans une itération
(une boucle PL/SQL) si les opérations peuvent être réalisées
en vrac (bulk)
Declare
C u r s o r . . . s e l e c t from X
Begin
For C u r s o r i n . . . Loop
Insert into Z
values ( Cursor . col1 , Cursor . col2 ∗1.5 , ... ) ;
Commit ;
End l o o p ;
End ; −− Mauvais

Begin
I n s e r t i n t o Z s e l e c t c o l 1 , c o l 2 ∗ 1 . 5 from X where ;
Commit ;
End ; −− Bon

150/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire


Evitez l’utilisation des sous-requêtes
→ Impact négatif sur les performances de votre système en
consommant beaucoup de ressources CPU
Solution : utilisation des vues en ligne (inline views),
c’est-à-dire des sous-requêtes dans la clause from de
l’instruction select, disponible depuis la version 7.3
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 t i d = e . d e p t i d ) ; −− M a u v a i s

S e l e c t e . ∗ from EMP e ,
( s e l e c t i . d e p t i d DEP , avg ( i . s a l a r y ) SAL from EMP I
group by d e p t i d ) EMP VUE
where e . d e p t i d = EMP VUE . d e p t i d and
e . s a l a r y > EMP VUE . SAL ; −− Bon

151/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire

Evitez les produit cartesien


Ne pas construire la clause from d’une instruction select
avec des tables qui n’apparaissent pas dans les conditions de
jointure de la clause where afin d’éviter de réaliser un produit
cartésien
Regrouper la création des tables et l’insert
Si la table est créée et alimentée, regrouper l’opération :
C r e a t e t a b l e X ( c o l 1 number , c o l 2 v a r c h a r 2 ( 3 0 ) . . . ) ;
I n s e r t i n t o X s e l e c t c o l 1 , c o l 2 from Y . . . ; −− M a u v a i s

C r e a t e t a b l e X ( c o l 1 number , c o l 2 v a r c h a r 2 ( 3 0 ) ... )
as s e l e c t col1 , c o l 2
from Y . . . ; −− Bon

152/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire

Eviter l’utilisation de select x from dual


Bien qu’elle semble innocente, elle peut consommer l’essentiel
des performances de votre système
For i i n 1 . . 1 0 0 0 0 l o o p
S e l e c t SEQ . NEXTVAL i n t o m a v a r i a b l e from d u a l ;
Insert into X values ( mavariable , . . . ) ;
End l o o p ; −− Mauvais

For i i n 1 . . 1 0 0 0 0 l o o p
I n s e r t i n t o X v a l u e s (SEQ . NEXTVAL, ... );
End l o o p ; −− Bon

153/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire


Eviter l’utilisation de NOT IN
Privilègier l’utilisation de NOT EXISTS plutôt que NOT IN dans
les clauses where (voir l’utilisation d’une jointure externe)
avec not in (lent)
S e l e c t a . nom , a . prenom
From S a l a r i e a
Where a . nom no t i n
( s e l e c t nom from F o n c t i o n
where j o b = ’INFORMATICEN ’ ) ;

avec jointure externe (plus rapide)


S e l e c t a . nom , a . prenom
From S a l a r i e a , F o n c t i o n b
Where a . nom = b . nom(+) and b . nom i s NULL
And b . j o b = ’ INFORMATICIEN ’ ;

154/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire


Utiliser l’opérateur LIKE avec un caractère initial plutôt que la
fonction SUBSTR()
Dans le cas de requêtes très complexes contenant de
nombreuses conditions OR
Envisager leur réécriture à l’aide de UNION ALL
Possibilité de découpage de la requête en modules bien
dimensionnés qui pourront être optimisés plus facilement
Rappel :
Opérateur UNION : récupération de l’ensemble des
enregistrements retournés par les deux requêtes
Les doublons ne sont pas pris en compte
Opérateur UNION ALL : récupération de tous les
enregistrements y compris les doublons (contrairement à
l’opérateur UNION)

155/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire

Utiliser les index appropriés, les plus sélectifs


La sélectivité des données est le ratio entre le nombre de clés
uniques et le nombre de lignes
Plus elle approche 1.00, meilleur est l’index
Créer des index sur les colonnes de clés étrangères
Utiliser des index composites
Ceux-ci doivent être classés dans l’ordre décroissant de
sélectivité.

156/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire

Utiliser des index bitmaps lorsque la clause where


contient des colonnes à faible cardinalité ou des opérations
logiques comme OR, AND ou NOT exécutées sur ces colonnes
renvoit un grand nombre de lignes de la table
(sauf pour les tables supportant un grand nombre d’opérations
DML simultanées, du fait de leur comportement
intrinsèquement bloquant)

157/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire

Utiliser des single-table hashs ou des index clusters


Ces méthodes fournissent des performances excellentes sur les
tables relativement statiques mais interrogées sur une large
plage de valeurs
Sachant qu’un cluster enregistre les données dans un bloc de
manière ordonnée, un balayage de plages utilisant un index sur
ce cluster réalisera un plus petit nombre d’opérations
d’entrées-sorties pour répondre à la requête

158/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire

Choisir de manière active le type de jointure : nested loop,


merge join ou hash join
Lors de la jointure de trois tables ou plus, essayez de
structurer la requête pour réaliser l’élimination la plus forte
sur la première jointure
→ incorporer toutes les conditions sur une table dans la clause
where.
Privilégier le traitement en vrac (BULK COLLECT / FORALL)

159/169
Optimisation des performances
Optimisation des applications – Recettes

Les codes SQL à ne pas écrire


A partir d’Oracle 8i, remplacer DBMS_SQL par la nouvelle
fonctionnalité execute immediate (fonctionne nettement
mieux)
E x e c u t e immediate ’CREATE TABLE XX AS SELECT ∗ FROM YY ’ ;

En cas d’utilisation de l’optimiseur syntaxique (ce qui ne


devrait plus durer)
Structurer les clauses from de manière à ce que la table la
plus petite soit la dernière définie dans la liste des tables
S’il est nécessaire d’accélérer la création d’un index
Augmenter la valeur du paramètre SORT_AREA_SIZE au
niveau session
→ l’essentiel des tris seront exécutés en mémoire

160/169
Optimisation des performances
Optimisation des applications – Recettes

Vos requêtes SQL en mode trace

Les étapes du processus d’optimisation

Activation d’une session en mode trace

161/169
Optimisation des performances
Optimisation des applications – Recettes

Les étapes du processus d’optimisation


1 Vérifier que le paramètre TIMED_STATISTICS est positionné à TRUE au
niveau instance
2 Vérifier que la valeur du paramètre MAX_DUMP_FILE_SIZE est suffisante
Ce paramètre détermine la taille maximale du fichier de trace
3 Déterminer l’emplacement pointé par le paramètre USER_DUMP_DEST
USER_DUMP_DEST : indication de l’emplacement où les fichiers de trace
seront enregistrés
4 Activer le paramètre SQL_TRACE pour la session concernée
5 Exécuter l’application
6 Exécuter tkprof sur les fichiers de trace
7 Etudier le fichier de sortie de tkprof
8 Ajuster les instructions SQL les plus coûteuses
9 Répéter les étapes 4 à 8 jusqu’à ce que l’objectif de performance soit
atteint

162/169
Optimisation des performances
Optimisation des applications – Recettes

Les étapes du processus d’optimisation

Remarque : Ne pas positionner pas le paramètre SQL_TRACE à


TRUE dans le fichier init.ora :
Toutes les instructions SQL exécutées seraient enregistrées,
aboutissant à un ralentissement sensible du système, ainsi
qu’à la saturation du système de fichiers

163/169
Optimisation des performances
Optimisation des applications – Recettes

Activation d’une session en mode trace


Exécution de la commande suivante :
a l t e r session set t i m e d s t a t i s t i c s = true ;
a l t e r session set s q l t r a c e = true ;
...
−− e x e c u t i o n de v o s t r a i t e m e n t s . . .
...
a l t e r session set t i m e d s t a t i s t i c s = f a l s e ;
a l t e r session set s q l t r a c e = f a l s e ;
Remarques :
(à partir de la version 7.2) il est possible de désactiver la trace
à partir d’une autre session
Ne pas désactiver la trace en annulant la session (kill)
→ Peut provoquer la troncature du fichier de trace et/ou
introduire des informations erronées dans ce fichier

164/169
Optimisation des performances
TKPROF

TKPROF

Mettre la base ou la session en mode Trace :


Base : mettre SQL_TRACE=TRUE dans init.ora
Session :
a l t e r s e s s i o n s e t SQL TRACE TRUE

s e t a u t o t r a c e on

Utilisation de TKPROF : pour analyser le fichier trace


Syntaxe :
TKPROF fichier_entree.trc fichier_sortie
[Explain=username/password] [sys=no]
[insert=filename] [print=entier]

165/169
Optimisation des performances
TKPROF

Exemple de TKPROF

SELECT NVL(TO_CHAR(CG,’YYYYMMDD’),’ ’)||C01||C02||C03||C04||C05||C06||C07


FROM
D21V2_ENGSEC WHERE CB = :0000

call count cpu elapsed disk query current rows


------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 24562 2.64 2.66 0 0 0 0
Execute 24562 1.44 1.23 0 0 0 0
Fetch 24562 0.49 0.33 0 24562 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 73686 4.57 4.22 0 24562 0 0

Misses in library cache during parse: 0


Optimizer goal: RULE
Parsing user id: 34

Rows Row Source Operation


------- ---------------------------------------------------
0 TABLE ACCESS BY INDEX ROWID D21V2_ENGSEC
1 INDEX UNIQUE SCAN (object id 103435)

166/169
Optimisation des performances
TKPROF

Interprétation du résultat de TKPROF


Call : La phase du traitement de l’instruction SQL (
les phases define et bind sont incluses dans la phase parse
Count : Le nombre d’appels et d’exécutions d’une phase
CPU : Le temps CPU (en secondes) consommé pour
l’exécution d’une phase
Elapsed : Le temps CPU (en secondes) écoulé, cumulé avec
l’ensemble des temps utilisés par le SE pour
réaliser les changements de contexte
traiter les interruptions
répondre aux signaux
exécuter les entrées-sorties
attendre les ressources
etc.

167/169
Optimisation des performances
TKPROF

Interprétation du résultat de TKPROF

Disk : Le nombre de blocs Oracle lus sur le disque pour une


phase donnée
Query : Le nombre de blocs Oracle lus en mémoire en mode
cohérent (consistent mode)
Current : Le nombre de blocs Oracle lus en mémoire en
mode courant
Rows Le nombre de lignes traitées dans chaque phase, avec les
valeurs pour les instructions select dans la phase fetch, et
pour les opération insert, update dans la phase execute

168/169
Utilitaires et Outils d’optimisation

Utilitaires et Outils d’optimisation


Résumé

TOAD
OEM
TKPROF (outil capable de générer des traces)
UTLBSTAT/UTLESTAT
STATPACK (UTL et STAT sont des outils équivalents qui
permettent de recenser les requêtes les plus consommatrices)
Scripts du DBAs (le DBA doit développer ses scripts)

169/169

Vous aimerez peut-être aussi