oracle并行查询一列的实现

在oracle数据库中碰到SQL执行时间过长。根本无法得到结果集的问题。服务器压力也没有很高,估计又是一个非常消耗磁盘的查询。通过oracle并行查询一列的方法,解决了这个问题。

果然,发现是一个200w的表和一个超过1100w表的HASH JOIN .
简单的帮助优化了一个SQL后,SQL如下:

  1.     select     count(ui.usin_uid_fk)  
  2.      from table1 av, table2 ui  
  3. where av.av_usse_activatedate >= to_date('20090102', '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 =XXX%' 

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

  1. COUNT(UI.USIN_UID_FK)  
  2. ---------------------  
  3.  1918591  
  4.  
  5. Elapsed: 00:19:03.07  
  6. Statistics  
  7. ----------------------------------------------------------  
  8. 0     recursive calls  
  9. 0     db block gets  
  10.      32921639     consistent gets  
  11.   352073     physical reads  
  12. 0     redo size  
  13.    395     bytes sent via SQL*Net to client  
  14.    503     bytes received via SQL*Net from client  
  15. 2     SQL*Net roundtrips to/from client  
  16. 0     sorts (memory)  
  17. 0     sorts (disk)  
  18. 1     rows processed  

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

  1. select /*+parallel (tbl_userinfo 4)*/ 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 'XXX%'; 

执行效果还是非常明显的。从19分钟多到1分45秒!其中consistent gets更是减少了一个数量级。
    

  1.  COUNT(UI.USIN_UID_FK)  
  2. ---------------------  
  3.  1918591  
  4.  
  5. Elapsed: 00:01:45.15  
  6.  
  7. Statistics  
  8. ----------------------------------------------------------  
  9. 0     recursive calls  
  10. 0     db block gets  
  11.  2571109     consistent gets  
  12.   124523     physical reads  
  13. 0     redo size  
  14.    395     bytes sent via SQL*Net to client  
  15.    504     bytes received via SQL*Net from client  
  16. 2     SQL*Net roundtrips to/from client  
  17. 0     sorts (memory)  
  18. 0     sorts (disk)  
  19. 1     rows processed  

因为这个服务器为2×4核心的cpu,应该可以算是8个CPU,所以应该可以通过增加并行度来进一步减少执行时间。如下SQL:

  1.     SQL> select /*+parallel (tbl_userinfo 8)*/ count(ui.usin_uid_fk)  
  2.      2  from table1 av, table2 ui  
  3.      3     where av.av_usse_activatedate >= to_date('20090101', 'yyyymmdd')  
  4.      4  and av.av_usse_activatedate < to_date('20090401', 'yyyymmdd')  
  5.      5  and av.av_usse_uid_fk = ui.usin_uid_fk  
  6.      6  and ui.usin_mcnc_fk like '460%';  
  7.  
  8. COUNT(UI.USIN_UID_FK)  
  9. ---------------------  
  10.  1949033  
  11.  
  12. Elapsed: 00:00:20.60  
  13.  
  14. Statistics  
  15. ----------------------------------------------------------  
  16. 0     recursive calls  
  17. 0     db block gets  
  18.   2607524     consistent gets  
  19.       55050     physical reads  
  20. 0     redo size  
  21.    395     bytes sent via SQL*Net to client  
  22.    503     bytes received via SQL*Net from client  
  23. 2     SQL*Net roundtrips to/from client  
  24. 0     sorts (memory)  
  25. 0     sorts (disk)  
  26. 1     rows processed  

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

  1.       COUNT(UI.USIN_UID_FK)  
  2. ---------------------  
  3.  1949033  
  4.  
  5. Elapsed: 00:00:20.64  
  6.  
  7. Statistics  
  8. ----------------------------------------------------------  
  9. 0     recursive calls  
  10. 0     db block gets  
  11.  2607524     consistent gets  
  12.       55299     physical reads  
  13. 0     redo size  
  14.    395     bytes sent via SQL*Net to client  
  15.    504     bytes received via SQL*Net from client  
  16. 2     SQL*Net roundtrips to/from client  
  17. 0     sorts (memory)  
  18. 0     sorts (disk)  
  19. 1     rows processed        
  20.  

没有任何提高,并且执行时间还稍高于并行度为8的SQL。

通过以上测试我们不难发现:

在处理大量数据查询,例如出现HASH JOIN的情况下,oracle并行非常有效果的。也就是说并行查询在数据仓库这样的应用中会“大显身手”。

但是oracle并行的使用还是有很多限制的。例如相对较小的数据查询和连接是会适得其反的。盲目增加并行度也是大忌,相对来讲,并行度和CPU数相同比较好。这里的CPU数应该是指的核心数。例如服务器中有一个CPU是4核心的,并行度为4是好的。

技术很难有十全十美的,最重要的是对于特定技术的使用要恰到好处,保证扬长避短。
 

 

 

 

【编辑推荐】

ORACLE ROWNUM语句的使用

Oracle索引的类型

创建Oracle索引的方法

C#连接Oracle数据库查询数据

使用oracle存储过程分页的实例

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/289615.html<

(0)
管理的头像管理
上一篇2025-05-16 21:10
下一篇 2025-05-16 21:12

相关推荐

  • 站群服务器如何批量管理更高效,有哪些管理技巧?

    站群服务器批量管理想提效,自动化是唯一出路,通过统一配置管理工具与面板系统,结合服务商提供的底层基础设施支持,能将运维效率提升数倍,批量管理的核心痛点与解决思路多台站群服务器分散管理,最常见的问题就是重复劳动,每次软件更新、配置修改、安全加固,都需要逐台登录操作,不仅耗时,还容易漏掉某台机器,更头疼的是,一旦某……

    2026-07-27
    0
  • 服务器磁盘IO过高如何优化?,磁盘IO过高的原因有哪些?

    服务器磁盘IO过高,核心优化路径是“先定位、再分流、后升级”,你需要通过系统工具精确判断究竟是应用程序、日志策略还是硬件瓶颈导致,然后针对性地从代码、缓存、存储架构和硬件选型四个层面下手,其中选择持有持牌自营机房和增值电信业务经营许可证的服务商,能从根本上保障底层IO稳定性,定位IO瓶颈:动手优化的第一步盲目优……

    2026-07-27
    0
  • 跨境网站访问延迟高怎么解决,网站访问慢的原因是什么?

    跨境网站访问延迟高的核心解决思路在于多维度优化网络路径,包括使用全球CDN加速、选择靠近目标区域的优质IDC机房、调整传输协议以及精简应用层资源,其中服务商的基础设施质量直接决定优化上限,为什么跨境访问延迟高?三大核心因素物理距离与光速限制数据包在海底光缆中的传输速度受限于介质,从中国到美国西海岸的物理往返时间……

    2026-07-27
    0
  • 站群服务器到底是什么意思,怎么选择比较好

    站群服务器就是一台拥有多个独立IP地址、专门用于托管和管理多个网站的高性能服务器,其核心价值在于通过独立IP降低网站间的关联风险,并提升搜索引擎优化效果,站群服务器的工作原理与适用场景站群服务器本质上是将一台物理服务器通过虚拟化或直接配置的方式,分配给多个独立IP地址,每个IP对应一个独立的网站,这些网站共享服……

    2026-07-27
    0
  • 高防服务器误封正常流量如何调整,怎么解决?

    高防服务器误封正常流量,核心调整思路是从“一刀切”转向“精细化”——通过分析业务特征,调整防护阈值、配置白名单和启用智能学习模式,让防护系统学会区分真假流量,为什么会误封正常流量误封主要源于防护策略的通用化,高防服务器通常默认启用严格防护规则,当流量特征与攻击特征库部分匹配时,就会被拦截,据行业安全白皮书指出……

    2026-07-27
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注