我看原文以后的感想:1.不要使数据表数据过大2.建立适当的查询索引.
原文地址:http://blog.csdn.net/lunar2000/archive/2006/04/06/652263.aspx
原文如下:
接到报告说，某省数据库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