检索慢，索引没用上，怎么办？老毛病了。哎。愁呀。。。。

Question

SELECT T.KENSYU_CD,
       DECODE(T.TORI_KAI_CD, '635', '1', '2') AS JISYA_TASYA_KBN,
       SUM(T.DAI_JOSYA_JININ) AS DAI_JOSYA_JININ,
       SUM(T.SYO_JOSYA_JININ) AS SYO_JOSYA_JININ,
       SUM(T.DAI_JISEN_UNCHIN) AS DAI_UNCHIN,
       SUM(T.SYO_JISEN_UNCHIN) AS SYO_UNCHIN
--BULK COLLECT INTO o_last_year_data_tbl
  FROM TP_KIKAKU_TORI T
 WHERE T.KEIJO_YM BETWEEN 201004 AND 201103
   AND T.HATSU_REF_KBN = '1'
 GROUP BY T.KENSYU_CD, DECODE(T.TORI_KAI_CD, '635', '1', '2')SELECT STATEMENT, GOAL = ALL_ROWS Cost=206622 Cardinality=36 Bytes=1836
 HASH GROUP BY Cost=206622 Cardinality=36 Bytes=1836
  PARTITION RANGE ITERATOR Cost=206353 Cardinality=5860019 Bytes=298860969
   TABLE ACCESS FULL Object owner=SB1 Object name=TP_KIKAKU_TORI Cost=206353 Cardinality=5860019 Bytes=298860969索引为：KEIJO_YM HATSU_REF_KBN 就是where语句的顺序。
表中有36*500万条记录。
现象为：单独执行sql只需要1分钟时间，这个时间可以达标。
        但是，在过程中执行的时间为1个小时，太恐怖了￥#%@#￥%   不知道为什么，会这么大的差距，我应该怎么改善？？？？？？？

Answer 1

.....你的意思是,在procedure中执行得非常慢?而单独执行时不慢?是这个意思吗?在使用10046看一下你的真实的单个执行时的执行计划.扫描了多少个分区.另外,你的那个谓词应该是分区key吧.

Answer 2

在使用10046看一下你的真实的单个执行时的执行计划. 
什么是10046，不太明白，呵呵。指教下。谢谢；
对，就是在procedure中执行很慢。这个sql应该扫描12个分区，因为，WHERE T.KEIJO_YM BETWEEN 201004 AND 201103 
KEIJO_YM 就是分区的key。

Answer 3

有没有删除过旧分区哟。你的index是什么类型的 是local还是global

Answer 4

10046事件说明10046事件是Oracle提供的内部事件，是对SQL_TRACE的增强.
10046事件可以设置以下四个级别:
1 - 启用标准的SQL_TRACE功能,等价于sql_trace
4 - Level 1 加上绑定值(bind values)
8 - Level 1 + 等待事件跟踪
12 - Level 1 + Level 4 + Level 8
类似sql_trace，10046事件可以在全局设置，也可以在session级设置。开启10046事件SQL> alter session set events '10046 trace name context forever ,level 12' ;会话已更改。关闭10046事件SQL> alter session set events '10046 trace name context off' ;会话已更改。

Answer 5

瓶颈肯定不在这段sql。这段sql基本上没有什么优化的余地，顶多就是在KEIJO_YM 上面加一个索引，而且即使加了索引，如果根据该字段过滤出来的记录数超过总记录的10%，索引也基本上没用。
好好检查一下你的过程吧。

Answer 6

zuzuou说的有道理. 通常这种问题不是SQL能解决的，考虑用数据仓库的方式--数据库安装的时候配置为数据仓库，或者按照数据仓库的要求调整配置。
这么巨量的数据上，不用分布式数据库，或者不考虑数据仓库，如有多个并发，百分之百是 GAME OVER。
建议解决途径：生成中间表，并适当调整业务 。如果无法说服客户，那只能等死.
---------------------------------------------------------------------------------------------------
就事论事，你的表结构，数据库等信息不明，无法提供更好的意见。
至于PROC更费时，建议你查询下当时是否存在并发事务（不一定是这个查询).
这样的情况，我遇到过，整个数据库只为一个SQL或者过程服务的时候，看起来还可以忍受，稍微并发立马吐血。

Answer 7

人家楼主是问为什么在procedure和单独执行的执行计划不一样.怎么又变成所谓的"中间表"了.
另外,楼主,你确定你在procedure是这个慢吗?dbms_profiler 先作一下这个procedure的跟踪看看.10046是一个跟踪事件.

Answer 8

跟踪没有太大意义 ，36*500万 
sum，fullscan。这样的设计，只要多几个并发包死。

Answer 9

你怎么觉得没有意义?并发是并发,不是一回事.你明白楼主的意思了没? 人家不是指的生产时刻.现象为：单独执行sql只需要1分钟时间，这个时间可以达标。 
        但是，在过程中执行的时间为1个小时，太恐怖了￥#%@#￥% 

Answer 10

还是做一下事件跟踪，看看这个sql究竟比单独执行多做了些什么。