Optimisation GROUP BY et IN avec beaucoup de valeurs

Bonjour.
Dans le cadre d'une application, je dois réaliser une requête de type group by sur une table assez volumineuse.

La requete ressemble donc a cela :

Code:

---

1 2 3 4 5 6

SELECT COUNT (*), B FROM TABLE WHERE T_DATE BETWEEN ? AND ? AND T_SITE IN (?,?,?,.......) GROUP BY B

---

Je cherche donc le nombre de lignes ou le site est dans les valeurs de la liste, et ce pour chacun des sites spécifiées, le tout dans les dates indiqués (c'est une table de traces)

EDIT : il peut arriver que dans T_SITE IN (?,?,?...) , il y aie 400 valeurs différentes !

La table est assez grande (15 000 000 lignes). La requête prend a peu prés deux minutes, et ce n'est pas acceptable pour le client.

Je travaille en Oracle 9i, et je cherche un moyen de l'optimiser (index, réécriture de la requete...) auriez vous des idées ?

Merci d'avance de votre aide.

Quand tu as 400 valeurs dans le IN combien de lignes trouves-tu au total ?

Le nombre de résultats est très variable, selon l'étendue de date et selon les sites :

Il y a approximativement 20000 sites différents dans la base.
pour un site lourd, sur une journée il doit y avoir dans les 25 lignes.
pour un site léger, sur une journée il doit y avoir dans les 2 ou 3 lignes.

Par contre c'est envisageable de limiter le nombre de résultats. Par exemple n'avoir que les X plus grandes valeurs de group by. J'avais oublié de le préciser.

Citation:

---

Envoyé par le_gnou

auriez vous des idées ?

---

Une idée serait d'analyser le plan d'exécution! Ou sinon de remplacer le IN(1,2,3,4...) par IN(SELECT*FROM"temptable"). En effet si tu as 400 valeurs aujourd'hui, tu en auras peut-être 2000 demain ou dans dix ans (et la limite est de 1000).

:)

J'ai regardé du cote du plan d'exécution, il y a du unique scan et du range scan (ce qui ne devrait pas couter trop cher, si ?)

pour ce qui est de la requête, les sites sont passés en paramètre dans une appli J2EE. j'avais déja prévu le coup du IN en remplaçant par (SITE = ? OR SITE = ? OR....) faute de mieux, et vu que le plan d'éxec était le même qu'avec un IN, je m'en suis pas plus occupé que ca.

Je ne connais pas la répartition de vos données, mais vous pouvez envisager une partition sur T_DATE (mois / année en fonction de la volumétrie), avec des index locaux sur T_SITE.

Citation:

---

Envoyé par le_gnou

J'ai regardé du cote du plan d'exécution, il y a du unique scan et du range scan (ce qui ne devrait pas couter trop cher, si ?)

---

Serait-ce trop demander que de nous le partager ?

Je ne sais pas si le code va ressortir proprement !
Voici le plan d'exécution :

Code:

---

1 2 3 4 5

SELECT STATEMENT CHOOSE SORT(GROUP BY) COUNT(STOPKEY) ROWNUM<=2000 TABLE ACCESS(BY INDEX ROWID) M1USER.JOURNAL "JOURNAL"."JOUR_ID_SITE"=19332 OR "JOURNAL"."JOUR_ID_SITE"=19332 OR "JOURNAL"."JOUR_ID_SITE"=19332 OR "JOURNAL"."JOUR_ID_SITE"=19332 INDEX(RANGE SCAN) M1USER.DATETRAITEMENT "JOURNAL"."JOUR_DATE_TRAITEMENT">TO_DATE(' 2008-10-17 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "JOURNAL"."JOUR_DATE_TRAITEMENT"<TO_DATE(' 2008-10-24 00:00:00', 'syyyy-mm-dd hh24:mi:ss')

---

Edit : j'ai mis 4 sites seulement pour ne pas polluer le plan, le résultat est le meme avec 400 sites