继昨天使用DB time能够快速灵活的定位sql语句之后，发现分析问题更快捷，高效了。今天就牛刀小试，把一个数据库从500%的负载调到不到100%的负载。前提是确实有可提升可改进的空间。
ZABBIX-监控系统: 5
对于OLAP目前设定的阀值是500%,相对来说是一个较高的阀值了。来分析一下看看是否由于sql的影响较大。8tmf11fvxy09j这个语句。这个语句一个快照时间范围内执行了近30次，每次执行大概是80秒左右。发现这个语句是一个看似简单的查询。SQL Plan Monitoring Details (Plan Hash Value=2129377450)
| Id | Operation | Name | Estimated | Cost | Execs | Rows | |
| Rows | |||||||
| . | 0 | SELECT STATEMENT | . | . | . | 1 | . |
| . | 1 | . SORT AGGREGATE | . | 1 | 13 | 1 | . |
| -> | 2 | .. HASH GROUP BY | . | 1 | 13 | 1 | 0 |
| -> | 3 | ... PARTITION RANGE ITERATOR | . | 1 | 12 | 1 | 3 |
| -> | 4 | .... TABLE ACCESS BY LOCAL INDEX ROWID | TES_BILLDETAIL | 1 | 12 | 5 | 3 |
| -> | 5 | ..... INDEX RANGE SCAN | IND_TES_BILLDETAIL _END_TIME |
49 | 1 | 5 | 9M |
绑定变量值也能抓取到。
| Name | Position | Type | Value |
|---|---|---|---|
| :1 | 1 | VARCHAR2(128) | 582891946 |
带着疑问查看了下数据的情况，发现使用字段CN来过滤，只有1000多条记录，相比通过时间来过滤的900多万记录来说差别实在是太大了。EXPLAIN PLAN FOR SELECT /*+INDEX(TES_BILLDETAIL IND_TES_BILLDETAIL_CN)*/ROUND(AVG(SUM(END_TIME-START_TIME)*1440)) AVG FROM TES_BILLDETAIL WHERE END_TIME > TRUNC(SYSDATE - 30) AND CN = :1 GROUP BY TRUNC(END_TIME) 发现索引能够正常启用，而且cost也不高，就按照这个方子来试试。9h0kr4s3365mt就是我们努力的目标，使用提供的脚本来得到执行计划的profile信息。输入sql_id和hash_value即可。
逻辑读的效果更加明显。