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 :

Problème de performance suite migration Oracle 9i vers Oracle 11g


Sujet :

Administration Oracle

  1. #1
    Nouveau Candidat au Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mai 2014
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : mai 2014
    Messages : 3
    Points : 1
    Points
    1
    Par défaut Problème de performance suite migration Oracle 9i vers Oracle 11g
    Bonjour,

    Notre migration de base de données est actuellement bloquée suite à des problèmes de performances sur un traitement particulier
    Environnement de départ :
    base oracle 9.2.0.8 sur linux RedHat 4 (Nahant Update 7) installé sur serveur physique HP Lame HS21
    Environnement d'arrivée :
    base oracle 11.2.0.3.5 sur linux RedHat 6.4 (Santiago) installé sur un serveur physique HP lame HS22

    Sur une base de test équivalente en volumétrie à notre base de production, les performances sont globalement correct. Par contre, nous avons un traitement externe d'un fournisseur dont les temps de traitement ont quasiment été multiplié par 3. Nous avons pu mettre au point un programme de test simulant le comportement de ce programme externe :
    363000 insert suivi chacun d'un commit

    Quelqu'un a-t-il déjà rencontré des problèmes de performance sur des traitements similaires et/ou sur des environnements semblables à notre environnement cible ?

    Merci d'avance pour votre aide.

    Philippe

  2. #2
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    5 602
    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 602
    Points : 11 538
    Points
    11 538
    Par défaut
    Faite juste un seul commit et non pas 363000. Et insérez en batch.
    Pour analyser ce qui coince activer une trace SQL étendue dans le traitement batch qui pose des problèmes.

  3. #3
    Membre régulier
    Homme Profil pro
    Consultant
    Inscrit en
    mai 2006
    Messages
    145
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : mai 2006
    Messages : 145
    Points : 87
    Points
    87
    Par défaut
    Bonjour ,
    Faites un rapport AWR(ou statpack si vous n'avez pas la license Diagnostic Pack).

  4. #4
    Nouveau Candidat au Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mai 2014
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : mai 2014
    Messages : 3
    Points : 1
    Points
    1
    Par défaut
    Merci pour votre réponse.
    Citation Envoyé par mnitu Voir le message
    Faite juste un seul commit et non pas 363000. Et insérez en batch.
    Pour analyser ce qui coince activer une trace SQL étendue dans le traitement batch qui pose des problèmes.
    Cependant, nous n'avons aucune possibilité d'intervention sur le traitement qui pose problème. Il s'agit d'un processus ve5admin.exe intégré dans un logiciel externe "CAMELEON SOFTWARE" fournis par "Access Commerces".

  5. #5
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    5 602
    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 602
    Points : 11 538
    Points
    11 538
    Par défaut
    Je comprends que vous ne pouvez pas modifier le traitement. C'est OK.
    Faite quand même une trace du traitement pour que vous arrivez à comprendre pourquoi ce traitement est dégradé par rapport à l'ancienne version d'Oracle.

  6. #6
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 730
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 730
    Points : 6 122
    Points
    6 122
    Par défaut
    Bonjour,
    C'est probablement beaucoup de redo -> attentes sur log file sync.
    Il serait intéressant de comparer dans un rapport AWR les durées moyennes des i/o sur les redo (log file parallel write). Les temps d'i/o sont peut-être moins bons sur le nouveau système.
    Cordialement,
    Franck.
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  7. #7
    Nouveau Candidat au Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mai 2014
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : mai 2014
    Messages : 3
    Points : 1
    Points
    1
    Par défaut
    Bonjour,

    Durant les traitements sur l'environnement cible et sur l'environnement source, l'évènement le plus consommateur est "log file sync". Le temps moyen de traitement de 1ms pour l'environnement source et 4ms pour l'environnement cible.

    est-ce normale d'avoir une telle différence ? et surtout est-ce normale que ce soit plus long en 11g qu'en 9i.

    Cordialement,

    Philippe

  8. #8
    Expert éminent sénior Avatar de mnitu
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    octobre 2007
    Messages
    5 602
    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 602
    Points : 11 538
    Points
    11 538
    Par défaut
    Comme on disait il y a trop de commit.
    log file sync
    When a user session commits, the session's redo information must be flushed to the redo logfile. The user session will post the LGWR to write the log buffer to the redo log file. When the LGWR has finished writing, it will post the user session.

    Wait Time: The wait time includes the writing of the log buffer and the post
    A lire aussi Tuning ‘log file sync’ wait events

  9. #9
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 730
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 730
    Points : 6 122
    Points
    6 122
    Par défaut
    C'est plutôt log file paralle write qui est représentatif du temps i/o, car plusieurs sessions peuvent attendre sur log file sync en même temps.
    est-ce normale que ce soit plus long en 11g qu'en 9i
    Rien à voir, c'est l'appel système i/o qui est en cause, pas Oracle (sauf s'il y a du dataguard en plus)
    est-ce normale d'avoir une telle différence
    1ms c'était pas beaucoup. 4ms c'est quand même bon. C'est tous ces commits le problème. Le problème était peut-être masqué par des disques très rapides (SSD ?)

    Si ce traitement peut supporter le fait de perdre des modifications en cas de crash, un workaround pourraît être COMMIT_WAIT et COMMIT_LOGGING. Mais faire des commits moins frequents serait mieux.

    Cordialement,
    Franck.
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

Discussions similaires

  1. [OL-2010] problème pst suite migration adresse Outlook vers Exchange
    Par voldorak dans le forum Outlook
    Réponses: 1
    Dernier message: 29/11/2012, 11h46
  2. Réponses: 12
    Dernier message: 20/08/2012, 11h59
  3. Réponses: 6
    Dernier message: 20/05/2011, 17h29
  4. Réponses: 0
    Dernier message: 05/09/2009, 13h45
  5. Réponses: 3
    Dernier message: 20/06/2007, 19h42

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