数据库应用优化2012.6.25邮件.docx

郭主任，您好！ 从5月初开始，项目组进行了数据库应用优化。 为提高数据库性能，消除数据库隐患做了以下工作： 1 重复及无效索引的清理； 2 资料完整性检查，异常记录的修正与清理； 3 历史数据的迁移； 4 高水位表的收集与分类； 5 低效索引的收集与分类； 6 5月12日的帐务资料全量同步，迁移资料接口表，降水位操作，回收索引碎片操作等。 经过十天的数据库性能监控，与5月的性能比较，取有可比性的一天，观察AWR比对报告。监控结果与数据如下： 以2012年6月18日 8：00 ---18：00， 与 2012年5月21日8：00 ---18：00 的数据库性能做比对，这两天都是某月中旬的星期一，它们的业务受理量为： select count(*) from tf_bh_trade where ACCEPT_DATE=to_dateyyyymmdd) and ACCEPT_DATE to_dateyyyymmdd)； ----- 111106 select count(*) from tf_bh_trade where ACCEPT_DATE=to_dateyyyymmdd) and ACCEPT_DATE to_dateyyyymmdd)； ----- 119308 营业数据库节点一： 营业数据库节点二： 帐务数据库节点一： 帐务数据库节点二： AWR报告 功能点说明： Redo size：每秒/每事务产生的redo大小（单位字节），可标志数据库任务的繁重程序。 Logical reads：每秒/每事务逻辑读的块数 Block changes：每秒/每事务修改的块数 Physical reads：每秒/每事务物理读的块数 Physical writes：每秒/每事务物理写的块数 User calls：每秒/每事务用户call次数 Parses：SQL解析的次数 Hard parses：其中硬解析的次数，硬解析太多，说明SQL重用率不高。 Sorts：每秒/每事务的排序次数 Logons：每秒/每事务登录的次数 Executes：每秒/每事务SQL执行次数 Transactions：每秒事务数 Blocks changed per Read：表示逻辑读用于修改数据块的比例 Recursive Call：递归调用占所有操作的比率 Rollback per transaction：每事务的回滚率 Rows per Sort：每次排序的行数 从比对报告看，营业数据库节点二，帐务数据库节点一，帐务数据库节点二 的性能提升明显； 营业数据库节点一的部分功能点提升不明显。 与维护人员讨论后，可能与 网格功能 与 佣金计算 有关。 这两个功能还在更新维护中，网格功?? 与 佣金计算 的执行，会对当天的性能产生影响。 网格功能 与 佣金计算，可在后面做专题优化。 在6月30日 - 7月3日 出帐期间，还可做性能监控与比对。 后面还要做强制索引改造，TOPSQL优化等工作。 我们的系统可以跑的更快，运行更稳定！