Probleme TABLE ACCESS BY INDEX ROWID

Bonjour,

Sous Oracle 9ir2, j’ai le probleme suivant:

SELECT C.CODE,
(SIGN(NVL(SUM(C.col1), 0))) CRES,
C.TRX_TYPE
FROM RISK C
WHERE C.col2 IN ( :1, '!NUL')
AND C.col3 IN ( :2, '!NUL')
AND C.CANC C IN ( :3, '!NUL' )
AND C.RC IN ( :4, '!NUL')
AND C.MRI IN ( :5, '!NUL')
AND C.col4 = :6
AND C.col5 = :7
AND C.col6 IN (:8, '!NUL')
GROUP BY C.CODE,C.TRX_TYPE

Voila ce que j'ai comme PK et indexes:

Il ya une PK_RISK primary key (RISK_DB_ID)
Il ya un index INN_RISK_1 on RISK (col3, col2, RC, MRI, CANC) dans cet ordre
Il ya un index INN_RISK_2 on RISK (CODE, TRX_TYPE)

Le plan d'execution me donne les informations suiavantes:
SELECT STATEMENT, GOAL = CHOOSE Cost=3 Cardinality=1 Bytes=51
SORT GROUP BY Cost=3 Cardinality=1 Bytes=51
INLIST ITERATOR
TABLE ACCESS BY INDEX ROWID Object owner=A Object name=RISK Cost=2 Cardinality=1 Bytes=51
INDEX RANGE SCAN Object owner=A Object
name=INN_RISK_ 1 Cost=1 Cardinality=1


C’est une petite table de 256 lignes elle garde cette taille a vie , le coût reste toujours 3, le problème il ya un TABLE ACCESS BY INDEX ROWID, qui bouffe de cost, je veux que le cost final devient 1, quelqu’un à une solution pour ca svp ? parceque cette requete elle est encapsulé par d’autres requete !!!!!!!, et presque toute les requetes ont le meme problemes

Merci d’avance de vos reponses

Attention, le coût d'un plan d'exécution n'a de sens pour le CBO que comparé pendant la phase de compilation/d'optimisation à d'autres plans d'exécution possibles pour la même requête dans le même environnement. Autrement dit, ce n'est pas parce que le coût est divisé par 3 que la requête sera 3 fois plus rapide.

Merci Pifor,

Mais tu connais pas une methode pour balayer les 256 ligne de la table sans le access by rowid index? ou bien d'autres hint? j'ai utilisé le full(table) ca ne ma rien donné?

S'il passe par l'index pour une table de cette taille, tes stats ne sont peut etre pas à jours.

Autrement, tu détruis tes index ! pour une table de 256 lignes statiques, ils ne servent à rien.
ou
tu mets des fonctions sur la premiere colone de tes index dans ta clause where.
...
col3||'' in....
...

Mais c'est probablement inutile en terme de perf.