Discussion :

[Ikebukuro]

Bonjour,

J'ai généré une trace 10046 sur une Oracle 12 avec le niveau 4 pour voir les bind variables.
Avec tkprof je me rends compte que les bind values sautent... mais bon, ce n'est pas le plus grave, je vais lire le fichier brut.

Le problème que je rencontre est le suivant : une même requête peut s'exécuter plusieurs fois, avec des valeurs de bind différentes MAIS, parfois, leur nombre change, leur type est parfois incompatible...

Exemple 1 OK : 3 exécutions, bind variables OK en nombre et en type.

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
SQL ID: 1p5grz1gs7fjq Plan Hash: 813480514
select obj#,type#,ctime,mtime,stime, status, dataobj#, flags, oid$, spare1, spare2, spare3, signature, spare7, spare8, spare9
from obj$ 
where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null and linkname is null and subname is null
 
 
Bind#0 value=96 	
Bind#1 value="ZZ01"
Bind#2 value=1  	
 
 
Bind#0 value=1
Bind#1 value="ZZ01"
Bind#2 value=1
 
 
Bind#0 value=0
Bind#1 value="_NEXT_OBJECT"
Bind#2 value=1

Exemple 2 KO : le type des bind ne correspond pas au type des colonnes du SELECT. Bind 0 et 1 OK mais les bind 2 et 3 sont des dates qui vont soit dans les colonnes namespace et obj# soit dans les colonnes name et namespace...
Au fait, pourquoi les bind commencent à 0 dans la trace et à 1 dans la requête? On est d'accord, ci-desous Bind#0 est associé au champ owner?

Code :

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

1
2
3
4
5
6
7
SQL ID: 8zc85a8249x81 Plan Hash: 2683643009
update obj$ set obj#=:4, type#=:5,ctime=:6,mtime=:7,stime=:8,status=:9, dataobj#=:10,flags=:11,oid$=:12,spare1=:13,spare2=:14,spare3=:15,signature=:16,spare7=:17,spare8=:18,spare9=:19
where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null and linkname is null and subname is null
Bind#0 value=1
Bind#1 value=0
Bind#2 value="5/31/2017 9:6:7"
Bind#3 value="2/5/2018 13:39:1"

Exemple 3 KO : nombre de bind différent différent selon les exécutions : pour quelle raison?

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
SQL ID: 9tgj4g8y4rwy8 Plan Hash: 3755742892
select type#,blocks,extents,minexts,maxexts,extsize,extpct,user#,iniexts,
  NVL(lists,65535),NVL(groups,65535),cachehint,hwmincr, NVL(spare1,0),
  NVL(scanhint,0),NVL(bitmapranges,0)
from seg$ 
where ts#=:1 and file#=:2 and block#=:3
 
 
Bind#0 value=0
Bind#1 value=1024
Bind#2 value=1112 
 
 
Bind#0 value=104
 
 
Bind#0 value=0
Bind#1 value="I_SYN2"
Bind#2 value=4
 
 
Bind#0 value=103 
 
 
Bind#0 value=0
Bind#1 value="I_SYN1"
Bind#2 value=4

[pachot]

Bonjour,

Est-tu sûr de faire correctement le lien entre les bind variables et les curseurs?
Dans la trace brute, le texte SQL est après PARSING IN CURSOR #140511204450784
puis les PARSE BIND EXEC FETCH référencent le curseur avec le même nombre, par exemple BINDS #140511204450784
se trouvera entre PARSE #140511204450784 et EXEC #140511204450784, suivi des datatype et valeurs, mais d'autres curseurs peuvent être exécutés entre temps (requêtes récursives)

Cordialement,
Franck.

[Ikebukuro]

Je te remercie, je regarde ça dès que j'ai un moment de libre chez mon client