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

Administration Oracle Discussion :

Encore une comparaison de tkprof


Sujet :

Administration Oracle

Mode arborescent

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé
    Homme Profil pro
    CMA-CGM
    Inscrit en
    Novembre 2005
    Messages
    531
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : CMA-CGM
    Secteur : Transports

    Informations forums :
    Inscription : Novembre 2005
    Messages : 531
    Par défaut Encore une comparaison de tkprof
    Bonjour à tous...

    Je vous joins un document où j'ai effectué deux tkprofs sur 1 select Ordered. Ok

    Ce select tourne sur des caisses différentes...

    Le traitement de la caisseA s'exécute en 2 minutes, celui de la caisseB en 1 heure...

    CaisseA (plus grosse table mpliquée dans le select=> 30 000 000 de ligne)
    CaisseB (plus grosse table mpliquée dans le select=> 50 000 000 de ligne)

    Les chemins d'accès sont identiques car 'SELECT ORDERED' => Ok
    Les stats sont à jour sur les 2 caisses => OK

    Il y a une grosse différence entre le Fetch de la caisseA (1 fetch) et celui de la caisseB (21850 fetchs).
    La caisseB a deux fois plus de mémoire (SGA, SHARED-POOL, JAVA_POOL etc...) que la caisseA => OK

    Pourquoi d'après vous, la différence d'exécution entre les fetch est-elle aussi importante... et qu'est-ce qui pourrait faire qu'une database 1 fois 1/2 plus grosse qu'une autre (30 000 000 contre 50 000 000) puisse générer des temps d'attente aussi décalés (de 2 minutes à 1 heure) étant donné que les chemin d'accès sont identiques...
    Vous pourrez voir aussi que les volumétries triées ne sont pas les mêmes entre les deux caisses... et c'est peut-être pour cela que le temps d'exécution passe de 2 minutes à 1 heure, mais j'ai doublé les zones mémoires de la caisse à 50 000 000 de ligne et cela n'a rien changé !
    Comment pouvez-vous expliquer ça ?
    A part réécrire le select, verriez-vous une autre piste pour optimiser...

    Merci d'avance pour vos réponses...
    Fichiers attachés Fichiers attachés

Discussions similaires

  1. Encore une jointure sous Oracle pour la route
    Par ebaynaud dans le forum Langage SQL
    Réponses: 15
    Dernier message: 04/11/2004, 11h40
  2. Encore une question sur malloc
    Par IG88 dans le forum C
    Réponses: 5
    Dernier message: 23/06/2004, 15h35
  3. une comparaison qui marche pas.
    Par gandf dans le forum C++Builder
    Réponses: 7
    Dernier message: 16/02/2004, 15h59
  4. Encore une requête complexe sur plusieurs tables
    Par DenPro dans le forum Langage SQL
    Réponses: 5
    Dernier message: 09/12/2003, 19h05

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