Paramètre OPTIMIZER_INDEX_COST_ADJ

J'ai constaté récemment que la valeur du paramètre OPTIMIZER_INDEX_COST_ADJ influait considérablement sur le plan d'exécution et le coût d'une requête, et que la valeur par défaut fixée par Oracle était loin d'être optimale.

En effet, par défaut cette valeur est à 100.
Si je demande le plan d'exécution d'une requête comportant un certain nombre de jointures, j'obtiens un coût de 1763 avec 5 TABLE ACCESS FULL.
En passant le paramètre à 10, j'obtiens 1364 et seulement 2 TABLE ACCESS FULL.
Enfin, en mettant le paramètre au minimum, soit 1, j'obtiens un coût de 218 avec un seul TABLE ACCESS FULL.

Cela paraît logique vu que plus la valeur du paramètre est faible, plus le choix des index est privilégié. Mais dans ce cas, pourquoi fixer la valeur par défaut à 100 ? :!: :?:

Dans la requête que j'ai prise en exemple, l'évolution du plan d'exécution est flagrante. Mais pour certaines autres requêtes, le plan d'exécution reste rigoureusement identique entre les valeurs 100 et 1, alors que le coût de la requête diminue considérablement 8O Comment est défini ce coût exactement s'il ne se base pas uniquement sur le plan d'exécution ?

Merci de vos réponses.

L'optimiseur peut choisir de joindre vos table par HASH JOIN, qui engendre obligatoirement des FULL ACCESS TABLE en opposition à la jointure par NESTED LOOP qui utilise les index.

Il faut essayer de garder la main sur le plan d'exécution en forçant si besoin les hints. l'Oracle ne devine pas tout...

effectivement et ce n'est pas le seul paramètre d'initialisation dont la valeur par défaut ne corresponde pas à la valeur optimale

d'ailleurs une valeur n'est optimale que dans un environnement donné

néanmoins concernant ce paramètre, une valeur de 100 indique qu'un accès FULL SCAN a le même coût qu'un indexed access , ce qui n'est effectivement jamais le cas dans des systèmes OLTP

à toi de tester plusieurs valeurs entre 0 et 100 (10-25 semble communément être la fourchette recommandée)

sache également que le para optimizer_index_caching (qui représente le %age de bloc supposé présent dans le buffer cache via une recherche par index) est souvent trop bas (0 au lieu de 90 en OLTP)

voila ce que j'en sais

Marc

Merci pour vos réponses.

En effet, je viens de tester ma requête avec optimizer_index_caching à 90, le coût diminue encore de moitié :!:

Oracle ou comment passer vos nuits à lire la doc :wink: