| |De : Emmanuel Magnier [mailto:xxx@yyy.zzz]
|Envoyé : lundi 6 février 2006 12:00
|À : Support Eptica
|Cc : 2A; Jérôme LICCIARDELLO; Benoit Py
|Objet : probleme avec les requêtes sql des rapports
Bonjour,
les DBA me remontent des problèmes avec les requêtes des rapports (au
moins certains) qui prennent un temps terrifiant à s'exécuter.
En l'occurence, une de celle posant problème est celle-ci:
SELECT REQUEST.REQUESTTYPE, COUNT (*)
FROM REQUESTSTATEVENT, REQUEST
WHERE REQUEST.REQUESTID = REQUESTSTATEVENT.REQUESTID
AND REQUESTSTATEVENT.REQUESTNEWSTATUS <> 1
AND REQUESTSTATEVENT.STATEVENTID IN (
SELECT MAX (REQUESTSTATEVENT.STATEVENTID)
FROM REQUESTSTATEVENT, STATEVENT
WHERE REQUESTSTATEVENT.STATEVENTID = STATEVENT.STATEVENTID AND
STATEVENT.EVENTDATE <= :1
GROUP BY REQUESTSTATEVENT.REQUESTID)
GROUP BY REQUEST.REQUESTTYPE
elle met 32h (!!) à retourner un résultat.
De plus son plan d'exécution utilise un TABLE ACCESS FULL sur la table
REQUESTSTATEVENT et non les index définis. Après quelques essais,
impossible de lui faire utiliser les index...
(1) SELECT STATEMENT CHOOSE
Est. Rows: 1 Cost: 9 868
(12) SORT GROUP BY
Est. Rows: 1 Cost: 9 868
(11) NESTED LOOPS
Est. Rows: 1 Cost: 9 865
(8) HASH JOIN SEMI
Est. Rows: 1 Cost: 9 863
(2) TABLE ACCESS FULL HERMES.REQUESTSTATEVENT
[Analyzed]
(2) Blocks: 24 884 Est. Rows: 5 291 114 of
6 172 966 Cost: 1 518
Tablespace: HERMES_DATA
(7) VIEW SYS.VW_NSO_1
Est. Rows: 411 841 Cost: 6 098
(6) SORT GROUP BY
Est. Rows: 411 841 Cost: 6 098
(5) HASH JOIN
Est. Rows: 411 841 Cost: 4 107
(3) NON-UNIQUE INDEX RANGE SCAN
HERMES.EVENTDATEINDX [Analyzed]
Est. Rows: 411 841 Cost: 371
(4) NON-UNIQUE INDEX FAST FULL SCAN
HERMES.REQUESTIDINDX [Analyzed]
Est. Rows: 6 172 966 Cost: 1 416
(10) TABLE ACCESS BY INDEX ROWID HERMES.REQUEST [Analyzed]
(10) Blocks: 132 032 Est. Rows: 1 of 838 219 Cost: 2
Tablespace: HERMES_DATA
(9) UNIQUE INDEX UNIQUE SCAN HERMES.SYS_C002181
[Analyzed]
Est. Rows: 1 Cost: 1
voici la liste des index actuellement définis sur cette table:
SYS_C002194(STATEVENTID)
REQUESTIDINDX(REQUESTID, STATEVENTID)
REQEVENTKINDINDX(REQUESTEVENTKIND, REQUESTNEWSTATUS, STATEVENTID,
REQUESTID, AGENTID)
IDX_REQUESTSTATEVENT(REQUESTID)
REQNEWSTATUS(REQUESTNEWSTATUS, STATEVENTID, REQUESTID)
Il me semble qu'il y a d'autres requêtes de rapports qui utilise cette
table et qui posent le même genre de problème mais je ne les ai pas sous
la main actuellement.
Ce n'est pas un problème nouveau mais cela devient particulièrement
critique en ce moment.
Pourriez vous nous indiquer un moyen de faire en sorte que ces requêtes
utilisent des index et non des "table full access" qui plombent les
performances générales.
Je reste à votre disposition si vous avez besoin de renseignements
complémentaires.
Merci.
Emmanuel.
|