查看: 17921|回复: 53

[原创] 一次简单的性能优化诊断,聚簇因子过高导致全表扫描。

[复制链接]
认证徽章
论坛徽章:
21
奔驰
日期:2013-08-06 15:23:05日产
日期:2013-08-07 22:56:38蜘蛛蛋
日期:2012-12-29 19:15:08奥迪
日期:2013-08-07 17:02:24数据库板块每日发贴之星
日期:2010-06-28 01:01:03奥迪
日期:2013-08-13 10:10:28本田
日期:2013-11-20 15:17:02优秀写手
日期:2013-12-18 09:29:08玉兔
日期:2014-03-04 16:47:17铁扇公主
日期:2012-02-21 15:02:40
发表于 2010-6-23 20:37 | 显示全部楼层 |阅读模式
业务人员反映一个查询非常慢:
--------------------------------------------------------------------------------
select * from ab44 where aae002=201006;
--------------------------------------------------------------------------------

查看执行计划,是全表扫描
SQL> explain plan for select * from ab44 where aae002=201006;
已解释。
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT                                                               
--------------------------------------------------------------------------------
Plan hash value: 781340439                                                      
                                                                                
--------------------------------------------------------------------------      
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |      
--------------------------------------------------------------------------      
|   0 | SELECT STATEMENT  |      | 10554 |   865K|  8777   (3)| 00:01:46 |      
|*  1 |  TABLE ACCESS FULL| AB44 | 10554 |   865K|  8777   (3)| 00:01:46 |      
--------------------------------------------------------------------------      
                                                                                
Predicate Information (identified by operation id):                             
---------------------------------------------------                             
PLAN_TABLE_OUTPUT                                                               
--------------------------------------------------------------------------------
                                                                                
   1 - filter("AAE002"=201006)                                                  
已选择13行。


看看查询应该返回多少数据量,还有这个表有多少记录。
SQL> select count(*) from ab44 where aae002='201006';
  COUNT(*)
----------
       576
SQL> select count(*) from ab44;
  COUNT(*)
----------
   3310023

SQL> select 576/3310023 from dual;
576/3310023
-----------
.000174017

查询所需返回的行数仅占表的很小比例,如果有索引的话,应该索引扫描才对。
查看表的索引,发现在aae002字段上有一个复合索引,四个字段组成AAE002, AAE003, AAB001, AAE140。既然有索引,为什么没有使用呢?莫非是缺失统计信息。

查看表、索引、直方图的信息都有。而且统计信息相对还是比较新的。
SQL> select num_rows,blocks,avg_row_len from user_tables where table_name='AB44';
  NUM_ROWS     BLOCKS AVG_ROW_LEN                                               
---------- ---------- -----------                                               
   3310017      44538          84      
SQL> select distinct_keys,clustering_factor,num_rows from  USER_IND_STATISTICS WHERE table_name='AB44' and index_name='PK_AB44';
DISTINCT_KEYS CLUSTERING_FACTOR   NUM_ROWS                                      
------------- ----------------- ----------                                      
      3309447           3299907    3309447  
SQL> SELECT * FROM USER_HISTOGRAMS WHERE table_name='AB44';
略。。。。。。。。。。。。。。。。。。。。。。。。

查询到索引的统计信息的时候,发现索引的聚簇因子非常高,非常接近表的行数。重新分析表,依然如此。
修改聚簇因子后,查看执行计划,已经是索引扫描了。


begin
  dbms_stats.set_index_stats(ownname => 'NCSI',indname => 'PK_AB44',clstfct => '7800');
end;
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------
-------------
Plan hash value: 1618544176
---------------------------------------------------------------------------------------
| Id  | Operation                   | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |         | 10554 |   865K|   239   (1)| 00:00:03 |
|   1 |  TABLE ACCESS BY INDEX ROWID| AB44    | 10554 |   865K|   239   (1)| 00:00:03 |
|*  2 |   INDEX RANGE SCAN          | PK_AB44 | 10554 |       |    45   (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("AAE002"=201006)
已选择14行。

但是到这里并不能说一定是聚簇因子导致的,因为很可能是还有直方图的因素。查询列AAE002上的唯一值个数为420,而表的记录总数是330万,如果没有直方图的话,ORACLE评估返回的行数应该是3300000/420=7857条记录,按照这个记录量来看,返回的行数占表记录总数的0.2%.根据经验,应该也能使用到索引才对。
于是重新收集统计信息,取消直方图。查看执行计划,还是全表扫描。看来直方图在本例中所占影响因素较小,还是聚簇因子过大惹的祸。

暂时通过修改聚簇因子暂时改善了性能问题,晚上的时候,按照索引字段的顺序重新创建了表。
SQL>create table AB44_TEMP as select * from ab44 where 1=0;
SQL>INSERT /*+ append */INTO AB44_TEMP  SELECT * FROM AB44  ORDER BY AAE002, AAE003, AAB001, AAE140;
SQL>commit;
SQL>drop table ab44;
SQL>alter table ab44_temp rename to ab44;

重新创建索引,分析表。重建后的聚簇因子只有60197,远远小于之前的 3299907。查看执行计划,也对了。

SQL> explain plan for select * from ab44 where aae002=201006;
已解释。
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
-------------
Plan hash value: 2627288474
---------------------------------------------------------------------------------------------
| Id  | Operation                   | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |               | 10799 |   885K|   249   (1)| 00:00:03 |
|   1 |  TABLE ACCESS BY INDEX ROWID| AB44          | 10799 |   885K|   249   (1)| 00:00:03 |
|*  2 |   INDEX RANGE SCAN          | AB44_TEMP_IND | 10799 |       |    50   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("AAE002"=201006)
已选择14行。


而且为了验证本例确实是由于聚簇因子过大占了决定因素。我把重建后的表直方图取消掉,重新查询,每一个AAE002的值都是索引扫描了。而之前聚簇因子较大的无直方图的实验,还是全表扫描。进一步证明了本例聚簇因子的影响占了很大比例。
BEGIN
  DBMS_STATS.GATHER_TABLE_STATS(OWNNAME    => 'NCSI',
                                TABNAME    => 'AB44',
                                CASCADE    => TRUE,
                                METHOD_OPT => 'for ALL columns SIZE 1');
END;

SQL>EXPLAIN PLAN FOR SELECT * FROM ab44 WHERE aae002=201002;
SQL>EXPLAIN PLAN FOR SELECT * FROM ab44 WHERE aae002=201006;
SQL>EXPLAIN PLAN FOR SELECT * FROM ab44 WHERE aae002=198701;
SQL>EXPLAIN PLAN FOR SELECT * FROM ab44 WHERE aae002=199101;

SQL>EXPLAIN PLAN FOR SELECT * FROM ab44 WHERE aae002=199804;

  SQL> select object_name,operation,options from plan_table where id=2;
OBJECT_NAME          OPERATION                      OPTIONS
-------------------- ------------------------------ --------------------
AB44_TEMP_IND        INDEX                          RANGE SCAN
AB44_TEMP_IND        INDEX                          RANGE SCAN
AB44_TEMP_IND        INDEX                          RANGE SCAN
AB44_TEMP_IND        INDEX                          RANGE SCAN
AB44_TEMP_IND        INDEX                          RANGE SCAN




[ 本帖最后由 wei-xh 于 2010-6-26 14:42 编辑 ]
论坛徽章:
136
ITPUB年度最佳技术回答奖
日期:2010-06-12 13:17:14现代
日期:2013-10-02 14:53:59路虎
日期:2013-11-22 12:26:182014年新春福章
日期:2014-02-18 16:42:02马上有房
日期:2014-02-18 16:42:02马上有车
日期:2014-02-19 11:55:14马上有房
日期:2014-02-19 11:55:14马上有钱
日期:2014-02-19 11:55:14马上有对象
日期:2014-02-19 11:55:14马上加薪
日期:2014-02-19 11:55:14
发表于 2010-6-23 21:00 | 显示全部楼层
问题解决了,但是解决思路我不太认可,

1.你看看评估的行数为什么是10799,而不是500呢,如果评估的行数是500,你不改clustering_factor,一样解决
2.应该使用hint强制走索引,看看是否是不是table access by rowid导致成本大增
3.你随便改变表的顺序,太武断,可能对别的索引造成影响

终上所述,根本原因是行数没评估对,也就是选择性计算的有问题

使用道具 举报

回复
论坛徽章:
86
2015中国数据库技术大会纪念徽章
日期:2015-04-24 16:04:24马上有车
日期:2014-02-19 11:55:14马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11优秀写手
日期:2013-12-18 09:29:11日产
日期:2013-10-17 08:44:39马自达
日期:2013-08-26 16:28:022013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-23 16:55:51马上有房
日期:2014-02-19 11:55:14
发表于 2010-6-23 21:28 | 显示全部楼层
原帖由 wei-xh 于 2010-6-23 20:37 发表
SQL> select distinct_keys,clustering_factor,num_rows from  USER_IND_STATISTICS WHERE table_name='AB44' and index_name='PK_AB44';
DISTINCT_KEYS CLUSTERING_FACTOR   NUM_ROWS                                      
------------- ----------------- ----------                                      
      3309447           3299907    3309447  
SQL> SELECT * FROM USER_HISTOGRAMS WHERE table_name='AB44';
略。。。。。。。。。。。。。。。。。。。。。。。。

查询到索引的统计信息的时候,发现索引的聚簇因子非常高,甚至超过了表的行数。重新分析表,依然如此。
修改聚簇因子后,查看执行计划,已经是索引扫描了。


聚簇因子不可能超过表行数

使用道具 举报

回复
认证徽章
论坛徽章:
21
奔驰
日期:2013-08-06 15:23:05日产
日期:2013-08-07 22:56:38蜘蛛蛋
日期:2012-12-29 19:15:08奥迪
日期:2013-08-07 17:02:24数据库板块每日发贴之星
日期:2010-06-28 01:01:03奥迪
日期:2013-08-13 10:10:28本田
日期:2013-11-20 15:17:02优秀写手
日期:2013-12-18 09:29:08玉兔
日期:2014-03-04 16:47:17铁扇公主
日期:2012-02-21 15:02:40
发表于 2010-6-23 21:40 | 显示全部楼层
原帖由 棉花糖ONE 于 2010-6-23 21:00 发表
问题解决了,但是解决思路我不太认可,

1.你看看评估的行数为什么是10799,而不是500呢,如果评估的行数是500,你不改clustering_factor,一样解决
2.应该使用hint强制走索引,看看是否是不是table access by rowid导致成本大增
3.你随便改变表的顺序,太武断,可能对别的索引造成影响

终上所述,根本原因是行数没评估对,也就是选择性计算的有问题


对对对,说的有道理,当时忙着下班,没太认真看(虽然是正式环境,可没上线呢,要不也不敢马虎)。明天上班再研究研究。
至于改变表的顺序,这个是可以的,首先这个表上只有两个索引,除了这个外,还有一个我们应用程序架构需要的一个索引,用来做业务回退的,经办业务的时候不会用到。还有就是业务产生的数据也是按照这个顺序来排列的。

根据斑竹的意见,我觉得这个问题是有两个方面导致的:一个是ORACLE评估的行数过高了,二是由于聚簇因子过高了,几乎接近了表的行数。

[ 本帖最后由 wei-xh 于 2010-6-23 21:45 编辑 ]

使用道具 举报

回复
认证徽章
论坛徽章:
21
奔驰
日期:2013-08-06 15:23:05日产
日期:2013-08-07 22:56:38蜘蛛蛋
日期:2012-12-29 19:15:08奥迪
日期:2013-08-07 17:02:24数据库板块每日发贴之星
日期:2010-06-28 01:01:03奥迪
日期:2013-08-13 10:10:28本田
日期:2013-11-20 15:17:02优秀写手
日期:2013-12-18 09:29:08玉兔
日期:2014-03-04 16:47:17铁扇公主
日期:2012-02-21 15:02:40
发表于 2010-6-23 21:42 | 显示全部楼层

回复 #3 sundog315 的帖子

。。真是惭愧,还是一样的解释,着急着下班,打了个草稿,就提交了。明天再整理下。
应该是接近表的行数,已修改。

使用道具 举报

回复
认证徽章
论坛徽章:
21
奔驰
日期:2013-08-06 15:23:05日产
日期:2013-08-07 22:56:38蜘蛛蛋
日期:2012-12-29 19:15:08奥迪
日期:2013-08-07 17:02:24数据库板块每日发贴之星
日期:2010-06-28 01:01:03奥迪
日期:2013-08-13 10:10:28本田
日期:2013-11-20 15:17:02优秀写手
日期:2013-12-18 09:29:08玉兔
日期:2014-03-04 16:47:17铁扇公主
日期:2012-02-21 15:02:40
发表于 2010-6-24 10:22 | 显示全部楼层
原帖由 棉花糖ONE 于 2010-6-23 21:00 发表
问题解决了,但是解决思路我不太认可,

1.你看看评估的行数为什么是10799,而不是500呢,如果评估的行数是500,你不改clustering_factor,一样解决
2.应该使用hint强制走索引,看看是否是不是table access by rowid导致成本大增
3.你随便改变表的顺序,太武断,可能对别的索引造成影响

终上所述,根本原因是行数没评估对,也就是选择性计算的有问题


我试了如下几种方法,可是ORACLE评估出来的行数一直在1万以上。查询列AAE002上的唯一值个数为420,因此只能采用等高直方图,这种直方图本来就是可能会导致比较大误差的直方图。不过话倒是说回来,如果这个列是个数据分布均匀的列,CBO选择全表扫描还是说得过去的,那么这次的问题出了聚簇因子的问题,直方图的问题也是一个非常大的问题。
1)重新分析表,设置ESTIMATE_PERCENT为100,直方图的桶数收集选项设置为AUTO.
Plan hash value: 2627288474
---------------------------------------------------------------------------------------------
| Id  | Operation                   | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |               | 10796 |   885K|   195   (2)| 00:00:03 |
|   1 |  TABLE ACCESS BY INDEX ROWID| AB44          | 10796 |   885K|   195   (2)| 00:00:03 |
|*  2 |   INDEX RANGE SCAN          | AB44_TEMP_IND | 10796 |       |    48   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

ORACLE对查询列AAE002选择的桶数是176.
2)重新分析表,设置AAE002的桶数为200。
Plan hash value: 2627288474
---------------------------------------------------------------------------------------------
| Id  | Operation                   | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |               | 19291 |  1582K|   345   (1)| 00:00:05 |
|   1 |  TABLE ACCESS BY INDEX ROWID| AB44          | 19291 |  1582K|   345   (1)| 00:00:05 |
|*  2 |   INDEX RANGE SCAN          | AB44_TEMP_IND | 19291 |       |    84   (2)| 00:00:02 |
---------------------------------------------------------------------------------------------



看来加大桶数,只能导致评估变高。

3)减少桶数为100,重新分析表,并且刷新了共享池。
---------------------------------------------------------------------------------------------
| Id  | Operation                   | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |               | 19291 |  1582K|   345   (1)| 00:00:05 |
|   1 |  TABLE ACCESS BY INDEX ROWID| AB44          | 19291 |  1582K|   345   (1)| 00:00:05 |
|*  2 |   INDEX RANGE SCAN          | AB44_TEMP_IND | 19291 |       |    84   (2)| 00:00:02 |
---------------------------------------------------------------------------------------------


竟然跟步骤二的一样。





由于分析表采用的ESTIMATE_PERCENT是100,因此除直方图外,其他的统计信息都是定制,不存在变数。
我本来想通过调整直方图的桶数来观察评估的准确性,可是失败了。
分析表的语句类似如下:
BEGIN
  DBMS_STATS.GATHER_TABLE_STATS(OWNNAME          => 'NCSI',
                                TABNAME          => 'AB44',
                                ESTIMATE_PERCENT => 100,
                                METHOD_OPT       => 'FOR  COLUMNS aae002 SIZE 100',
                                CASCADE          => TRUE);
END;



对棉花斑竹问题二的回答,ORACLE确实评估全表扫描的代价小于索引的代价。
SQL>flashback table ab44 to before drop rename to ab44_temp;
闪回完成
已用时间:  00: 00: 00.00
SQL> explain plan for select /*+ index(ab44_temp pk_ab44_temp) */* from ab44_temp where aae002='2010
已解释。
已用时间:  00: 00: 00.00
SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
--------
Plan hash value: 1691704602

--------------------------------------------------------------------------------------------
| Id  | Operation                   | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |              | 10554 |   865K| 10584   (1)| 00:02:08 |
|   1 |  TABLE ACCESS BY INDEX ROWID| AB44_TEMP    | 10554 |   865K| 10584   (1)| 00:02:08 |
|*  2 |   INDEX RANGE SCAN          | PK_AB44_TEMP | 10554 |       |    45   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("AAE002"=201006)
已选择14行。
已用时间:  00: 00: 00.01
SQL> explain plan for select * from ab44_temp where aae002='201006';

已解释。
已用时间:  00: 00: 00.01
SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
--------
Plan hash value: 1730138233

-------------------------------------------------------------------------------
| Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |           | 10554 |   865K|  8777   (3)| 00:01:46 |
|*  1 |  TABLE ACCESS FULL| AB44_TEMP | 10554 |   865K|  8777   (3)| 00:01:46 |
-------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("AAE002"=201006)
已选择13行。
已用时间:  00: 00: 00.02

[ 本帖最后由 wei-xh 于 2010-6-25 17:23 编辑 ]

使用道具 举报

回复
论坛徽章:
311
行业板块每日发贴之星
日期:2012-07-12 18:47:29双黄蛋
日期:2011-08-12 17:31:04咸鸭蛋
日期:2011-08-18 15:13:51迷宫蛋
日期:2011-08-18 16:58:25紫蛋头
日期:2011-08-31 10:57:28ITPUB十周年纪念徽章
日期:2011-09-27 16:30:47蜘蛛蛋
日期:2011-10-20 15:51:25迷宫蛋
日期:2011-10-29 11:12:59ITPUB十周年纪念徽章
日期:2011-11-01 16:19:41鲜花蛋
日期:2011-11-09 20:33:30
发表于 2010-6-25 14:03 | 显示全部楼层
楼主,该索引有4个字段,你可以尝试只对该字段建索引,看看优化器的评估效果如何?

使用道具 举报

回复
认证徽章
论坛徽章:
21
奔驰
日期:2013-08-06 15:23:05日产
日期:2013-08-07 22:56:38蜘蛛蛋
日期:2012-12-29 19:15:08奥迪
日期:2013-08-07 17:02:24数据库板块每日发贴之星
日期:2010-06-28 01:01:03奥迪
日期:2013-08-13 10:10:28本田
日期:2013-11-20 15:17:02优秀写手
日期:2013-12-18 09:29:08玉兔
日期:2014-03-04 16:47:17铁扇公主
日期:2012-02-21 15:02:40
发表于 2010-6-25 14:16 | 显示全部楼层
原帖由 ZALBB 于 2010-6-25 14:03 发表
楼主,该索引有4个字段,你可以尝试只对该字段建索引,看看优化器的评估效果如何?


斑竹,只对该字段建立索引ORACLE选择了索引扫描。只不过觉得建立这样的索引有点浪费。

不过斑竹的话提示了我一点,组合索引的聚簇因子往往相对都比较高,特别是插入的顺序如果不是按照索引顺序来的时候。

使用道具 举报

回复
认证徽章
论坛徽章:
15
奥运会纪念徽章:击剑
日期:2008-07-17 14:58:53懒羊羊
日期:2015-03-04 14:52:11马上有房
日期:2014-02-18 16:42:022014年新春福章
日期:2014-02-18 16:42:02ITPUB 11周年纪念徽章
日期:2012-10-09 18:08:152012新春纪念徽章
日期:2012-01-04 11:53:54ITPUB十周年纪念徽章
日期:2011-11-01 16:23:262011新春纪念徽章
日期:2011-02-18 11:42:472011新春纪念徽章
日期:2011-01-04 10:35:17ITPUB9周年纪念徽章
日期:2010-10-08 09:34:01
发表于 2010-6-25 14:17 | 显示全部楼层
为什么不做个10053看一下细节?

使用道具 举报

回复
认证徽章
论坛徽章:
21
奔驰
日期:2013-08-06 15:23:05日产
日期:2013-08-07 22:56:38蜘蛛蛋
日期:2012-12-29 19:15:08奥迪
日期:2013-08-07 17:02:24数据库板块每日发贴之星
日期:2010-06-28 01:01:03奥迪
日期:2013-08-13 10:10:28本田
日期:2013-11-20 15:17:02优秀写手
日期:2013-12-18 09:29:08玉兔
日期:2014-03-04 16:47:17铁扇公主
日期:2012-02-21 15:02:40
发表于 2010-6-25 14:30 | 显示全部楼层
原帖由 lsq_008 于 2010-6-25 14:17 发表
为什么不做个10053看一下细节?


其实不用做10053了,通过HINT,查看两种执行计划的COST,ORACLE评估全表扫描比索引扫描代价更少。因此导致了全表扫描。



SQL> explain plan for select /*+ index(ab44_temp pk_ab44_temp) */* from ab44_temp where aae002='201006‘;
已解释。
已用时间:  00: 00: 00.00
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
--------
Plan hash value: 1691704602
--------------------------------------------------------------------------------------------
| Id  | Operation                   | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |              | 10554 |   865K| 10584   (1)| 00:02:08 |
|   1 |  TABLE ACCESS BY INDEX ROWID| AB44_TEMP    | 10554 |   865K| 10584   (1)| 00:02:08 |
|*  2 |   INDEX RANGE SCAN          | PK_AB44_TEMP | 10554 |       |    45   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("AAE002"=201006)
已选择14行。
已用时间:  00: 00: 00.01
SQL> explain plan for select * from ab44_temp where aae002='201006';
已解释。
已用时间:  00: 00: 00.01
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
--------
Plan hash value: 1730138233
-------------------------------------------------------------------------------
| Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |           | 10554 |   865K|  8777   (3)| 00:01:46 |
|*  1 |  TABLE ACCESS FULL| AB44_TEMP | 10554 |   865K|  8777   (3)| 00:01:46 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("AAE002"=201006)
已选择13行。
已用时间:  00: 00: 00.02


[ 本帖最后由 wei-xh 于 2010-6-25 14:36 编辑 ]

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表