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

SQL Oracle Discussion :

Optimisation de requête


Sujet :

SQL Oracle

  1. #1
    Nouveau membre du Club
    Inscrit en
    Juin 2011
    Messages
    19
    Détails du profil
    Informations forums :
    Inscription : Juin 2011
    Messages : 19
    Points : 27
    Points
    27
    Par défaut Optimisation de requête
    Bonjour,

    Je souhaiterais optimiser cette requête qui me prends du temps en instruction.
    Malheureusement j'ai pas de privilège pour agir sur la base alors je ne peux que essayer de rendre la requete plus performante.


    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
     
    SELECT /* +PARALLEL(P, 8) */ 
        MAX (DECODE(P.NAME,'id_prestation',P.STRING_VALUE,NULL)) NUM_PRESTATION,
        MAX (DECODE(P.NAME,'date_mes',P.DATE_VALUE,NULL)) DATE_SERVICE,
        SUBSTR (MAX (DECODE(P.NAME,'row_id_produit',P.STRING_VALUE,NULL)),3) ID_SIEBEL,
        BR.EFFECTIVE_DATE AS DATE_APPLI_FACTURE,
        BR.CANCELLATION_DATE AS DATE_RESILLIATION,
        BR.EXPIRATION_DATE AS DATE_EXPIRATION,
        P1.PARTY_ID AS CF,
        P2.PARENT_ID  AS CG,
        BR.DESCRIPTION AS PRODUIT,
        BR.OFFERCODE AS OFFRE 
    FROM
        PARAMETER P, BUSINESS_RELATIONSHIP BR, PARTY P1, PARTY P2, BR_PARAMETERS_CHRONOLOGY BPC
    WHERE 
        BR.OID=BPC.OWNER_ID
        AND BPC.OBJECT_OID = P.PARAMETERS_SET_ID 
        AND BR.DEBTOR = P1.PARTY_ID
        AND P1.PARENT_ID=P2.PARTY_ID
    GROUP BY
    BR.EFFECTIVE_DATE, BR.CANCELLATION_DATE, BR.EXPIRATION_DATE, P1.PARTY_ID, P2.PARENT_ID, BR.DESCRIPTION, BR.OFFERCODE
    ;

    Merci d'avance pour votre aide.

  2. #2
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Octobre 2007
    Messages
    5 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2007
    Messages : 5 611
    Points : 11 252
    Points
    11 252
    Par défaut
    Analysez le plan d’exécution réel par rapport à celui estimé. Mais
    1. Si vous n’avez pas l’accès direct ou indirect, à la base pour investiguer
    2. Si vous ne savez pas quelle est la cible de cette optimisation c’est-à-dire dans combien de temps cette requête doit s’exécuter pour être considère optimale
    3. Si vous ne savez pas ce que vous faites par la suite avec les données ramène par la requête
    Alors vous pouvez tranquillement vous occuper avec des autres choses.

  3. #3
    Membre chevronné Avatar de dmganges
    Homme Profil pro
    Retraité. Ne recherche pas un emploi.
    Inscrit en
    Septembre 2011
    Messages
    1 392
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 71
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Retraité. Ne recherche pas un emploi.
    Secteur : Service public

    Informations forums :
    Inscription : Septembre 2011
    Messages : 1 392
    Points : 2 044
    Points
    2 044
    Par défaut
    Bonjour,
    effectivement avec des marges de manœuvre aussi restreintes c'est mal barré.

    Une marge consisterait à invalider à taton certains index, si les tables sont très grosses...
    Dans le temps lorsque les HINT n'existaient pas on invalidait un index en faisant +0 ou en concaténant une chaine vide... sur les colonnes de la clause WHERE (du bon côté )
    Encore faut-il trouver le ou les index qui pénalisent le plus !
    Si tu connais le nombre de lignes de tes tables et les colonnes indexées le à taton devrait être limité
    Bon courage !

  4. #4
    Membre actif
    Profil pro
    Inscrit en
    Septembre 2007
    Messages
    207
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2007
    Messages : 207
    Points : 237
    Points
    237
    Par défaut
    J'ajouterai également (mais sans connaitre le contexte, le materiel) de faire le test en enlevant le hint sur la parallelism
    J'ai déja été confronté à des gros problèmes de performance a cause de la mise en place de parallélisme...

  5. #5
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    SELECT /* +PARALLEL(P, 8) */

    Ceci n'est pas un hint valide. La syntaxe pour faire du parallel query sur P serait:
    Sinon, pour optimiser, il faut déjà voir où ça prend du temps -> plan d'exécution avec dbms_xplan.display_cursor(format=>'ALLSTATS LAST')

    Cordialement,
    Franck.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

Discussions similaires

  1. [Access] Optimisation performance requête - Index
    Par fdraven dans le forum Access
    Réponses: 11
    Dernier message: 12/08/2005, 15h30
  2. Optimisation de requête avec Tkprof
    Par stingrayjo dans le forum Oracle
    Réponses: 3
    Dernier message: 04/07/2005, 10h50
  3. Optimiser une requête SQL d'un moteur de recherche
    Par kibodio dans le forum Langage SQL
    Réponses: 2
    Dernier message: 06/03/2005, 21h55
  4. optimisation des requêtes
    Par yech dans le forum PostgreSQL
    Réponses: 1
    Dernier message: 21/09/2004, 20h03
  5. Optimisation de requête
    Par olivierN dans le forum SQL
    Réponses: 10
    Dernier message: 16/12/2003, 11h09

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