Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
Oracle数据库数据恢复、性能优化»论坛 › Oracle › Oracle数据库管理 › 关于全表扫描的问题
发新帖
张沛

0

积分

1

好友

29

主题

[RAC性能调优] 关于全表扫描的问题

1#
发表于 2013-1-16 09:30:03 | 查看: 3996| 回复: 5
原始语句
SELECT SUM(nvl(rcl.amount, 0)) amount, ooh.sold_to_org_id customer_id

FROM oe_order_headers_all   ooh,oe_order_lines_all     ool,  ra_interface_lines_all rcl

WHERE ooh.header_id = ool.header_id
           AND ool.open_flag = 'N'
           AND ool.line_id = rcl.interface_line_attribute6
           AND ooh.org_id in (103, 104)
  GROUP BY ooh.sold_to_org_id
执行计划
1         
2        --------------------------------------------------------------------------------------------
3        | Id  | Operation            | Name                         | Rows  | Bytes |TempSpc| Cost (%CPU)|
4        --------------------------------------------------------------------------------------------
5        |   0 | SELECT STATEMENT     |                        | 16480 |   627K|       | 46479   (2)|
6        |   1 |  HASH GROUP BY       |                        | 16480 |   627K|       | 46479   (2)|
7        |*  2 |   HASH JOIN          |                            |   148K|  5649K|  5360K| 46467   (2)|
8        |*  3 |    HASH JOIN         |                            |   148K|  3621K|  3480K| 38877   (2)|
9        |   4 |       TABLE ACCESS FULL| RA_INTERFACE_LINES_ALL |   148K|  1738K|       |  4411   (1)|
10        |*  5 |      TABLE ACCESS FULL| OE_ORDER_LINES_ALL     |   940K|    11M|       | 33164   (2)|
11        |*  6 |    TABLE ACCESS FULL | OE_ORDER_HEADERS_ALL   |   253K|  3459K|       |  7010   (1)|
12        --------------------------------------------------------------------------------------------
13         
14        Predicate Information (identified by operation id):
15        ---------------------------------------------------
16         
17           2 - access("OOH"."HEADER_ID"="OOL"."HEADER_ID")
18           3 - access("OOL"."LINE_ID"=TO_NUMBER("RCL"."INTERFACE_LINE_ATTRIBUTE6"))
19           5 - filter("OOL"."OPEN_FLAG"='N')
20           6 - filter("OOH"."ORG_ID"=103 OR "OOH"."ORG_ID"=104)
21         
22        Note
23        -----
24           - 'PLAN_TABLE' is old version
我的问题是：
关于第5步中的OPEN_FLAG"='N'造成了全表扫描，我的oe_order_lines_all     ool这张表约96万行数据，
SELECT COUNT(*) FROM (SELECT open_flag FROM oe_order_lines_all WHERE open_flag = 'N')返回94万行数据，确实是通过全表要比索引要好
但是问题是：这么一条设计百万行左右的语句要耗费半分钟左右才能返回结果，有没有办法通过修改语句或者访问路径能让他快一点的方法
注：
select * from v$version;
1        Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
2        PL/SQL Release 10.2.0.3.0 - Production
3        CORE        10.2.0.3.0        Production
4        TNS for IBM/AIX RISC System/6000: Version 10.2.0.3.0 - Productio
5        NLSRTL Version 10.2.0.3.0 - Production
2#
发表于 2013-1-16 10:00:05
补充一条OE_ORDER_HEADERS_ALL表共38万行左右数据
select count(*) from OE_ORDER_HEADERS_ALL   where org_id in (103, 104)返回24万行数据

回复 只看该作者 道具 举报

3#
发表于 2013-1-16 10:02:18
系统是OLAP还是OLTP系统？   如果是OLAP系统可以考虑给OPEN_FLAG加BITMAP INDEX

回复 只看该作者 道具 举报

4#
发表于 2013-1-16 10:07:14
wshxgxiaoli 发表于 2013-1-16 10:02
系统是OLAP还是OLTP系统？   如果是OLAP系统可以考虑给OPEN_FLAG加BITMAP INDEX

OLAP
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
对open_flag列加位图索引么？

回复 只看该作者 道具 举报

5#
发表于 2013-1-16 10:36:06
我刚刚对这个情况做了个小测试， 测试如下：
  1. SQL> create table testbit(id number(9));

  3. Table created.


  6. SQL> declare
  7.   2  i number(9);
  8.   3  begin
  9.   4     for i in 1..1000000 loop
  10.   5  insert into testbit values(i);
  11.   6  end loop;
  12.   7  end;
  13.   8  /

  15. PL/SQL procedure successfully completed.


  18. SQL> update testbit set id=9 where id<1000000;

  20. 999999 rows updated.

  22. SQL> commit;

  24. Commit complete.



  28. SQL> exec dbms_stats.gather_table_stats('SYS','TESTBIT');

  30. PL/SQL procedure successfully completed.

  32. SQL> set autotrace traceonly            
  33. SQL> create index idx_testbit on testbit(id);

  35. Index created.


  38. SQL> exec dbms_stats.gather_index_stats('SYS','IDX_TESTBIT');

  40. PL/SQL procedure successfully completed.

  42. SQL> set autotrace traceonly


  45. 10:25:43 SQL> select id from testbit where id=9;


  48. 999999 rows selected.


  51. Execution Plan
  52. ----------------------------------------------------------
  53. Plan hash value: 1663158793

  55. -----------------------------------------------------------------------------
  56. | Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
  57. -----------------------------------------------------------------------------
  58. |   0 | SELECT STATEMENT  |         |   500K|  1464K|   420   (2)| 00:00:06 |
  59. |*  1 |  TABLE ACCESS FULL| TESTBIT |   500K|  1464K|   420   (2)| 00:00:06 |
  60. -----------------------------------------------------------------------------

  62. Predicate Information (identified by operation id):
  63. ---------------------------------------------------

  65.    1 - filter("ID"=9)


  68. Statistics
  69. ----------------------------------------------------------
  70.           0  recursive calls
  71.           0  db block gets
  72.       68188  consistent gets
  73.           0  physical reads
  74.           0  redo size
  75.    17200437  bytes sent via SQL*Net to client
  76.      733850  bytes received via SQL*Net from client
  77.       66668  SQL*Net roundtrips to/from client
  78.           0  sorts (memory)
  79.           0  sorts (disk)
  80.      999999  rows processed

  82. 10:28:48 SQL> create bitmap index testbit_idx on testbit(id);

  84. Index created.

  86. 10:30:47 SQL> exec dbms_stats.gather_index_stats('SYS','TESTBIT_IDX');

  88. PL/SQL procedure successfully completed.

  90. 10:31:15 SQL> set autotrace traceonly
  91. 10:31:26 SQL> select id from testbit where id=9;

  93. 999999 rows selected.


  96. Execution Plan
  97. ----------------------------------------------------------
  98. Plan hash value: 3687339562

  100. --------------------------------------------------------------------------------
  101. -----------

  103. | Id  | Operation                   | Name        | Rows  | Bytes | Cost (%CPU)|
  104. Time     |

  106. --------------------------------------------------------------------------------
  107. -----------

  109. |   0 | SELECT STATEMENT            |             |   500K|  1464K|    11   (0)|
  110. 00:00:01 |

  112. |   1 |  BITMAP CONVERSION TO ROWIDS|             |   500K|  1464K|    11   (0)|
  113. 00:00:01 |

  115. |*  2 |   BITMAP INDEX SINGLE VALUE | TESTBIT_IDX |       |       |            |
  116.           |

  118. --------------------------------------------------------------------------------
  119. -----------


  122. Predicate Information (identified by operation id):
  123. ---------------------------------------------------

  125.    2 - access("ID"=9)


  128. Statistics
  129. ----------------------------------------------------------
  130.           8  recursive calls
  131.           0  db block gets
  132.          59  consistent gets
  133.           0  physical reads
  134.           0  redo size
  135.    17200437  bytes sent via SQL*Net to client
  136.      733850  bytes received via SQL*Net from client
  137.       66668  SQL*Net roundtrips to/from client
  138.           4  sorts (memory)
  139.           0  sorts (disk)
  140.      999999  rows processed
  141. 10:31:44 SQL>
复制代码
可以看到用BTREE和BITMAP的区别， BITMAP索引处理OLAP系统中的索引中重复值过多的情况相当有效！

回复 只看该作者 道具 举报

6#
发表于 2013-1-16 10:38:36
wshxgxiaoli 发表于 2013-1-16 10:36
我刚刚对这个情况做了个小测试， 测试如下：可以看到用BTREE和BITMAP的区别， BITMAP索引处理OLAP系统中的 ...

太感谢了，做的太透彻了

回复 只看该作者 道具 举报

返回列表
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-6-1 22:26 , Processed in 0.050317 second(s), 20 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569