接到报告说,某省数据库CPU长时间负载很高,很多时候还经常是cpu idle值为各位数,甚至经常为<5 的各位数,于是赶紧登陆检查,发现主要的瓶颈是WAIT IO,初步判断是和业务中的SQL语句有关的问题造成的。
HP-UX db01 B.11.11 U 9000/800 02/14/06
09:40:17 %usr %sys %wio %idle
09:40:19 13 3 72 11
09:40:21 10 2 80 8
09:40:23 9 3 71 16
09:40:25 11 3 71 16
09:40:27 12 3 74 12
Average 11 3 74 13
依据STATSPACK和一些维护经验,作出了如下调整策略:
1, 一个业务历史大表,已经将近40G多,有史以来的历史数据全部在线。
修改策略,将改表重建为时间分区表,按月份存放,并建立相应的local index
注:
由于日常对于这个表的操作都是insert,只有在授理投诉的时候会这个表来查找历史数据,因此这个表的影响几乎从未在STATSAPCK中体现过。
影响:这个调整使得wio降低了25%左右
2, 根据statspack报告:
CPU Elapsd
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
2,996,669 86 34,845.0 26.6 168.34 1363.19 1482568540
Module: JDBC Thin Client
select count(*) from operation_log where 0=0 and OPR_TIME>=to_da
te('2006-03-14','yyyy-mm-dd') and OPR_TIME<=to_date('2006-03-14'
,'yyyy-mm-dd')+1
可以看到这个语句的执行计划:
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | |
| 1 | SORT AGGREGATE | | | | |
|* 2 | TABLE ACCESS FULL | OPERATION_LOG | | | |
-----------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("OPERATION_LOG"."OPR_TIME"<=TO_DATE('2006-03-15
00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND
"OPERATION_LOG"."OPR_TIME">=TO_DATE('2006-03-14 00:00:00', 'yyyy-mm-dd
hh24:mi:ss'))
俨然一个权标扫描,还是没有RBO的!!
检查发现这个表 322M,2074560行数据,只有一个主键索引:
INDEX_NAME
------------------------
PK_OPERATION_LOG
于是给它添加基于OPR_TIME字段的索引。
SQL> select COLUMN_NAME from dba_ind_columns where table_name = 'OPERATION_LOG'
2 and index_name='IDX_OPERLOG_TIME';
COLUMN_NAME
-------------------------------------------------------
OPR_TIME
SQL>
修改后的执行计划:
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 7 | 37 |
| 1 | SORT AGGREGATE | | 1 | 7 | |
|* 2 | INDEX RANGE SCAN | IDX_OPERLOG_TIME | 13038 | 91266 | 37 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("OPERATION_LOG"."OPR_TIME">=TO_DATE('2006-03-14 00:00:00',
'yyyy-mm-dd hh24:mi:ss') AND "OPERATION_LOG"."OPR_TIME"<=TO_DATE('2006-03-
15 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))
现在执行一次这个语句的时间:
SQL> l
1 SELECT COUNT (*)
2 FROM OPERATION_LOG
3 WHERE 0 = 0
4 AND opr_time >= TO_DATE ('2006-03-14', 'yyyy-mm-dd')
5* AND opr_time <= TO_DATE ('2006-03-14', 'yyyy-mm-dd') + 1
SQL> /
COUNT(*)
----------
11617
Elapsed: 00:00:00.01
SQL>
3, 根据statspack报告,发现BOSSCHARGEINFO 表有1995188行,
CPU Elapsd
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
916,933 30 30,564.4 26.7 102.74 654.58 2412605967
Module: XXXXXXX (TNS V1-V3)
select MID ,SERVID ,ACCESSMODEID ,SERVICEGRADEID ,STATUS ,FEEMON
TH ,to_char(chargedate,'YYYYMMDDHH24MISS') from BOSSCHARGEINFO
where (status=4 and feemonth=:b0)
问题的现象和处理方法通问题2一样,这里是添加基于status和feemonth的联合索引。
修改后,该语句效率提高了一倍多(请注意改语句基本上每分钟执行一次,因此,总体效率的提高更为显著)。
4,
CPU Elapsd
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
427,455 20 21,372.8 12.5 50.18 215.02 1608726146
Module: XXXXXXX (TNS V1-V3)
SELECT MID,SERVID,ACCESSMODEID, SERVICEGRADEID,STATUS,FEEMONTH,
to_char(chargedate,'YYYYMMDDHH24MISS') FROM DELAYCHARG
EINFO WHERE status = 4 and feemonth =
'200603'
问题的现象和处理方法通问题3一样,这里是添加基于status和feemonth的联合索引。
修改后,该语句效率提高了一倍多(请注意改语句基本上每分钟执行一次,因此,总体效率的提高更为显著)。
调整后的状态:
HP-UX db01 B.11.11 U 9000/800 04/05/06
15:45:16 %usr %sys %wio %idle
15:45:18 25 3 30 42
15:45:20 21 4 35 40
15:45:22 24 5 24 47
15:45:24 23 5 27 46
15:45:26 23 3 31 43
Average 23 4 30 44
来源:博远电子(软件定制),如涉及版权问题请与我们联系。
TAG
软件定制,软件开发,瀚森HANSEN,辽宁,沈阳,抚顺