同样的sql,在jboss中查询速度慢，在其他地方却很快？

peixubin

以下查询：
SELECT t0_o.YS FROM DF t0_o
WHERE (t0_o.SFRQ BETWEEN ? AND ? AND t0_o.ZT = 20 AND t0_o.ZF = 100 AND t0_o.DM = ?)
在jboss3.2.x的cmp entity bean中运行很慢，10分钟以上，但我直接用JDBC却很快，
对该表运行analyze table df compute statstics 也没用，为什么？
DF表:
YS varchar2(20) primary key
sfrq date　有索引
rq varchar(6) 格式为yyyymm 为分区字段。

这个sql有三个参数，开始日期，终止日期再加一个字符型，每次约查询1000条记录，
该表数据有上千万。
我怀疑在jboss cmp中运行时，oracle对这个查询采用了全表扫描，有没有办法能监测？

sshd

v$sql_area, v$sql_plan to see the execution plan

peixubin

通过跟踪session,发现oracle使用了全表扫描：
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch      298      0.00       0.00     165440     167911        357        2978
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      300      0.00       0.00     165440     167911        357        2978

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 127

Rows     Row Source Operation
-------  ---------------------------------------------------
   2978  PARTITION RANGE ALL PARTITION: START=1 STOP=85
   2978   TABLE ACCESS FULL HS_DFLSZ PARTITION: START=1 STOP=85

oracle8.1.7.4.0怎么这么傻啊？

peixubin

以下是用jdbc直接访问的日志：
********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed  = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
********************************************************************************

SELECT t0_o.YSID
FROM
YD.HS_DFLSZ t0_o WHERE (t0_o.SFRQ BETWEEN :1 AND :2 AND t0_o.DFZT = 20 AND
  t0_o.ZFFS = 100 AND t0_o.YHDM = :3)


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch      171      0.00       0.00          0        764          0        1707
total      173      0.00       0.00          0        764          0        1707

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 127

Rows     Row Source Operation
-------  ---------------------------------------------------
   1707  PARTITION RANGE ALL PARTITION: START=1 STOP=85
   1707   TABLE ACCESS BY LOCAL INDEX ROWID HS_DFLSZ PARTITION: START=1 STOP=85
  10968    INDEX RANGE SCAN PARTITION: START=1 STOP=85 (object id 362173)

同样的sql,相差为何这样大呢？

1017of

是不是索引太多了？

peixubin

索引太多也不应该这样啊？
像数据仓库索引更多。

有没有english比较好的同志帮我在http://www.orafaq.net上发布一下啊？

1017of

倒，我弄反了，full table scan慢这么多啊？
莫非是CMP的问题？

peixubin

CMP没有问题，发送到数据库的sql是一样的，而执行效果不同，应该是oracle有bug。
有没有办法可以绕过阿？

sshd

use query hint?

peixubin

query hint,我有点反感,作为一个大型数据库系统,连这样简单的查询都不能正确的分析,哀!!!