IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Oracle Discussion :

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


Sujet :

Oracle

  1. #1
    Membre averti

    Inscrit en
    Septembre 2003
    Messages
    425
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 425
    Points : 398
    Points
    398
    Par défaut [9i] pb Temps de réponse avec FETCH ... INTO
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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)

    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 ??

  2. #2
    Membre régulier
    Profil pro
    Inscrit en
    Août 2005
    Messages
    68
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2005
    Messages : 68
    Points : 78
    Points
    78
    Par défaut
    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.

  3. #3
    Membre averti

    Inscrit en
    Septembre 2003
    Messages
    425
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 425
    Points : 398
    Points
    398
    Par défaut
    Je sais ou sa peche.

    dans le cursor il y a un truc genre :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    and cod_etat in (c_cod_etat_A, c_cod_etat_B, c_cod_etat_C)
    si je change avec
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 !!
    La procedure ptrace me permet de connaitre le ligne !!

  4. #4
    Membre habitué
    Profil pro
    Inscrit en
    Décembre 2005
    Messages
    138
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2005
    Messages : 138
    Points : 166
    Points
    166
    Par défaut
    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)

  5. #5
    Membre averti

    Inscrit en
    Septembre 2003
    Messages
    425
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 425
    Points : 398
    Points
    398
    Par défaut
    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 !!
    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 : 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
     
    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 : 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
     
    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 !

  6. #6
    Membre averti

    Inscrit en
    Septembre 2003
    Messages
    425
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 425
    Points : 398
    Points
    398
    Par défaut
    Citation Envoyé par sygale
    dans le cursor il y a un truc genre :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    and cod_etat in (c_cod_etat_A, c_cod_etat_B, c_cod_etat_C)
    si je change avec
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

    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)

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [8i]Query avec temps de réponse étrange?
    Par Ujitsu dans le forum SQL
    Réponses: 1
    Dernier message: 18/06/2008, 16h52
  2. Optimiser le temps réponse avec sql server
    Par yuri2008 dans le forum Développement
    Réponses: 1
    Dernier message: 30/05/2008, 23h41
  3. Réponses: 27
    Dernier message: 23/05/2008, 02h18
  4. pbl de temps de réponse sur un EXE en réseau avec BDE
    Par gregcat dans le forum Bases de données
    Réponses: 1
    Dernier message: 06/07/2006, 09h52
  5. Hebergeur mutilialisé avec mysql et temps de réponse
    Par dreck dans le forum Requêtes
    Réponses: 7
    Dernier message: 06/02/2006, 08h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo