Discussion :

[SQLpro]

En anglais on dit "row by row is slow by slow" et cela peut importe où se trouve la base. Vous êtes encore en train de deviner.

Plus exactement "RBAR" : Row By Agonizing Row
http://stackoverflow.com/questions/1...amming-for-sql

A +

[Karma57]

Bonjour Mnitu,

Le problème n'est pas que l'on veut pas, c'est que l'on est limité dans ce qu'on peut investiguer (on est chez le client, et ca prends déjà du temps pour avoir un rapport AWR).
On sait que le rapport AWR est bon => Temps db sur le rapport très faible.
On sait que ce sont les appels DB qui sont long (ceci par des traces dans les programmes). Pour la trace DB, on placé des logs coté client, et rien trouvé.
Il ne reste que le réseau entre les deux, et ceci on pourra le mesurer qu'avec un sniffer. (Devrait être prévu, mais de notre coté faut qu'on avance pour améliorer les perfs de toute façon).

Le seul moyen que je connais est de limiter le nombre d'accès DB.

Bàt,
Karma.

[mnitu]

Je ne sais pas si le AWR peut être restreint à une session, c'était le cas avec STATPACK. L'idée est de collecter l'activité de la base juste pour le batch en question pour focaliser l'analyse juste sur ce traitement. La trace SQL étendue est très bonne pour ça. Normalement dans le fichier brut de trace vous devez retrouver des événements d'attente de la part de la base si le problème est au niveau du réseaux. Le pattern devrait être quelque chose de type: appel de la base, réponse rapide puis n événements d'attente de la base de la suite de la demande de la part du client.