Oracle 8.1.7.4 interpration resultat tkprof

Bonjour ,

Suite à un changement de version, nous constations qu ' job dure 25 minutes au lieu de 6 dans la version précédente .
Le système,la base de données, la volumétrie n' ont pas changé entre les deux .
L' éditeur du logiciel ne croit pas que le chgt de version soit en cause .
J' ai récupéré la trace du job et lancé le tkprof, je ne comprends pas tout
dans le résultat :

J' ai tracé pendant 10 minutes ( fichier dump plein )
ds le tkprof, j' ai seulement 15 requêtes sql explicités sur les 75141 !

l' outil tkprof ( ou la trace) ne récupére les différentes valeurs bindées
ce qui expliquerait le nb de requêtes et le nb de fois qu' elles sont executées .

résultat tkprof :

Citation:

---

SELECT CB||CE||NVL(TO_CHAR(CG,'YYYYMMDD'),' ')||C01||C02
FROM
D21V2_ENG WHERE CB = :0000 AND CE >= :0001 ORDER BY CB,CE


call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 24562 2.03 1.98 0 0 0 0
Fetch 49124 4.53 5.01 736 153224 0 245621
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 73687 6.56 6.99 736 153224 0 245621

Misses in library cache during parse: 0
Optimizer goal: RULE
Parsing user id: 34
********************************************************************************

SELECT NVL(TO_CHAR(CG,'YYYYMMDD'),' ')||C01||C02||C03||NVL(TO_CHAR(C04,
'YYYYMMDD'),' ')
FROM
D21V2_ENGHIE WHERE CB = :0000


call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 24562 4.49 3.56 0 0 0 0
Execute 24562 1.51 1.40 0 0 0 0
Fetch 24562 1.42 1.43 473 98248 0 24562
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 73686 7.42 6.39 473 98248 0 24562

Misses in library cache during parse: 0
Optimizer goal: RULE
Parsing user id: 34

Rows Row Source Operation
------- ---------------------------------------------------
1 TABLE ACCESS BY INDEX ROWID D21V2_ENGHIE
1 INDEX UNIQUE SCAN (object id 103367)

********************************************************************************

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)

********************************************************************************

SELECT NVL(TO_CHAR(CG,'YYYYMMDD'),' ')||C01||C02||NVL(TO_CHAR(C03,'YYYYMMDD'),
' ')||NVL(TO_CHAR(C04,'YYYYMMDD'),' ')||C05||NVL(TO_CHAR(C06,
'S00000000000D00'),' ')||NVL(TO_CHAR(C07,'S00000000000D00'),' ')||C08||C09
FROM
D21V9_PARPAR WHERE CB = :0000


call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1445 0.16 0.16 0 0 0 0
Execute 1445 0.06 0.07 0 0 0 0
Fetch 1445 0.07 0.09 0 2890 0 1445
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4335 0.29 0.32 0 2890 0 1445

Misses in library cache during parse: 0
Optimizer goal: RULE
Parsing user id: 34

Rows Row Source Operation
------- ---------------------------------------------------
1 TABLE ACCESS BY INDEX ROWID D21V9_PARPAR
1 INDEX UNIQUE SCAN (object id 105169)

Trace file: ora_87032_pletst.trc
Trace file compatibility: 8.00.04
Sort options: default

1 session in tracefile.
75139 user SQL statements in trace file.
2 internal SQL statements in trace file.
75141 SQL statements in trace file.
15 unique SQL statements in trace file.
749956 lines in trace file.

---

comment interpreteriez vous le paragraphe ou parse=execute=fecth=24562 et ne ramène aucune ligne ?

cordialement

Citation:

---

Suite à un changement de version

---

Changement de version de quoi, du progiciel, de la base Oracle ?

Toutes tes requêtes sont en RULE, c'est normal ou bien c'est parce qu'il n'y a aucune stats sur la nouvelle base ?



Laly.

Bonjour ,

Nouvelle version du logiciel (prigiciel pleiades), j' ai remarqué un alter session dans
la trace sql qui force le mode rule.
j' en déduis que ce mode est imposé par l' éditeur du logiciel , ce qui n' est pas surprenant vu la façon dont est faite l' appli
( beaucoup de tables, tres peu de colonnes (3,4) , 1 seul index par table
sur la clé primaire )

pour ceux qui ne connaissent pas pleiades : ce produit est écrit en cobol
qui execute du pro-c pour interroger la base .

cdlt

Citation:

---

Envoyé par ducho

force le mode rule

---

:? :koi:

C'est quand même obsolète !

Ce que je te conseillerais c'est de calculer toutes les stats, relancer ton traitement en supprimant cet alter session et de comparer les temps de traitements. Si ce n'est pas convaincant ce qui m'étonnerais, tu pourras toujours supprimer les stats et remettre l'alter session.


Laly.

désolé, mon but n' est pas de lancer le traitement avec l' optimiseur statistique, c' est de comparer les traces sql entre les deux versions .

de toute façon, je ne peux pas supprimer cette commande, ne sachant
absolument pas dans quel fichier elle se trouve
( eventuellement je pourrais chercher avec un grep mais bon ..)

ce qui m' interesse, c' est de comprendre un peu mieux le résultat
du tkprof .

je te remercie toutefois de tes réponses ( je compte mettre en place
ces stats si l' éditeur du logiciel ratifie cette décision )

cdlt

Citation:

---

75141 SQL statements in trace file

---

Il n'y a que 15 requêtes dans le rapport tkprof, car les requêtes ont été aggrégées quand elles sont identiques.

Citation:

---

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)

---

Ce type de requête a été parsé 24562 fois. Comme "Misses in library cache during parse: 0", il s'agit uniquement de soft parse (la requête a été retrouvé dans le shared pool). Il peut s'agir d'un curseur qui est fermé puis ouvert à chaque exécution...

Le fait que Fetched=24562 mais que ca ne rapporte aucune ligne ne me choque pas, c'est juste que la requête ne rapporte aucune ligne.


Si on regarde les temps des différentes requêtes : 6.99 + 6.39 + 4.22 + 0.32 = 17.95s on est très loin des 10min ! En plus vu le nombre de fois où chaque requête est exécutée, elles sont même très performantes.
Il y a sans doute autre chose qui consomme du temps entre l'exécution de deux requêtes (calcul PL/SQL pur ?)

Laly.

Quelles sont les évènements d'attente au niveau de la session ???

AHh ta réponse m' interesse beaucoup ,

le temps cpu est-il le temps total que prennent les 24562 opérations ?
peut-on penser qu' il y a autant d' executions que de valeurs différentes
de CB ?

ou est-ce que tkprof fait un calcul global pour toutes les requêtes
identiques qui ne sont pas explicitées dans le rapport ?

sinon je pense effectivement qu' il y a de gros traitements entre les requêtes car le batch prend 50% des resources cpu du sereveur .

je te remercie vivement de ton aide .

cdlt

Jaouad,

j' ai cherché aussi cette piste, la table v$session_wait pour cette session
ne contient que des events de type :
"sql*net message from client"

je me suis servi de l' excellent livre "optimisation des performances sous oracle" pour avancer dans cette voie , mais pour l' instant je n' aboutis à rien .

cdlt

Citation:

---

Envoyé par ducho

Jaouad,

j' ai cherché aussi cette piste, la table v$session_wait pour cette session
ne contient que des events de type :
"sql*net message from client"

je me suis servi de l' excellent livre "optimisation des performances sous oracle" pour avancer dans cette voie , mais pour l' instant je n' aboutis à rien .

cdlt

---

C'est effctivment un trés bon livre , cependant cet évènement ne siginifie pas qu'il nowait .

Quand est il du traffic réseau ?

Justement là ça m' échappe un peu,

ne sachant pas comment les requêtes sont appelées ( via net8 ou pas),
je ne peux pas investiguer plus ..
en tout cas ce serveur héberge 4 transactionnels et les utilisateurs
n' ont pas constaté de ralentissement dans leurs temps de réponse .
mon serveur est un petit unix bi-pro, je ne pense pas qu' il soit en cause,
n' en déplaise à cet éditeur de logiciel .

( j' attends toujours un rappel de leur hot-line! )

EN fait oracle , si je me rappelle bien de mes cours d'optim se met en SQL*NET .....
dés qu'il commence à renvoyer la prmiére lignes demandés , et pas quand tu dispose de toutes tes lignes sur ton POSTE

oui
mais là c' est du batch : rien ne sort du serveur .

Citation:

---

Envoyé par ducho

oui
mais là c' est du batch : rien ne sort du serveur .

---

pas de requête du type

insert .... select

je n' ai pas le code sql complet mais s' il y avait des insert (sql) ,
la trace me les aurait montrés .
il s' agit d' extraction de donneées avec lesquelles on crée un fichier
de sortie, donc à priori que du select .

Citation:

---

Envoyé par ducho

il s' agit d' extraction de donneées avec lesquelles on crée un fichier
de sortie, donc à priori que du select .

---

ton fichier de sortie est crée sur le serveur ?

oui

et quelles sont les autres évènements d'attente aprés celui ci

pour cette session, la table ne contient que cet event, rien d' autres .

Citation:

---

Envoyé par ducho

pour cette session, la table ne contient que cet event, rien d' autres .

---

c'est pas possible
il y au moins du DB FILE SCATERRED READ , car tu passe par un index pour les données dans ta table

Attention que le batch lorsqu'il se termine , ne se déconnecte pas