[OPTI] Requête gourmande

Version imprimable

Salut à tous,
dans mon application j2ee je fais l'appel à cette requete :
Code:

1 2 3 4 5 6 7 select sum(valeur) from pt_chron_res_u pt, chron_res_u ch where pt.id_chron_res_u = ch.id_chron_res_u and ch.id_etude=15032 and ch.type in ('RPRIM','RSEC','PRODUCTION') and pt.date_res_u >= ( select date_debut from marge_periode where marge_periode.id_calcul=101 and marge_periode.id_etude=15032 and marge_periode.numero_periode=1 ) and pt.date_res_u < ( select date_fin from marge_periode where marge_periode.id_calcul=101 and marge_periode.id_etude=15032 and marge_periode.numero_periode=1 )
le plan d'execution est en PJ.

la structure des tables est la suivante :

|----------------|
| CHRON_RES_U |
|----------------|
| id_chron_res_u |
| type |
| id_etude |
|----------------|

|-------------------|
| PT_CHRON_RES_U |
|-------------------|
| id_chron_res_u |
| date_res_u |
| valeur |
|-------------------|

|----------------|
| MARGE_PERIODE |
|----------------|
| id_calcul |
| numero_periode |
| id_etude |
| date_debut |
| date_fin |
|----------------|

Voici les index présent sur la table PT_CHRON_RES_U :

Code:

CREATE INDEX A_PT_CHRON_RES_U_FK ON PT_CHRON_RES_U

Code:

CREATE UNIQUE INDEX PK_PT_CHRON_RES_U ON PT_CHRON_RES_U

Le problème là, c'est que la dite requete prend entre 30s et 45s pour s'executer et que je dois le faire 15 fois (pour un numéro de période allant de 1 à 15), du coup je cherche à l'optimiser au max mais là, mais à part ajouter un index sur la table PT_CHRON_RES_U, sur l'id, jvois pas, car c'est cette table qui apparement pose soucis.

Le plan n'est pas lisible, il est préférable de le récurérer via sqlplus et de le poster dans des balises codes (bouton #)
Il manque les colonnes sur lesquels portent les index.

La requête ne semble pas optimisée, que donne la requête réécrite comme çà ? (déjà en terme de résultat)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
with t as (
select ch.id_chron_res_u, m.date_debut, m.date_fin
  from chron_res_u ch
  join marge_periode m on m.id_etude = ch.id_etude
 where ch.id_etude = 15032
   AND ch.type IN ('RPRIM','RSEC','PRODUCTION')
   and m.id_calcul = 101
   and m.numero_periode = 1
)
select sum(valeur)
  from pt_chron_res_u pt
 where exists (select 1
                 from t
                where t.id_chron_res_u = pt.id_chron_res_u
                  and pt.date_res_u >= t.date_debut
                  and pt.date_res_u <  t.date_fin)

Faire 15 fois la même requête dans une boucle n'est pas optimal non plus, que donne la requête réécrite comme ça pour les 15 périodes ? (déjà en terme de pertinance de résultat)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
with t as (
select ch.id_chron_res_u, m.date_debut, m.date_fin, m.numero_periode
  from chron_res_u ch
  join marge_periode m on m.id_etude = ch.id_etude
 where ch.id_etude = 15032
   AND ch.type IN ('RPRIM','RSEC','PRODUCTION')
   and m.id_calcul = 101
   and m.numero_periode between 1 and 15
)
select m.numero_periode, sum(pt.valeur)
  from pt_chron_res_u pt
  join t  on t.id_chron_res_u = pt.id_chron_res_u
         and pt.date_res_u   >= t.date_debut
         and pt.date_res_u   <  t.date_fin
 group by m.numero_periode

Il faudrait aussi préciser la version de la base.

03/12/2012, 14h10
erox44

Salut, je vais essayer de choper le plan sous un autre format, pour ce qui est de la base, on est sous du oracle 10g.
03/12/2012, 14h15
erox44

Ok donc , pour les requetes que tu m'as proposé, la 1ere donne le bon résultat, mais en 320s, et la 2e, donne les bons résultats, en 14s.

Du coup pour l'instant je vais surement partir sur la seconde et revoir le code applicatif derriere.

merci en tout cas :b
03/12/2012, 15h51
skuatamad

Faire un tkprof de la trace étendue serait intéressant.

Il est possible qu'un index couvrant puisse améliorer les perfs si le tkprof met en évidence une contention sur la table PT_CHRON_RES_U.

Code:

CREATE INDEX IDX_CHRON_RES_id_date_val ON PT_CHRON_RES_U (id_chron_res_u, date_res_u, valeur)

Après 14sec peut être largement acceptable en fonction de l'utilisation, sinon le tkprof ainsi que la version + license permettront d'identifier d'autres directions/solutions envisageables.