Discussion :

[jenesuispasunrobot]

Bonjour à tous,

un problème que je rencontre me laisse sceptique... Un traitement sur une appli durait plusieurs heures... Ceci principalement du à une requête d'update qui met environ 1 secondes par exécution, ceci n'est pas le fonctionnement normal de l'application.

Lorsque je regarde le plan d'exécution de la requête, celui-ci est correct et passe bien par le bon index, par contre la presque totalité du temps passé est sur du temps CPU. Si je fait un rebuild de l'index, le plan d'exécution reste identique mais le temps / requête passe à 0.4 ms.

J'ai du mal à saisir en quoi une reconstruction d'index peut engendrer cela sachant que les index sont supprimés et recréés régulièrement sur cette base (oui je sais >_<). Je me serais plutôt attendu à une baisse de performance en même temps que l'organisation de l'index se dégradait, mais à une augmentation si nette du temps de la requête.

C'est un oracle 10.2.4 sur une linux redhat.

Vous auriez une explication "logique" à un comportement de la sorte ?

[Ahmed AANGOUR]

Bonjour,

pouvez vous fournir les traces/stas/plans vous permettant d'arriver à cette conclusion?

[jenesuispasunrobot]

Voici le plan d'exécution

Code :

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

1
2
3
4
5
6
7
8
9
10
 
----------------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------
|   0 | UPDATE STATEMENT              |                          |     1 |    52 |     2   (0)| 00:00:01 |
|   1 |  UPDATE                       | TBDT1_JOUR               |       |       |            |          |
|*  2 |   FILTER                      |                          |       |       |            |          |
|*  3 |    TABLE ACCESS BY INDEX ROWID| TBDT1_JOUR               |     1 |    52 |     2   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN          | IDXU_IDUNBLRATBLART1_CAT |     1 |       |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------

qui se trouve être le même dans les 2 cas...

[Ahmed AANGOUR]

Un Index Range Scan peut effectivement s'avérer un peu plus long si l'index est fragmenté. C'est l'un des rares cas où le rebuild d'index peut aider. Sinon la reconstruction des indexes régulières n'est pas une bonne pratique.
http://richardfoote.files.wordpress....-the-truth.pdf

As-tu un rapport tkprof pour les 2 requêtes?

[Waldar]

À noter aussi, si j'ai bien compris, dans votre traitement vous avez énormément de mises à jour que vous traitez en ligne à ligne.

Si c'est réalisable dans votre cas, une requête ensembliste de mise à jour sera beaucoup plus efficace.

[jenesuispasunrobot]

Merci pour vos réponses,

Je comprends bien votre propos, seulement cela ne m'éclaire pas sur la cause du problème... Exemple, le traitement était lent, suite à un rebuild de l'index, le traitement se retrouve immédiat.

2 jours après le traitement s'avère encore très long, il ne s'agit donc pas de la fragmentation de l'index qui est en cause car les lignes de la tables sont modifiées de manière marginale (au plus quelques 10 aines de milliers de modifications sur 1.500k lignes).

Je vais voir à ressortir le tkprof de la requête.

[mnitu]

Ca sera mieux. Jusqu’au là vous dit : « mon traitement était lent je fais un rebuild de index et après le traitement est devenu rapide. Mais aujourd’hui je constante à nouveau que mon est traitement lent. » Donc peut être ça n’a rien à voir avec le rebuild d’index.
Par contre une trace SQL étendue pourrait mettre en évidence ce qui se passe.