[9i] pb Temps de réponse avec FETCH ... INTO

Version imprimable

Bonjour, j'ai un traitement en PL/SQL qui est très long.
J'ouvre un curseur et je mets dans un variable le curseur. Et fait kk traitement sur cette variables (en selection pas de curseur for update)

Le SQL du curseur en question mets 2 min sous SQL Plus
Code:

1 2 3 4 692 ligne(s) sélectionnée(s). Ecoulé : 00 :00 :02.05
Mais dès que le pl fait la même chose il met 15 minutes :
Code:

1 2 3 4 5 6 7 8 9 10 [i]ptrace('SGA_B_open1');[/i] open c_accesext; [i]ptrace('SGA_B_open2');[/i] loop [i]ptrace('SGA_B_loop');[/i] fetch c_accesext into r_accesext; [i]ptrace('SGA_B_into');[/i] exit when c_accesext%NOTFOUND OR c_accesext%NOTFOUND IS NULL; [i]ptrace('SGA_B_exit');[/i]
ptrace est une procédure de trace dans un fichier.
Résultat de la trace :
06/04/05 14:40:40> SGA_B_open1
06/04/05 14:40:40> SGA_B_open2
06/04/05 14:40:40> SGA_B_loop
06/04/05 14:56:04> SGA_B_into
06/04/05 14:56:04> SGA_B_exit

Soit 15 Min et 24 Sec pour le premier fetch (je sais que celui ci correspond au parsing du curseur mais qd même) :zekill:

ensuite tout vas bien
06/04/05 14:56:06> SGA_B_loop
06/04/05 14:56:06> SGA_B_into

Moins d'une seconde pour le Second fetch.
KK1 a une idée ??

05/04/2006, 15h48
xavi

un petit coup de tkprof pour voir où la requête prend son temps ?
http://oracle.developpez.com/guide/tuning/tkprof/

+ ça te permet de vérifier que l'explain plan dans ton code pl est le même que quand tu lances la requête indépendemment.
05/04/2006, 15h56
sygale
Je sais ou sa peche.

dans le cursor il y a un truc genre :
Code:

1 2 and cod_etat in (c_cod_etat_A, c_cod_etat_B, c_cod_etat_C)
si je change avec
Code:

1 2 and cod_etat in ('A', 'B','C')
Plus de pb de temps kk à une idée.
Qd au TKPROF c'est dead, je n'ai pas le droit de l'installer !! :piou:
La procedure ptrace me permet de connaitre le ligne !!
05/04/2006, 16h04
bpprive

La différence entre le temps d'exécution sous SQL*Plus versus PL/SQL est du à la manière dont le traitement est codé.

Si vous utilisez le bulk fetch à la place d'une boucle pour charger vos données, le temps de réponse en sera grandement amélioré (en fait, les performance devrait être similaires à celles sous SQL*Plus)

Le bulk collect ne vaut que si vous ramener bcp, bcp,bcp de lignes.
Il est tout a fait normal que ORACLE parcours un tableau de 10 000 lignes plus rapidement qu'un curseur de 10 000 lignes.

Mon pb n'est pas en terme de boucle, mais de chargement de la première ligne !! :oops:
La première ligne mets 15 min mais l'acces aux autre lignes est en dessous de la seconde.

Dc le bulk n'est pas intéressant dans mon cas mais merci

Qd aux plan d'exécution voici :

Rq de 2 min :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
Operation	Object Name	Rows	Bytes	Cost	Object Node	In/Out	PStart	PStop
SQLPlus sans variables RAPIDE								
SELECT STATEMENT Optimizer Mode=CHOOSE		1	 	202	 	      	             	 
SORT ORDER BY		1	65	202	 	      	             	 
FILTER		  	 	 	 	      	             	 
TABLE ACCESS BY INDEX ROWID	ETOILE.AC_CONDPART_GLC	1	65	201	 	      	             	 
INDEX RANGE SCAN	ETOILE.I_CONDPART_GLC_COD_PRODUIT	1 K	 	6	 	      	             	 
TABLE ACCESS FULL	SYS.DUAL	82	 	3	 	      	             	 
TABLE ACCESS FULL	SYS.DUAL	82	 	3	 	      	             	 
TABLE ACCESS FULL	SYS.DUAL	82	 	3	 	      	             	 
FILTER		  	 	 	 	      	             	 
NESTED LOOPS		1	53	102	 	      	             	 
TABLE ACCESS BY INDEX ROWID	ETOILE.AC_FACTUR	1	40	100	 	      	             	 
INDEX RANGE SCAN	ETOILE.I_FACTUR_1	123	 	4	 	      	             	 
TABLE ACCESS FULL	SYS.DUAL	82	 	3	 	      	             	 
TABLE ACCESS FULL	SYS.DUAL	82	 	3	 	      	             	 
TABLE ACCESS FULL	SYS.DUAL	82	 	3	 	      	             	 
INDEX RANGE SCAN	ETOILE.PK_LIGNEDETAIL_FCT	1	13	3

Rq de 15 min

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
Operation	Object Name	Rows	Bytes	Cost	Object Node	In/Out	PStart	PStop
Avec constante ! LONG								
SELECT STATEMENT Optimizer Mode=CHOOSE		1	 	170	 	      	             	 
SORT ORDER BY		1	65	68	 	      	             	 
FILTER		  	 	 	 	      	             	 
TABLE ACCESS BY INDEX ROWID	ETOILE.AC_CONDPART_GLC	1	65	68	 	      	             	 
INDEX RANGE SCAN	ETOILE.I_CONDPART_GLC_COD_PRODUIT	439	 	3	 	      	             	 
TABLE ACCESS FULL	SYS.DUAL	82	 	3	 	      	             	 
TABLE ACCESS FULL	SYS.DUAL	82	 	3	 	      	             	 
TABLE ACCESS FULL	SYS.DUAL	82	 	3	 	      	             	 
NESTED LOOPS		1	53	102	 	      	             	 
TABLE ACCESS BY INDEX ROWID	ETOILE.AC_FACTUR	1	40	100	 	      	             	 
INDEX RANGE SCAN	ETOILE.I_FACTUR_1	123	 	4	 	      	             	 
TABLE ACCESS FULL	SYS.DUAL	82	 	3	 	      	             	 
TABLE ACCESS FULL	SYS.DUAL	82	 	3	 	      	             	 
TABLE ACCESS FULL	SYS.DUAL	82	 	3	 	      	             	 
INDEX RANGE SCAN	ETOILE.PK_LIGNEDETAIL_FCT	1	13	3

La seule différence que je trouve est au niveau de ETOILE.I_CONDPART_GLC_COD_PRODUIT mais franchement je conmprends rien ! :D

05/04/2006, 17h51
sygale
Citation:
Envoyé par sygale

dans le cursor il y a un truc genre :

Code:

1 2 and cod_etat in (c_cod_etat_A, c_cod_etat_B, c_cod_etat_C)

si je change avec

Code:

1 2 and cod_etat in ('A', 'B','C')
Bon ca y est, voici la soluce pour la communauté :

Le champs cod_etat intérrogé via des IN est de type VARCHAR2(3), les constantes sont de type CHAR(3).

Du coups oracle, convertit mon champs cod_etat en char(3) afin de faire la comparaison et hop 15 min. :?

J'ai donc passé mes constantes en VARCHAR2, là plus de conversion, donc 2 min de traitement. :lahola:

Bref, ne faites pas comme moi, ne mettez pas toutes les constantes en CHAR si c'est du texte (sous prétexte que l'on connait tjs la longueur, ceux sont des constantes) mais répliquez le même format que la champs conditionné par la constante. 8)