CPU语句占用高解决一例

  查看主机CPU，发现只有10%的IDLE，高CPU进程的语句的基本为11个地区全扫描，存大较多的latch:cache buffers chains. 通过查看报告，发现这条语句1小时执行超过10万次，

SELECT   ps_id, action_id, ps_param, TO_CHAR (busi_code), TO_CHAR (stop_type),

         TO_CHAR (done_code), TO_CHAR (ps_type), TO_CHAR (prio_level),

         TO_CHAR (sort_id), TO_CHAR (sub_valid_date, 'yyyymmddhh24miss'),

         TO_CHAR (ps_service_type), bill_id, sub_bill_id,

         TO_CHAR (create_date, 'yyyymmddhh24miss'), TO_CHAR (retry_times),

         TO_CHAR (fail_num), fail_reason, TO_CHAR (op_id), TO_CHAR (sp_id),

         region_code, TO_CHAR (org_id), TO_CHAR (old_ps_id), ps_net_code,

         old_ps_param, target_param

    FROM ps_pro_split4

   WHERE ps_status = 0 AND ps_net_code = :f1

ORDER BY dead_line, prio_level DESC;

 

select  ps_status , ps_net_code,count(*) from  ps_pro_split4 group by   ps_status, ps_net_code order by count(*) desc;

 

PS_STATUS	PS_NET_CODE	COUNT(*)
0	GCSTATUS	35140
1	GCSTATUS	4000
1	SJB	43
1	LYH	16
0	CPSTATUS	3
0	SPMS	3
1	LSRX	3
1	VAC	3
1	NB6_HW	2
0	ZXWG	2
1	HYS	2
1	ZXWG	2
9	NB6_HW	1

 

 

与这个应用的开发交流后得知 每个对于上面的查询的每一列为条件查询次数基本相同，如果在这两个字段（PS_STATUS，PS_NET_CODE）建上联合索引的话，可以加快以下的查询:

1	SJB	43
1	LYH	16
0	CPSTATUS	3
0	SPMS	3
1	LSRX	3
1	VAC	3
1	NB6_HW	2
0	ZXWG	2
1	HYS	2
1	ZXWG	2
9	NB6_HW

 

 

但目前主要积压在GCSTATUS

的处理上，对于GCSTATUS来说使用表扫描效最高，目前由于ps_net_code 这个条件上用的在绑定变量，在SQL parse时bind peeking容易造成执行计划变化，建议这个字段不用绑定变量，并在两个字段建一个联合索引，让这个功能的语句每次执行时，进行一次hard parse会做一次bind peeking,可以避免发生SQL执行计划变化。

 

这个问题关建在于，这个表ps_pro_split4的ps_status ，ps_net_code  字段倾斜太历害，牵扯到bind peeking导致执行计划改变的问题，让应用开发将下面的语句在GCSTATUS这个功能ps_net_code = :f1改成不用绑定变量

SELECT   ps_id, action_id, ps_param, TO_CHAR (busi_code), TO_CHAR (stop_type),

         TO_CHAR (done_code), TO_CHAR (ps_type), TO_CHAR (prio_level),

         TO_CHAR (sort_id), TO_CHAR (sub_valid_date, 'yyyymmddhh24miss'),

         TO_CHAR (ps_service_type), bill_id, sub_bill_id,

         TO_CHAR (create_date, 'yyyymmddhh24miss'), TO_CHAR (retry_times),

         TO_CHAR (fail_num), fail_reason, TO_CHAR (op_id), TO_CHAR (sp_id),

         region_code, TO_CHAR (org_id), TO_CHAR (old_ps_id), ps_net_code,

         old_ps_param, target_param

    FROM ps_pro_split4

   WHERE ps_status = 0 AND ps_net_code = :f1

ORDER BY dead_line, prio_level DESC;

 

TO

 

SELECT   ps_id, action_id, ps_param, TO_CHAR (busi_code), TO_CHAR (stop_type),

         TO_CHAR (done_code), TO_CHAR (ps_type), TO_CHAR (prio_level),

         TO_CHAR (sort_id), TO_CHAR (sub_valid_date, 'yyyymmddhh24miss'),

         TO_CHAR (ps_service_type), bill_id, sub_bill_id,

         TO_CHAR (create_date, 'yyyymmddhh24miss'), TO_CHAR (retry_times),

         TO_CHAR (fail_num), fail_reason, TO_CHAR (op_id), TO_CHAR (sp_id),

         region_code, TO_CHAR (org_id), TO_CHAR (old_ps_id), ps_net_code,

         old_ps_param, target_param

    FROM ps_pro_split4

   WHERE ps_status = 0 AND ps_net_code = 'GCSTATUS'

ORDER BY dead_line, prio_level DESC;

 

再建上ps_status , ps_net_code这两个字段的联合索引，

 

CREATE INDEX P_ON ps_pro_split4(ps_status , ps_net_code)  online;

 

进行表分析并分析索引列的柱状图,

改完一个地市，发可以看到IDLE CPU回来5%,改完11个地区后CPU IDLE恢复为88%,问题得到解决。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10834762/viewspace-589228/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10834762/viewspace-589228/