Discussion :

[fifi44680]

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

[mnitu]

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.

[devkais]

Bonjour ,
Faites un rapport AWR(ou statpack si vous n'avez pas la license Diagnostic Pack).

[fifi44680]

Merci pour votre réponse.

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".

[mnitu]

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.

[pachot]

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.

[fifi44680]

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

[mnitu]

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

[pachot]

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.