Discussion :

[rbarbot]

Bonjour à tous,

contexte :

Depuis maintenant 2 ans (!!), nous souhaitons migrer notre base de production actuellement en 9i vers une base en 11g.
Le problème est que nous rencontrons des baisses de performances en ÉCRITURE en 11G par rapport à la version 9i.
Pour le côté "challenge", je précise que nos 2 anciens DBA, nos prestataires et même ORACLE ont été sollicités et n'ont pas résolus de manière satisfaisante notre problème.
Me concernant je suis analyste développeur et je viens très récemment d'être promu au poste de DBA. J'en suis content, j'ai eu des formations, mais vous comprendrez aisément pourquoi je viens rechercher sur ce forum des avis de DBA expérimentés qui pourront m'aider !


Notre environnement technique :

Base Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

installée sur la machine suivante :
RHEL 6.4 (Santiago)
2 x CPU Intel Xeon 2,4Ghz Quadcore
36 Go
il s'agit d'un serveur PHYSIQUE.



Détail des problèmes :

Problème n° 1 :

Nous avons un programme d'une société externe, extrêmement mal développé, qui fait des insertions de masse avec des COMMIT entre chaque instructions INSERT.
les temps en 11g sont multipliés par 3 voir 4 par rapport à la 9i !
Nous n'avons pas la main sur le code de ce logiciel et l'éditeur refuse d'y toucher.

En 2 ans, nous avons vu plusieurs DBA et sollicité le support ORACLE (CR toujours en cours...).
Verdict : trop d’événement "log file sync"

Les réponses reçues par nos différents interlocuteurs ont systématiquement consisté à proposer le changement de paramètres ORACLE (niveau SYSTEM ou SESSION) pour améliorer les résultats :
- Soit mettre COMMIT_LOGGING à BATCH afin de s'affranchir du trop grand nombre de commit réalisé par le programme au niveau de la base de données.
OU
- Soit mettre COMMIT_WAIT à NOWAIT afin de ne pas attendre l'information de retour de l'écriture du COMMIT dans le logfile current (traitement asynchrone).

Remarque: par défaut ces paramètres sont "vides" mais j'ai lu sur INTERNET qu'ORACLE met en interne COMMIT_LOGGING à IMMEDIATE et COMMIT_WAIT à WAIT.

Dans les 2 cas, nous avons effectivement constaté des améliorations (surtout la 2ème proposition).

Ce qui nous interpelle, nous pose problème et nous bloque dans notre migration c'est qu'en passant dans une version supérieure de base de données on soit obligé de "jouer" avec certains paramètres, ce qui ressemble plus à une solution de contournement qu'à une vraie solution...

Le pire et le plus grave est qu'aucun de ces partenaires n'acceptent en plus de nous certifier officiellement que leur solution est la bonne (même pas ORACLE) !
Cela n'étant ni encourageant ni rassurant, nous hésitons donc à migrer...

Qu'en pensez vous ?
Trouvez vous normale (dans le sens "acceptable") les propositions faites par ORACLE et nos prestataires ?
Avez vous rencontré une situation comparable ? Si oui qu'avez vous fait ?
Quel paramétrage avez-vous mis sur vos bases ?
que feriez-vous à ma place ?

Sinon, le problème est très simple à reproduire. Il suffit de créer une table et de faire 200.000 INSERT avec 1 COMMIT systématique. Exemple :
INSERT INTO ESSAI VALUES (1,'bbbb','cccc','dddd');
COMMIT;
INSERT INTO ESSAI VALUES (2,'bbbb','cccc','dddd');
COMMIT;
INSERT INTO ESSAI VALUES (3,'bbbb','cccc','dddd');
ECT.....


Ci dessous le rapport ASH lié à ce problème :
rapportASH.html



Problème n° 2 :

Nous obtenons des temps très décevants en 11g sur un traitement de test effectuant 200.000 INSERTS dans une table avec un COMMIT à la fin en comparaison du même traitement exécuté sur un petit serveur hébergeant une petite base 9i...

voici les résultats :
Future base ORACLE 11g de production : 2 mins 26 secs
Petite base de test en 9i : 1 mins 57 secs ( !?)

je précise que :

• pour ce test comparatif, sur la base 11g les paramètres COMMIT_LOGGING et COMMIT_WAIT ont étés remis avec leur valeur par défaut.
• un DBA a récemment effectué un AUDIT de notre base 11g et nous a confirmé qu'elle était bien paramétrée.
• voici les caractéristique du petit serveur de la base 9i :
  RHEL 4 (Nahant Update 7)
  2 x CPU Intel Xeon 2,4Ghz Quadcore
  16 Go
  il s'agit d'un serveur PHYSIQUE.

Là, pour le coup, moi DBA débutant, j'ai vraiment besoin de l'aide de DBA séniors pour comprendre comment est-ce possible qu'un même traitement lancé sur une base 11g installé sur un serveur puissant soit moins rapide qu'une base d'une génération antérieure installé sur un serveur de tests moins puissant ?
Avez vous déjà constaté ce phénomène ?
Auriez-vous une explication ?

Si je relance le même traitement sur la base 11G avec le paramètre COMMIT_WAIT =NOWAIT les temps sont de 2 mins et 20 secs (aucune amélioration).
Ce qui semble indiqué que le fait d'utiliser ce paramètre comme préconisé par nos différents prestataire ne servira que pour notre premier problème...


Sinon pour finir, voici les paramètres ORACLE de notre base 11G :
PARAMS_11G.xls


Voilà...
Déjà merci d'avoir pris le temps de me lire...
Maintenant j’espère vraiment tomber sur des experts qui pourront m'aider à faire progresser la situation. J'ai pas envi de rester en 9i toute ma vie !!!

@+


Richard

[McM]

Bonjour,

Je ne suis pas un expert dans le domaine de tuning de base, donc je peux dire des grosses bêtises
Moi je ferais des vérifs du hardware, le log file sync event est basé sur le LGWR.
Est-ce que les redologs sont sur un "disque" qui encaisse bien les writes (genre séparé des datafiles ou des archive logs)
Combien de groupes ? Quelle taille ? Peut être jouer là-dessus.

J'avais lu, il y a un moment sur le net, des posts sur le disk_asynch_io qui pouvait entraîner des ralentissements mais impossible de remettre la main dessus.
Voici un lien sur le async_IO http://orababy.blogspot.fr/2013/09/i...iooptions.html

[rbarbot]

Bonjour,

Je ne suis pas un expert dans le domaine de tuning de base, donc je peux dire des grosses bêtises
Moi je ferais des vérifs du hardware, le log file sync event est basé sur le LGWR.
Est-ce que les redologs sont sur un "disque" qui encaisse bien les writes (genre séparé des datafiles ou des archive logs)
Combien de groupes ? Quelle taille ? Peut être jouer là-dessus.

J'avais lu, il y a un moment sur le net, des posts sur le disk_asynch_io qui pouvait entraîner des ralentissements mais impossible de remettre la main dessus.
Voici un lien sur le async_IO http://orababy.blogspot.fr/2013/09/i...iooptions.html

Merci pour la réponse,

Notre base de données Oracle 11g a été crée selon l'architecture OFA (Optimal Flexible Architecture).

D'après mes administrateurs systèmes & réseaux, avec notre architecture SAN on ne sait jamais sur quel disque physique de la baie on se trouve.
On crée des volumes virtuels, puis on leur affecte un profil « CRITICAL » (disques rapides) ou « ARCHIVE » (disques normaux) puis le système gère la répartition.
Ces volumes sont ensuite présentés aux serveurs Oracle.

• Les fichiers redologs, les fichiers datafiles et les fichiers d'archive logs sont sur des volumes virtuels différents.
• Les fichiers Redologs et les fichiers controls files sont multiplexés.
• Les fichiers RedoLog font chacun 600 MO.
• Les fichiers RedoLog sont organisés en 3 groupes de 2 fichiers.

On a déjà joué sur ces paramètres selon les préconisations d'un DBA sans résultats probants.
Dans le même registre nous avons aussi jouer sur d'autres paramétrage de la base comme la taille de la SHARED POOL (maintenant à 1200 MO) et la taille du REDO LOG BUFFER (maintenant à 2 MO).


Sinon merci pour le lien que je suis en train de lire




Richard

[mnitu]

Verdict : trop d’événement "log file sync"

Log file Sync

[mnitu]

Pb1 & 2
Bref je comprends bien que sur la nouvelle base le traitement incriminé prends plus de temps mais la question est: avez-vous ou pas la fenêtre de temps nécessaire à l'exécution du traitement ? Plus clairement sur le Pb 2: bon ça prends 2'26'' au lieu de 1'57'' en quoi cela vous empêche de migrer ?Vous n'avez pas 3 minute disponible pour ce traitement ? Est-ce vraiment important qu'il passe en moins de deux minutes ?

Si vous voulez comprendre pourquoi le même traitement sur la base 11g prends plus de temps que sur la 9 exécutez le même traitement sur les deux bases avec une trace SQL étendue et comparer les résultats; surtout les évènements de d'attente.

[rbarbot]

Pb1 & 2
Bref je comprends bien que sur la nouvelle base le traitement incriminé prends plus de temps mais la question est: avez-vous ou pas la fenêtre de temps nécessaire à l'exécution du traitement ? Plus clairement sur le Pb 2: bon ça prends 2'26'' au lieu de 1'57'' en quoi cela vous empêche de migrer ?Vous n'avez pas 3 minute disponible pour ce traitement ? Est-ce vraiment important qu'il passe en moins de deux minutes ?

Si vous voulez comprendre pourquoi le même traitement sur la base 11g prends plus de temps que sur la 9 exécutez le même traitement sur les deux bases avec une trace SQL étendue et comparer les résultats; surtout les évènements de d'attente.

Merci pour la réponse,

Je n'ai sans doute pas été assez clair : Mon questionnement ne se situe pas sur une hypothétique fenêtre de tir mais plutôt sur le fait qu'avec un traitement identique (200.000 INSERT + COMMIT final) on ait des temps moins bon sur une base 11G avec une grosse config en comparaison à une base 9I sur une moyenne config.
Je m'attendais à des temps largement meilleurs sur la première configuration enn 11G.
Cela ne vous choque pas ? pourquoi ?

Pour ce problème n°2, j'ai sorti, comme vous me l'avez recommandé, des traces du traitement sur les 2 bases.
les fichiers étant énormes j'ai n'ai mis ici qu'un extrait avec les 3 derniers INSERT et le COMMIT final.

Voici les traces pour la base 9i :
=====================

PARSING IN CURSOR #1 len=65 dep=0 uid=0 oct=2 lid=0 tim=1408105270823047 hv=3005206835 ad='6e268c50'
INSERT INTO ADMIN_PROG.ESSAI VALUES (199998,'bbbb','cccc','dddd')
END OF STMT
PARSE #1:c=0,e=222,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=1408105270823043
BINDS #1:
EXEC #1:c=0,e=53,p=0,cr=1,cu=3,mis=0,r=1,dep=0,og=4,tim=1408105270823150
WAIT #1: nam='SQL*Net message to client' ela= 2 p1=1650815232 p2=1 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 169 p1=1650815232 p2=1 p3=0
=====================
PARSING IN CURSOR #1 len=65 dep=0 uid=0 oct=2 lid=0 tim=1408105270823594 hv=2060661179 ad='6decd72c'
INSERT INTO ADMIN_PROG.ESSAI VALUES (199999,'bbbb','cccc','dddd')
END OF STMT
PARSE #1:c=0,e=179,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=1408105270823591
BINDS #1:
EXEC #1:c=0,e=52,p=0,cr=1,cu=3,mis=0,r=1,dep=0,og=4,tim=1408105270823696
WAIT #1: nam='SQL*Net message to client' ela= 2 p1=1650815232 p2=1 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 171 p1=1650815232 p2=1 p3=0
=====================
PARSING IN CURSOR #1 len=65 dep=0 uid=0 oct=2 lid=0 tim=1408105270824143 hv=2355644526 ad='6c25e1bc'
INSERT INTO ADMIN_PROG.ESSAI VALUES (200000,'bbbb','cccc','dddd')
END OF STMT
PARSE #1:c=0,e=176,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=1408105270824139
BINDS #1:
EXEC #1:c=0,e=52,p=0,cr=1,cu=3,mis=0,r=1,dep=0,og=4,tim=1408105270824246
WAIT #1: nam='SQL*Net message to client' ela= 2 p1=1650815232 p2=1 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 164 p1=1650815232 p2=1 p3=0
=====================
PARSING IN CURSOR #1 len=6 dep=0 uid=0 oct=44 lid=0 tim=1408105270824589 hv=1053795750 ad='6c83b4f4'
COMMIT
END OF STMT

Voici les traces pour la base 11G :

PARSING IN CURSOR #139933426070488 len=65 dep=0 uid=0 oct=2 lid=0 tim=1441897691598963 hv=2139161323 ad='10dd668e0' sqlid='51csz9xzs20rb'
INSERT INTO ADMIN_PROG.ESSAI VALUES (199998,'bbbb','cccc','dddd')
END OF STMT
PARSE #139933426070488:c=1000,e=356,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1441897691598963
EXEC #139933426070488:c=0,e=36,p=0,cr=1,cu=3,mis=0,r=1,dep=0,og=1,plh=0,tim=1441897691599049
STAT #139933426070488 id=1 cnt=0 pid=0 pos=1 obj=0 op='LOAD TABLE CONVENTIONAL (cr=1 pr=0 pw=0 time=25 us)'
WAIT #139933426070488: nam='SQL*Net message to client' ela= 1 driver id=1650815232 #bytes=1 p3=0 obj#=1169802 tim=1441897691599096
WAIT #139933426070488: nam='SQL*Net message from client' ela= 91 driver id=1650815232 #bytes=1 p3=0 obj#=1169802 tim=1441897691599200
CLOSE #139933426070488:c=0,e=4,dep=0,type=0,tim=1441897691599227
=====================
PARSING IN CURSOR #139933426070488 len=65 dep=0 uid=0 oct=2 lid=0 tim=1441897691599572 hv=2911855317 ad='13c342dc8' sqlid='8dv2pnkqsysqp'
INSERT INTO ADMIN_PROG.ESSAI VALUES (199999,'bbbb','cccc','dddd')
END OF STMT
PARSE #139933426070488:c=0,e=321,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1441897691599571
EXEC #139933426070488:c=0,e=36,p=0,cr=1,cu=3,mis=0,r=1,dep=0,og=1,plh=0,tim=1441897691599649
STAT #139933426070488 id=1 cnt=0 pid=0 pos=1 obj=0 op='LOAD TABLE CONVENTIONAL (cr=1 pr=0 pw=0 time=25 us)'
WAIT #139933426070488: nam='SQL*Net message to client' ela= 1 driver id=1650815232 #bytes=1 p3=0 obj#=1169802 tim=1441897691599691
WAIT #139933426070488: nam='SQL*Net message from client' ela= 88 driver id=1650815232 #bytes=1 p3=0 obj#=1169802 tim=1441897691599793
CLOSE #139933426070488:c=0,e=9,dep=0,type=0,tim=1441897691599830
=====================
PARSING IN CURSOR #139933426070488 len=65 dep=0 uid=0 oct=2 lid=0 tim=1441897691600160 hv=175612780 ad='113ba8ea0' sqlid='84v2wws57g8vc'
INSERT INTO ADMIN_PROG.ESSAI VALUES (200000,'bbbb','cccc','dddd')
END OF STMT
PARSE #139933426070488:c=0,e=305,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1441897691600159
EXEC #139933426070488:c=0,e=34,p=0,cr=1,cu=3,mis=0,r=1,dep=0,og=1,plh=0,tim=1441897691600238
STAT #139933426070488 id=1 cnt=0 pid=0 pos=1 obj=0 op='LOAD TABLE CONVENTIONAL (cr=1 pr=0 pw=0 time=25 us)'
WAIT #139933426070488: nam='SQL*Net message to client' ela= 0 driver id=1650815232 #bytes=1 p3=0 obj#=1169802 tim=1441897691600281
WAIT #139933426070488: nam='SQL*Net message from client' ela= 89 driver id=1650815232 #bytes=1 p3=0 obj#=1169802 tim=1441897691600384
CLOSE #139933426070488:c=0,e=4,dep=0,type=0,tim=1441897691600413
=====================
PARSING IN CURSOR #139933426070488 len=6 dep=0 uid=0 oct=44 lid=0 tim=1441897691600448 hv=255718823 ad='0' sqlid='8ggw94h7mvxd7'
COMMIT
END OF STMT

Ces informations vous semblent t'elles pertinentes et suffisantes pour faire un constat ? quelque chose vous interpelle t'il ?

Log file Sync

Merci pour cette documentation très intéressante.
On retrouve bien les conseils "évidents" : faire moins de COMMIT
on retrouve même l'utilisation de paramètre ORACLE.


Mais maintenant, ce que je souhaiterais connaître, c'est l'avis d'experts ORACLE à mon problème !
Sur mon 1er message j'ai mis un lien vers un fichier EXCEL présentant tous les paramètres ORACLE de notre base 11G ? l'avez vous vu ? y'a t'il quelque chose de choquant selon vous ?

J'insiste encore , mais pour moi, ce qui paraît incompréhensible c'est toujours le fait de devoir d'emblée partir dans des opérations de TUNING alors que mon traitement avec "INSERT + COMMIT final" est quand même le "minimum de base" que l'on puisse demander à une base de données ORACLE !

S'il vous plait, j'aimerais bien avoir des avis d'experts argumentés par rapport à ma situation et surtout par rapport à vos retours d'expérience constaté sur le terrain : LOL, En effet ce n'est pas possible que je sois le seul sur TERRE à rencontrer ce problème !
que feriez vous de plus à ma place ? je suis à cours d'idée...


MERCI,
Richard

[mnitu]

Ces informations vous semblent t'elles pertinentes et suffisantes pour faire un constat ? quelque chose vous interpelle t'il ?

Il faut analyser ça tranquillement mais juste comme ça

1. Le temps écoulés lors du parsing sont plus grandes en 11g, pourquoi ?
2. Il y a un appel à la base de plus en 11g (CLOSE), pourquoi ?

L'optimiseur est paramétré différemment: CHOSE vs ALL_ROWS mais cela n'a pas d'importance dans ce cas.

Vous pouvez utiliser un profilez (visiter le site de Christian Antognini) pour mieux analyser le traitement.

Je ne pense pas que le paramétrage de la base peut influencer ce type de traitement. Le lien que je vous ai fournie montre bien les deux directions des actions.

Je comprends bien que ce problème vous interpelé et qu'il faut l'analyser pour comprendre ce qui se passe mais je n'ai pas l'impression que vous avez vraiment un problème d'optimisation actuellement.

Je ne comprends pas également la position de l'éditeur surtout que ce type de traitement s'optimise bien à son niveau. En fait plusieurs piste peuvent être envisagées au niveau du traitement pour l'optimiser.

Pour des articles concernant l'interprétation des fichiers de trace brute ainsi qu'optimisation en général visiter le site de Carry Milsap, Method-R.

[Waldar]

De votre premier message, la chose la plus choquante me paraît être celle-ci :

Nous avons un programme d'une société externe, extrêmement mal développé, qui fait des insertions de masse avec des COMMIT entre chaque instructions INSERT.
les temps en 11g sont multipliés par 3 voir 4 par rapport à la 9i !
Nous n'avons pas la main sur le code de ce logiciel et l'éditeur refuse d'y toucher.

Quelle est l'architecture disque de votre Oracle 9i ?

En 11g vous avez un SAN, et j'attire votre attention sur cet élément d'architecture.
Les SANs, s'ils facilitent l'administration et l'allocation de disque pour les administrateurs réseau, ce ne sont pas la panacée en terme de performance pour les BDD.
Quel est le lien réseau entre votre SAN et votre BDD ?

Évidemment si votre 9i utilise le même SAN avec la même configuration, ce n'est pas la source du problème.

Regardez ce lien qui propose une méthode simple sur 11g pour mesure vos IO/s et Mo/s :
https://oracle-base.com/articles/mis...oracle-systems

[rbarbot]

De votre premier message, la chose la plus choquante me paraît être celle-ci :


Quelle est l'architecture disque de votre Oracle 9i ?

En 11g vous avez un SAN, et j'attire votre attention sur cet élément d'architecture.
Les SANs, s'ils facilitent l'administration et l'allocation de disque pour les administrateurs réseau, ce ne sont pas la panacée en terme de performance pour les BDD.
Quel est le lien réseau entre votre SAN et votre BDD ?

Évidemment si votre 9i utilise le même SAN avec la même configuration, ce n'est pas la source du problème.

Regardez ce lien qui propose une méthode simple sur 11g pour mesure vos IO/s et Mo/s :
https://oracle-base.com/articles/mis...oracle-systems

Merci pour votre réponse et désolé pour le retard,

Je ne l'ai pas précisé sur mon premier post mais notre base 9i de production et notre future base 11g de production sur laquelle je fais des tests sont bien sur le même SAN avec la même configuration !
je vais lire attentativement votre lien.

Sinon Vous avez raison d'être choqué mais ce programme est une cata en terme de développement !
par contre moi ce qui me choque le plus serait plutôt notre 2ème problème...

[rbarbot]

Il faut analyser ça tranquillement mais juste comme ça

1. Le temps écoulés lors du parsing sont plus grandes en 11g, pourquoi ?
2. Il y a un appel à la base de plus en 11g (CLOSE), pourquoi ?

L'optimiseur est paramétré différemment: CHOSE vs ALL_ROWS mais cela n'a pas d'importance dans ce cas.

Vous pouvez utiliser un profilez (visiter le site de Christian Antognini) pour mieux analyser le traitement.

Je ne pense pas que le paramétrage de la base peut influencer ce type de traitement. Le lien que je vous ai fournie montre bien les deux directions des actions.

Je comprends bien que ce problème vous interpelé et qu'il faut l'analyser pour comprendre ce qui se passe mais je n'ai pas l'impression que vous avez vraiment un problème d'optimisation actuellement.

Je ne comprends pas également la position de l'éditeur surtout que ce type de traitement s'optimise bien à son niveau. En fait plusieurs piste peuvent être envisagées au niveau du traitement pour l'optimiser.

Pour des articles concernant l'interprétation des fichiers de trace brute ainsi qu'optimisation en général visiter le site de Carry Milsap, Method-R.

Merci mnitu pour votre réponse,


je vais étudier de très prés les sites que vous évoquer.
je vous tiens au courant au + vite.

une question : êtes vous DBA ?

@+

Richard

[pachot]

Bonjour Richard,


Je vais faire quelques remarques en lisant tout ça avant de dire comment je pendrais le problème.
- la comparaison 9i/11g se fait sur un autre serveur, je suppose. On peut penser qu'un nouveau serveur est plus puissant, mais ce n'est pas tout à fait vrai. Les serveurs on plus de cores qu'avant, mais souvent des frequences plus faibles. Donc ce qui tourne sur un seul process peut être plus long. 1 mins 57 secs qui passent à 2 mins 26 secs, c'est tout à fait possible si la frequence passe de 3,46 Ghz à 2,4Ghz.
- et au niveau système, il faut regarder si cpuspeed est désactivé, ça peut baisser la frequence
- des commits ligne à ligne, c'est un mauvais design. Peut-être que ça passait avant, mais un léger changement peut avoir des consequences énormes. Comme sur une autoroute chargée, le moindre ralentissement fera un bouchon
- COMMIT_LOGGING=BATCH ne sert pas à grand chose tout seul. COMMIT_WAIT=NOWAIT supprime les 'log file sync'. Oui, c'est une solution de contournement au problème de design (commit ligne à ligne). Donc pourquoi pas vu que vous ne pouvez pas changer le design. Attention, COMMIT_WAIT=NOWAIT est très bien pour des commits intermédiaires, mais pas pour tout. Un crash d'instance peut perdre des transaction commitées.


Bon, pour le cas 1 il faut voir, on sait qu'on fait trop de commits et qu'on ne peut rien y faire. Il faut voir le temps que ça met. Un rapport AWR en regardant les sections 'top events' et 'wait event histogram' pour 'log file parallel write' et 'log file sync'. Il l'idéal serait de le comparer avec la 9i (pas d'AWR, c'est Statspack).
Sur des disques modernes, on peut descendre à la milliseconde pour les log file parallel write. Si ce n'est pas suffisant, alors commit nowait peut être étudié.


Pour le problème 2, il faut voir ce qui prend du temps. Idem: rapport AWR.
Bon, c'est probablement du temps de parsing vu les requêtes (pas de bind variables)
Et dans ce cas un workaround pourrait être cursor_sharing=force
Mais ne changez rien sans savoir pourquoi avant!


Cordialement,
Franck.

[devkais]

Bonjour ,
Avez vous réalisé un calibrage IO en 11g puis un calcul des stats système ?
Kais

[SQLpro]

Personnellement je mettrais l'éditeur en cause avec menace de procès et appel en garantie de défaut de vice caché.
En effet ce n'est pas perce que l'on est en informatique, qu'il n'y a pas de règles de l'art qui sont la Loi en la matière.
Pour avoir fait plusieurs fois le "sapiter" pour des expertises judiciaires en bases de données, une fois le défaut bien expliqué et le remède montré et prouvé métriques à l'appui, l'éditeur pourra être contraint d'agir sous peine d’astreinte.

En effet, de ce que vous dites, les performances anormales (et je ne m'étonnerais pas d'un fois 10 à fois 100 si COMMIT plus global) sont seulement dues à un COMMIT appliqué bien trop fréquemment sans aucune justification logique;...

A +