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
    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
    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
    Bonjour ,
    Faites un rapport AWR(ou statpack si vous n'avez pas la license Diagnostic Pack).

  4. #4
    Nouveau Candidat au Club
    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
    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
    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 - dbi services - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  7. #7
    Nouveau Candidat au Club
    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
    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
    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 - dbi services - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

###raw>template_hook.ano_emploi###