安图特收到某银行客户提出的优化需求，希望进行一次数据库性能优化。该数据库每晚都要进行跑批操作，每次执行需花上整晚时间。客户希望可以对整个跑批操作进行分解，并分析出可以优化的部分，进行改进缩短跑批时间。　　

安图特团队在收到客户的请求后首先进行了详细的分析，并编写了性能分析及解决方案，经客户同意后正式申请变更，最终此方案达到了客户预期的优化效果，得到了客户的好评。

方案介绍

操作系统版本：红旗AX3 SP4

数据库版本：Oracle 10g RAC 10.2.0.4

1、首先粗略的查了一下晚上的awr报告，发现有条sql语句访问频繁，随机挑选了一个绑定变量值测试了一下，发现时间基本都在2分钟以上，但数据返回只有一行。Sql如下：select recv into :b0 from tb_msg where (type='0' and substr(recv,1,45)=:b1);查看该条sql语句的执行计划，发现走的是全表扫描，并且该表上没有任何索引。Tb_msg表大小为3个多G，数据量大约500w行，执行计划如下：

尝试建立索引，分别测试了substr(revc,1,45)的函数索引，以及recv，type的组合索引和type，recv的组合索引。最后发现函数索引的执行时间更短，不到1秒就执行完毕，执行计划如下：

２、在进一步与应用沟通后可以确认跑批期间也有大量业务及备份在跑；同时可以确认跑批执行在第一节点，并且是由ap2这台服务器发起的，因此通过ash，对ap2这台服务器进行跟踪，但由于模块众多，应用人员只是从前台点击开始执行跑批，因此并不能完全确认具体模块，但对比白天与夜晚的业务模块，以及部分模块的出现和消失时间，基本可以判断bj开头的模块与日终有关，因此通过ASH对bj开头的模块进行抓取分析。并抓取到如下sql语句：select sq , dt , tm , id ,at , msg1 from v_ log where　((((dt>=:b0 and dt<=:b1) and id=:b2) and cd in ('811015')) and stat_cd in ('011'))执行计划如下：

该语句返回的数据量为700w，v_log是个视图，查看定义发现是对tb_log,tb_log_hist两张表进行了union all操作，这两张表分别3个G和100个G。两张表都为分区表，根据表名可以推断为日志表和历史表，并且根据整晚的跟踪，可以发现业务逻辑为把tb_log对应日期的部分插入到tb_log_hist中，并删除原表对应分区内容。上面的查询在手工查询后，发现执行时间超过2小时，同时对比多天发现执行时间有超过3小时的情况，时间过久。查询表对应索引，发现执行计划里调用的索引为复合索引，对应字段为DT和SQ，而查询字段只涉及到DT，执行计划里走的是INDEX RANGE SCAN，为单块读，效率不高。两张表的分区列都是DT，range分区，范围为一天。因dt取值为一个月，而表是按照天来分区，这样导致索引查询后回表的数据量要达到几十万至几百万条，因此采用全扫的方式改写，尝试重新执行：select /*+full(a.tb_log) full(a.tb_log_hist) */ count(1) from v_log a where (((dt>='20141101' and dt<='20141130') and cd in ('811015')) and stat_cd in ('011'));执行计划如下：

时间从原先的2小时59分，缩短到25分钟，程序效率大大提升。由此可以看出，统计信息的收集准确与否，对程序性能影响巨大。后续我们通过定制合理的数据库统计信息收集策略，保障了客户的业务程序性能的长期高效。 

如欲了解更多，请登录安图特官方网站:www.antute.com.cn