背景说明：一个供应链协同系统上线后的几天后，陆陆续续有用户反馈系统有些慢，这个时候项目的老大第一反映就是让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/
******************************************************************************************************
