OWI性能诊断.pptxVIP

OWI 性能诊断 讲师：魏兴华 ，新彩软件数据库架构师 2 OWI优化方法论 4 响应时间模型 3 旧的优化理论-命中率，及其缺陷 1 开车与OWI Log File Sync优化 5 outline Hold一下，我们先来看看历史。。。 Buffer Cache Library Cache PGA Dictionary cache Latch Sort In Memeory Hit ratio 各种命中率 一般来说内存的命中率高就代表“性能好” 访问速度： Cpu cache SGA File system cache Raid cache Storage cache disk 早期的优化是围绕着命中率来展开的 也意味着优化的方法常常是通过提升硬件能力来提高命中率 进而“提高性能” 可是 总靠谱吗？ 命中率的缺陷 一个小故事 分享一个面试题： 为什么 select * from test where id=1 瞬间返回结果 而 update test set name=‘xxxx’ where id=1 很慢，没有响应？ 习惯性的提问：它在等什么？ 开车与OWI 开车与OWI 红绿灯太多？ 堵车太严重？ 遭遇了交通事故？ 车没油了? 开车速度太慢？ Why ?? 为什么迟到 开车与OWI 我用不同的颜色标识出了开车时间和等待时间，等待时 间包含了两次堵车的10分钟，红灯的3分钟。假如再给 小王一次机会，他该如何调整方案来保证半个小时可以 到达呢？ 开车与OWI 降低开车时间，可以通过加快开车速度来实现，或者选择较短的路程，如上图，如果有直线的路程，可以明显减少开车的路程，进而降低开车时间。 降低等待时间，比如是不是可以绕一个红绿灯比较少的路，或者在行人、车辆比较少的情况下的出行 如何优化？ 响应时间=服务时间+等待时间 服务时间是进程占用CPU的时间，对应到我们上面的例子里就是开车时间，等待时间是进程在继续处理任务之前等待某些特定资源可用的时间，对应到我们上面的例子里就是等待红绿灯、堵车的时间。这个公式是基于这样一个事实：在任何时刻，进程或是在CPU上进行任务计算，或是脱离CPU运行队列处于等待状态。 响应时间模型 对应到数据库里，在会话级别，服务时间对应v$sesstat（做了什么）里的CPU used when call started，等待时间对应v$session_event（时间花哪了）里特定会话的所有前台进程相关等待事件的time_waited之和。CPU used when call started又被细分为：CPU used for parsing，CPU used for recursive calls，CPU used for normal work。（需要注意的是，CPU相关的统计信息是在一个call结束后才会被统计更新，而等待事件统计信息的资料将以实时的模式更新。因此一个耗时很长的SQL将不会更新他的CPU信息直到其执行结束） 数据库响应时间 数据库响应时间模型更加接近终端用户的体验，也将数据库性能调优提升到了一个新的高度。DBA在进行性能跟踪诊断的时候，时刻应该把响应时间牢记心中，而响应时间慢，往往是由于等待某些资源可用的时间过长导致。 为什么关注响应时间比关注命中率重要？因为时间对于终端用户的感受是最直接的，一位开发向你抱怨一个任务执行缓慢，或者网站的一位客户投诉网页打开慢，他们都是对响应时间的不满，他们根本不关心是因为某种命中率低或者你主机的内存、CPU资源、IO资源不足等等原因才来抱怨的。 响应时间模型的好处 OWI表达的内容跟等待事件相关。继续以我们上面的开车为例，如果可以设计一个功能，能够跟踪小王当前开车的状态，并且在他开车发生等待的情况下，提供给你一个接口，通过这个接口可以查询当前他在发生什么等待、发生在这个等待上的时间、次数，并且保留他本次路程里，所有发生的等待的事件（红绿灯、堵车、等待行人通过）、等待的次数、等待的总时间，那么这个功能对应到ORACLE里就叫OWI-oracle wait interface，翻译为中文叫Oracle等待事件接口。 什么是OWI 我们举一个数据库的例子： update test set a=1 where id=1; commit; 这个事务一共花费了1024ms，我们可以通过v$sesstat，v$session_event了解到整个执行过程 什么是OWI