Discussion :

[stof]

Hello,

J'ai une requête qui me pose pas mal de soucis de performances depuis un moment.
Au début j'étais en Hibernate et puis à un moment donné les performances se sont dégradées (sans que le code ait changé), j'ai tenté différents "patchs" et au final j'ai été carrément vers une solution d'appel de la requête en SQL natif.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

getConnexion().prepareStatement(sqlRequest).executeQuery();

L'application utilise le diriver odbc com.oracle.jdbc.odbc.11-5.1-JDK5.jar pour parler à la base Oracle11.

• Ce matin, les DBA me disaient que ce qui était long c'était pas l'exécution mais la partie fetch (6s / 277s).
• Cet après-midi, tout est de nouveau rapide sans qu'aucune configuration n'ait changé (6s au total ==> 0s / 6s)

Note : personne d'autre que moi ne travaille sur la base pour expliquer cette différence et dès ce matin on avait tenté un recalcul d'index sans que ça n'influe


Du coup je recontacte les DBA qui me disent que la requête (toujours la même) utilise cet après-midi des plan d'exécution différents que ce matin.
(mais là je comprends pas car ce qui prend le plus de temps c'est le fetch donc si je ne me trompe pas le plan d'exécution influence le temps...d'exécution).

Comment ça se fait que ça switche de plan d'exécution?
Ils me disent qu'on peut forcer l'utilisation d'un plan d'exécution mais qu'ils auiment pas trop car c'est un peu moche comme solution.

[OButterlin]

Que dire sinon "change de DB ou de DBA"
En tout cas, il semble que la cause ne soit pas dans la couche JDBC...
Si déjà on avait une idée de la requête et de la structure de la DB, il serait envisageable de t'aider...

[stof]

Alors la requête ça va pas être possible car elle est évidemment pas simple (et elle utilise aussi des vues, ce qui peut être le plus intéressant à signaler car je suis pas sûr que les vues utilisent correctement les index de tables).

La structure de la DB ==> quelles infos seraient utiles?

PS : ce matin ça marche toujours (alors que depuis plusieurs semaines c'était quasiment en permanence 100 fois trop long)

[dinobogan]

Peut-être un problème de volumétrie des tables utilisées ? Si par exemple les tables sont juste assez remplies pour toutes tenir en RAM, alors la requête sera rapide.
Par contre, si une ou plusieurs tables est trop grosse pour tenir en RAM, alors Oracle va supprimer des données de la RAM. S'il en a besoin, il fera des accès disques.
As-tu contrôlé la taille des tables et de l'espace RAM restant pour Oracle ? Il ne faut pas oublier le stockage temporaire créé par Oracle pour répondre à ta requête, par exemple un produit cartésien entre deux tables.
Si tu es le seul utilisateur et que ton programme ne change pas, il est probable que se sont les données dans Oracle qui changent et influence le temps de réponse, ce qui pourrait expliquer également le changement de plan d'exécution.

[stof]

Pour l'instant on est passé de 4Go à 8Go ==> on n'observe pas d'amélioration.
Par contre je pensais que c'était différent via l'application ou requêteur mais en testant dans les mêmes conditions (flush de la mémoire avant test) c'est pareil.
Le problème est donc bien purement dans la base.

Sinon l'advisor d'Oracle nous indique environ 10 index (dont 6 sur des tables de moins de 500 lignes donc je ne suis pas sûr que ça soit pertinent) et d'autres sur lesquels fonctionnellement j'ai des doutes par rapport à la requête qui pose problème mais bon...(j'ai essayé ==> idem)

MAIS LE GROS SOUCI : 6s pour exécuter la requête et 200s pour sortir les données ==>comment on agit sur ça?

PS : à propos du buffer ==> augmenter le buffer de SQLPlus n'a rien changé non plus

[dinobogan]

Je comprends mal. Des barrettes de RAM ont été ajoutées dans la machine et le temps d'exécution de la requête n'a pas changé ?
Il ne faut pas oublier de modifier la config d'Oracle pour lui dire d'utiliser plus de RAM. Cette modif a été faite aussi ?

Quel est le volume de données lues par le programme Java pour cette requête ?
La base Oracle est en local ou sur une machine distante ?
Si la base est en local, est-ce qu'Oracle est configuré pour passé par le loopback et non la carte réseau ?
Si c'est en réseau, que disent les statistiques des différentes cartes réseaux (volume, nombre de messages...) ?
Les 200 secondes, est-ce réellement en "sortie d'Oracle" ou en fin de traitement du programme Java ? Peut-être est-ce un accès disque très lent effectué par le programme Java ? Le chronométrage calcule le temps global de la requête ou du programme complet ? Et si, dans le programme Java, il n'y a que la lectures des données issues d'Oracle et rien d'autre, que di tle chronométrage ?
Et cette même requête lancée depuis une console Oracle, est-ce aussi long ?