Discussion :

[fredodeveloppeur]

Bonjour à tous,

La situation est la suivante, nous avons déplacé les index d'un tablespace sur un autre (à cause d'un problème de stockage).

Depuis, nous rencontrons des lenteurs sur les requetes sql lancées de "sqldeveloppeur" ou d'une connexion "ado.net".

Cela peut-il être lié ?

Merci pour votre aide.
Fred.

[Waldar]

Peut-être, si le tablespace original était sur une grappe RAID 0 de SSD et que le nouveau est sur un HD magnétique tout seul.

Sinon, il faut prendre des mesures. Isoler une requête où l'impact est important, regarder le plan d'exécution réel et tracer la requête.
Si vous pouvez effectuer ces mesures avec l'index sur ces deux tablespaces c'est bien entendu l'idéal.

[fredodeveloppeur]

Bonjour et merci pour cette première réponse.

Nous ne pouvons plus utiliser l'ancien tablespace car corrompu à cause du matériel.

Nous avons donc regardé le plan d’exécution entre la machine de prod ou le problème existe et une machine de test.

TEST :
----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 7259 | 4373K| 5356 (1)| 00:01:05 |
|* 1 | TABLE ACCESS FULL| XXXXXXXXXXXX | 7259 | 4373K| 5356 (1)| 00:01:05 |
----------------------------------------------------------------------------------

Prod : (lenteurs)
----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 140K| 83M| 8067 (1)| 00:01:37 |
|* 1 | TABLE ACCESS FULL| XXXXXXXXXXXX | 140K| 83M| 8067 (1)| 00:01:37 |
----------------------------------------------------------------------------------

Sachant que la machine de prod est supérieure en performances (x2 CPU et x8 mem), les temps d’exécutions de la requête nous semblent cohérents...

Doit-on rechercher une cause sur la transmission des données entre le serveur et le poste client ?

Merci d'avance pour vos réponses.

Fred.

[Ikebukuro]

Plusieurs remarques :
- la base de test n'est pas identique à celle de prod en terme de volumétrie donc c'est difficile de comparer les temps d'exécution des deux bases sur deux machines différentes :
TEST : 7259 rows récupérées
PROD : 140 000 rows récupérées soit 20 fois plus
- en plus, la machine de prod est plus puissante que la machine de test au niveau hardware donc les plans d'exécutions ne peuvent être comparés

- néanmoins : les temps d'exécution sont grosso modo les mêmes, 1 minute 05 en TEST, 1 minute 37 en PROD --> et tu dis que le problème est en PROD mais pour 20 fois plus de rows récupérées, on a presque le même temps d'exécution; je trouve que la machine de prod est rapide (si je compare à celle de TEST que tu dis fonctionner normalement)

[fredodeveloppeur]

Bonjour & merci pour ces nouveaux éléments.

Volumétrie : ce qui est étrange c'est que le résultat (export des données en fichier plat) donne à 99% le même nombre de lignes. (140k)
Je ne sais pas expliquer pourquoi le plan d'exécution n'en fait pas état sur la machine de test, avez-vous une explication ?

Autre information : les traitements subissant les lenteurs en utilisant la base de données sont des traitements SSIS sur une autre machine en conection ado.net ?

Quelle piste suivre maintenant ? Réseau? tampon de données ? applicatif oracle ?

Merci pour votre aide.
Fred

[mnitu]

Activez une trace SQL étendue lors de l'exécution des traitements qui subissent des lenteurs et analysez le fichier ainsi générée. Vous allez comprendre ce qui est devenu lent.

[Ikebukuro]

Volumétrie : ce qui est étrange c'est que le résultat (export des données en fichier plat) donne à 99% le même nombre de lignes. (140k)
Je ne sais pas expliquer pourquoi le plan d'exécution n'en fait pas état sur la machine de test, avez-vous une explication ?

Est-ce que tu as obtenu les plans d'exécution en faisant un explain plan, un set autotrace ou bien l'ordre SQL a vraiment été exécuté puis tu as utilisé DBMS_XPLAN.DISPLAY_CURSOR?
Si c'est un explain plan que tu as fait, l'ordre SQL n'a pas été exécuté mais seulement analysé par l'optimiseur qui te sort un plan d'exécution en se basant sur les stats de la base. Je pense que sur la machine de test les stats ne sont pas à jour : utiliser le package DBMS_STATS pour les régénérer et réexécute l'ordre SQLpour voir si le plan d'exécution a le même nombre de rows que sur la machine de prod.