今天碰到一个开发人员反映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