今天碰到一个开发人员反映SQL执行时间过长。根本无法得到结果集。
        看到服务器压力也没有很高，估计又是一个非常消耗磁盘的查询。果然，发现是一个200w的表和一个超过1100w表的HASH JOIN .
        简单的帮助优化了一个SQL后，SQL如下:
    
select    count(ui.usin_uid_fk)
    from table1 av, table2 ui
where av.av_usse_activatedate >= to_date('20090102', 'yyyymmdd')
     and av.av_usse_activatedate < to_date('20090401', 'yyyymmdd')
     and av.av_usse_uid_fk = ui.usin_uid_fk
     and ui.usin_mcnc_fk =XXX%'

       不难想象执行的不是很理想。近20分钟的执行时间，真是让人崩溃。

COUNT(UI.USIN_UID_FK)
---------------------
                            1918591

Elapsed: 00:19:03.07
Statistics
----------------------------------------------------------
                    0    recursive calls
                    0    db block gets
     32921639    consistent gets
         352073    physical reads
                    0    redo size
                395    bytes sent via SQL*Net to client
                503    bytes received via SQL*Net from client
                    2    SQL*Net roundtrips to/from client
                    0    sorts (memory)
                    0    sorts (disk)
                    1    rows processed

        对于那张TABLE2的大表（符合条件的超过1100w），决定试图通过并行来提高执行速度。SQL如下：

select /*+parallel (tbl_userinfo 4)*/ count(ui.usin_uid_fk)
from table1 av, table2 ui
where av.av_usse_activatedate >= to_date('20090101', 'yyyymmdd')
and av.av_usse_activatedate < to_date('20090401', 'yyyymmdd')
and av.av_usse_uid_fk = ui.usin_uid_fk
and ui.usin_mcnc_fk like 'XXX%';

      执行效果还是非常明显的。从19分钟多到1分45秒！其中consistent gets更是减少了一个数量级 -:)
    
COUNT(UI.USIN_UID_FK)
---------------------
                            1918591

Elapsed: 00:01:45.15

Statistics
----------------------------------------------------------
                    0    recursive calls
                    0    db block gets
        2571109    consistent gets
         124523    physical reads
                    0    redo size
                395    bytes sent via SQL*Net to client
                504    bytes received via SQL*Net from client
                    2    SQL*Net roundtrips to/from client
                    0    sorts (memory)
                    0    sorts (disk)
                    1    rows processed

   
      
      因为这个服务器为2×4核心的cpu，应该可以算是8个CPU，所以应该可以通过增加并行度来进一步减少执行时间。如下SQL：
    
SQL> select /*+parallel (tbl_userinfo 8)*/ count(ui.usin_uid_fk)
    2        from table1 av, table2 ui
    3     where av.av_usse_activatedate >= to_date('20090101', 'yyyymmdd')
    4         and av.av_usse_activatedate < to_date('20090401', 'yyyymmdd')
    5         and av.av_usse_uid_fk = ui.usin_uid_fk
    6         and ui.usin_mcnc_fk like '460%';

COUNT(UI.USIN_UID_FK)
---------------------
                            1949033

Elapsed: 00:00:20.60

Statistics
----------------------------------------------------------
                    0    recursive calls
                    0    db block gets
        2607524    consistent gets
            55050    physical reads
                    0    redo size
                395    bytes sent via SQL*Net to client
                503    bytes received via SQL*Net from client
                    2    SQL*Net roundtrips to/from client
                    0    sorts (memory)
                    0    sorts (disk)
                    1    rows processed

       可以说还是比较理想的。只有20S左右了。虽然最大并行度可以到CPU*2，但是效果未必会好。进一步做一个16个并行度的SQL执行测试。

     
COUNT(UI.USIN_UID_FK)
---------------------
                            1949033

Elapsed: 00:00:20.64

Statistics
----------------------------------------------------------
                    0    recursive calls
                    0    db block gets
        2607524    consistent gets
            55299    physical reads
                    0    redo size
                395    bytes sent via SQL*Net to client
                504    bytes received via SQL*Net from client
                    2    SQL*Net roundtrips to/from client
                    0    sorts (memory)
                    0    sorts (disk)
                    1    rows processed
     
       没有任何提高，并且执行时间还稍高于并行度为8的SQL。
       通过以上测试我们不难发现：
       在处理大量数据查询，例如出现HASH JOIN的情况下，并行查询非常有效果的。也就是说并行查询在数据仓库这样的应用中会“大显身手”。
        但是并行查询的使用还是有很多限制的。例如相对较小的数据查询和连接是会适得其反的。盲目增加并行度也是大忌，相对来讲，并行度和CPU数相同比较好。这里的CPU数应该是指的核心数。例如服务器中有一个CPU是4核心的，并行度为4是好的。
        技术很难有十全十美的，最重要的是对于特定技术的使用要恰到好处，保证扬长避短。 -:)
 ----------------------------
 以上测试环境：
ORACLE 9.2.0.4
RHEL 4 U4