Discussion :

[totoche]

Bonjour,
Est-ce un 'mauvais parmetrage ' du DB_FILE_MULTIBLOCK_READ_COUNT peut entrainer un full acess sur une attribut indexé mais à faible sélectivité (peu de cardinalité)?
Merci de vos réponses

[mnitu]

Comment l'optimiseur d'Oracle calcule le coût

[totoche]

Si un attribut possede 10 cardinalités, mais qu'un seul attribut retourne 70% des lignes de la table.
Que le db_file_multiblock_read_count est calé sur la taille du cache OS.

Sachant que le temps lecture en mode multiblocs intervient dans le calcul du cout, il peut-y avoir un risque que l'optimiseur fasse un full table scan, même si la requete dans son prédicat porte sur l'attribut à faible sélectivité (70%)

Seule la lecture du plan d'execution, indiquera s'il faut faire un hint pour forcer l'usage de l'index, au détriment des cardinalités a forte séléctivité.

Face a ce constat, ne vaut-il mieux ne pas faire de hint afin de bénéficier de la lecture multibmock pour les cardinalité a forte sélectivité, et joindre une vue materializée pour l'attribut a faible sélectivité ?


Merci de vos suggestions

[Waldar]

Je ne suis pas sûr d'avoir compris l'intégralité de votre discours, mais si une requête doit retourner 70% des lignes de la table, un full scan sera nettement plus rapide qu'un index scan + table scan by rowid.

[mnitu]

...
Seule la lecture du plan d'execution, indiquera s'il faut faire un hint pour forcer l'usage de l'index, au détriment des cardinalités a forte séléctivité.

Face a ce constat, ne vaut-il mieux ne pas faire de hint afin de bénéficier de la lecture multibmock pour les cardinalité a forte sélectivité, et joindre une vue materializée pour l'attribut a faible sélectivité ?

...

Rules for Hinting

Mais, vos propos sont un peu confuses.

[totoche]

Pardon, je ne me suis pas relu, et j'ai fais une inversion

Sachant que le temps lecture en mode multiblocs intervient dans le calcul du cout, il peut-y avoir un risque que l'optimiseur fasse un full table scan, alors que la requete porte sur une cardinalité a forte sélectivité (peu de lignes retournés)

Face a ce constat, ne vaut-il mieux une vue materializée pour l'attribut a faible sélectivité ?

[skuatamad]

alors que la requete porte sur une cardinalité a forte sélectivité (peu de lignes retournés)

Face a ce constat, ne vaut-il mieux une vue materializée pour l'attribut a faible sélectivité ?

Il y a les histogrammes pour aider l'optimiseur, mais le phénomène de bind variable peeking (cf l'article de mnitu) impacte fortement l'intérêt des histogrammes.

Plutôt qu'une vue materialisée tu peux peut être tester la valeur pour la renseigner en dur et pour le reste utiliser les binds variables, du style :

Code :

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

1
2
3
4
5
if (p_var1 == 1) then 
  select * from t where c = 1 and c2 = p_var2;
else 
  select * from t where c = p_var1 and c2 = p_var2;
end;

Ou peut être juste ne pas bind la variable si tu es dans un contexte type DW.