Discussion :

[Pozzo]

Bonjour,

J'espère poster sur le bon forum.
Nous utilisons tkprof pour tracer un traitement.

L'outil est invoqué deux fois:
- Une fois pour générer un fichier texte (pas d'options)
- Une fois pour générer un fichier sql (option insert=fic.sql) qui renseignera la table tkprof_table

OR je constate que les valeurs de la colonne FETCH_ELAP ne sont pas toujours les mêmes dans le fichier texte et le fichier SQL:
Fichier texte:

Code :

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

1
2
3
4
5
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.46       1.11          0        103          0           0
Fetch     6001   2348.92   >13984.43<          0   78374068          0    60000000

fichier sql:

Code :

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

1
2
3
4
5
6
7
INSERT INTO tkprof_table VALUES
(
  14562, 395, 2, 93, 1, 0, 429, 0, 0, 0, 1 
, 1, 468000, 1114855, 0, 103, 140720308486144, 1, 0 
, 6001, 2348924000, >1099536497<, 0, 78374068, 0, 60000000, 1312530799 
, '[SQL]'
);

La valeur 1099536497 / 1000000 = 1099 est différente de 13984.43
Alors que la valeur précédente 2348924000 / 1000000 = 2348.924 correspond bien à 2348.92
C'est TRES gênant.

Ma question est: Est-ce que quelqu'un s'est déjà servi de la table tkprof_table et a-t-il entendu parler d'une valeur erronée de FETCH_ELAP ?

Pozzo.1JournéeGâchée?

[pachot]

Bonjour,
Est-ce que tu peux fournir le fichier trace brute (.dmp)? Je testerai.
Merci,
a+,
Franck.

[pachot]

J'ai testé sur une 12.1 et les deux chiffres me paraissent coherents:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
cat > tmp.dmp <<EOF
PARSING IN CURSOR #1 len=308 dep=0 uid=0 oct=3 lid=0 tim=90405840140 hv=3565039109 ad='0x8530fc38' sqlid='42kzscra7wbh5'
select ...
END OF STMT
FETCH #1:c=111111,e=222222,p=0,cr=4,cu=0,mis=0,r=0,dep=1,og=4,plh=813480514,tim=90405840218
EOF
tkprof tmp.dmp tmp.txt
tkprof tmp.dmp tmp.txt insert=tmp.sql
awk '/call/,/total/' tmp.txt
awk '/INSERT/,/[/]/' tmp.sql

Code :

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

1
2
3
4
5
6
7
8
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        1      0.11       0.22          0          4          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        1      0.11       0.22          0          4          0           0

Code :

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

1
2
3
4
5
6
7
INSERT INTO tkprof_table VALUES(
  SYSDATE, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0
, 0, 0, 0, 140733193388032, 0, 0, 0, 0
, 1, 111111, 222222, 0, 4, 0, 0, 78
, 'select ...
')
/

[Pozzo]

Salut,

Merci de prendre du temps pour me répondre.
Je suis sous Oracle 12.1.0.2 EE sous Linux suse

Une bonne proportion des valeurs de FETCH_ELAP sont bons.
Quelques uns seulement sont faux.

Je vais isoler la partie de la trace brute qui concerne l'exemple erroné que j'ai donné.
(La trace totale fait 65G)

Il est possible que du parallélisme s'applique à ma requête. Je vais vérifier.

A très vite.
Pozzo