OWI性能诊断课件

OWI性能诊断讲师：魏兴华，新彩软件数据库架构师.2OWI优化方法论4响应时间模型33旧的优化理论-命中率，及其缺陷31开车与OWILogFileSync优化5outline.Hold一下，我们先来看看历史。。。.BufferCacheLibraryCachePGADictionarycacheLatchSortInMemeoryHitratio各种命中率.一般来说内存的命中率高就代表“性能好”访问速度：CpucacheSGAFilesystemcacheRaidcacheStoragecachedisk早期的优化是围绕着命中率来展开的也意味着优化的方法常常是通过提升硬件能力来提高命中率进而“提高性能”可是总靠谱吗？.命中率是被平均的命中率不是征兆学的命中率往往通过提升硬件来解决数据库性能问题命中率不容易理解命中率高与系统性能没有直接的因果关系命中率是与吞吐量、响应时间无关的命中率的缺陷.一个小故事分享一个面试题：为什么select*fromtestwhereid=1瞬间返回结果而updatetestsetname=‘xxxx’whereid=1很慢，没有响应？.习惯性的提问：它在等什么？.开车与OWI.小王接到领导电话，需要下午2点从无锡新区到市中心参加一个重要会议，他预估了路程30分钟可以到达，于是悠闲的吃过中饭，收拾好东西后，一点半开始出发，但是另他意外的是他足足花了50分钟才到，他迟到了！他感觉到客户对他的迟到产生了反感，他悔恨万分自己错估了时间。如果你是小王，会如何分析这次迟到的原因？开车与OWI.红绿灯太多？堵车太严重？遭遇了交通事故？车没油了?开车速度太慢？Why??为什么迟到.以上的分析大部分人都能想出来，也非常的合理，既然实际到达的时间比预估的长，有可能是开车速度过慢，或者是发生了一些事件导致等待。这其中其实隐藏了时间模型的方法论。在我们的例子里就是：总的路程时间=开车时间+等待时间，开车速度过慢，会导致开车时间过长，进而导致总时间过长，等待时间过长同样会导致总的路程时间过长。开车与OWI.我用不同的颜色标识出了开车时间和等待时间，等待时间包含了两次堵车的10分钟，红灯的3分钟。假如再给小王一次机会，他该如何调整方案来保证半个小时可以到达呢？开车与OWI.降低开车时间，可以通过加快开车速度来实现，或者选择较短的路程，如上图，如果有直线的路程，可以明显减少开车的路程，进而降低开车时间。降低等待时间，比如是不是可以绕一个红绿灯比较少的路，或者在行人、车辆比较少的情况下的出行如何优化？.

响应时间=服务时间+等待时间服务时间是进程占用CPU的时间，对应到我们上面的例子里就是开车时间，等待时间是进程在继续处理任务之前等待某些特定资源可用的时间，对应到我们上面的例子里就是等待红绿灯、堵车的时间。这个公式是基于这样一个事实：在任何时刻，进程或是在CPU上进行任务计算，或是脱离CPU运行队列处于等待状态。响应时间模型.

对应到数据库里，在会话级别，服务时间对应v$sesstat（做了什么）里的CPUusedwhencallstarted，等待时间对应v$session_event（时间花哪了）里特定会话的所有前台进程相关等待事件的time_waited之和。CPUusedwhencallstarted又被细分为：CPUusedforparsing，CPUusedforrecursivecalls，CPUusedfornormalwork。（需要注意的是，CPU相关的统计信息是在一个call结束后才会被统计更新，而等待事件统计信息的资料将以实时的模式更新。因此一个耗时很长的SQL将不会更新他的CPU信息直到其执行结束）数据库响应时间.数据库响应时间模型更加接近终端用户的体验，也将数据库性能调优提升到了一个新的高度。DBA在进行性能跟踪诊断的时候，时刻应该把响应时间牢记心中，而响应时间慢，往往是由于等待某些资源可用的时间过长导致。为什么关注响应时间比关注命中率重要？因为时间对于终端用户的感受是最直接的，一位开发向你抱怨一个任务执行缓慢，或者网站的一位客户投诉网页打开慢，他们都是对响应时间的不满，他们根本不关心是因为某种命中率低或者你主机的内存、CPU资源、IO资源不足等等原因才来抱怨的。响应时间模型的好处.OWI表达的内容跟等待事件相关。继续以我们上面的开车为例，如果可以设计一个功能，能够跟踪小王当前开车的状态，并且在他开车发生等待的情况下，提供给你一个接口，通过这个接口可以查询当前他在发生什么等待、发生在这个等待上的时间、次数，并且保留他本次路程里，所有发生的等待的事件（红绿灯、堵车、等待行人通过）、等待的次数、等待的总时间，那么这个功能对应到ORACLE里就叫OWI-oraclewaitinterface，翻译为中文叫Oracle等待事件接口。什么是OWI.我们举一个数据库的例子：updatetestseta=1whereid=1;commit;这个事务一共花费了1024ms，我们可以通过v$sesstat，v$session_event了解到整个执行过程什么是OWI.OWI记录的等待过程.从数据库获取等待过程SELECTEVENT,TIME_WAITED,TOTAL_WAITS

FROMV$SESSION_EVENT

WHERESID=485

ANDWAIT_CLASS<>'Idle'UNIONALLSELECTB.NAME,VALUE,NULL

FROMV$SESSTATA,V$STATNAMEB

WHEREA.STATISTIC#=B.STATISTIC#

ANDB.NAME='CPUusedwhencallstarted'

ANDA.SID=485;.从数据库获取等待过程EVENTTIME_WAITEDTOTAL_WAITS

DiskfileoperationsI/O14latch:cachebufferschains01logfilesync51dbfilesequentialread134dbfilescatteredread21enq:TX-rowlockcontention3721SQL*Netmessagetoclient036CPUusedwhencallstarted10987.我们开启了一个事务并提交，这个过程里，经过了两次dbfilesequentialread，共6ms，一次enq:TX-rowlockcontention，共1s，一次logfilesync，共6ms，共发生等待1012ms。这些等待在ORACLE里称为waitevent，对这些等待进行计数（次数+时间），并且通过各种v$视图进行展现的功能接口叫做OWI。什么是OWI.版本等待时间总数（大约）7.0.11008I2209I40010GR287411GR2115212CR11567各版本等待次数统计.Oracle的等待事件之所以越来越多，一方面是由于新增的功能导致，另一方面也是把之前没纳入到等待事件中的系统调用重新开发，然后增加到新版本中来。比如开车过程中可能会遭遇堵车、红绿灯、行人过马路种种等待，一开始系统的OWI基于这三个等待来进行计数、展示，但是后来可能发现交通事故其实也是等待的一种，因此在下个版本发布的时候，将其纳入进来。等待事件越来越多.OWI是量化的。OWI记录了所有等待事件的等待次数、等待时间、平均等待时间。在没有OWI的情况下遭遇系统缓慢，可能会通过种种猜测来进行试错，活跃会话数过多？系统可能会有锁等待？buffercache命中率太低？硬解析过多？但是如果是通过OWI分析，那么就可以理直气壮的得出，分析近半个小时的等待事件，出现了大量的sharedpoollatch争用，占整个dbtime的百分之三十，而正常情况这一指标仅仅只占百分之五，并且结合每秒硬解析数看，这个指标也非常高，因此可以推论出是由于硬解析过高导致的数据库性能下降。由此可以看出，熟练使用OWI后，能够摆脱以往优化性能问题时候的”猜测性“，将复杂的性能优化问题，解释为任何人都容易理解的量化的值。OWI优点.OWI是更贴近“自然”的分析理论。拿我举的开车的例子来说，大部分人都会想到细分出等待过程中的各个环节，然后找出最耗时的几个环节，有目的性的进行优化。OWI是征兆学的。OWI优点.不包含CPU统计，可以通过v$sesstat弥补早期版本缺少历史数据不完全的等待时间以OWI为出发点优化数据库性能总不失为一个好的开始。但是它不能告诉你全部。OWI的缺点.视图名作用v$session_wait记录session的当前等待状态，具有实时性，10G后逐渐被v$session取代v$event_name记录了等待事件的名称，静态表v$system_event自本次系统启动以来累计的等待事件的次数、等待总时间，系统级别v$session_event记录具体session自连接以来等待事件的次数、等待时间，session级别v$event_histogram等待事件的直方图v$active_session_history会话状态、等待事件历史，Dba_Hist_Active_Sess_Historyv$session_wait_history会话最近十次的等待事件OWI相关工具.理论很简单，转变思路很难转变思路.LOGFILESYNCcommit操作rollback操作DDL操作（DDL操作实施前都会首先进行一次commit）DDL操作导致的数据字典修改所产生的commit某些能递归修改数据字典的操作：比如查询SEQ的next值，可能会导致修改数据字典。一个典型的情况是，SEQ的cache属性设置为nocache，那么会导致每次调用SEQ都要修改数据字典，产生递归的commit.LOGFILESYNC.LOGFILESYNC.LOGFILESYNC.GroupCommitc1作为一个commitrecord已经被拷贝到了logbuffer里，接着前台进程通知lgwr去写日志，在前台进程postlgwr到lgwr真正开始写之前，非常可能存在着时间差，就在这个时间差里，c2,g1,c3也已经把相应的日志拷贝到了logbuffer里，其中c1,c2,c3是commit的记录，g1仅仅是普通的事务日志，不是commit日志。在lgwr真正开始写之前，它会去检查当前logbuffer的最高点，发现在c3位置处，把这个点作为此次刷新日志的目标，把c1,c2,g1,c3的日志都刷新到磁盘。虽然刷新日志这个操作是由c1出发的，但是c2,g1,c3也是受惠者搭了便车，日志也被刷新到了日志文件里，这个功能叫组提交.LOGFILESYNC调优作为通用的logfilesync的诊断、调优方法，一般可以通过诊断系统的IO延迟为多大，cpu资源是否充足来判断哪里出现了问题。IO延迟的诊断、调优（IO抖动造成logfilesync虚高，拼吞吐？IOPS？）cpu资源的诊断、调优（调高LGWR优先级有用？）调优应用（减少commit）数据库调优（块大小、减少logmember、redosize、logswitch,sequence）操作系统调优：内存、网络（lgwr内存pageout,lgwrasyncDG）.v$event_histogram.新的调优手段10G后，事务的提交操作可以不等待日志持久化的完成（看不到logfilesync等待）。10GR1的时候，ORACLE公司默默的推出了一个参数：commit_logging，这个参数可以有四种组合：commitwrite[batch|immediate][wait|nowait]，其中