Version imprimable
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...Citation:
Envoyé par Wurlitzer
Gloups, je me rends compte que j'ai été quelque peu ambigu, et votre perplexité est légitime !Citation:
Envoyé par Wurlitzer
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 :
Il aurait effectivement été intéressant que je fournisse une telle trace lors de l'exécution qui force l'utilisation de l'index.Code:STAT #1 id=2 cnt=1689 pid=1 pos=1 obj=23243 op='TABLE ACCESS FULL ZYTD12 '
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.