Discussion :

[yanis97]

Bonjour;

je souhaite savoir quels sont les paramètres critiques les plus importants à vérifier ds un rapport statspack avec les seuils de tolérance.
J'utilise dèjà l'analyseur : http://www.statspackanalyzer.com/analyze.asp
mais les recommandations ne sont pas terribles !
Concernant les req SQL :

Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ---

Comment vérifier qu'une req pose pb de perf ?
S'il y'a une doc (de pref en français) qui explique tout ca, je suis prenant.

Merci

[pifor]

Une requête peut poser des problèmes de performances si par exemple les temps d'exécution ou les temps CPU cumulés sont importants par rapport à la durée de la période analysée.

Il faut essayer de confirmer ceci en mettant en testant un scénario applicatif avec la trace SQL et analyser la trace avec TKPROF. Théoriquement, c'est l'utilisateur final qui doit dire "le scénario A met actuellement X secondes/minutes/heures à s'exécuter mais il faut qu'il prenne seulement Y".

[mnitu]

...
Comment vérifier qu'une req pose pb de perf ?
S'il y'a une doc (de pref en français) qui explique tout ca, je suis prenant.

Merci

Tom Kyte, Effective Oracle By design, chapitre 2 qui peut être téléchargé gratuitement sur internet explique ça. Mais c'est en anglais.
Le statpackanalyzer c'est trop commercial il finit toujours par te vendre des disks plus rapides
Je prefère de loin oraperf. C'est toujours en anglais mais en plus on peut télécharger quelques articles qui expliquent le démarche d'Anjo Kolk.

[farenheiit]

Une requête peut poser des problèmes de performances si par exemple les temps d'exécution ou les temps CPU cumulés sont importants par rapport à la durée de la période analysée.

Il faut essayer de confirmer ceci en mettant en testant un scénario applicatif avec la trace SQL et analyser la trace avec TKPROF. Théoriquement, c'est l'utilisateur final qui doit dire "le scénario A met actuellement X secondes/minutes/heures à s'exécuter mais il faut qu'il prenne seulement Y".

Il vaut mieux diviser le temps d'exécution d'une requête par son nombre d'exécution dans v$sql ça permet de voir rapidement les requêtes qui posent le plus pb.
Sinon dans Statspack il faut surtout regarder le Top 5 wait events

[farenheiit]

Tom Kyte, Effective Oracle By design, chapitre 2 qui peut être téléchargé gratuitement sur internet explique ça. Mais c'est en anglais.

T'as le lien ? ça m'intéresse

[mnitu]

T'as le lien ? ça m'intéresse

Le lien non le chapitre oui.

[farenheiit]

Le lien non le chapitre oui.

tu peux me l'envoyer?

[mnitu]

tu peux me l'envoyer?

oui

[pifor]

Voici le lien:
http://asktom.oracle.com/pls/asktom/...22925097021874

[farenheiit]

merci Pierre!!
t'as le lien vers tous les chapitres ? les chapitres 5 et 8 m'intéressent aussi

[pifor]

Non, je n'ai pas les autres chapitres. Ce lien peut être trouvé sur le menu Files de AskTom (cliquer sur Files en haut à droite).

[pachot]

Bonjour,

Je ne crois pas que tu prennes le problème par le bon bout.
L'idée de statspack (ou n'importe quelle autre statistique) c'est lorsqu'il y a un problème de perf, celà permet de comprendre pourquoi, et donc d'y remédier.
Mais pas l'inverse !
Rien dans le système ne te dira qu'une requête a un pb. C'est le temps de réponse de l'appli qui t'amenera à une analyse, qui te dirigera vers une ou plusieurs requêtes.
Les seuils de tolérance, c'est un temps de réponse. Rien d'autre.

Sinon, c'est comme si tu allais chez le medecin pour lui demander si tu vas bien.

Quelques examples:
utilisation de 90% de CPU, c'est bien ou pas bien ?
utilisation de 10% de CPU, c'est bien ou pas bien ?
un full scan de table, c'est bien ou pas bien ?
un plan d'execution avec que des accès par index, c'est bien ou pas bien ?

Par contre,
utilisateur satisfait, application répondant en moins d'une seconds, batch ne dépassant pas la nuit, performance identique même avec 2 fois plus d'utilisateurs: ça c'est bien. C'est ça les 'seuils de tolérance', pour moi.

Cordialement,
Franck.

[farenheiit]

tout à fait d'accord

[Pomalaix]

Sinon, c'est comme si tu allais chez le medecin pour lui demander si tu vas bien.

Mais justement, chez les êtres humains, des indicateurs de bonne santé ont été identifiés : température autour de 37 °, tension artérielle entre X et Y, taux de cholestérol, nombre de globules blancs, poids en proportion de la stature, etc.
Ce qui serait stupide, c'est de vouloir juger de la santé d'un poulpe avec les mêmes indicateurs.

Or le souci, c'est que 2 bases Oracle peuvent être aussi dissemblables qu'un humain et un poulpe.
Dans ce cas, les valeurs absolues ne sont d'aucun secours.

C'est pourquoi par exemple Oracle 10g a introduit la notion de ligne de base : en enregistrant l'activité pendant une période où les performances sont jugées normales et satisfaisantes, on définit une référence, et ensuite on pourra détecter les écarts par rapport à ces valeurs de référence, mais qui n'auront de sens que pour la base concernée.

[Ashleycole]

Bonjour la communauté,
je viens solliciter votre aide pour déceler une déficience de ma base de données Oracle.
Je crois que mon cas est celui dont Pifor parle: temps et délai d'exécution de mes requêtes sont trop importants au point que mes utilisateurs ne peuvent même plus travailler.
Dans la pratique lorsque çà arrive, tout se "grippe" et le sablier apparaît chez tous les utilisateurs connectés sur la base et qui travaillent sur l'application (une application codé forms/oracle 10G R2 qui tourne sur 1serveur d'état avec pour OS RED HAT 4 et 1serveur de BD avec pour OS RED HAT 5 et les clients sont sur Windows ).
J'ai installé donc cet outil statpack en espérant déceler quelque chose dans le rapport.
Je soupçonne également les sessions et j'aimerais qu'on m'éclaire sur le choix à faire pour une meilleure performance:est-il meilleur de fonctionner avec des sessions dédiées ou pas?
Mon rapport est très volumineux (66pages en .doc) si bien que je suis gêné de l'ajouter en pièce jointe .

Merci

[McM]

Première chose à lire : le top 5 des events

Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time
----------------------------------------- ------------ ----------- ------ ------
enq: TM - contention 100 290 2897 97.7

Tu as des locks sur ta base, d'où le sablier des utilisateurs.
Le mieux est de vérifier les sessions bloquantes avec un outil comme toad ou sql developer lorsque cela se produit.

PS : C'était juste une analyse rapide du fichier

[Mohamed.Houri]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
Top 5 Timed Events                                                    Avg %Total
~~~~~~~~~~~~~~~~~~                                                   wait   Call
Event                                            Waits    Time (s)   (ms)   Time
----------------------------------------- ------------ ----------- ------ ------
enq: TM - contention                               100         290   2897   97.7
CPU time                                                         4           1.5
os thread startup                                   54           1     20     .4
control file parallel write                      1,202           1      1     .2
log file parallel write                            861           0      0     .1
          -------------------------------------------------------------

97,7% du temps du rapport a été consommé par l'événement enq: TM-contention

Ce type de lock s'associe généralement avec des DML sur des tables. Ces locks, en temps normal, génèrent des temps d'attentes insignifiants sauf si vous faites des (insert, delete, update, select for update) d'une table mère ayant une table fille reliée par une contrainte d'intégrité (FK) qui n'est pas indexée.

Donc, vérifiez bien que vos tables filles possèdent des indexes sur les colonnes composant la contrainte FK pour couvrir ce cas de lock.

Vous pouvez aussi consulter la partie "SQL ordered by Elapsed time" car il y a de fortes chances que les sqls qui s'y trouvent participent bien à ce lock.

[skuatamad]

Donc, vérifiez bien que vos tables filles possèdent des indexes sur les colonnes composant la contrainte FK pour couvrir ce cas de lock.

Juste pour fournir le script de tom kyte qui permet de détecter les FK non indéxées :
Unindexed Foreign Keys

[mnitu]

Ces locks, en temps normal, génèrent des temps d'attentes insignifiants sauf si vous faites des (insert, delete, update, select for update) d'une table mère ayant une table fille reliée par une contrainte d'intégrité (FK) qui n'est pas indexée.
...

Il faut nuancer un peu ça sinon il y aura des indexes par tout!

Session 1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 
Connected to Oracle Database 10g Express Edition Release 10.2.0.1.0 
Connected as mni
 
SQL> 
SQL> create table t_mere (
  2    id_mere   int primary key,
  3    lib       varchar2(10)
  4  )
  5  /
 
Table created
SQL> create table t_fils (
  2    id         int primary key,
  3    id_mere    references t_mere,
  4    text        varchar2(20)
  5  )
  6  /
 
Table created
SQL> insert all
  2    into t_mere
  3      values (1, 'mere 1')
  4    into t_mere
  5      values (2, 'mere 2')
  6    into t_mere
  7      values (3, 'mere 3')
  8  Select Null
  9    From dual
 10  /
 
3 rows inserted
SQL> insert all
  2    into t_fils
  3      values (100, 1, 'fils 100 mere 1')
  4    into t_fils
  5      values (101, 1, 'fils 101 mere 1')
  6    into t_fils
  7      values (200, 2, 'fils 200 mere 2')
  8    into t_fils
  9      values (201, 2, 'fils 201 mere 2')
 10  Select Null
 11    From dual
 12  /
 
4 rows inserted
SQL> commit
  2  /
 
Commit complete
 
SQL>

Session 2

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
lock table t_fils in exclusive mode nowait
/

Après dans Session 1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
update t_mere set lib = upper(lib)
  2  /
 
3 rows updated
 
SQL> rollback;
 
Rollback complete
 
SQL> 
SQL> Select *
  2    From t_mere
  3   for update
  4  /
 
                                ID_MERE LIB
--------------------------------------- ----------
                                      1 mere 1
                                      2 mere 2
                                      3 mere 3
 
SQL> rollback;
 
Rollback complete
 
SQL>

Comme vous pouvez le constater je fais des update et des select for update sans aucun (inter)blocage.

[pachot]

Bonjour,

Comme vous pouvez le constater je fais des update et des select for update sans aucun (inter)blocage.

De manière générale c'est lorsqu'on modifie dans la table mère la clé référencée par la table fille que celle-ci est verrouillée (verrou TM en mode Share) si la foreign key vers cette clé n'est pas indexée.
Donc un delete un la table mère, ou un update d'une colonne de la contrainte référencée.

Dans ton exemple, un delete sur t_mere ou un update de id_mere, même s'ils ne touchent aucune ligne, aurait été bloqué et aurait en outre bloqué toute nouvelle modification sur la table t_fils, jusqu'à ce que la transaction initiale se termine.

Il y a d'autres variations là dessus. MERGE par exemple pose ce type de verrou même s'il ne fait ni delete ni update. Probablement un bug qui sera corrigé un jour. Des ON CASCADE peuvent aussi propager des verrous sans raison.

Mais c'est vrai qu'il ne faut pas toujours indexer les foreign key. Si on a une table de référence statique qui a peu de valeurs, il n'y a pas de problème de verrous (pas de mises à jour) et on a pas besoin qu'un index qui ne serait pas assez sélectif.

Cordialement,
Franck.