Vous êtes sur la page 1sur 220

1/210

Bases de Donnees Avancees


Optimisation
Thierry Hamon
Bureau H202
Institut Galil
ee - Universit
e Paris 13
&
LIMSI-CNRS
hamon@limsi.fr
http://perso.limsi.fr/hamon/Teaching/BDA-20132014/

INFO2 BDA

2/210

Optimisation des performances


Introduction

Optimisation dune Application ?

Quand decide-ton doptimiser ?


Optimiser quoi ?
Qui participe, et Comment ?
Type de lapplication (TP ou Batch)
Interet de lapplication pour lentreprise

3/210

Optimisation des performances


Introduction

Quand decide-ton doptimiser ?

Application Batch
Lapplication nest pas disponible `a partir dune certaine heure

Application transactionnelle
Lutilisateur constate que le temps de reponse est inacceptable
(Agence de voyage, application interne, etc.)

4/210

Optimisation des performances


Acteurs

Qui participe et pourquoi ?


Adminstrateurs de DB, Developpeurs, Ingenieurs Syst`eme
(IS), Chef de projet
Definition de la puissance de la machine (Nombre de
processeurs, Capacite memoire, Espace disque necessaire en
fonction du type de lapplication)
Type du SGBD (Oracle, DB2, etc.)
Type de lapplication (Batch, TP)
Langage de programmation utilise (Java, PL/SQL, etc.)

5/210

Optimisation des performances


Acteurs

Role dun Administrateur dune Base de Donnees


(ABD ou DataBase Administrator DBA)

Double role de ladministrateur dune Base de Donnees :


role organisationnel
Definition du schema conceptuel des donnees
Partage de ces donnees par les utilisateurs

role technique
Mise en uvre ce schema
partage `a laide des capacites techniques du SGBD

6/210

Optimisation des performances


Acteurs

Role dun Administrateur dune Base de Donnees


r
ole technique

Installation du SGBD et des outils associes


Creation de la BD et ses composants conformement `a un
schema conceptuel
Surveillance de son evolution en modifiant, en creant ou en
supprimant certaines structures
Gestion des privil`eges dacc`es
Attribution et retrait de privil`eges dacc`es aux donnees aux
differents utilisateurs de la base de donnees

7/210

Optimisation des performances


Acteurs

Role dun Administrateur dune Base de Donnees


r
ole technique

Amelioration les performances


Choix de limplantation optimale des donnees de facon `a
obtenir les meilleures performances
Identification et prise en compte des utilisations qui seront
faites des donnees
Surveillance de la securite et la coherence des donnees
Mise en place de structures et de procedures permettant
de faire face `a tous les incidents
de retrouver lintegrite et la coherence des donnees

8/210

Optimisation des performances


Acteurs

Role dun Administrateur dune Base de Donnees


r
ole technique

Echange
les donnees entre la BD et le monde exterieur
Surveillance de lintegration des donnees en provenance
dautres applications ou BD
Migration des donnees de la base vers dautres applications ou
BD

Outils `a utiliser : SQL*DBA, SQL*Loader, SQLPLUS, etc.

9/210

Optimisation des performances


Objectifs

Quest-ce qui reste `a faire ?

Les besoins en puissance machine definis


Les acteurs administrateurs BD, (IS), developpeurs, etc. au
courant du projet (impliques, responsable de la reussite du
projet,..)
Optimisation de la base et de lapplication ?

10/210

Optimisation des performances


Objectifs

Sur quoi doit-on focaliser les efforts doptimisation ?


Partie N 1 : Conception des syst`emes dinformations et
optimisation des applications
Lors de la conception des syst`emes dinformations (si pas trop
tard)
Optimisation des applications

Partie N 2 : Presentation des outils pour assurer le suivi de la


base et garantir sa performance
Optimisation de la memoire
Optimisation des entrees/Sorties Disque
Identifier les contentions dans la base de donnees

11/210

Optimisation des performances


Objectifs

Sur quoi doit-on focaliser les efforts doptimisation ?


Partie N 1 : Conception des syst`emes dinformations et
optimisation des applications
Lors de la conception des syst`emes dinformations :
(Si pas trop tard)
Syst`eme non performant : resultat dune mauvaise definition
du mod`ele conceptuel
Mod`ele conceptuel : au moins sous la 3`eme forme Normale
(3NF)
Sauf dans quelque cas (choix volontaire) o`
u la
de-normalisation apporte une certaine performance au syst`eme
dinformation (Dataware house)
Lors de la conception : tenir compte lacc`es aux donnees
Analyse de la repartition des donnees :
replication de donnees (sur une ou plusieurs bases, etc.)
agregation des tables, pour les syst`emes decisionnels
etc.

11/210

Optimisation des performances


Objectifs

Sur quoi doit-on focaliser les efforts doptimisation ?


Partie N 1 : Conception des syst`emes dinformations et
optimisation des applications
Optimisation des applications :
lexperience montre que 80% des probl`emes de performances
des applications, sont resolus, par une optimisation des
requetes SQL
Ordonnancer les Batchs et eviter leur execution pendant des
heures ou lutilisation des machine est intense
Dispatcher les Batchs les plus consommateurs en puissance
machine `a des heures differentes

12/210

Optimisation des performances


Objectifs

Sur quoi doit-on focaliser les efforts doptimisation ?

Partie N 2 : Presentation des outils pour assurer le suivi de la


base et garantir sa performance
Optimisation de la memoire :
determiner la bonne taille des buffers de la base
(shared_pool, buffer cache, log buffer, etc) par lutilisation
des outils tels que Utlbstat/Utlestat, ou Statpack, etc.

12/210

Optimisation des performances


Objectifs

Sur quoi doit-on focaliser les efforts doptimisation ?


Partie N 2 : Presentation des outils pour assurer le suivi de la
base et garantir sa performance
Optimisation des entrees/Sorties Disque :
Bien dimensionner les fichiers de la base de donnees
et placer dans des disques prevus pour le type dapplication
(Batch ou TP),

pour assurer un temps de reponse acceptable des requetes


adressees `a la Base.
Ne pas oublier de recenser les disques les plus sollicites, les
tablespaces les plus fragmentes, full table scan, etc.

12/210

Optimisation des performances


Objectifs

Sur quoi doit-on focaliser les efforts doptimisation ?

Partie N 2 : Presentation des outils pour assurer le suivi de la


base et garantir sa performance
Identifier les contentions dans la base de donnees :
Etudier les locks, les latches et les wait events au niveaux de
la base de donnees, et les eliminer si possible

13/210

Optimisation des performances


Conception des SI et optimisation des Applications

Partie 1

Lors de la conception des syst`emes dinformations


Optimisation des applications :
Lexperience montre que loptimisation des requetes SQL
resout la majorite des probl`emes de performances des
applications

14/210

Optimisation des performances


Conception des SI et optimisation des Applications

Objectifs de loptimisation

Clarifier et situer les differents param`etres internes des SGBD


(relationnel ; objet-relationnel) afin dameliorer leurs
performances.
Reecrire les codes SQL ; PL/SQL etc..
Restructurer les donnees, indexer les donnees, creer des vues
materialisees
Partager les donnees, dupliquer les donnees sur plusieurs
disques, creer des partitions sur les donnees

15/210

Optimisation des performances


Conception des SI et optimisation des Applications

Objectifs de loptimisation
Intervenants :
Administrateurs de Bases de Donnees (ABD = DBA)
Programmeurs dApplications sur SGBD
Objectifs :
Optimiser un syst`eme existant et connatre les impacts de
certains param`etres en fonction du type dapplication sur le
syst`eme
Choisir un SGBD en ayant comme contrainte les crit`eres de
performances

16/210

Optimisation des performances


Conception des SI et optimisation des Applications

Augmentation des performances


Pour augmenter les performances trois grandes solutions
apparaissent :
1

Premi`ere solution (dordre logique) : optimiser les schemas


conceptuel et logique pour quil  colle aux applications

Deuxi`eme solution (dordre physique) : optimiser les


param`etres internes du SGBD

Autre solution (de type materielle) : augmenter la puissance


machine ou utiliser des ordinateurs speciaux dedies `a la
gestion des donnees.
Cette approche est plus connue sous le nom  Machine Bases
de Donnees 

17/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation du Schema Relationnel

Schema Conceptuel de Donnees (SCD),


obtenu `a la phase danalyse
une ensemble dEntites et dAssociations ou un ensemble de
Classes selon le formalisme utilise

En EA, transformation en schema relationnel (Schema Logique de


Donnees SLD), qui permet
Implantation du SCD dans une BD relationnelle
Exploitation par le SGBD et les modules de programmation

18/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation du Schema Relationnel

Normalisation : processus permettant de sassurer de la


conception du SLD
non redondance de ses donnees
Cadre formel pour effectuer la normalisation :

Bonne

la d
ependance fonctionnelle
les formes normales (1e`re FN, 2e`me FN, 3e`me FN, FNBC,
4e`me FN, ...)

19/210

Optimisation des performances


Optimisation logique

Normalisation
Exemple

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

Decomposition de la relation Relation1, en deux ou plusieurs


relations qui contiennent moins danomalies de mises `a jour
(peu ou pas du tout) :
On parle de
Decomposition sans perte dinformation
Decomposition sans perte de dependance fonctionnelle (DF) ...

Apr`es normalisation :
Relation11 ( Attribut11 , Attribut12 , . . . )
Relation21 ( Attribut21 , Attribut22 , . . . )

20/210

Optimisation des performances


Optimisation logique

Normalisation
Les relations obtenues doivent etre en 3e`me Forme Normale, au
moins
bon rapport redondance/espace occupe
Cle Primaire
Pas de DF entre les attributs de la cle primaire ;
Pas de DF entre un sous ensemble dattributs de la cle
primaire et les attributs qui nappartiennent pas `a la cle
primaire
Pas de DF entre les attributs qui nappartiennent pas `a la cle
primaire

21/210

Optimisation des performances


Optimisation logique

Normalisation
Illustration

Format dune relation

bien concue

22/210

Optimisation des performances


Optimisation logique

Normalisation
Exemple

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

Decomposition de la relation
ADRESSES ( r e l a t i o n en 3`eme 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 )

23/210

Optimisation des performances


Optimisation logique

Normalisation
Exemple

ADRESSES
VILLE
Paris
Paris
Paris
Paris
Paris
Epinay sur Seine
CPR
CODE POSTAL
75015
75015
75008
93800

NUMERO
6
16
51
55
8
23

RUE
Rue de la Rosi`
ere
Rue de la Rosi`
ere
Rue des Entrepreneurs
Rue des Entrepreneurs
Avenue des Champs Elys
ees
Boulevard Foch

RUE
Rue de la Rosi`
ere
Rue des Entrepreneurs
Avenue des Champs Elys
ees
Boulevard Foch

CODE POSTAL
75015
75015
75015
75015
75008
93800

CPV
CODE POSTAL
75008
75015
93800

VILLE
Paris
Paris
Epinay sur Seine

24/210

Optimisation des performances


Optimisation logique

Normalisation
Exemple

Un client a une adresse :


SLD version 1
CLIENT ( C o d e C l i , NomCli , Pre nomCli ,
Numero , 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 , Pre nomCli ,
Numero , 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 ;

25/210

Optimisation des performances


Optimisation logique

Bilan
Un schema relationnel normalise
contiendra donc un nombre plus important de relations (de
tables)
pourra ainsi penaliser certaines requetes, qui seront obligees
de proceder `a des jointures plus nombreuses sur la base
Or
La jointure est une operation tr`es co
uteuse
Les operations binaires (qui portent sur deux tables) peuvent
etre co
uteuses

26/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee

Technique doptimisation des requetes dinterrogation


Introduction volontairement de redondances dans le
schema logique  relationnel 
Cette redondance est dite calculee car elle tient compte
des besoins des modules de traitement des donnees
de leurs exigences en terme de temps de reponse

27/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee

Deux methodes de realisation de la redondance calculee :


le stockages des donnees deductibles
la de-normalisation

28/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee : stockages des donnees deductibles

Donnees deductibles
les resultats des requetes les plus frequentes
des statistiques historiques
des donnees issues de calculs complexes

29/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee : stockages des donnees deductibles

Dans les trois cas, stockage des donnees, physiquement dans


la base
(sous la forme de  Tables/Vues  ou de Colonnes)
Avantage du stockage physique : eviter leur re-generation en
cas de besoin
Inconvenient de la redondance :
1
2

Place occupee par les donnees redondante


Necessite de traitements supplementaires pour les operations
de mises `a jour
Risque dincoherence

30/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee : stockages des donnees deductibles
Exemple de requete frequente

Base de donnees SportAct : Adherents `a 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 )

Requete frequente : Nombre dinscrits 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 ;

30/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee : stockages des donnees deductibles
Exemple de requete frequente

Creation dune 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 operations tr`es co


uteuses :
Une jointure en moins
Un groupement en moins

30/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee : stockages des donnees deductibles
Exemple de requete frequente

Impact sur le reste de la base de donnees


Prise en compte de cette nouveaute par les operations de
mises `a jours de la table ESTMEMBRE
Modification de la colonne NbrInscr `a chaque insertion ou
suppression dinscription
La coherence est affectee si on ne le fait pas

30/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee : stockages des donnees deductibles
Exemple de requete frequente

Chaque operation INSERT / DELETE implique une operation


UPDATE
INSERT INTO ESTMEMBRE VALUES (....) ; doit
etre

accompagnee 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
etre

accompagnee par
UPDATE CENTRE SET N b r I n s c r=N b r I n s c r 1 ;

31/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee : stockages des donnees deductibles
Exemple de Statistiques Historiques

Requete : Nombre dinscrits par centre et par mois ?


Objectif : eviter le recalcul `a chaque fois du nombre dinscrits
par centre et par mois
Solution : creation dune nouvelle table/vue
STAT_MENS_INSCR
STAT MENS INSCR ( NumC, Mois , N b r I n s c r )

Necessite dun nouveau traitement mensuel pour lactualiser


avec les statistiques du mois ecoule

32/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee : stockages des donnees deductibles
Resultat de calcul complexe

Soit la base de donnees :


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 , QteComDee )

Requete : Montant de la commande ?

32/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee : stockages des donnees deductibles
Resultat de calcul complexe

Obtention du montant de la commande :


SELECT C . NumCom, SUM(D . QteComDeeA . 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 doperation avec la creation de la colonne Montant dans


la table COMMANDE
COMMANDE ( NumCom, C o d e C l i , DateCom , Montant )
SELECT NumCom, Montant
FROM COMMANDE ;

33/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee : de-normalisation

Autre methode doptimisation des interrogations


Transformer, si besoin est, une table de la 3`eme FN en 2`eme
FN ou en la 1`ere FN
Objectif : eviter des jointures successives pouvant etre
co
uteuses en performances

34/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee : de-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 , QteComDee , P r i x A r t )

DETAILCOM passe de la 3`eme FN `a la 1`ere FN


Requete : Montant de la commande ?
SELECT NumCom, SUM( QteComDee P r i x A r t )
FROM DETAILCOM
GROUP BY NumCom ;

AS Montant

35/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Redondance calculee : de-normalisation

Inconvenients de la de-normalisation : identiques `a ceux du


stockage des donnees deductibles
Place supplementaire
Penalisation des traitements dinsertion et de suppression
Risque dincoherence

Necessite la creation de declencheurs (triggers)

36/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL

Requete SQL : ordre passe au SGBD pour lui demander de


rechercher des donnees specifiees dans la requete
(sans expliciter le comment)
SQL est non procedural
SELECT / FROM / WHERE / GROUP BY / HAVING / ORDER BY
DISTINCT
IN / NOT IN /

SUM / MIN / MAX / AVG / COUNT


LIKE / NOT LIKE / EXISTS / NOT EXISTS / =

INSERT / DELETE / UPDATE


CREATE / TABLE / VIEW / INDEX

37/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL

Traduction dune requete exprimee en langage naturel en un


ensemble dordres SQL
Plusieurs agencements sont souvent possibles :
au niveau de lordre dans lequel les conditions sont exprimees
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

37/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL

Traduction dune requete exprimee en langage naturel en un


ensemble dordres SQL
Plusieurs agencements sont souvent possibles :
au niveau des operations algebriques
Possibilite dutiliser plusieurs methodes differentes pour
exprimer la meme chose
La jointure : possibilite dexprimer loperation de plusieurs
mani`eres differentes
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 ;

38/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Expression de la jointure

Methode predicative
SELECT FROM R1 , R2 WHERE R1 . A=R2 . A ;

Methodes 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 ) ;

39/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Exemple de duree dexecution SQLPlus

SET TIMING ON

Execution de la requete ; SELECT ... FROM ...


Oracle vous donne le temps ecoule
Methode predicative :
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 e s

451 100 u n i t e 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 e s

690 690 u n i t e s

40/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Exemple de duree dexecution SQLPlus

Methodes 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 e s

139 230 u n i t e 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 e s

139 890 u n i t e 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 e s

181 360 u n i t e s

41/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL

Traduction dune requete exprimee en langage naturel en un


ensemble dordres SQL :
Plusieurs agencements sont souvent possibles
Possibilite dutiliser plusieurs methodes differentes pour
exprimer la meme chose
La difference :
R = Diff
erence ( R1, R2 )
SELECT FROM R1

MINUS

SELECT FROM R2 ;

42/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Expression de la difference

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 ) ;

43/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


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 ;

44/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Vues materialisees

Presentation des vues materialisees :


Creation dune vue physique dune table
Duplication des donnees
Definition de vues materialisees `a partir de tables, de vues, et
de vues materialisees
Possibilite de decalage entre la table matre et la vue
materialisee : gestion de la fraicheur des donnees de la vue
materialisee (refresh)

45/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Vues materialisees

Utilisation des vues materialisees :


Optimisation/amelioration des performances
Re-ecriture des requetes portant sur des tables
select particuli`erement complexe ou lourd
replication de table

46/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Exemple dutilisation de vues materialisees

Soit le schema logique de donnees suivant :

47/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Exemple dutilisation de vues materialisees

Soit la requete Q :
Total des ventes des magasins en France ou en Belgique -pour la
periode de 2001 `a 2003- par ville et annee
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 o r
upper (MAGASINS .ADRPAYSMAG)= BELGIQUE ) and
TEMPS . ANNEET between 2001 and 2003
group by ADRVILLEMAG , ANNEET ;

48/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Exemple dutilisation de vues materialisees

V1 : Total des ventes des magasins `a partir de 2002, par ville


et annee
c r e a t e m a t e r i a l i z e d v i e w v1 ( V i l l e , Annee , Montant1 ) a s
( 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 ) ;

48/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Exemple dutilisation de vues materialisees

V2 : Total des ventes des magasins en France par ville, annee


et mois
c r e a t e m a t e r i a l i z e d v i e w v2 ( V i l l e , Annee , Mois , Montant2 ) a s
( 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
u p p e r (MAGASINS .ADRPAYSMAG)= FRANCE
group by ADRVILLEMAG , ANNEET, MOIST ) ;

48/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Exemple dutilisation de vues materialisees

V3 : Total des ventes des magasins en Belgique avant 2001


par ville, annee et mois
c r e a t e m a t e r i a l i z e d v i e w v3 ( V i l l e , Annee , Mois , Montant3 ) a s
( 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
u p p e r (MAGASINS .ADRPAYSMAG)= BELGIQUE and
TEMPS . ANNEET <= 2001
group by ADRVILLEMAG , ANNEET, MOIST ) ;

49/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Exemple dutilisation de vues materialisees

Soit la requete Q qui utilise des vues materialisees :


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 u p p e r (MAGASINS .ADRPAYSMAG)= FRANCE o r
u p p e r (MAGASINS .ADRPAYSMAG)= BELGIQUE ) s 1
where v1 . v i l l e = s 1 . ADRVILLEMAG and a n n e e <= 2003
union
select

v i l l e , annee , sum ( Montant2 ) from v2 where a n n e e =2001


group by v i l l e , a n n e e

union
s e l e c t s 2 . ADRVILLEMAG , Annee , sum ( Montant3 )
from v3 , ( s e l e c t d i s t i n c t ADRVILLEMAG from MAGASINS) s 2
where v3 . v i l l e = s 2 . ADRVILLEMAG and a n n e e = 2001
group by s 2 . ADRVILLEMAG , a n n e e ;

50/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Utilisation de vues materialisees

Inconvenients :
Resultat de la requete stocke et valable `a un instant t
en fonction des param`etres, la vue materialisee sera tenue `a
jour ou non quand la table change
Entretien des vues en temps reel : co
uteux (et peu souvent
mis en uvre)

51/210

Optimisation des performances


Optimisation logique

Optimisation logique de la Base de Donnees


Optimisation des ordres SQL
Utilisation de vues materialisees

Avantages
Simple reecriture de requete et execution de requetes
imbriquees
Lorsquil nest necessaire de disposer des donnees en temps
reel, economie dinterrogation
Exemple : analyse de chiffres economiques de la veille
donnees figees
interet `a stocker des resultats (qui ne changeront plus !)

Utilisation dans les datawarehouse : problematique de


performances

52/210

Optimisation des performances


Optimisation physique

Gestion physique des donnees


Adaptation et enrichissement du SLD pour tenir compte
des specificites du SGBD
des performances des traitements et de la securite
A ce stade delaboration du schema physique de donnees, on
dispose :
du SLD normalise ou non
du schema physique de traitement (description detaillee des
modules)

53/210

Optimisation des performances


Optimisation physique

Gestion physique des donnees


Resultat : Schema Physique des Donnees (SPD)
representation de la structure definitive de la base de donnees
telle quelle doit etre implantee
prise en compte
des caracteristiques technique du SGBD et du materiel
des exigences en interfaces et en performances des modules de
programmation

Si le materiel ou le SGBD change alors il faut changer le SPD (les


exigences changent)

54/210

Optimisation des performances


Optimisation physique

Gestion physique des donnees


Etat des lieux : des tables en 3`eme FN, ou autre etc.
concues 
Objectifs :

bien

optimisation des acc`es en choisissant les colonnes qui doivent


etre indexees
introduction (eventuellement) de redondances calculees
definition de vues standards et des vues materialisees
definition des contraintes dintegrite et des declencheurs sur
les tables

55/210

Optimisation des performances


Optimisation physique

Gestion physique des donnees

creation des tables et des colonnes techniques


definition des droits dacc`es aux donnees
repartition des tables sur les sites (en cas de BD reparties)
calcul des param`etres de stockage des tables et des index
etc.

56/210

Optimisation des performances


Optimisation physique

Gestion physique des donnees


Colonnes `
a indexer

les cles primaires (concatenees ou pas) pour garantir lunicite


et accelerer les recherches
INDEX UNIQUE
les cles etrang`eres (concatenees ou pas) pour accelerer les
jointures
INDEX NOT UNIQUE
les colonnes servant de crit`eres de recherche (apparaissent
souvent dans la clause WHERE de SQL)
INDEX NOT UNIQUE

57/210

Optimisation des performances


Optimisation physique

Gestion physique des donnees


Colonnes `
a indexer

Remarque :
Un  vrai SGBD se caracterise par lemploi dun SEUL
fichier pour y stocker la BD
(ou eventuellement 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 donnees est assuree par le
syst`eme dexploitation, interdisant tout param`etre
doptimisation

58/210

Optimisation des performances


Indexation

Gestion des methodes dacc`es aux donnees

Methodes dacc`es :
Methode sequentielle
Methodes basees sur les index :
Index hierarchise,
Arbre-B (B-tree), Arbre-B+, Arbre-B+*, ...

Methode de hachage
Mise en cluster

59/210

Optimisation des performances


Indexation

Donn
ees (110 octets)
Cl
e primaire
Info. compl.
(10 octets)
(100 octets)
10
info1
15
info2
20
info3
30
info4
40
info5
50
55
77
80
10
150

Index (14 octets)


Cl
e primaire
Adresse physique
(10 octets)
(4 octets)
10
@1
10
@2
10
@3
10
@4
10
@5
50
55
77
80
10
150

250

info k

250

@k

1610

info n

1610

@n

60/210

Optimisation des performances


Indexation
Donn
ees (110 octets)
Cl
e primaire
Info. compl.
(10 octets)
(100 octets)

Index (14 octets)


Cl
e primaire
Adresse physique
(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

61/210

Optimisation des performances


Indexation

Taille dune Table & Taille dun Index


Exemple

Table (110 octets par enregistrement) : Cle primaire (10


octets), Informations complementaires (100 octets)
Index (14 octets par enregistrement) : Cle primaire (10
octets), Adresse Physique (4 octets)
Bloc de 512 octets
Nombre denregistrements de lordre de 100 000

62/210

Optimisation des performances


Indexation

Taille dune Table & Taille dun Index


Exemple

Pour les donnees :


Pour un nombre entier denregistrements par bloc (512/110)
Nombre maximal denregistrements par bloc est 4
Il faudrait donc (100 000/4) = 25000 blocs de donnees

Pour les index :


Pour un nombre entier denregistrements par bloc (512/14)
Nombre maximal denregistrements par bloc est 36
Il faudrait donc (100 000/36) = 2778 blocs dindex

63/210

Optimisation des performances


Indexation

Index type B-arbre (B-tree)


Exemple

64/210

Optimisation des performances


Indexation

Index
Differents types dindex :
Logique
Index
Index
Index
Index

simple (sur une colonne)


concatene (sur plusieurs colonne)
unique (colonne ne comportant pas de doublon)
non unique (colonne comportant des doublons)

Physique
B-tree
Bitmap
Hash

65/210

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 concatene
c r e a t e i n d e x idx commande on

( no four , n c l i e n t )

66/210

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

67/210

Optimisation des performances


Indexation

Index
manipulations

Modification dun 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 dun 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

68/210

Optimisation des performances


Indexation

Index
Manipulation

Modification dun 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 ;

69/210

Optimisation des performances


Indexation

Index Bitmap

Creation dun index Bitmap (pour faible cardinalite)


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

70/210

Optimisation des performances


Indexation

INDEX HASH Cluster


Creation 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 dune 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 ) ;

Creation de lindex 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 ;

71/210

Optimisation des performances


Indexation

INDEX B-TREE
Preparation de lutilisation de B-Tree
(`a utiliser dans le cas dune forte cardinalite)
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

72/210

Optimisation des performances


Indexation

INDEX B-TREE
Creation dun 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 ) ;

73/210

Optimisation des performances


Optimisation des requ
etes

Optimisation des requetes

Exemples doptimisation Algorithmique


Algorithme des boucles imbriquees de la jointure BI-passe
Algorithme Multi-Passes de la jointure MP

74/210

Optimisation des performances


Optimisation des requ
etes

Jointure Bi-passe
Hashage de deux tables en paquets de memoire virtuelle
De but A l g o r i t h m e BI :
POUR i DE 1 `
a n1 FAIRE
DEBUT
LIRE Page de R1
POUR j de 1 `
a n2 FAIRE
DEBUT
LIRE Page de R2
S I R1 . A=R2 . A ALORS C r e e r r e s u l t a t F I N S I
FIN
FIN
F i n A l g o r i t h m e BI :

75/210

Optimisation des performances


Optimisation des requ
etes

Jointure Multi-Passe
De but A l g o r i t h m e MP :
POUR i DE 1 `
a m FAIRE
DEBUT
CHARGE MEMOIRE( )
POUR j de 1 `
a n2 FAIRE
DEBUT
LIRE Page de R2
S I R1 . A=R2 . A ALORS C r e e r r e s u l t a t F I N S I
FIN
FIN
CHARGER MEMOIRE( )
POUR k DE 1 `
a m FAIRE
DEBUT
LIRE Page de R1
FIN
F i n A l g o r i t h m e MP :

76/210

Optimisation des performances


Optimisation des requ
etes

Optimisation des requetes

Visualisation :
Expression Algebrique
Arbre algebrique
Plan dexecution de la requete

77/210

Optimisation des performances


Plan dex
ecution

Plan dexecution
Sous Oracle, possibilite de connatre pour chaque requete son
plan dexecution
Consultation du plan dexecution selon lequel une instruction
SQL sera executee par le SGBD Oracle dans une table
 syst`
eme 
Stockage des plans dexecution dans une table PLAN_TABLE
dont le script de creation (fourni par Oracle) se trouve dans
$ORACLE_HOME/rdbms/admin/utlxplan.sql
Etapes en vue de la consultation :
creation la table de nom PLAN_TABLE
Eventuellement la detruire et la recreer
executtion dune commande EXPLAIN PLAN sur une requete
Stockage (description) du plan dexecution de cette derni`ere)
dans la table PLAN_TABLE
Interrogation de la table PLAN_TABLE

78/210

Optimisation des performances


Plan dex
ecution

Execution dune commande EXPLAIN PLAN sur une


requete

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 e 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% ;

79/210

Optimisation des performances


Plan dex
ecution

Affichage du plan dexecution


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 e 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 ;

Resultat affiche :
Plan dex
ecution
----------------------------------------------SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID ELEVES
INDEX RANGE SCAN I_NOM

80/210

Optimisation des performances


Plan dex
ecution

Remarques et explications
Representation dune requete par un arbre
Sous Oracle,
possibilite de representation et de manipulation
de donnees ayant une structure de donnees recursive (arbre)
par une representation tabulaire et avec la commande SQL :
SELECT . . . FROM . . . WHERE . . .
CONNECT BY PRIOR c o l o n n e o p e r a t e u r c o l o n n e
[CONNECT BY c o l o n n e o p e r a t e u r PRIOR c o l o n n e ]
START WITH . . .
LEVEL . . .

Extensible des donnees quelconques

81/210

Optimisation des performances


Plan dex
ecution

Exemples de parcours de
structure de donnees de type recursif
Structures de donnees recursives de type Arbres
Exemples :
Arbre Genealogique
Nomenclature dun produit (Compose, Composant)
Oracle offre la commande CONNECT BY
SELECT . . . FROM . . . WHERE . . .
CONNECT BY PRIOR c o l o n n e o p e r a t e u r c o l o n n e
CONNECT BY c o l o n n e o p e r a t e u r PRIOR c o l o n n e
START WITH
LEVEL

82/210

Optimisation des performances


Plan dex
ecution

Structures hierarchiques, arborescentes


Arbre Genealogique

Oracle permet la representation et la manipulation des donnees


ayant une structure arborescente par le mod`ele 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 ) )
);

83/210

Optimisation des performances


Optimisation des requ
etes

Optimisation des requetes


Requete simple sur une table non indexee
DELETE p l a n t a b l e ;
// ( l a t a b l e
etant cr
e
e 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 | | | |


object name Plan d e x
ecution
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 dex
ecution
----------------------------------------------SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID ELEVES
INDEX RANGE SCAN I_NOM

84/210

Optimisation des performances


Optimisation des requ
etes

Optimisation des requetes


Requete simple sur une table indexee
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 | | | |


object name Plan d e x
ecution
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 dex
ecution
-----------------------------------------------SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID ELEVES
INDEX RANGE SCAN I_NOM

85/210

Optimisation des performances


Optimisation des requ
etes

Optimisation des requetes


Comparaison

Requete simple sur une table non indexee :


Plan dex
ecution
--------------------------------------------SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID ELEVES
INDEX RANGE SCAN I_NOM

Requete simple sur une table indexee :


Plan dex
ecution
--------------------------------------------SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID ELEVES
INDEX RANGE SCAN I_NOM

86/210

Optimisation des performances


Optimisation des requ
etes

Optimisation des requetes


Requete avec un order by sur une table non indexee
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 | | | |


object name Plan d e x
ecution
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 dex
ecution
--------------------------------SELECT STATEMENT
SORT ORDER BY
TABLE ACCESS FULL ELEVES

87/210

Optimisation des performances


Optimisation des requ
etes

Optimisation des requetes


Requete avec un order by sur une table indexee
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 | | | |


object name Plan d e x
ecution
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 dex
ecution
-----------------------------------SELECT STATEMENT
SORT ORDER BY
TABLE ACCESS BY INDEX ROWID ELEVES
INDEX RANGE SCAN I_NOM

88/210

Optimisation des performances


Optimisation des requ
etes

Optimisation des requetes


Comparaison

Requete avec un order by sur une table non indexee


Plan dex
ecution
----------------------------------------------SELECT STATEMENT
SORT ORDER BY
TABLE ACCESS FULL ELEVES

Requete avec un order by sur une table indexee


Plan dex
ecution
--------------------------------------------SELECT STATEMENT
SORT ORDER BY
TABLE ACCESS BY INDEX ROWID ELEVES
INDEX RANGE SCAN I_NOM

89/210

Optimisation des performances


Optimisation des requ
etes

Optimisation des requetes


Requete de jointure avec les deux tables indexees
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 | | | |
object name Plan d e x
ecution
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 dex
ecution
---------------------------------------------SELECT STATEMENT
NESTED LOOPS
TABLE ACCESS FULL RESULTATS
TABLE ACCESS BY INDEX ROWID ELEVES
INDEX UNIQUE SCAN PK_ELEVES

90/210

Optimisation des performances


Optimisation des requ
etes

Optimisation des requetes


Requete de jointure avec les deux tables indexees

Lordre 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 | | | |
object name Plan d e x
e c u t i o n FROM
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

Plan dex
ecution
---------------------------------------------SELECT STATEMENT
NESTED LOOPS
TABLE ACCESS FULL ELEVES
TABLE ACCESS BY INDEX ROWID RESULTATS
INDEX RANGE SCAN PK_RESULTATS

options | | | |
plan table

id = requete3 ;

91/210

Optimisation des performances


Optimisation des requ
etes

Optimisation des requetes


Comparaison

Requete de jointure avec les deux tables indexees


Plan dex
ecution
---------------------------------------------SELECT STATEMENT
NESTED LOOPS
TABLE ACCESS FULL RESULTATS
TABLE ACCESS BY INDEX ROWID ELEVES
INDEX UNIQUE SCAN PK_ELEVES

Requete de jointure avec les deux tables indexees


(Lordre des 2 tables change)
Plan dex
ecution
---------------------------------------------SELECT STATEMENT
NESTED LOOPS
TABLE ACCESS FULL ELEVES
TABLE ACCESS BY INDEX ROWID RESULTATS
INDEX RANGE SCAN PK_RESULTATS

92/210

Optimisation des performances


Optimisation des requ
etes

Optimisation des requetes


Requete de jointure avec les deux tables indexees et une selection

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 | | | |
object name Plan d e x
ecution
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 ;

93/210

Optimisation des performances


Optimisation des requ
etes

Optimisation des requetes


Requete de jointure avec les deux tables indexees et une selection

Plan dex
ecution
---------------------------------------------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

94/210

Optimisation des performances


Outils doptimisation

Partie 2
Introduction

Presentation
des outils
des methodes
pour assurer le suivi de la base et garantir sa performance

95/210

Optimisation des performances


Outils doptimisation

Amelioration du Suivi et de la performance de la base

Choix de loptimiseur et collecte des statistiques

Suivi des indicateurs

Outils pour ameliorer loptimisation de la base

96/210

Optimisation des performances


Optimiseur Oracle

Historique de loptimiseur dOracle


Optimiseur Syntaxique

Avant la version 7.0 :


optimiseur syntaxique (rule-based optimizer ) avant la
version 7/0 :
Hypoth`ese de base :
`a partir du moment o`
u une instruction SQL validait une r`egle,
et que le numero de la r`egle diminuait, le plan dexecution
etait repute meilleur.
Fonctionnement :
uniquement optimisation du code en utilisant un ensemble de
r`egles internes fixes
et en les appliquant `
a partir dune analyse syntaxique du code

97/210

Optimisation des performances


Optimiseur Oracle

Historique de loptimiseur dOracle


Optimiseur Syntaxique

Limites de loptimiseur syntaxique : incapacite `a determiner la


methode la moins co
uteuse
Pas usage de type de fonction de co
ut ou de statistiques
Mais, initialement concu pour les BDD transactionnelles (les
Datawarehouses nexistaient pas encore)

98/210

Optimisation des performances


Optimiseur Oracle

Historique de loptimiseur dOracle


Optimiseur Statistique

Apparition avec la version 7.0 dOracle


Objectifs :
Utilisation dun plus grand nombre doptions lors de la
construction des plans dexecution du code SQL
Mais maturite difficile `a atteindre : 7 ans !
A partir de Oracle 7.3 : Possibilite de generer et denregistrer des
histogrammes de colonnes
Histogrammes de colonnes : Fonctionnalite capable de determiner
la distribution effective des donnees pour une colonne particuli`ere

99/210

Optimisation des performances


Optimiseur Oracle

Initialisation des Parametrage de lOptimiseur


Configuration de linstance Oracle `a laide du param`etre
OPTIMIZER_MODE
Valeur definie dans le fichier init.ora
Valeur par defaut : CHOOSE (valeur necessaire pour
loptimisation statistique)
Valeur RULE : optimisation syntaxique (rule-based optimizer )
Optimisation du code en utilisant un ensemble de r`egles
internes fixes telles que :
Acc`es par lintermediaire dun index composite avec toutes les
cles contenues dans la clause where
Acc`es par lintermediaire dun index sur une colonne, etc.

Autres valeurs possibles (selon les versions doracle) :


FIRST_ROWS, ALL_ROWS

100/210

Optimisation des performances


Optimiseur Oracle

Initialisation des Parametrage de lOptimiseur

Modification du param`etre au niveau session `a laide 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 ;

101/210

Optimisation des performances


Optimiseur Oracle

Mode CHOOSE de lOptimiseur

Obejectif de loptimiseur :
tenter de tout executer en memoire 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 generer le plan dexecution des requetes

102/210

Optimisation des performances


Optimiseur Oracle

Mode CHOOSE de lOptimiseur


En mode CHOOSE, la presence de statistiques dans le
dictionnaire determine si loptimiseur statistique est utilise
Pas de mise `a jour reguli`ere des catalogues par Oracle
Le DBA qui doit donc sen charger
Recuperation de la date de dernier calcul des statistiques :
Requete dans la vue DBA_TAB_COLUMNS pour afficher
linformation 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 > 01JAN00 ;

103/210

Optimisation des performances


Statistiques

Collecte des statistiques

Calcul des statistiques dobjets :


Utilisation de la commande ANALYZE pour :
collecter ou supprimer des statistiques des tables (ou partition
de table), dindex (ou partition dindex), cluster , ...
valider la structure des tables (ou partition de table), dindex
(ou partition dindex), cluster , ...
identifier des lignes migrees ou chainees dune table dun
cluster, ...

104/210

Optimisation des performances


Statistiques

Collecte des statistiques dune table


Analyse statistique dune partition (estimation sur la totalite
de la partition)
ANALYZE TABLE emp PARTITION ( p1 ) COMPUTE STATISTICS ;

Analyse statistique et validation de la structure dune table


ANALYZE TABLE emp VALIDATE STRUCTURE ;

Analyse statistique dune partie dune table (exemple 33 %)


ANALYZE TABLE emp ESTIMATE STATISTICS SAMPLE 33 p e r c e n t ;

Analyse statistique dune table ainsi que de ses indexes


ANALYZE TABLE emp COMPUTE STATISTICS FOR ALL INDEXED COLUMNS ;

105/210

Optimisation des performances


Statistiques

Collecte des statistiques dune Index

Analyse statistique et validation de la structure dun index


ANALYZE INDEX p a r t s i n d e x VALIDATE STRUCTURE ;

Analyse statistique ( sur la totalite de lindex)


ANALYZE INDEX i n d x 1 COMPUTE STATISTICS ;

Analyse statistique dune partie dun index (exemple 44 %)

ANALYZE INDEX p a r t s i n d e x ESTIMATE STATISTICS SAMPLE 44 p e r

106/210

Optimisation des performances


Statistiques

Suppression des statistiques dune table et des index

ANALYZE TABLE emp DELETE STATISTICS

Optimisation des performances


Statistiques

Quelle est la quantite optimale des statistiques necessaire ?

107/210

Si estimation des statistiques des objets en se fondant sur un


echantillon (estimate) :
La taille de celui-ci doit etre appropriee
ement essentiel pour fournir `a loptimiseur des statistiques
El
dotees dun bon intervalle de confiance
Un niveau de 20% est souvent utilise et semble approprie

Si choix de calculer les statistiques (compute) :


Niveau de confiance : 100%
Et les statistiques doivent etre parfaitement precises
Necessite des ressources et du temps pour realiser ces calculs

Optimisation des performances


Statistiques

Quelle est la quantite optimale des statistiques necessaire ?

108/210

Sil sagit dOracle 8i ou superieur, le package DBMS_STATS


pourra analyser les tables en parall`ele
Si execution dune commande analyze estimate sur une
taille dechantillon > 49% :
le module calculera les statistiques sur lensemble de la table

Optimisation des performances


Statistiques

Nouveaux packages pour la generation des statistiques

109/210

DBMS_UTILITY.ANALYZE_SCHEMA : analyse des schemas


Oracle
DBMS_STATS : (nouveau package) statistique dobjets
dOracle8i

110/210

Optimisation des performances


Statistiques

DBMS UTILITY.ANALYZE SCHEMA

Analyse des schemas Oracle


Execution de la procedure 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) ;

111/210

Optimisation des performances


Statistiques

DBMS STATS
Nouveau package de statistiques dobjets dOracle8i
Execution de calculs avec differentes options
Procedure
GATHER_INDEX_STATS
GATHER_TABLE_STATS
GATHER_SCHEMA_STATS
GATHER_DATABASE_STATS

Description
Rassemblement de statistiques sur les
index
Rassemblement de statistiques sur les
index, colonnes et tables
Rassemblement de statistiques sur
tous les objets dun schema
Rassemblement de statistiques sur
tous les objets dune base de donnees

112/210

Optimisation des performances


Statistiques

DBMS STATS
Exemple dutilisation doption : Procedure GATHER_TABLE_STATS
DBMS STATS . GATHER TABLE STATS
( DEV ,
> Schema
Contrat ,
> T a b l e
NULL,
> P a r t i t i o n
30 ,
> % de l e 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,
> Degre de p a r a l l e 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

113/210

Optimisation des performances


Statistiques

DBMS STATS

Explications :
La table CONTRAT du user DEV est analysee avec un degre
de parallelisme de 4
Toutes les colonnes sont analysees ainsi que les index
correspondants
Lanalyse se fait avec une estimation de 30% au niveau ligne

114/210

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;

115/210

Optimisation des performances


Statistiques

Restauration des statistiques avec DBMS STATS


Si les statistiques :
semblent fausses
entraine lOptimiseur `a generer des mauvais plans dexecution
Il faut restaurez les statistiques dorigines 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;

116/210

Optimisation des performances


Statistiques

Frequence des statistiques

A quelle frequence les statistiques doivent etre calculees ?


Cela depend
du taux
du volume de changement des donnees dans la base

117/210

Optimisation des performances


Suivi des Indicateurs

Suivi des Indicateurs

Indicateurs :
Ratios
Alertes (corruption, messages derreurs etc.) et les traces
Vues de depannage et reglage
Tuning des I/O des requetes couteuses

118/210

Optimisation des performances


Suivi des Indicateurs

Ratios de la base
Buffer cache hit Rate
nombre de fois quun block utile `a la requete 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
e 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
e moire

Objectif : avoir en memoire linformation dont on a besoin


Amelioration de ce ratio : augmenter le db_block_buffers

119/210

Optimisation des performances


Suivi des Indicateurs

Ratio de la base
Library cache get hit Rate
Proportion des requetes pour obtenir un verrou sur un objet
Les requetes sont satisfaite en trouvant le descripteur de
lobjet qui doit dej`a etre en memoire

ce pourcentage doit etre 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 ;

Amelioration des performances : Augmentation des valeurs


SHARED_POOL_SIZE, et OPEN_CORSORS dans init.ora

120/210

Optimisation des performances


Suivi des Indicateurs

Ratio de la base

Dictionary Cache Hit Ratio


Mesure du taux de requetes pour obtenir des informations du
dictionnaire de donnees, des tables et des vues contenant des
informations sur
la base de donnees
les structures
les utilisateurs

121/210

Optimisation des performances


Suivi des Indicateurs

Ratio de la base

Remarque :
Au demarrage, le cache du dictionnaire de donnees est vide
Chaque requete SQL est absente du cache, et entrane un
defaut
Comme il y devrait y avoir de plus en plus de donnees lues
dans le cache, le nombre de defaut dans le cache diminuera
La base de donnees peut atteindre un etat stable (steady
state) : les donnees du dictionnaires les plus frequemment
utilisees sont dans le cache

122/210

Optimisation des performances


Suivi des Indicateurs

Ratio de la base
Exemple dutilisation
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 : stocke dans le Shared Pool (partie


du SGA)
Amelioration 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 

123/210

Optimisation des performances


Suivi des Indicateurs

Ratio de la base

Sorts in Memory
Mesure de la proportion de donnees triees qui sont en
memoire plutot 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 ) ;

124/210

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 memoire est defini par la taille de la
zone de tri (sort area size) taille dans lequel de PGA est
utilise
Chaque processus Oracle effectuant un tri reserve autant de
memoire, meme sil nen a pas besoin.
Lutilisation de cette memoire reduit celle disponible pour SGA

Optimisation : augmenter le param`etre SORT_AREA_SIZE


dans init.ora

125/210

Optimisation des performances


Alertes

Les alertes
Fichier alert_ORACLE_SID.log
Exemple : alert_bdaINFO2.log
Contenu dun fichier dalerte :
des informations utilisees par le DBA de la base pour une
maintenance, un suivi, ... de la base Oracle
Des traces sont rajoutees dans le fichier Log suite `a :
un demarrage de la base,
un arret de la base,
une creation ou la mise `
a jour dun tablespace,
une creation, ou la mise `
a jour dun rollback segment,
etc ...

126/210

Optimisation des performances


Alertes

Les alertes

Fichiers de trace Oracle_Sid_numero.trc


Ces fichiers contiennent des informations :
utile pour loptimisation de la base : traces generees par les
utilitaires tkprof, statpack, utlbstat, etc.
ou permettent au DBA, de suivre et de corriger des erreurs,
afin deviter le plantage, ou un mauvais fonctionnement de la
base Oracle

127/210

Optimisation des performances


Alertes

Exemple de fichier dalerte


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 nond e f a u l t v a l u e s :
processes
= 320
sessions
= 357
timed statistics
= TRUE
= FRANCE
nls territory
nls date format
= YYYYMMDD
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
ORA1652: 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
ORA1652: 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

128/210

Optimisation des performances


Catalogue Oracle

Catalogue Oracle:Instance et base de donnees

V$database : description de la base


V$instance : description de linstance
V$parameter : param`etres de la base
V$process~: nombre de process actifs
V$waitstat~: statistiques relatives aux attentes
V$system_event : attentes totales pour des ev`enements
particuliers

129/210

Optimisation des performances


Catalogue Oracle

Parametres de la base : v$parameter


S e l e c t Name , Type , Value ,
NAME
timed statistics
trace enabled
sql trace
db name
utl file dir
instance name
db block size
open cursors
sort area retained size

description
TYPE
1
1
1
2
2
2
3
3
3

db file multiblock read count 3


max enabled roles
3
max rollback segments

sga max size


shared pool reserved size

6
6

large pool size

java pool size

from v $ p a r a m e t e r
VALUE
TRUE
TRUE
FALSE
dwh

DESCRIPTION
maintain i n t e r n a l timing s t a t i s t i c s
e n a b l e KST t r a c i n g
e n a b l e SQL t r a c e
d a t a b a s e name s p e c i f i e d i n
CREATE DATABASE

utl file accessible directories l i s t


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
16384
Size of database block in bytes
500
max # c u r s o r s p e r s e s s i o n
6000000
s i z e o f i nmemory s o r t work a r e a
r e t a i n e d between f e t c h ca
4
db b l o c k t o be r e a d e a c h IO
148
max number o f r o l e s a u s e r can h a v e
enabled
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
1178569392 max t o t a l SGA s i z e
26843545
size in bytes of reserved area of
shared pool
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
33554432
s i z e i n b y t e s of the Java pool

130/210

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
sort block
s a v e undo b l o c k
segment he a d e r
s a v e undo h e a d e r
free l i s t
e x t e n t map
1 s t l e v e l bmb
2 nd l e v e l bmb
3 r d l e v e l bmb
bitmap b l o c k
bitmap index b l o c k
f i l e header block
unused
s y s t e m undo h e a d e r
s y s t e m undo b l o c k
undo h e a d e r
undo b l o c k

19866
0
0
5301
0
0
0
0
0
0
0
0
0
0
0
0
1933
44

26102
0
0
4161
0
0
0
0
0
0
0
0
0
0
0
0
397
3

131/210

Optimisation des performances


Catalogue Oracle

attentes totales pour des ev`enements 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

latch free
pmon t i m e r
enqueue
c o n t r o l f i l e s e q u e n t i a l read
control f i l e p a r a l l e l write
b u f f e r busy w a i t s
log f i l e s e q u e n t i a l read
log f i l e s i n g l e write
log f i l e p a r a l l e l write
LGWR w a i t f o r r e d o c o p y
db f i l e s e q u e n t i a l r e a d
db f i l e s c a t t e r e d r e a d
db f i l e s i n g l e w r i t e
db f i l e p a r a l l e l w r i t e
db f i l e p a r a l l e l r e a d
l i b r a r y cache pin
l i b r a r y cache l o c k
l i b r a r y cache load l o c k

3740
1929737
10937
596427
1870221
27144
1571
1562
443272
12490
173476
1010050
104
37096
1
139
149
3

AVERAGE WAIT
1
293
103
0
3
1
0
1
0
0
0
0
1
3
6
285
11
0

132/210

Optimisation des performances


Catalogue Oracle

Catalogue dOracle : Disques

V$datafile : liste des fichiers des donnees


V$filestat : statistiques relatives aux I/O dans les fichiers
de donnees
V$tempstat : informations sur les statistiques relatives aux
operations des I/O pour les fichiers de donnees des TBS
temporaires
V$segment_statistics : statistiques sur les I/O par
segments

133/210

Optimisation des performances


Catalogue Oracle

Catalogue dOracle : Contention

V$lock : verrou externe


V$latch : verrou interne dOracle
V$rollstat : statistiques sur les segments dannulation
V$process : nombre de process actifs
V$waitstat : statistiques sur les contention des blocks

134/210

Optimisation des performances


Catalogue Oracle

Catalogue dOracle : Memoire

V$buffer_pool_statistics : statistiques sur buffer pool


V$db_object_cache : objets de la base, dans le cache
V$rowcache : echec et succ`es dans le dictionnaire
V$sysstat : statistique sur linstance dOracle
V$librarycache : statistiques sur le librarycache

135/210

Optimisation des performances


Catalogue Oracle

Catalogue dOracle : Session

V$session : liste des sessions


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

Optimisation des performances


Optimisation des applications Recettes

Comment ameliorer le temps de reponse des applications ?

136/210

Partitionnement
Execution parall`ele
Tuning des entrees/sorties
Detection des lignes chanees ou migrees
Detection des Index inutilises
Reorganisation des index
Utilisation des Hints
Codes SQL `a ne pas utiliser

137/210

Optimisation des performances


Optimisation des applications Recettes

Creation dune table partitionnee 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 value l e s s than
( t o d a t e ( 20040101 , YYYYMMDD ) )
p a r t i t i o n p 200406 value l e s s than
( t o d a t e ( 20040701 , YYYYMMDD ) )
p a r t i t i o n p 200412 value l e s s than
( t o d a t e ( 20050101 , YYYYMMDD ) )
)

138/210

Optimisation des performances


Optimisation des applications Recettes

Execution parall`ele de la creation dindex 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 ;

139/210

Optimisation des performances


Optimisation des applications Recettes

Tuning des Entrees/sorties

Desc V$filestat

file#
phyrds
phywrts
phyblkrd
phblkwrt
readtim
writetim

:
:
:
:
:
:
:

num
ero du fichier
lecture disque
ecriture disque

nbre de block disque lus


nombre de block disque
ecrits
temps de lecture
temps d
ecriture

140/210

Optimisation des performances


Optimisation des applications Recettes

Tuning des Entrees/sorties

Pour les fichiers dont la colonne phyrds est importante :


verifier si les tables sont accedees 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 : verifier les applications ...


Definir les bons index

141/210

Optimisation des performances


Optimisation des applications Recettes

Detection des lignes chanees ou migrees

Detection de letat de chanage dune 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

142/210

Optimisation des performances


Optimisation des applications Recettes

Detection des lignes chanees ou migrees

Etat de chanage au niveau de la base


Detection de letat de chanage 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 ;

143/210

Optimisation des performances


Optimisation des applications Recettes

Detection des Index inutilises

Alter index nom index monitoring usage;


Select index name , used
From v $ i n d e x u s a g e
where i n d e x n a m e = NOM INDEX ;
Alter index nom index nomonitoring usage;

144/210

Optimisation des performances


Optimisation des applications Recettes

Strategies dindexation
Quand faut-il utiliser les index ?
Construction dindex optimaux
Quelques options dindexation :
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.

145/210

Optimisation des performances


Optimisation des applications Recettes

Strategies dindexation

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 e d u r e PL/SQL

Quand faut-il reconstruire les index ?

146/210

Optimisation des performances


Optimisation des applications Recettes

Reorganiser/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 ) ;

Equivalent
de ANALYZE INDEX VALIDATE STRUCTURE
Desc Index_stats
lf_rows
lf_rows_len
Del_lf_rows
del_lf_rows_len

:
:
:
:

Nombre de valeurs pr
esentes dans index
Longueur de lindex (en octets)
Nombre de valeur supprim
ees
Longueur dindex supprim
ees (en octets)

147/210

Optimisation des performances


Optimisation des applications Recettes

Reorganiser/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 ;

148/210

Optimisation des performances


Optimisation des applications Recettes

Utilisation des hints


Hint :
indication placee dans une requete pour orienter le plan
dexecution
ressemble beaucoup `a un commentaire, `a lexception du +
apr`es 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`es important de placer le hint `a lemplacement
approprie du code SQL, idealement avant la reference `a la
premi`ere colonne du code SQL
Si le hint inclus est incorrect il sera tout simplement ignore
par loptimiseur, sans affichage de la moindre erreur !

149/210

Optimisation des performances


Optimisation des applications Recettes

Utilisation des hints


Exemple/syntaxe generique :
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)
INDEX(table, index)
NO_INDEX(table, index)
ORDERED
FIRST_ROWS

PARALLEL(table, n)
etc.

:
:
:
:

Parcours de toute la table (sans utiliser lindex)


Force lutilisation de lindex de la table
Desactivation de lindex de la table
Force lordre de jointure des tables, telles quelles
apparaissent dans la clause From
: Force Oracle `
a choisir le plan dexecution qui retourne les n premi`eres lignes de mani`ere la plus efficace
: Specification des n serveurs concurrent pouvant etre
utilises pour une requete
:

(voir : http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96533/hintsref.htm)

150/210

Optimisation des performances


Optimisation des applications Recettes

Utilisation des hints

Outils daide :
PRECISE : suivi dune base de production
TOAD : suivi du passage du prototypage `a la production
OEM : Oracle Entreprise Manager
etc.

151/210

Optimisation des performances


Optimisation des applications Recettes

Utilisation des hints

Utilisation ORDERED : impose `a loptimiseur dutiliser les tables


dans lordre dapparition dans la requete 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 ;

152/210

Optimisation des performances


Optimisation des applications Recettes

Utilisation des hints

Utilisation INDEX : impose `a loptimiseur dutiliser les indexes


specifies 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 ;

153/210

Optimisation des performances


Optimisation des applications Recettes

Differents types de hints

Optimisation :
FIRST_ROWS, ALL_ROWS : Force Oracle `a utiliser les premi`eers
ou toutes les lignes
ORDERED : Acc`es aux tables dans lordrede de la clause FROM

Acc`es: FULL(tab), ROWID, PARALLEL

154/210

Optimisation des performances


Optimisation des applications Recettes

Impact des Hints Exemple


SQL>
2
3
4

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 ,
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 ;

resultats r

SQL> 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
ecution
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 ;
Plan d e x
ecution

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 ligne ( s ) s
electionn
ee (s ).

155/210

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 ;
Explicit
e.
SQL> SELECT LPAD( , 2 ( LEVEL 1 ) ) | | o p e r a t i o n | | | | o p t i o n s | | | |
ecution
object name Plan d e x
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 ;
Plan d e x
ecution

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 ligne ( s ) s
electionn
ee (s ).

156/210

Optimisation des performances


Optimisation des applications Recettes

Impact des Hints


Exemple

Sans le Hint :
Plan d e x
ecution

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)


Plan d e x
ecution

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

157/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire


Premier exemple

Eviter lutilisation des index dans les clauses where


Consultation par les instructions SQL dun plus grand
nombre de blocs de donnees
en utilisant lindex
plut
ot quen executant un balayage complet de la table

Amelioration :
ajout dune expression anodine `a la colonne dindex
Par exemple :
ajout de +0 `
a une colonne numerique
concatenation dune chane vide `
a une colonne alphanumerique
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 . . . . . .

158/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire


Deuxi`eme exemple

Eviter de melanger ou de comparer des valeurs et des types de


donnees de colonnes
loptimiseur ignorera lindex
Ameliorations :
Si le type de colonne est NUMBER : ne pas utiliser de guillemets
pour encadrer la valeur
Ne pas oublier dencadrer une valeur avec ses guillemets
lorsquelle est definie comme de type alphanumerique
Select
Select
Select
Select

...
...
...
...

from
from
from
from

EMP
EMP
EMP
EMP

where
where
where
where

SALARY > 1000 ; Mauvais


SALARY > 1000 ; Bon
MANAGER = SMITH ; Mauvais
MANAGER = SMITH ; Bon

159/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire


Troisi`eme exemple : Ne pas utiliser loperateur IS NULL dans
une colonne indexee
loptimiseur ignorera lindex
SELECT N emp , name , a d r from EMP

name i s n u l l ;

Quatri`eme exemple :
En cas dutilisation de curseurs ou du SQL dynamique : ne pas
coder pas ls instruction avec des valeurs en dur
Empeche la reutilisation du code SQL dans le pool partage
Utiliser des variables liees :
S e l e c t . . . from EMP where
S e l e c t . . . from EMP where
EXECUTE IMMEDIATE D e l e t e
EXECUTE IMMEDIATE D e l e t e

EMPNO = 2324
EMPNO = : 1
from EMP w h e r e EMPNO = 2324
from EMP w h e r e EMPNO = : 1 USING v a r i a b l e

;
;
;
;

Mauvais
Bon
Mauvais
Bon

160/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire

Amelioration de lutilisation des bind variables `a partir de


Oracle 8i
Insertion du param`etre CURSOR_SHARING=force dans le
fichier init.ora
NB :
Possibilite de definir le param`etre au niveau session
Mais possibilite daugmentation des delais danalyse
Il peut etre preferable de reecrire le code

161/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire


Pas dinstruction Insert, update ou delete dans une iteration
(une boucle PL/SQL) si les operations peuvent etre realisees
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

162/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire


Evitez lutilisation des sous-requetes
Impact negatif sur les performances de votre syst`eme en
consommant beaucoup de ressources CPU
Solution : utilisation des vues en ligne (inline views),
cest-`a-dire des sous-requetes dans la clause from de
linstruction 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

163/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire


Evitez les produit cartesien
Ne pas construire la clause from dune instruction select
avec des tables qui napparaissent pas dans les conditions de
jointure de la clause where afin deviter de realiser un produit
cartesien
Regrouper la creation des tables et linsert
Si la table est creee et alimentee, regrouper loperation :
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

...

164/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire


Eviter lutilisation de select x from dual
Bien quelle semble innocente, elle peut consommer lessentiel
des performances de votre syst`eme
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

...

);

165/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire


Eviter lutilisation de NOT IN
Privil`egier lutilisation de NOT EXISTS plut
ot que NOT IN
dans les clauses where, voir lutilisation dune 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 ;

166/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire


Utiliser loperateur LIKE avec un caract`ere initial plutot que la
fonction SUBSTR()
Dans le cas de requetes tr`es complexes contenant de
nombreuses conditions OR
Envisager leur reecriture `a laide de UNION ALL
Possibilite de decoupage de la requete en modules bien
dimensionnes qui pourront etre optimises plus facilement
Rappel :
Operateur UNION : recuperation de lensemble des
enregistrements retournes par les deux requetes
Les doublons ne sont pas pris en compte
Operateur UNION ALL : recuperation de tous les
enregistrements y compris les doublons (contrairement `
a
loperateur UNION)

167/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire

Utiliser les index appropries, les plus selectifs


La selectivite des donnees est le ratio entre le nombre de cles
uniques et le nombre de lignes
Plus elle approche 1.00, meilleur est lindex
Creer des index sur les colonnes de cles etrang`eres
Utiliser des index composites
Ceux-ci doivent etre classes dans lordre decroissant de
selectivite.

168/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire

Utiliser des index bitmaps lorsque la clause where


contient des colonnes `a faible cardinalite ou des operations
logiques comme OR, AND ou NOT executees sur ces colonnes
renvoit un grand nombre de lignes de la table
(sauf pour les tables supportant un grand nombre doperations
DML simultanees, du fait de leur comportement
intrins`equement bloquant)

169/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire

Utiliser des single-table hashs ou des index clusters


Ces methodes fournissent des performances excellentes sur les
tables relativement statiques mais interrogees sur une large
plage de valeurs
Sachant quun cluster enregistre les donnees dans un bloc de
mani`ere ordonnee, un balayage de plages utilisant un index sur
ce cluster realisera un plus petit nombre doperations
dentrees-sorties pour repondre `a la requete

170/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire

Choisir de mani`ere 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 requete pour realiser lelimination la plus forte
sur la premi`ere jointure
incorporer toutes les conditions sur une table dans la clause
where.
Privilegier le traitement en vrac (BULK COLLECT / FORALL)

171/210

Optimisation des performances


Optimisation des applications Recettes

Les codes SQL `a ne pas ecrire


A partir dOracle 8i, remplacer DBMS_SQL par la nouvelle
fonctionnalite execute immediate (fonctionne nettement
mieux)
E x e c u t e immediate CREATE TABLE XX AS SELECT FROM YY ;

En cas dutilisation de loptimiseur syntaxique (ce qui ne


devrait plus durer)
Structurer les clauses from de mani`ere `a ce que la table la
plus petite soit la derni`ere definie dans la liste des tables
Sil est necessaire daccelerer la creation dun index
Augmenter la valeur du param`etre SORT_AREA_SIZE au
niveau session
lessentiel des tris seront executes en memoire

172/210

Optimisation des performances


Optimisation des applications Recettes

Vos requetes SQL en mode trace

Les etapes du processus doptimisation


Activation dune session en mode trace

173/210

Optimisation des performances


Optimisation des applications Recettes

Les etapes du processus doptimisation


1

Verifier que le param`etre TIMED_STATISTICS est positionne `


a TRUE au
niveau instance

Verifier que la valeur du param`etre MAX_DUMP_FILE_SIZE est suffisante


Ce param`etre determine la taille maximale du fichier de trace

Determiner lemplacement pointe par le param`etre USER_DUMP_DEST


USER_DUMP_DEST : indication de lemplacement o`
u les fichiers de trace
seront enregistres

Activer le param`etre SQL_TRACE pour la session concernee

Executer lapplication

Executer tkprof sur les fichiers de trace

Etudier le fichier de sortie de tkprof

Ajuster les instructions SQL les plus co


uteuses

Repeter les etapes 4 `


a 8 jusqu`
a ce que lobjectif de performance soit
atteint

174/210

Optimisation des performances


Optimisation des applications Recettes

Les etapes du processus doptimisation

Remarque : Ne pas positionner pas le param`etre SQL_TRACE `a


TRUE dans le fichier init.ora :
Toutes les instructions SQL executees seraient enregistrees,
aboutissant `a un ralentissement sensible du syst`eme, ainsi
qu`a la saturation du syst`eme de fichiers

175/210

Optimisation des performances


Optimisation des applications Recettes

Activation dune session en mode trace


Execution 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 :
(`a partir de la version 7.2) il est possible de desactiver la trace
`a partir dune autre session
Ne pas desactiver la trace en annulant la session (kill)
Peut provoquer la troncature du fichier de trace et/ou
introduire des informations erronees dans ce fichier

176/210

Optimisation des performances


Optimisation des applications Recettes

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]

177/210

Optimisation des performances


Optimisation des applications Recettes

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)

178/210

Optimisation des performances


Optimisation des applications Recettes

Interpretation du resultat de TKPROF


Call : La phase du traitement de linstruction SQL (
les phases define et bind sont incluses dans la phase parse
Count : Le nombre dappels et dexecutions dune phase
CPU : Le temps CPU (en secondes) consomme pour
lexecution dune phase
Elapsed : Le temps CPU (en secondes) ecoule, cumule avec
lensemble des temps utilises par le SE pour
realiser les changements de contexte
traiter les interruptions
repondre aux signaux
executer les entrees-sorties
attendre les ressources
etc.

179/210

Optimisation des performances


Optimisation des applications Recettes

Interpretation du resultat de TKPROF

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


phase donnee
Query : Le nombre de blocs Oracle lus en memoire en mode
coherent (consistent mode)
Current : Le nombre de blocs Oracle lus en memoire en
mode courant
Rows Le nombre de lignes traitees dans chaque phase, avec les
valeurs pour les instructions select dans la phase fetch, et
pour les operation insert, update dans la phase execute

180/210

Optimisation des performances


Optimisation des applications Recettes

Utilitaires et Outils doptimisation


Resume

TOAD
OEM
TKPROF (outil capable de generer des traces)
UTLBSTAT/UTLESTAT
STATPACK (UTL et STAT sont des outils equivalents qui
permettent de recenser les requetes les plus consommatrices)
Scripts du DBAs (le DBA doit developper ses scripts)

181/210

Optimisation des performances


Utilitaires daudit

Interface TOAD

182/210

Optimisation des performances


Utilitaires daudit

Utilisation de TOAD

Administration de plusieurs Bases


Generation des scripts (Creation TBS, Table,IDX, ..)
Consultation et MAJ des Donnees
Comparaison des Objets des objects de deux schemas
etc.

183/210

Optimisation des performances


Utilitaires daudit

Interface Oracle Entreprise Manager (OEM)

184/210

Optimisation des performances


Utilitaires daudit

Utilisation dOEM

Administration de plusieurs bases


Generation des sripts
Consultation et mise `a jour des donnees
Comparaison des Objets objects de deux schemas
etc.

185/210

Optimisation des performances


Utilitaires daudit

TKPROF
Mettre la base ou la session en mode Trace :
Base : mettre SQL_TRACE=TRUE dans init.ora
Session : alter session set SQL_TRACE TRUE : set autotrace 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]

186/210

Optimisation des performances


Utilitaires daudit

Utlbstat et Utlestat

Utlbstat : permet le collecte des statistiques par lalimentation


des vues de la base
Utlestat : permet ledition dun etat de lactivite de la base en
sappuyant sur les donnees statistique collectees par
Utlbstat.sql (anciens outils doracle)
Ils sexecutent `a partir de SQL*PLUS connecte en tant que
SYSDBA
I n i t . o r a ( TIMED STATISTICS=TRUE)

187/210

Optimisation des performances


Utilitaires daudit

Utlbstat et Utlestat : Report.txt


Statistic
Total
Per Transact Per Logon Per Second
--------------------------- ---------- ------------ --------- ---------SQL*Net roundtrips to/from
15
15
15
.71
background timeouts
21
21
21
1
bytes received via SQL*Net
916
916
916
43.62
bytes sent via SQL*Net to c
601
601
601
28.62
calls to get snapshot scn:
6
6
6
.29
calls to kcmgas
1
1
1
.05
calls to kcmgrs
16
16
16
.76
commit cleanouts
10
10
10
.48
commit cleanouts successful
10
10
10
.48
consistent gets
4
4
4
.19
cursor authentications
4
4
4
.19
db block changes
26
26
26
1.24
db block gets
27
27
27
1.29
enqueue releases
15
15
15
.71
enqueue requests
9
9
9
.43
execute count
6
6
6
.29
free buffer requested
4
4
4
.19
logons cumulative
1
1
1
.05
messages received
1
1
1
.05
messages sent
1
1
1
.05
opened cursors cumulative
2
2
2
.1
parse count (hard)
4
4
4
.19

188/210

Optimisation des performances


Utilitaires daudit

Statpack
Installation (nouvel outil doracle, remplace Utlbstat, Utlestat)
Execution du script spcreate.sql

Collecte des statistiques


manuelle : statspack.snap
automatique : spauto.Sql
edition dun report entre deux snapshots spreport.sql

Compte-rendu de Statpack
Cinq premiers ev`enements Wait
Liste compl`ete des ev`enements Wait
Informations sur les instructions SQL
E/S des TBS et des fichiers
Statistiques sur lactivite de linstance

Optimisation des performances


Utilitaires daudit

Exemple de Scripts  du DBA  pour le suivi de la base (1)

189/210

Analyze.sql : Analyse statistique dun schema.


TablesChainees.sql : Affiche les tables ayant des enregistrements
chanes.
Freetbs.sql : Espace libre pour chaque tablespace.
Invalid.sql : Liste des objets invalides.
NbreExtents.sql : Objets depassant un certain nombre dextensions.
RbsStatus.sql : Statut des rollbacks.
Space.sql : Espace libre pour chaque tablespace.
ObjectNotExtent.sql : Objets ne pouvant plus setendre.
TbsCoalesce.sql : Liste de tous les tablespaces de la base avec pour
chacun, son pourcentage de fragmentation.

Optimisation des performances


Utilitaires daudit

Exemple de Scripts  du DBA  pour le suivi de la base (2)

190/210

TbsOffline.sql : Listes des tablespaces non actifs.


IndexUusuable.sql : Listes des index UNUSUABLE.
FragTable.sql : Etat de la fragmentation des tables.
UnusColTab : Tale eayant des colonnes UNUSED.

Optimisation des performances


Utilitaires daudit

Affichage de la liste des tables chanees :TablesChainees.sql

191/210

REM
REM P r o c e d u r e
REM
REM F o n c t i o n
REM

: TablesChainees . sql
: Affiche

les

t a b l e s ayant des e n r e g i s t r e m e n t s chai

c o l owner
f o r m a t a10
c o l t a b l e n a m e f o r m a t a30
spool chained rows . log
select

OWNER
,
TABLE NAME ,
CHAIN CNT ,
r o u n d ( ( CHAIN CNT/NUM ROWS) 1 0 0 , 2 ) % CHAIN
from
DBA TABLES
where
n v l ( CHAIN CNT , 0 ) > 0
o r d e r by CHAIN CNT d e s c ;
spool off

Optimisation des performances


Utilitaires daudit

Affichage des espaces libres des differents Tablespace de la


base

192/210

REM ==========================================================
REM P r o c e d u r e . . . . . . . . . . : FeeTbs . s q l
REM F o n c t i o n . . . . . . . . . . . : E s p a c e l i b r e p o u r c h a q u e t a b l e s p a c e
REM
spool

f r e e t b s . log

select

TABLESPACE NAME
sum (BLOCKS)
t r u n c ( sum (BYTES ) / ( 1 0 2 4 1 0 2 4 ) )
max ( b y t e s ) / ( 1 0 2 4 )
count ( )
from
DBA FREE SPACE
group by TABLESPACE NAME
o r d e r by f r e e m
/
spool off

as
as
as
as

,
free blk
,
,
free m
big chunk k ,
num chunks

193/210

Optimisation des performances


Utilitaires daudit

Affichage des objets ne pouvant plus setendre (1)

REM =======================================================
REM P r o c e d u r e . . . . . . . . . . : O b j e c t N o t E x t e n t . s q l
REM F o n c t i o n . . . . . . . . . . . : O b j e t s ne p o u v a n t p l u s s e t e n d r e
spool object extent . log
s e t l i n e s i z e 130
s e t t r i m s on
COLUMN
COLUMN
COLUMN
COLUMN
COLUMN
COLUMN

Tablespace
SegmentType
Owner
Segment
R e q u i r e d E x t e n t (KB)
M a x A v a i l (KB)

Format
Format
Format
Format
Format
Format

A30
A12
A12
A30
999 ,999 ,999.99
999 ,999 ,999.99

194/210

Optimisation des performances


Utilitaires daudit

Affichage des objets ne pouvant plus setendre (2)


SELECT
/+ RULE /
SEG . TABLESPACE NAME T a b l e s p a c e ,
SEG . SEGMENT TYPE
SegmentType ,
EXT .OWNER
,
Segment
,
EXT . SEGMENT NAME
decode ( FREESPACE . EXTENT MANAGEMENT,
DICTIONARY , SEG . NEXT EXTENT ,
LOCAL
, decode ( FREESPACE . ALLOCATION TYPE ,
UNIFORM , FREESPACE . INITIAL EXTENT ,
SYSTEM , EXT . BYTES
)
)
/ 1024
AS R e q u i r e d E x t e n t (KB) ,
FREESPACE . LARGEST / 1024 M a x A v a i l (KB)
FROM DBA EXTENTS EXT ,
DBA SEGMENTS SEG ,

195/210

Optimisation des performances


Utilitaires daudit

/+ RULE /
MAXSIZE PERFILE . TABLESPACE NAME ,
TBS . EXTENT MANAGEMENT
,
TBS . ALLOCATION TYPE
,
TBS . INITIAL EXTENT
,
TBS . NEXT EXTENT
,
max ( MAXSIZE PERFILE . MAXSIZEBYTES) AS LARGEST
FROM ( s e l e c t
/+ RULE /
DDF . TABLESPACE NAME ,
DDF . F I L E I D
,
decode (AUTOEXTENSIBLE ,
YES , (DDF . MAXBYTES DDF . BYTES ) ,
0
)
+ n v l ( max (DFS . BYTES ) , 0 ) AS MAXSIZEBYTES ,
NVL (MAX ( d f s . BYTES ) ,
0
) AS MAXFREEEXTENTSIZEBYTES

( select

196/210

Optimisation des performances


Utilitaires daudit

Affichage des objets ne pouvant plus setendre (4)


from DBA FREE SPACE DFS ,
DBA DATA FILES DDF,
DBA TABLESPACES TBSP
where DFS . F I L E I D (+)
= DDF . F I L E I D
and
TBSP . TABLESPACE NAME = DDF . TABLESPACE NAME
and
TBSP . CONTENTS
= PERMANENT
and
TBSP . s t a t u s
= ONLINE
group by DDF . TABLESPACE NAME ,
DDF . F I L E I D ,
decode (AUTOEXTENSIBLE ,
YES , (DDF . MAXBYTES DDF . BYTES ) ,
0
) ) MAXSIZE PERFILE ,
DBA TABLESPACES TBS

197/210

Optimisation des performances


Utilitaires daudit

Affichage des objets ne pouvant plus setendre (5)


WHERE MAXSIZE PERFILE . TABLESPACE NAME = TBS . TABLESPACE NAME
AND
TBS . STATUS
= ONLINE
group by MAXSIZE PERFILE . TABLESPACE NAME ,
TBS . EXTENT MANAGEMENT,
TBS . ALLOCATION TYPE ,
TBS . INITIAL EXTENT ,
TBS . NEXT EXTENT) FREESPACE
where SEG .OWNER
= EXT .OWNER
and
SEG . SEGMENT TYPE
= EXT . SEGMENT TYPE
and
SEG . SEGMENT NAME
= EXT . SEGMENT NAME
and
SEG . TABLESPACE NAME = EXT . TABLESPACE NAME
and
( SEG . EXTENTS 1 )
= EXT . EXTENT ID
and
SEG . TABLESPACE NAME = FREESPACE . TABLESPACE NAME
and
decode ( FREESPACE . EXTENT MANAGEMENT,
DICTIONARY , SEG . NEXT EXTENT ,
LOCAL
, decode ( FREESPACE . ALLOCATION TYPE ,
UNIFORM ,
FREESPACE . INITIAL EXTENT ,
SYSTEM , EXT . BYTES
)
) >= FREESPACE . LARGEST

198/210

Optimisation des performances


Utilitaires daudit

Affichage des objets ne pouvant plus setendre (5)

o r d e r by SEG . TABLESPACE NAME ,


SEG . SEGMENT TYPE
,
SEG . SEGMENT NAME
/
spool off

199/210

Optimisation des performances


Utilitaires daudit

Affichage des objets dont nombre extents > `a une


constante (1)
REM
REM
REM
REM
REM

===========================================================
Procedure : NbreEextents . s q l
Fonction
: O b j e t s d e p a s s a n t un c e r t a i n nombre d e x t e n s i o n s
P a r a m e t r e s . . . . . . . . . : &1 : Nombre d e x t e n s i o n s
===========================================================

c o l OWNER
f o r m a t a8
c o l SEGMENT TYPE f o r m a t a18
c o l SEGMENT NAME f o r m a t a25
spool nr extents . log
select

S .OWNER
,
S . SEGMENT TYPE
,
S . SEGMENT NAME
,
EXTENTS ,
t o c h a r ( S . BYTES/ ( 1 0 2 4 1 0 2 4 ) , 9 9 9 , 9 9 9 . 9 0 ) a s MB

200/210

Optimisation des performances


Utilitaires daudit

Affichage des objets dont nombre extents > `a une


constante (2)

FROM
DBA SEGMENTS s
where
EXTENTS > &1
o r d e r by EXTENTS d e s c
/
spool off

201/210

Optimisation des performances


Utilitaires daudit

Affichage des objets invalides (1)


REM
REM
REM
REM

===========================================================
Procedure : I n v a l i d . s q l
Fonction
: O b j e t s d e p a s s a n t un c e r t a i n nombre d e x t e n s i o n s
===========================================================

c o l owner
f o r m a t a10
c o l o b j e c t t y p e f o r m a t a20
c o l o b j e c t n a m e f o r m a t a30
spool i n v a l i d . log
prompt OBJETS
s e l e c t owner , o b j e c t t y p e , o b j e c t n a m e , s t a t u s
from
dba objects
where
s t a t u s != VALID
/

202/210

Optimisation des performances


Utilitaires daudit

Affichage des objets invalides (2)

prompt TRIGGER
select trigger name
from
dba triggers
where
s t a t u s != ENABLED ;
spool off

203/210

Optimisation des performances


Utilitaires daudit

Resultat de la requete tps rep


Service Time
************
Parse CPU
Recursive CPU
Other

:
:
:

Total CPU

38,111 (1.27%)
1,083,086 (36.19%)
1,871,438 (62.53%)
-----------------------2,992,635 (100%)

Wait Time
*********
Total Wait Time :

1,833,187,429

Response Time (Service Time + Wait Time)


***************************************
Service Time
Wait Time
Response Time

:
:

2,992,635 (.16%)
1,833,187,429 (99.84%)
-------------------------:
1,836,180,064 (100%)

204/210

Optimisation des performances


Utilitaires daudit

Requete tps rep.sql (1)


s e t s e r v e r o u t p u t on s i z e 1000000
s e t l i n e 80
declare
c u r s o r CalculCpu i s
select a . value
total cpu
,
b . value
parse cpu
,
c . value
recursive cpu ,
a . value b . value c . value
other
from
v$sysstat a ,
v$sysstat b ,
v$sysstat c
where a . name = CPU u s e d by t h i s s e s s i o n
and
b . name = p a r s e t i m e cpu
and
c . name = r e c u r s i v e cpu u s a g e ;

205/210

Optimisation des performances


Utilitaires daudit

Requete tps rep.sql (2)


c u r s o r CalculTime i s
s e l e c t sum ( t i m e w a i t e d ) t o t a l w a i t t i m e
from
v$system event a
where a . e v e n t no t l i k e SQL%
and
a . e v e n t no t l i k e KXFX%
and
a . e v e n t no t l i k e s l a v e w a i t
and
a . e v e n t no t l i k e Wait f o r s l a v e s%
and
a . e v e n t no t l i k e P a r a l l e l%Qu%I d l e%S l a%
and
a . e v e n t no t l i k e r e f r e s h c o n t r o f i l e%
and
a . e v e n t no t i n (
r e l i a b l e message ,
file identify ,
f i l e open ,
dispatcher timer ,
virtual circuit status ,
control f i l e p a r a l l e l write ,
c o n t r o l f i l e s e q u e n t i a l read ,
r e f r e s h c o n t r o l f i l e command ,

206/210

Optimisation des performances


Utilitaires daudit

Requete tps rep.sql (3)


Null event ,
pmon t i m e r ,
rdbms i p c r e p l y ,
rdbms i p c m e s s a g e ,
r e l i a b l e message ,
smon t i m e r ,
wakeup t i m e manager ,
PX I d l e Wait ,
SQL Net m e s s a g e t o c l i e n t ,
SQL Net m e s s a g e from c l i e n t ,
SQL Net b r e a k / r e s e t t o c l i e n t ) ;
ServiceTime
WaitTime
Fic1

NUMBER;
NUMBER;
UTL FILE . FILE TYPE ;

207/210

Optimisation des performances


Utilitaires daudit

Requete tps rep.sql (4)


begin
F i c 1 := u t l f i l e . f o p e n (
/ o p t / a p p l / dwhv / dbdc / o r a c l e / admin / dba / , t p s r e p . l i s , W ) ;
u t l f i l e . p u t l i n e ( F i c 1 , c h r ( 9 ) | | c h r ( 9 ) | | c h r ( 9 ) | | S e r v i c e Time ) ;
u t l f i l e . p u t l i n e ( F i c 1 , c h r ( 9 ) | | c h r ( 9 ) | | c h r ( 9 ) | | ) ;
u t l f i l e . p u t l i n e ( Fic1 , ) ;
f o r Boucle in CalculCpu
loop
u t l f i l e . p u t l i n e ( F i c 1 , P a r s e CPU
: ||
t o c h a r ( Boucle . parse cpu , 999 ,999 ,999 ,999 ) | | ( | |
r o u n d ( ( B o u c l e . p a r s e c p u / B o u c l e . t o t a l c p u ) 1 0 0 , 2 ) | | %) ) ;
u t l f i l e . p u t l i n e ( F i c 1 , R e c u r s i v e CPU : | |
t o c h a r ( Boucle . r e c u r s i v e c p u , 999 ,999 ,999 ,999 ) | | ( | |
r o u n d ( ( B o u c l e . r e c u r s i v e c p u / B o u c l e . t o t a l c p u ) 1 0 0 , 2 ) | | %) ) ;
u t l f i l e . p u t l i n e ( Fic1 , Other
: ||
t o c h a r ( Boucle . other , 999 ,999 ,999 ,999 ) | | ( | |
r o u n d ( ( B o u c l e . o t h e r / B o u c l e . t o t a l c p u ) 1 0 0 , 2 ) | | %) ) ;
u t l f i l e . p u t l i n e ( Fic1 , chr ( 9 ) | | chr ( 9 ) | | chr ( 9 ) | | chr ( 9 ) | |
c h r ( 9 ) | | ) ;

208/210

Optimisation des performances


Utilitaires daudit

Requete tps rep.sql (5)


u t l f i l e . p u t l i n e ( F i c 1 , T o t a l CPU
: ||
t o c h a r ( B o u c l e . t o t a l c p u , 9 9 9 , 9 9 9 , 9 9 9 , 9 9 9 ) | | (100%) ) ;
S e r v i c e T i m e := B o u c l e . t o t a l c p u ;
end l o o p ;
utl
utl
utl
utl

file
file
file
file

.
.
.
.

put
put
put
put

line
line
line
line

( Fic1
( Fic1
( Fic1
( Fic1

,
,
,
,

chr ( 1 0 ) ) ;
c h r ( 9 ) | | c h r ( 9 ) | | c h r ( 9 ) | | Wait Time ) ;
c h r ( 9 ) | | c h r ( 9 ) | | c h r ( 9 ) | | ) ;
);

f o r Boucle in CalculTime
loop
u t l f i l e . p u t l i n e ( F i c 1 , T o t a l Wait Time : | |
t o c h a r ( Boucle . t o t a l w a i t t i m e , 999 ,999 ,999 ,999 ) ) ;
WaitTime := B o u c l e . t o t a l w a i t t i m e ;
end l o o p ;
u t l f i l e . p u t l i n e ( Fic1 , chr ( 1 0 ) ) ;
u t l f i l e . p u t l i n e ( Fic1 , chr ( 9 ) | | chr ( 9 ) | | chr ( 9 ) | |
R e s p o n s e Time ( S e r v i c e Time + Wait Time ) ) ;

209/210

Optimisation des performances


Utilitaires daudit

Requete tps rep.sql (6)

u t l f i l e . p u t l i n e ( Fic1 , chr ( 9 ) | | chr ( 9 ) | | chr ( 9 ) | |


) ;
u t l f i l e . p u t l i n e ( Fic1 , ) ;
u t l f i l e . p u t l i n e ( F i c 1 , S e r v i c e Time
: ||
t o c h a r ( ServiceTime , 999 ,999 ,999 ,999 ) | | ( | |
r o u n d ( S e r v i c e T i m e / ( S e r v i c e T i m e+WaitTime ) 1 0 0 , 2 ) | | %) ) ;
u t l f i l e . p u t l i n e ( F i c 1 , Wait Time
: ||
t o c h a r ( WaitTime , 9 9 9 , 9 9 9 , 9 9 9 , 9 9 9 ) | | ( | |
r o u n d ( WaitTime / ( S e r v i c e T i m e+WaitTime ) 1 0 0 , 2 ) | | %) ) ;
u t l f i l e . p u t l i n e ( Fic1 , chr ( 9 ) | | chr ( 9 ) | | chr ( 9 ) | | chr ( 9 ) | |
c h r ( 9 ) | | ) ;
u t l f i l e . p u t l i n e ( F i c 1 , R e s p o n s e Time : | |
t o c h a r ( S e r v i c e T i m e+WaitTime , 9 9 9 , 9 9 9 , 9 9 9 , 9 9 9 ) | | (100%) )
u t l f i l e . f c l o s e ( Fic1 ) ;
e x c e p t i o n

when OTHERS t h e n

u t l f i l e . f c l o s e ( Fic1 ) ;
end ;
/

210/210

Optimisation des performances


Utilitaires daudit

Resultat de la requete tps rep


Service Time
************
Parse CPU
Recursive CPU
Other

:
:
:

Total CPU

38,111 (1.27%)
1,083,086 (36.19%)
1,871,438 (62.53%)
-----------------------2,992,635 (100%)

Wait Time
*********
Total Wait Time :

1,833,187,429

Response Time (Service Time + Wait Time)


***************************************
Service Time
Wait Time

:
:

Response Time

2,992,635 (.16%)
1,833,187,429 (99.84%)
-------------------------1,836,180,064 (100%)