Discussion :

[bpprive]

J'ai l'impression que le plan ne correspond pas à la requete. J'ai deja eu ce cas. Execute tu le plan et la requete dans le meme outils ?

Bon point, est-ce le plan fourni est celui produit via "explain plan for" ou celui qui sort du fichier de trace? Depuis 9i, le bind varible peaking (bvp) fait mentir le plan sorti par la commande "explain plan for"... Si c'est celui du fichier de trace (row source generation), il est celui réellement exécuté. "Explain plan for" donne le plan optimal, sans regarder s'il en existe un en cache pour le "même" énoncé, outre les bind variables...

[Pomalaix]

Le tkrof montre des "scattered read" ce qui indique a priori des acces par FULL SCAN alors que le plan montre des acces par INDEX on devrait avoir du "sequential read"

Gloups, je me rends compte que j'ai été quelque peu ambigu, et votre perplexité est légitime !

La trace issue de l'événement 10046 que j'ai fournie correspond à l'exécution en prod de la requête dans les conditions initiales : la table ZYTD12 en vrac telle que je l'ai trouvée, et sans influencer l'optimiseur.

Il s'agit donc bien d'un accès par balayage complet de la table.
C'est d'ailleurs visible dans la dernière ligne de cette trace :

Code :

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

STAT #1 id=2 cnt=1689 pid=1 pos=1 obj=23243 op='TABLE ACCESS FULL ZYTD12 '

Il aurait effectivement été intéressant que je fournisse une telle trace lors de l'exécution qui force l'utilisation de l'index.

Ca va être difficile maintenant, car je suis passé à l'action :
- j'ai réduit le DB_FILE_MULTIBLOCK_READ_COUNT (de 32 à 8)
- j'ai réordonné physiquement la table ZYTD12
- j'ai drastiquement augmenté le DB_BLOCK_BUFFERS, qui était ridiculement petit

J'atteins maintenant des performances identiques à celles de la base de test, alors qu'en test les données sont toujours en vrac, le tampon de données est aussi minuscule qu'il l'était en prod, etc.