对Hash Join的一次优化

rollingpig

实际上还有一个很明显的指标，就是CPU Time 与 buffer_gets 的比值明显高于普通的select操作。证明有异常的计算正在进行。

kkngisn

原帖由 rollingpig 于 2008-3-19 14:40 发表
实际上还有一个很明显的指标，就是CPU Time 与 buffer_gets 的比值明显高于普通的select操作。证明有异常的计算正在进行。

--------------------------------------------------------------------------
| Id  | Operation            |  Name        | Rows  | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |              |     2 |   174 |    18  (17)|
|   1 |  SORT UNIQUE         |              |     2 |   174 |    18  (17)|
|*  2 |   HASH JOIN          |              |     2 |   174 |    17  (12)|
|   3 |    TABLE ACCESS FULL | SMALL_TABLE  |  1879 | 48854 |    14   (8)|
|*  4 |    TABLE ACCESS FULL | BIG_TABLE    |     4 |   244 |     3  (34)|
--------------------------------------------------------------------------

   没有感觉CPU有多高。。。。。

rollingpig

不是看PLAN的cost , 看实际执行结果

anlinew

原帖由 adamyang 于 2008-3-19 14:29 发表


执行计划你不看access path？JOIN不看连接基数不看join key？

不过楼主结论都出来了，在说什么没意思了。

提醒大家处理一类问题的比较好的方式和顺序而已。

楼主先就没看，不然也不会费劲去dump。。。。

anlinew

原帖由 rollingpig 于 2008-3-19 14:40 发表
实际上还有一个很明显的指标，就是CPU Time 与 buffer_gets 的比值明显高于普通的select操作。证明有异常的计算正在进行。

然后凭经验直接判断问题出在or上，噼里啪啦一改sql，完事。。。。
不看什么access也无需dump，对咱们看客来说啥意思也没有，更别说精华了

blue_prince

靠，这是讨论技术问题还是讨论RPWT

anlinew

原帖由 blue_prince 于 2008-3-19 15:29 发表
靠，这是讨论技术问题还是讨论RPWT

建议DCBA想办法dump一下巴乔，看看到底有没有RPWT

eagle_fan

其实想到问题可能出在hash key的时候已经基本解决了，hash join trace因为常常用，所以很自然就想到了 （建议大家熟练掌握，还有10032,10033 sort trace）

在实际调优中，index scan有问题的很多（index scan的access,filter估计大家都会注意到的），hash key有问题的很少遇到，所以导致对hash join的filter信息不是很敏感

也许有人有问题，distinct value很少的build table很多啊，是不是都有这个问题呢？

答案是否定的

这个case独特的地方在于他还有另外一个join列from_cat，如果没有from_cat这个join列，这个hash join的性能是没有问题的

因为落在site_id=0这个bucket里面的行不需要来做from_cat上的filter，直接和链表头匹配成功就结束了，不需要扫描整个linked list

所以也不是说linked list很长就一定会有问题，明白了原理具体情况具体分析

OR也许不常见，更常见的SQL也许是像下面这种的：

[PHP]

SQL> explain plan for select /*+ use_hash(a,b) leading(b) */ a.id
  2  from big_table a,small_table b
  3  where a.site_id=b.site_id and a.category > b.from_cat
  4  ;

Explained.

SQL> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------
| Id  | Operation            |  Name        | Rows  | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |              |    94 |  6110 |    17  (12)|
|*  1 |  HASH JOIN           |              |    94 |  6110 |    17  (12)|
|   2 |   TABLE ACCESS FULL  | SMALL_TABLE  |  1879 | 48854 |    14   (8)|
|   3 |   TABLE ACCESS FULL  | BIG_TABLE    |    82 |  3198 |     3  (34)|
--------------------------------------------------------------------------

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

   1 - access(A.SITE_ID=B.SITE_ID)
       filter(A.CATEGORY>B.FROM_CAT)

15 rows selected.

[/PHP]

[ 本帖最后由 eagle_fan 于 2008-3-20 00:13 编辑 ]

eagle_fan

原帖由 rollingpig 于 2008-3-19 14:40 发表
实际上还有一个很明显的指标，就是CPU Time 与 buffer_gets 的比值明显高于普通的select操作。证明有异常的计算正在进行。

对于buffer_gets会高我持怀疑态度，因为这些动作发生在PGA里面，不一定会体现在buffer gets上

实际的sql中还有full(a) parallel(a,4) hint，如果你看v$session_wait，slave 进程的等待事件都是"PX Deq Credit: send blkd"

这些都是迷惑人的地方

rollingpig

正好相反，我说的是buffer_gets低，而CPU Time高（相对来说）