Version imprimable
Bonjour à tous.
Je travaille sur Oracle 8i, optimiser_mode = choose.
J'ai une colonne ayant environ 10 valeurs différentes sur une table de 6 000 000 d'enregistrements.
J'ai mis un index normal sur cette colonne et analysé la table, mais Oracle n'utilise jamais l'index dans les plans d'exécutions.
J'en déduis que Oracle juge mieux de parcourir toute la table au lieu d'utiliser l'index. Dans ce cas quel type d'index devrais-je utiliser?
Merci d'avance.
Bonjour,
mais ca depend de beaucoup de choses :
Quelle requete as tu utilisé ?
(clause where , utilisation de fionction upper ...)
Combien de ligne tu ramenes ?
Un full scan n'est pas forcément "dementiel" ....
En gros Oracle utilisera l'index si tu ramène moins de 20% des lignes
Merci de votre réponse.Citation:
Envoyé par fatsora
Je fais simplement :Code:select * from table where statut=2
Maintenant je commence à comprendre, merci. C'est logique que si je ramène les 70% des enregistrements c'est mieux de tout de suite parcourir la table.Citation:
Envoyé par fatsora
Par contre j'ai compté les enregistrement groupés par la colonne (statut):
- Pour le statut 2 par exemple : environ 4 000 000 enregistrements
- Pour le statut 8 : 2 000 enregistrements
Mais Oracle n'utilise pas l'index ni lors du filtre par statut 2, ni lors d'un filtre par statut 6.
Ensuite, j'ai un autre index composite : table (col1, col2, col3, statut)
Lorsque je faisOracle utilise l'index composite en FAST FULL SCAN.Code:select count(*) from table where statut = 2
Pourriez-vous m'expliquer parce que je voudrais vraiment comprendre comment ça marche réellement; ou pourriez-vous me recommander un doc intéréssant.
Merci bien.
Ici pour t'aider
http://jpg.developpez.com/oracle/tuning/
et
Pour l'optimiseur de cout
http://marius-nitu.developpez.com/tu...-calcule-cout/
Merci pour les docs, et merci de m'avoir apris à pêcher Fatsora :D
Bonjour,
Donc tu souhaite avoir un plan d'exécution différent suivant la valeur.Citation:
Pour le statut 2 par exemple : environ 4 000 000 enregistrements
Pour le statut 8 : 2 000 enregistrements
Pour celà, il faut 2 choses:
- que cette valeur soit un littéral et non une bind variable. Celà semble être le cas dans ton SQL
- que CURSOR_SHARING=EXACT, sinon oracle remplace ton littéral par une bind variable
Est-ce que tu peux vérifier:
Attention, changer cursor_sharing peut avoir un gros impact sur d'autres requêtes !Code:show parameter cursor_sharing
Cordialement,
Franck.
cursor_sharing est déjà = EXACT pour mon cas, et j'utilise un littéral pas une bind variable dans mon requête ....Citation:
Envoyé par pachot
Ah oui,
Alors j'ai oublié une 3ème chose: il faut qu'oracle puisse reconnaitre que la selectivité est différente suivant la valeur, au niveau de ses statistiques.
Il faut voir les histograms pour celà (sur la colonne STATUT).
Cordialement,
Franck.
Sauf erreur de ma part, tu précise cela pour la 8i ?Citation:
Envoyé par pachot
Car pour les versions suivantes cela n'est plus censé être vrai.
Enfin au moins avec la 10g (bind peek variable introduit en 9i bien que perfectible) et "intelligent cursor sharing" and bind peeking en 11g.
Quelle est la clé d'entrée sur le site pour trouver ces docs? car quand je vais sur la page des tutoriels d'oracle je ne retrouve pas ces documentsCitation:
Envoyé par fatsora
Bonjour,
Avec "intelligent cursor sharing" en 11g, je suis peut-être d'accord.Citation:
Envoyé par voran
Mais 'bind variable peeking' construit le plan d'exécution d'après les variables de la première exécution et le garde ensuite. Et donc ce plan d'exécution n'est probablement pas adapté aux autres exécutions. Celà rend même la stabilité du plan très aléatoire !
Personellement je préfères un mauvais plan d'exécution stable (au moins je le sais) qu'un plan instable...
Cordialement,
Franck.