DB2中存储过程执行慢问题故障处理

转载 2012年03月22日 14:56:50

其实这个问题是以前同一个客户遇见的问题,当时一个工程师解决后记录的过程如下:

应用同事反映但是对应到执行存储过程,执行了2,3个小时了,还没出来结果。

存储过程主要是执行一条update sql语句,单独将语句拿出来,clp命令行执行很快,2-3s即可执行完成。
 
执行的SP:
call pdw.P_OCS_ACTIVE_UPDATE('20120304',?)
 
存储过程主要业务SQL:
 /***********************开始实现业务******************************/
   /*******/
SET vn_Step=1;--
call papp.p_debug(txdate,vn_PrcName,vn_Step,vv_sql); --
  UPDATE PODS.T_ODS_PAR_CUSTMSG a
  SET run_code='UU'
WHERE sm_code in ('o3','os','om','ol','ox') AND NOT EXISTS
  (SELECT * FROM PODS.T_ODS_PAR_OCSACTIVEMSG b where a.ID_NO=b.ID_NO );
 
COMMIT;--
 /************************结束业务逻辑******************************/
 
 
根据了解,这个存储过程有些时候了,最近无改动,以前都正常。
 
根据具体情况,第一反应是这个存储过程中语句的执行计划不正确了。静态sql的访问计划是在第一次编译后存储在数据库的包中的,之后运行都是使用包中的执行计划。解决办法很简单,对存储过程包重新绑定一下,使用最新的数据库统计信息生成最新的访问计划。
 
先查出此存储过程对应的包:
SELECT   bname,
         pkgname,
         BSCHEMA
FROM     syscat.packagedep
WHERE    btype='T'
AND      pkgname in(select bname from sysibm.sysdependencies where dname in (select specificname from syscat.procedures where procname='P_OCS_ACTIVE_UPDATE'
        AND PROCSCHEMA='PDW'))
[DWE3:/tmp]db2 "SELECT   bname,
>          pkgname,
>          BSCHEMA
> FROM     syscat.packagedep
> WHERE    btype='T'
> AND      pkgname in(select bname from sysibm.sysdependencies where dname in (select specificname from syscat.procedures where procname='P_OCS_ACTIVE_UPDATE'
>         AND PROCSCHEMA='PDW'))
> "
BNAME                         BSCHEMA    
--------------------------------------------------------------------------------
T_ODS_PAR_CUSTMSG             P8414315                             PODS                                
T_ODS_PAR_OCSACTIVEMSG        P8414315                             PODS                                                                                                                           
 2 record(s) selected.

对包执行rebind,操作前需连库
[DWE3:/tmp]time db2 rebind package pdw.P8414315
DB20000I  The REBIND PACKAGE command completed successfully.
real    0m0.63s
user    0m0.02s
sys     0m0.00s
 
对存储过程包重新绑定后,存储过程几秒钟即执行完成,恢复正常。
 
 
拿出sql单独执行计划:
[DWE3:/newdb2home/db2inst3/fengsh]more 2.out
DB2 Universal Database Version 9.1, 5622-044 (c) Copyright IBM Corp. 1991, 2006
Licensed Material - Program Property of IBM
IBM DB2 Universal Database SQL and XQUERY Explain Tool
******************** DYNAMIC ***************************************
==================== STATEMENT ==========================================
        Isolation Level          = Cursor Stability
        Blocking                 = Block Unambiguous Cursors
        Query Optimization Class = 5
        Partition Parallel       = Yes
        Intra-Partition Parallel = No
        SQL Path                 = "SYSIBM", "SYSFUN", "SYSPROC", "SYSIBMADM",
                                   "DB2INST3"

Statement:
 
  UPDATE PODS.T_ODS_PAR_CUSTMSG a SET run_code='UU'
  WHERE sm_code in ('o3' , 'os' , 'om' , 'ol' , 'ox' )AND NOT EXISTS
     (SELECT *
     FROM PODS.T_ODS_PAR_OCSACTIVEMSG b
     where a.ID_NO=b.ID_NO )

Section Code Page = 1386
Estimated Cost = 1512832.000000
Estimated Cardinality = 183703.968750
Coordinator Subsection - Main Processing:
   Distribute Subsection #1
   |  Broadcast to Node List
   |  |  Nodes = 1, 2, 3, 4, 5, 6, 7
Subsection #1:
   Access Table Name = PODS.T_ODS_PAR_OCSACTIVEMSG  ID = 11,3174
   |  #Columns = 1
   |  Skip Inserted Rows
   |  Skip Deleted Rows
   |  Relation Scan
   |  |  Prefetch: Eligible
   |  Lock Intents
   |  |  Table: Intent Share
   |  |  Row  : Next Key Share
   |  Sargable Predicate(s)
   |  |  Process Build Table for Hash Join
   Anti Left Outer Hash Join
   |  Early Out: Single Match Per Outer Row
   |  Estimated Build Size: 7584000
   |  Estimated Probe Size: 6960000
   |  Access Table Name = PODS.T_ODS_PAR_CUSTMSG  ID = 11,155
   |  |  #Columns = 3
   |  |  Skip Inserted Rows
   |  |  Skip Deleted Rows
   |  |  Evaluate Block/Data Predicates Before Locking Row
   |  |  Relation Scan
   |  |  |  Prefetch: Eligible
Isolation Level: Read Stability
   |  |  Lock Intents
   |  |  |  Table: Intent Exclusive
   |  |  |  Row  : Update
   |  |  Sargable Predicate(s)
   |  |  |  #Predicates = 1
   |  |  |  Process Probe Table for Hash Join
   Establish Row Position
   |  Access Table Name = PODS.T_ODS_PAR_CUSTMSG  ID = 11,155
   Update:  Table Name = PODS.T_ODS_PAR_CUSTMSG  ID = 11,155
End of section

Optimizer Plan:
                                                  UPDATE
                                                  (   2)
                                       /---------/      \
                                 FETCH                 Table:           
                                 (   3)                PODS             
                        /-------/      \               T_ODS_PAR_CUSTMSG
                  HSJOIN            Table:           
                  (   4)            PODS             
             /---/      \--\        T_ODS_PAR_CUSTMSG
       TBSCAN               TBSCAN
       (   5)               (   6)
         |                    |   
 Table:             Table:                
 PODS               PODS                  
 T_ODS_PAR_CUSTMSG  T_ODS_PAR_OCSACTIVEMSG
 
 
rebind后存储过程中此update语句执行计划:
db2expln -d newdssdb -g -c pdw -p P8414315 -s 0 -t>2.explain_rebind

-------------------- SECTION ---------------------------------------
Section = 8

Statement:
 
  UPDATE PODS.T_ODS_PAR_CUSTMSG A
         SET RUN_CODE='UU'
        WHERE
          SM_CODE in ('o3' , 'os' , 'om' , 'ol' , 'ox' )AND NOT
          EXISTS
        
     (SELECT *
     FROM PODS.T_ODS_PAR_OCSACTIVEMSG B
     where A.ID_NO=B.ID_NO )

Section Code Page = 1386
Estimated Cost = 1512832.000000
Estimated Cardinality = 183703.968750
Coordinator Subsection - Main Processing:
   Distribute Subsection #1
   |  Broadcast to Node List
   |  |  Nodes = 1, 2, 3, 4, 5, 6, 7
Subsection #1:
   Access Table Name = PODS.T_ODS_PAR_OCSACTIVEMSG  ID = 11,3174
   |  #Columns = 1
   |  Skip Inserted Rows
   |  Skip Deleted Rows
   |  Relation Scan
   |  |  Prefetch: Eligible
   |  Lock Intents
   |  |  Table: Intent Share
   |  |  Row  : Next Key Share
   |  Sargable Predicate(s)
   |  |  Process Build Table for Hash Join
   Anti Left Outer Hash Join
   |  Early Out: Single Match Per Outer Row
   |  Estimated Build Size: 7584000
   |  Estimated Probe Size: 6960000
   |  Access Table Name = PODS.T_ODS_PAR_CUSTMSG  ID = 11,155
   |  |  #Columns = 3
   |  |  Skip Inserted Rows
   |  |  Skip Deleted Rows
   |  |  Evaluate Block/Data Predicates Before Locking Row
   |  |  Relation Scan
   |  |  |  Prefetch: Eligible
Isolation Level: Read Stability
   |  |  Lock Intents
   |  |  |  Table: Intent Exclusive
   |  |  |  Row  : Update
   |  |  Sargable Predicate(s)
   |  |  |  #Predicates = 1
   |  |  |  Process Probe Table for Hash Join
   Establish Row Position
   |  Access Table Name = PODS.T_ODS_PAR_CUSTMSG  ID = 11,155
   Update:  Table Name = PODS.T_ODS_PAR_CUSTMSG  ID = 11,155
End of section

Optimizer Plan:
                                                  UPDATE
                                                  (   2)
                                       /---------/      \
                                 FETCH                 Table:           
                                 (   3)                PODS             
                        /-------/      \               T_ODS_PAR_CUSTMSG
                  HSJOIN            Table:           
                  (   4)            PODS             
             /---/      \--\        T_ODS_PAR_CUSTMSG
       TBSCAN               TBSCAN
       (   5)               (   6)
         |                    |   
 Table:             Table:                
 PODS               PODS                  

 T_ODS_PAR_CUSTMSG  T_ODS_PAR_OCSACTIVEMSG


原文转载自http://www.db2china.net/home/space.php?uid=1433&do=blog&id=13208


DB2中存储过程执行慢问题故障处理

其实这个问题是以前同一个客户遇见的问题,当时一个工程师解决后记录的过程如下: 应用同事反映但是对应到执行存储过程,执行了2,3个小时了,还没出来结果。 存储过程主要是执行一条update sq...
  • marvelyu
  • marvelyu
  • 2012年03月22日 14:56
  • 4116

DB2性能调优资料,解决SQL执行慢的问题

  • 2009年12月01日 16:15
  • 779KB
  • 下载

db2脚本、存储过程执行命令

db2脚本使用: db2 -td@ -vf (filename)进行编译      C:\Documents and Settings\Administrator>db2 list comman...
  • qiuyang0607
  • qiuyang0607
  • 2016年08月18日 16:54
  • 3418

DB2数据库之命令行执行存储过程(以@符结束)

DB2数据中会用到存储过程,有的时候不能用客户端,需要在命令行中执行;下面是以@为结束符的存储过程。   方法1: [db2inst1@DB ~]$ db2 connect to jf user db...
  • super712
  • super712
  • 2013年12月09日 11:21
  • 2479

db2 性能优化

性能优化概述 DB2 的性能优化可以从三个方面分析:内存,CPU 和 I/O 。DB2 性能优化是一件较为复杂的综合性的工作 , 需要对问题的根源作全方位的探索和思考。同时也需要较深厚的数据...
  • rjcs888
  • rjcs888
  • 2014年02月20日 23:24
  • 2257

谈谈DB2的db2fmp进程

说起这个db2fmp进程,百度,google上那可是铺天盖地的文章,总结起来,都是在讨论如下四个问题: db2fmp进程是什么为什么db2fmp占用了这么多内存为什么db2fmp占用了这么多CPU为...
  • neu_lcj77
  • neu_lcj77
  • 2017年05月04日 11:02
  • 1051

DB2数据库使用存储过程详解

存储过程(Stored Procedure)是在大型数据库系统中,一组为了完成特定功能的SQL 语句集,经编译后存储在数据库中,用户通过指定存储过程的名字并给出参数(如果该存储过程带有参数)来执行它。...
  • fanyun_01
  • fanyun_01
  • 2016年11月30日 09:16
  • 8068

客户端直接执行存储过程正常但代码调用慢的问题

JAVA调用SQL后台存储过程时,有时突然就变得很慢,在后台直接执行存储过程没问题,但在前台调用存储过程时就是很慢,而且在前台调用成功后,再次调用还是一样的慢,但更新一下存储过程再调用就很快了。但这始...
  • qiao0078
  • qiao0078
  • 2016年11月24日 17:36
  • 1563

[PL/SQL] oracle sql语句 存储过程执行慢,单独执行快

1、执行计划情况 当存储过程挂住的时候,看看V$SESSION里面的 SQL_ID, SQL_CHILD_NUMBER 再根据这两个信息用DBMS_XPLAN.DISPLAY_CURSOR把计划拿出来...
  • sun120204535
  • sun120204535
  • 2017年10月24日 18:31
  • 164

存储过程

存储过程简介 什么是存储过程:存储过程可以说是一个记录集吧,它是由一些T-SQL语句组成的代码块,这些T-SQL语句代码像一个方法一样实现一些功能(对单表或多表的增删改查),然后再给这个代码...
  • qq_41140694
  • qq_41140694
  • 2018年02月07日 14:08
  • 6
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:DB2中存储过程执行慢问题故障处理
举报原因:
原因补充:

(最多只允许输入30个字)