1. #1
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 1
    Points
    1

    Par défaut Problème performance Oracle (ou en amont d'oracle)

    Bonjour,

    Je viens vers vous aujourd'hui car je commence à ne plus avoir d'idée.
    Dans mon entreprise, nous avons une DB sur un serveur (Oracle 12).
    Nous avons des problèmes de performance dans nos batch et nous sommes en train d'investiguer pourquoi.
    Nous avons éliminé tout ceci:
    - Problème performance d'écriture dans fichiers plats
    - Problème performance réseau pour accéder à la base de données (car la base est sur un autre serveur)
    - Problème d'accès disques
    Nous sommes arrivés à ce test qui est très étrange :
    Si j'execute un script PL/SQL qui va lire une table de 2M500k records, cela prends 28secondes. (par un select-fetch)
    Si j'exécute simultanément deux fois ce même script, les deux vont prendre 50secondes.
    ...
    Si j'execute simultanément cinq fois ce même script, les 5 vont prendre deux minutes à s'executer.
    Tout ceci plus ou moins: l'un va prendra 2minutes03, l'autre va prendre 1min59, etc...


    Si nous faisons le test sur un environnement de notre R&D (qui plus est n'est pas une bete de course), avec les même records, cela va prendre 11secondes.
    Peu importe le nombre de lancement simultannée.
    => On constate aussi que 11sec c'est beaucoup mieux que 28sec...

    Il y'a dont un genre de pool (limite mémoire, limite cpu, dispatcher, listener,...?) qui fait que le temps est très long et séquentiellement augmenté, selon la charge sur la DB.
    Nos batch prennent 5fois plus de temps qu'à la R&D et d'après nos investigations, tout le temps est perdu dans des appel DB.

    A noter que les temps de toutes les requêtes de nos batch sont très bons, puisque dans le rapport AWR il n'y a aucun souci.

    Quelqu'un aurait-il une idée d'ou cela peut venir, et quoi checker?

    Merci beaucoup de vos aides,
    Karma.

  2. #2
    Membre éclairé Avatar de 13thFloor
    Homme Profil pro
    DBA Oracle freelance
    Inscrit en
    janvier 2005
    Messages
    624
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France

    Informations professionnelles :
    Activité : DBA Oracle freelance

    Informations forums :
    Inscription : janvier 2005
    Messages : 624
    Points : 880
    Points
    880

    Par défaut

    Hello,
    problème intéressant.
    Dans un premier temps je vérifierai si le plan d'exécution ne varie pas entre 2 exécutions.
    Dans un 2nd temps, je vérifierai quelles sont les attentes pendant l'exécution de la requête
    a/ en single exécution
    b/ en simultané (5 exécutions en //)
    Il serait intéressant de savoir comment les données sont renvoyées : index scan, direct read...
    Que donne le plan d'exécution d'un simple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     select /*+ full(t) nocache(t) */ count(*) from ta_table t;
    N'y aurait-il pas un souci avec le cache file-system (si linux/unix) ?
    Mais au fait, quel est l'os ?

  3. #3
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    Salut,

    Merci de ta réponse.
    Le script exécuté est le suivant:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    SET serveroutput ON;
    declare
       nb NUMBER(8) := 0;
       cursor curs is
          select * from MATABLE
          order by 1, 2, 3;
       begin
          for CUR in curs loop
             nb := nb + 1;
          end loop;
          dbms_output.put_line ('Nombre enreg. dans MATABLE = '||to_char(nb));
       end;
    /
    exit;
    Donc aucun problème d'index,le temps passé ne dépend pas de mon select mais plutôt du curseur.
    Le rapport AWR correspondant est bon (gets ok, IO ok, cpu ok...)

    Tu vérifierais comment ton point 2? (Les attentes)

    Pour le cache-file system, tu vérifierais quoi?
    Je préfère demander tout, pour éventuellement si on oublie quelque chose. Nous ne sommes ni expert linux, ni expert database.

    Pour la version:
    cat /proc/version
    Linux version 2.6.32-573.22.1.el6.x86_64 (mockbuild@x86-029.build.eng.bos.redhat.com) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) ) #1 SMP Thu Mar 17 03:23:39 EDT 2016

    Merci à toi,
    Karma.

  4. #4
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    5 524
    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 524
    Points : 11 285
    Points
    11 285

    Par défaut

    Je suis désolé mais ce script est en concurrence pour les scripts les plus stupides jamais vu! Et il est bien placé pour occuper la première place!

    Justification:
    - la clause order by qui existe juste pour augmenter le temps de traitement.
    - le comptage des enregistrements via une boucle PL/SQL au lieu de compter les enregistrements directement en SQL via Count

    Si cela ne vous saute pas aux yeux quelle chances avez vous pour optimiser votre traitement ?

  5. #5
    Membre éclairé Avatar de 13thFloor
    Homme Profil pro
    DBA Oracle freelance
    Inscrit en
    janvier 2005
    Messages
    624
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France

    Informations professionnelles :
    Activité : DBA Oracle freelance

    Informations forums :
    Inscription : janvier 2005
    Messages : 624
    Points : 880
    Points
    880

    Par défaut

    Remarque 1 : si la finalité est de compter les lignes d'une table, il y a mieux que faire un curseur qui parcours toutes les lignes pour les traiter une par une => select count(*).
    Remarque 2 : l'order by ne sert à rien puisque les lignes sont comptées 1 par 1.
    Pour les attentes :
    tu identifies le sid qui exécute la requête (avec toad ou sqldeveloper) et tu lances :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    SELECT NVL(s.username, '(oracle)') AS username,
           s.sid,
           s.serial#,
           sw.event,
           sw.wait_class,
           sw.wait_time,
           sw.seconds_in_wait,
           sw.state
    FROM   v$session_wait sw,
           v$session s
    WHERE  s.sid = sw.sid
    and STATUS='ACTIVE'
    ORDER BY 2;
    Coté cache file-system : on va mettre de coté sauf si un admin système peut nous donner les bonnes commandes (que je n'ai pas).
    Il s'agissait de vérifier si Oracle utilise le cache FS ou va lire/écriture directement sur disque.
    Mais cela va impliquer trop de questions (asm ou pas...).
    Info toutefois intéressantes sur les hugepages :
    https://oracle-base.com/articles/lin...le-on-linux-64

    Les 2 environnements (prod et R&D) sont-ils les mêmes, notamment au niveau paramétrage oracle ?
    je pense notamment aux paramètres suivants :
    filesystemio_options
    memory_target
    memory_max_target
    pga_aggregate_target
    sga_max_size
    sga_target
    db_file_multiblock_read_count
    db_cache_size

  6. #6
    Membre éclairé Avatar de 13thFloor
    Homme Profil pro
    DBA Oracle freelance
    Inscrit en
    janvier 2005
    Messages
    624
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France

    Informations professionnelles :
    Activité : DBA Oracle freelance

    Informations forums :
    Inscription : janvier 2005
    Messages : 624
    Points : 880
    Points
    880

    Par défaut

    Citation Envoyé par mnitu Voir le message
    Je suis désolé mais ce script est en concurrence pour les scripts les plus stupides jamais vu! Et il est bien placé pour occuper la première place!
    C'est vrai que celui qui l'a écrit :

  7. #7
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    @13thfloor

    Merci je vais regarder ca.

    Pour info le script est juste la pour le test, il n'est en aucun cas dans un traitement.
    C'est juste pour comparaison des temps de réponse en le lançant plusieurs fois simultannéement.

    Bien à vous,
    Karma.

  8. #8
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    Donc:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    filesystemio_options                     DB problème: asynchrone            DB R&D: none
    memory_max_target                    DB problème: big integer 0           DB R&D: big integer 1536M                                                                                                
    memory_target                           DB problème: big integer 0           DB R&D: big integer 1536M  
    pga_aggregate_target                   DB problème: big integer 625M     DB R&D: big integer 0
    sga_max_size                             DB problème: big integer 1888M     DB R&D: big integer 1536M                                                                                                
    sga_target                                  DB problème: big integer 1888M     DB R&D: big integer 0    
    db_file_multiblock_read_count       DB problème: integer 38     DB R&D: integer 128
    db_cache_size                            big integer 0 pour les deux
    Quelque chose te saute aux yeux?

    Bien à toi,
    Karma.

  9. #9
    Expert confirmé
    Profil pro
    Inscrit en
    août 2008
    Messages
    2 525
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2008
    Messages : 2 525
    Points : 4 870
    Points
    4 870

    Par défaut

    Concernant la différence du temps d'exécution entre PROD et R&D, une piste pourrait être la taille (physique en nombre de blocs) de la table en prod qui serait nettement supérieure à celle de la table en R&D qui a probablement été rechargée à partir d'un dump de la prod pour les besoins du test.
    La taille physique de la table en prod dépend de sa vie et des process mis en oeuvre pour son alimentation, comme :
    DELETE de beaucoup de lignes puis chargement en insert /*+append*/ par exemple (correspond à ce qui peut être fait en batch par exemple), ou simplement un gros DELETE récemment effectué.

    Vous pouvez par exemple lire ce post sur le High Water Mark

    Par contre je ne vois pas bien l'origine de l'augmentation du temps de traitement avec l'exécution en // des scripts.

    Par ailleurs, un for loop en PL/SQL a un arraysize automatique de 100, mais pour décharger 2.5M de ligne c'est pas beaucoup.
    Une modification du code pour utiliser LIMIT et dimensionner manuellement et correctement cet arraysize peut éventuellement être intéressant.
    Row Prefetching (ARRAYSIZE)
    Array Size within PLSQL

  10. #10
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    @skuatamad

    Le temps d'execution est entre un environnement de TST (recréée après un truncate) donc la taille réélle de la table est sensiblement la même que celle de la R&D.
    De plus le problème ne dépend pas de la table, car c'est pareil sur toutes les tables de la DB, on a juste choisi celle-ci pour le test.

    Merci de votre intérêt au problème

  11. #11
    Membre éclairé Avatar de 13thFloor
    Homme Profil pro
    DBA Oracle freelance
    Inscrit en
    janvier 2005
    Messages
    624
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France

    Informations professionnelles :
    Activité : DBA Oracle freelance

    Informations forums :
    Inscription : janvier 2005
    Messages : 624
    Points : 880
    Points
    880

    Par défaut

    Mettre filesystemio_options à NONE et ne pas renseigner db_file_multiblock_read_count.
    Ca devrait améliorer le full table scan.
    La piste de skuatamad est pertinente : compares la taille de la table des 2 cotés.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    select sum(bytes)/1024/1024 "Mo",blocks from dba_segments where segment_name='TA_TABLE';

  12. #12
    Expert confirmé
    Profil pro
    Inscrit en
    août 2008
    Messages
    2 525
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2008
    Messages : 2 525
    Points : 4 870
    Points
    4 870

    Par défaut

    pga_aggregate_target semble bien petit sur la prod, à moins que vous n'ayez que très peu de ram sur le serveur.

    Un peu de lecture sur certains paramétrages
    Tuning the Program Global Area

  13. #13
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    pga_aggregate_limit big integer 3000M
    Pour ca ca devrait être ok non? Car Peu importe la target, le max sera toujours 3go, pourquoi tu dis que c'est faible comme valeur?

    EDIT:
    Pour la taille de la table: 606mo pour DB problème et 496mo pour DB R&D.

  14. #14
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    5 524
    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 524
    Points : 11 285
    Points
    11 285

    Par défaut

    Arrêtez de fouiller comme les aveugles à gauche ou a droit! Vous dit: "si je fais ça alors mon temps de traitement se dégrade"! Maintenant faite la même chose mais en activant la trace sql étendue ou tout autre forme de trace similaire et analysez le résultat. Comme ça vous saurez ce qui se passe et ensuite vous allez pouvoir intervenir d'une manière éduqué!

  15. #15
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    Si c'était aussi simple...

    - Nous avons analysé les rapports AWR => Rien d'alarmant, le problème semble en amont.
    - Nous avons placé des traces coté client sur sqlnet => On voit juste que le server met plusieurs minutes à nous répondre à certains endroits.

    Nous sommes chez le client, nous n'avons pas accès au coté server. Les DBA nous disent que tout est ok.
    Au niveau d'unix on nous dit que tout est ok aussi.

    Par contre ce que je vois sur leur moniteur c'est que le serveur de la DB (AIX) est toujours full, et on me dit que c'est normal car AIX utilise toujours toute la mémoire, et la vider ne servira a rien car elle sera reconstruire tout de suite. De plus ils nous disent que même si on y arrivait, cela ne changerait rien non plus car Oracle a une mémoire prédéfinie. Quelqu'un peut confirmer?

    Pensez-vous qu'une augmentation de pga_aggregate_target peut changer drastiquement les perfs?
    Quand je lance mon process je vois juste ces deux valeurs qui augmentent (jusque 3Go max je suppose si j'en lance 40):
    total PGA inuse 376086528
    total PGA allocated 454551552

    Je ne sais plus quoi monitorer et checker... Quelqu'un sait encore comment m'aider?

    Bien à vous,
    Karma.

  16. #16
    Modérateur

    Homme Profil pro
    Ingénieur d'études en décisionnel
    Inscrit en
    septembre 2008
    Messages
    7 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études en décisionnel
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2008
    Messages : 7 413
    Points : 15 671
    Points
    15 671

    Par défaut

    Votre DB est vraiment paramétrée pour une toute petite base : 3 Go de RAM, même les smartphones chinois ont plus de RAM.

    Vous dites que les index ne rentrent pas en jeu, c'est faux puisque vous faites un tri. Si vous avez un index qui suit ce tri d'un côté et pas de l'autre vous allez avoir deux plans différents.
    Pouvez-vous vérifier que sur chaque machine vous n'avez pas d'index utilisé ?

    S'il n'y a pas d'index en jeu et que les bases font bien des full table scans, votre multiblockread étant beaucoup plus bas sur la PROD que sur la R&D ça va influer sur les temps de lecture.
    Il faut aussi comparer les db_block_size de vos deux bases.

    Mais sinon suivez les conseils de mnitu : faites une trace étendue des deux traitements (rapprochez-vous des DBA-s).

  17. #17
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    Les db_block_size sont les mêmes: integer 8192.

    J'ai presque envie de dire que les 11sec de la R&D et les 28sec de la PROD, on ne s'en occupe pas pour l'instant car effectivement ca peut être dû à la taille DB, aux nombre de données remplies dans la table etc...
    On se focus pour l'instant sur le problème concernant le temps qui est proportionnellement augmenté en fonction du nombre de lancement en simultanée. (qui prouve que la charge sur la DB, la ralentie fortement)
    Nous avons l'impression que cela est dû à un goulot d'étranglement sur la DB (d’ailleurs ca peut aussi jouer sur les 28sec).
    Il faut noter que toutes les requêtes sur la DB sont lentes comme ceci (peu importe la table, et rien dans le rapport AWR qui montre que les requêtes sont mauvaises).

    Exemple:
    On lance un batch qui prends 8h.
    En temps CPU il a prit 50minutes.
    On s'est donc orienté vers un problème DB ou network (donc sur les entrées sorties du batch).
    On a mis des traces et c'est tous les programmes qui appelle la DB qui prennent tout le temps.
    On a donc regardé le rapport AWR => DB time 40minutes. Pas de lock, pas de I/O trop grand, pas de gets, aucun indice qui montrerait un problème sur l'instance de la DB.


    De plus, on a lancé les requêtes coté server, et pareil le temps d’exécution reste proportionnelle.

    Demain matin un DBA va relancé les scripts de la même façon et checker les log coté server DB, nous verrons bien s'il trouve quelque chose.

    Je ne cherche pas la solution miracle en vous sollicitant, je commence juste à être à court d'idée, et la moindre idée peut être la bienvenue

    Tout ce qu'on peut dire aujourd'hui c'est que le problème est sur le serveur de la DB, entre la DB et ce serveur.
    => linux, param Oracle, mémoire ...

    Merci de vos idées jusque maintenant en tout cas.
    Karma.

  18. #18
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    Oracle ACE Director, DBA OCM 12c, consultant. En Suisse (dbi services)
    Inscrit en
    novembre 2007
    Messages
    1 545
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Suisse

    Informations professionnelles :
    Activité : Oracle ACE Director, DBA OCM 12c, consultant. En Suisse (dbi services)
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 545
    Points : 5 375
    Points
    5 375
    Billets dans le blog
    5

    Par défaut

    Citation Envoyé par Karma57 Voir le message
    Les db_block_size sont les mêmes: integer 8192.
    On a donc regardé le rapport AWR => DB time 40minutes. Pas de lock, pas de I/O trop grand, pas de gets, aucun indice qui montrerait un problème sur l'instance de la DB.
    40 minutes sur les 8 heures? Le temps est passé ailleurs alors.
    Sur ces 40 minutes, que dit le time model?
    Franck Pachot - Consultant et formateur (dbi services) - Oracle ACED - Oracle Certified Master 12c - Oak Table member - twitter: @FranckPachot
    Besoin d'une formation Oracle 12cR2 ?


  19. #19
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 1
    Points
    1

    Par défaut

    Bonjour,

    Le cas de test que je vous ai présenté n'était en fait pas significatif.
    Le fait que cela prenne de plus en plus de temps si on fait de plus de plus de requete était dû à un problème disque ciblé de la DB (TMP lorsqu'on fait des ORDER BY), mais qui n'a rien à voir avec notre problème initial que le temps de traitement d'une nuit prends 24h au lieu de 6h à la R&D.

    Pour ma part je pense avoir ciblé le problème. A la R&D, et lors de toutes les ventes du logiciel, les base de données ont toujours été locales. Alors que ici la DB est sur un autre serveur.
    Le problème c'est que le logicial utilise énormément de OPEN FETCH de curseur pour selectionner les données, ainsi que des INSERT unitaires. Et sur 7M de données, chaque fetch aura une latence faible mais le temps global sera très long.

    Ce que j'ai proposé c'est de travailler en lot (OPEN FETCH sur des lots de 1000 records, pour SELECT et pour INSERT), ce qui diviserait par 1000 le nombre d'accès à la DB.
    D'autres ont proposé de faire des déchargements dans des fichiers plats de certaine table que l'on veut SELECT, et de faire des sqlloader pour charger dans des tables pour les INSERT.

    Qu'en pensez-vous des deux solutions?

    Bien à vous,
    Karma.

  20. #20
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    5 524
    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 524
    Points : 11 285
    Points
    11 285

    Par défaut

    En anglais on dit "row by row is slow by slow" et cela peut importe où se trouve la base. Vous êtes encore en train de deviner.

    Les faits: vous avez un traitement qui prend 8 heures.

    A faire :
    1. commencez par exécuter le traitement avec une trace SQL étendue pour avoir les données opérationnelles.
    2. analysez la trace pour voir où le temps passe
    3. en fonction de ce que vous aller trouver pensez aux divers solutions envisageables

Discussions similaires

  1. Problème performance Oracle 10g + OLAP
    Par superfunky dans le forum Oracle
    Réponses: 2
    Dernier message: 15/10/2009, 17h08
  2. Problème performance oracle : Elapsed Time d'un Fetch énorme!
    Par matd53 dans le forum Administration
    Réponses: 39
    Dernier message: 07/02/2008, 16h23
  3. Réponses: 5
    Dernier message: 16/03/2006, 00h09
  4. Problèmes de liens avec ODBC vars DB Oracle
    Par kmingaso dans le forum ASP
    Réponses: 1
    Dernier message: 05/09/2005, 09h51
  5. Problème avec les paramètres date BDE/ODBC Oracle/XP Pro
    Par Bloon dans le forum Bases de données
    Réponses: 3
    Dernier message: 06/10/2004, 10h09

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