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 :

Probleme de perforance oracle hibernate


Sujet :

Oracle

  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Août 2006
    Messages
    137
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 137
    Par défaut Probleme de perforance oracle hibernate
    Bonjour,

    Je suis en base oracle de qualification en 10.2.02, un traitement qui est lancé par hibernate mettait 1H30.
    Une fois on est passé sur la preproduction en 10.2.02, le même traitement avec les mêmes données que la qualification mets plus de 10heures, sachant que la preproduction est identique à la qualification ( même version d'oracle et le même spfile et le même os hpunix et les mêmes données à traiter entre les deux bases). j'exécute les deux requêtes de ce traitement via sqlplus ou toad sur la base de preproduction elles ne depassent pas 10 Mn ( une tres large différence par rapport hibernate) .

    J'ai eu sur les awr de la preporduction dans la partie du top five events :sql*Net message from client et aussi sql*net message to client .
    Je soupçonne que le probleme provient soit du reseaux ou bien de l'installation et la configuration hibernate pour la preprodcution, y' a t-il un moyen pour confimer cette hypothése , ou bien si vous avez rencontrez ces probleme entre oracle et hibernate ? Avez vous des pistes ou une methodologie à me proposer svp ?

    Merci d'avance de votre aide

  2. #2
    Membre averti
    Inscrit en
    Juillet 2008
    Messages
    35
    Détails du profil
    Informations forums :
    Inscription : Juillet 2008
    Messages : 35
    Par défaut réponse
    As-tu vérifier que les statistiques soient bien à jour?Sur les deux machines?
    Sinon il dois y avoir un lock quelque part, la différence de temps est trop grande.
    Assure toi que l'applicatif est de la même version sur les deux machines.

  3. #3
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Suisse

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

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 822
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    L'approche AWR est bonne. Mais je suis étonné que tu trouve des 'SQL*Net' dans les top 5 events car normalement AWR les considère comme ne faisant pas partie du temps passé en DB.

    Ce que je regarderais en premier, c'est les temps passé en base de donnée par rapport au temps elapsed. Car le problème ne vient peut-être pas de la base, mais du temps passé en JVM ou en aller-retours réseau.

    Avec hibernate en lazy fetching, il y a souvent beaucoup d'aller-retours réseau (et comme tu parles d'évènements 'SQL*Net message to/from client', ce serait peut-être le cas: Même Oracle, même OS, même données, mais est-ce le même réseau ?
    Peux-tu comparer le temps du ping entre le client (ou serveur d'appli) et la base oracle dans les 2 environnements ?

    Sinon le début du rapport AWR peut être intéressant (jusqu'au top 5 event inclus, et incluant les lignes SQL*NET en plus)

    Cordialement,
    Franck.

  4. #4
    Membre confirmé
    Profil pro
    Inscrit en
    Août 2006
    Messages
    137
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 137
    Par défaut
    merci joguess, l
    j'ai bien verifié les stats d'ailleur quand je lance les requetes sous toad ou sqlplus sur les memes bases elles sont rapides à l'ordre de 10 mn au lieu de 10 H ,pas de lock remonté, et je pense c'est la meme version d'applicatif, mais sinon coté hibernate? je ne sais pas ça pourrait venir de la?

  5. #5
    Membre confirmé
    Profil pro
    Inscrit en
    Août 2006
    Messages
    137
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 137
    Par défaut
    Merci pachot pour ces infos precieuses. Je pense qu'on a les mêmes idées, ce que je vais faire c'est de tester le ping entre le client et la base pour les deux environnements. Par contre tu veux dire qoui par le même reseaux?
    Une question stp comment tu sais localiser le db time pour ces requetes, est ce que c'est le elapsedtime sous v$sqlarea et awr? le db time c'est le temps passée uniquement par la requete sans le reseaux ......? si d'autres idées je suis preneurs?

    Merci d'avance

  6. #6
    Membre averti
    Inscrit en
    Juillet 2008
    Messages
    35
    Détails du profil
    Informations forums :
    Inscription : Juillet 2008
    Messages : 35
    Par défaut
    Sous sqlplus tu fixes ceci:
    >set timing = on
    Tu auras ainsi le temps d'exécution de ta requete (dbtime).
    Sinon tu l'as également dans le rapport awr sous l'onglet query elapsed time.

  7. #7
    Membre averti
    Inscrit en
    Juillet 2008
    Messages
    35
    Détails du profil
    Informations forums :
    Inscription : Juillet 2008
    Messages : 35
    Par défaut
    Le temps d'execution de la requete est le elapsed time.
    C'est celui ci qui nous intéresse.
    Si tu as 10h d'elapsed time pour UNE requete, c'est énorme.
    Si tu as 10h pour le dbtime c "normal".

  8. #8
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Suisse

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

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 822
    Billets dans le blog
    1
    Par défaut
    Bonjour,
    le db time dont je parlais, ce n'est pas le temps elapsed, mais effectivement le temps passé en base de donnée (cpu ou wait event non idle) on le trouve dans v$sesstat sous 'DB Time' ou dans les rapports AWR.
    On pourait dire que temps elapsed = application time + network time + db time
    Et par le même réseau, je voulais dire par rapport à la vitesse: du genre si la base de qualif est sur la même machine que le client (ou serveur d'appli) et que la preprod par contre passe par le LAN, alors là ça peut être différent.
    Cordialement,
    Franck.

  9. #9
    Membre confirmé
    Profil pro
    Inscrit en
    Août 2006
    Messages
    137
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 137
    Par défaut
    une étude a été lancée sur le tuning d'hibernate, je vous tiendrai au courant dés que j'aurais des news. Merci de votre aide les amis

Discussions similaires

  1. Probleme de lecture Sous Hibernate
    Par Invité dans le forum Hibernate
    Réponses: 11
    Dernier message: 24/03/2010, 11h16
  2. [VS2005/Oracle] Probleme pour utiliser Oracle
    Par cnguyen dans le forum Oracle
    Réponses: 1
    Dernier message: 03/07/2006, 17h13
  3. [ORACLE10g] Bonjour, probleme nombre operations oracle
    Par sterix92 dans le forum Oracle
    Réponses: 1
    Dernier message: 09/04/2006, 10h09
  4. Probleme d'authentification Oracle 9i r2
    Par tonton93 dans le forum Oracle
    Réponses: 8
    Dernier message: 21/10/2005, 13h34
  5. [JDBC]Probleme avec trigger Oracle
    Par aurel89 dans le forum JDBC
    Réponses: 2
    Dernier message: 02/08/2005, 11h53

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