一个新上线数据库的调优记录

背景说明：一个供应链协同系统上线后的几天后，陆陆续续有用户反馈系统有些慢，这个时候项目的老大第一反映就是让DBA看下系统的瓶颈。一般情况系统上线前期都会有压力测试，但是压力测试并不能模拟出复杂的业务场景，经过了压力测试也并不代表在实际的运行中不会出现问题。

顺便跑题一下：系统上线前期如果系统有问题，那么正是DBA大展身手的机会，因为只有DBA才知道系统"为什么慢、慢在哪里、怎么调",这个时候你的价值就体现出来了，如果碰到一个不厚道的领导，还可以忽悠他一下，因为我遇到的领导很不错，所以我也是兢兢业业的。

以下是整个问题的解决过程：

1、当用户反馈很卡的时候，进入检查三部曲：cpu、内存、归档空间、锁等待信息，经过一番检查发现数据库的整体压力并不高，也没有发现锁等待信息；

2、查看数据库的awr报告，自从稍微看懂了awr报告后，为整个数据库的管理增加了不少便利。

2.1 以下是问题时间段的awr报告截图：

在top5的等待事件中发现了cursor：pin S wait on X的等待事件，这个等待事件跟数据库Library有关系，根据经验这个等待事件一般跟以下几个有关系：

• sga自动管理,sga的频繁扩展和收缩；
• 过渡硬解析,造成library cache中的cursor object被频繁的reload；
• bug；

2.2 针对这个内存的问题，检查awr报告的内存大小，buffer cache和shared pool并未发生变化，所以可以排除sga的扩展和收缩导致的问题；

2.3 检查数据库的硬解析情况  

Time Model Statistics DB/Inst: SCMPRD/scmprd Snaps: 2045-2046

-> Total time in database user-calls (DB Time): 1576.1s

-> Statistics including the word "background" measure background process

time, and so do not contribute to the DB time statistic

-> Ordered by % or DB time desc, Statistic name

Statistic Name Time (s) % of DB Time

------------------------------------------ ------------------ ------------

DB CPU 1,426.7 90.5

sql execute elapsed time 1,404.8 89.1

parse time elapsed 717.7 45.5

hard parse elapsed time 645.2 40.9

hard parse (sharing criteria) elapsed time 480.5 30.5

PL/SQL execution elapsed time 52.8 3.3

sequence load elapsed time 2.3 .1

hard parse (bind mismatch) elapsed time 1.3 .1

connection management call elapsed time 0.8 .0

PL/SQL compilation elapsed time 0.1 .0

repeated bind elapsed time 0.1 .0

failed parse elapsed time 0.0 .0

DB time 1,576.1

background elapsed time 106.2

background cpu time 86.9

从上面的时间统计看出，数据库的硬解析占用了很大的一个占比，一般来说数据库硬解析产生的原因是由于未使用绑定变量导致的。（http://blog.itpub.net/12679300/viewspace-1217976/）

2.4 为了保险起见继续看AWR报告的其他部分

既然硬解析是由于SQL语句引起的，所以就很有必要看下这段时间里运行次数最多的语句，并针对这些语句和业务人员沟通；

2.5 解决方法，经过以上的分析，以短时间内保障系统的性能为目的，做了以下调整；

• 查找数据库top5的未使用绑定变量的语句，进行调优；
• 修改数据库的参数CURSOR_SHARING设置为SIMILAR；
• 一些后台会产生大量并发SQL语句的JOB转移到系统空闲期运行；

新系统上线前期一般会有一些的性能上的问题，但是这些问题往往并不是DBA调整几个参数就能解决的，见过好几个自开发的系统，应用层面都没有使用绑定变量的习惯，虽然可以通过CURSOR_SHARING参数暂时解决问题；便捷和稳定总是冲突的，虽然这样可以暂时的解决问题，但是从长期系统的稳定性来说还是有一定的风险的。

*********************************************************************************************************************

本文作者：JOHN QQ：1916066696 （请备注数据库）

ORACLE技术博客：ORACLE 猎人笔记 http://blog.itpub.net/12679300/

******************************************************************************************************