ITPub博客

首页 > 数据库 > Oracle > 一个新上线数据库的调优记录

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

Oracle 作者:fengzhanhai 时间:2014-12-27 19:27:30 0 删除 编辑

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

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

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25723371/viewspace-1382234/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2014-01-26

  • 博文量
    25
  • 访问量
    248925