《OWI性能诊断》由会员分享，可在线阅读，更多相关《OWI性能诊断（39页珍藏版）》请在金锄头文库上搜索。
1、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,早期的优化是围绕
2、着命中率来展开的 也意味着优化的方法常常是通过提升硬件能力来提高命中率 进而“提高性能” 可是 总靠谱吗？,命中率是被平均的 命中率不是征兆学的 命中率往往通过提升硬件来解决数据库性能问题 命中率不容易理解 命中率高与系统性能没有直接的因果关系 命中率是与吞吐量、响应时间无关的,命中率的缺陷,一个小故事,分享一个面试题： 为什么 select * from test where id=1 瞬间返回结果 而 update test set name=xxxx where id=1 很慢，没有响应？,习惯性的提问：它在等什么？,开车与OWI,小王接到领导电话，需要下午2点从无锡新区到市中 心参加一
3、个重要会议，他预估了路程30分钟可以到 达，于是悠闲的吃过中饭，收拾好东西后，一点半 开始出发，但是另他意外的是他足足花了50分钟才 到，他迟到了！他感觉到客户对他的迟到产生了反感 ，他悔恨万分自己错估了时间。如果你是小王，会 如何分析这次迟到的原因？,开车与OWI,红绿灯太多？,堵车太严重？,遭遇了交通事故？,车没油了?,开车速度太慢？,Why ?,为什么迟到,以上的分析大部分人都能想出来，也非常的合理，既然 实际到达的时间比预估的长，有可能是开车速度过慢， 或者是发生了一些事件导致等待。这其中其实隐藏了时 间模型的方法论。在我们的例子里就是： 总的路程时间=开车时间+等待时间，开车速度过慢
4、，会 导致开车时间过长，进而导致总时间过长，等待时间过 长同样会导致总的路程时间过长。,开车与OWI,我用不同的颜色标识出了开车时间和等待时间，等待时 间包含了两次堵车的10分钟，红灯的3分钟。假如再给 小王一次机会，他该如何调整方案来保证半个小时可以 到达呢？,开车与OWI,降低开车时间，可以通过加快开车速度来实现，或者选择较短的路程，如上图，如果有直线的路程，可以明显减少开车的路程，进而降低开车时间。 降低等待时间，比如是不是可以绕一个红绿灯比较少的路，或者在行人、车辆比较少的情况下的出行,如何优化？,响应时间=服务时间+等待时间 服务时间是进程占用CPU的时间，对应到我们上面的例子里就是
5、开车时间，等待时间是进程在继续处理任务之前等待某些特定资源可用的时间，对应到我们上面的例子里就是等待红绿灯、堵车的时间。这个公式是基于这样一个事实：在任何时刻，进程或是在CPU上进行任务计算，或是脱离CPU运行队列处于等待状态。,响应时间模型,对应到数据库里，在会话级别，服务时间对应v$sesstat（做了什么）里的CPU used when call started，等待时间对应v$session_event（时间花哪了）里特定会话的所有前台进程相关等待事件的time_waited之和。CPU used when call started又被细分为：CPU used for parsing，
6、CPU used for recursive calls，CPU used for normal work。（需要注意的是，CPU相关的统计信息是在一个call结束后才会被统计更新，而等待事件统计信息的资料将以实时的模式更新。因此一个耗时很长的SQL将不会更新他的CPU信息直到其执行结束）,数据库响应时间,数据库响应时间模型更加接近终端用户的体验，也将数据库性能调优提升到了一个新的高度。DBA在进行性能跟踪诊断的时候，时刻应该把响应时间牢记心中，而响应时间慢，往往是由于等待某些资源可用的时间过长导致。 为什么关注响应时间比关注命中率重要？因为时间对于终端用户的感受是最直接的，一位开发向你抱怨一
7、个任务执行缓慢，或者网站的一位客户投诉网页打开慢，他们都是对响应时间的不满，他们根本不关心是因为某种命中率低或者你主机的内存、CPU资源、IO资源不足等等原因才来抱怨的。,响应时间模型的好处,OWI表达的内容跟等待事件相关。继续以我们上面的开车为例，如果可以设计一个功能，能够跟踪小王当前开车的状态，并且在他开车发生等待的情况下，提供给你一个接口，通过这个接口可以查询当前他在发生什么等待、发生在这个等待上的时间、次数，并且保留他本次路程里，所有发生的等待的事件（红绿灯、堵车、等待行人通过）、等待的次数、等待的总时间，那么这个功能对应到ORACLE里就叫OWI-oracle wait interf
8、ace，翻译为中文叫Oracle等待事件接口。,什么是OWI,我们举一个数据库的例子： update test set a=1 where id=1; commit; 这个事务一共花费了1024ms，我们可以通过v$sesstat，v$session_event了解到整个执行过程,什么是OWI,OWI记录的等待过程,从数据库获取等待过程,SELECT EVENT, TIME_WAITED, TOTAL_WAITS FROM V$SESSION_EVENT WHERE SID = 485 AND WAIT_CLASS Idle UNION ALL SELECT B.NAME, VALUE, NU
9、LL FROM V$SESSTAT A, V$STATNAME B WHERE A.STATISTIC# = B.STATISTIC# AND B.NAME = CPU used when call started AND A.SID = 485;,从数据库获取等待过程,EVENT TIME_WAITED TOTAL_WAITS - - - Disk file operations I/O 1 4 latch: cache buffers chains 0 1 log file sync 5 1 db file sequential read 13 4 db file scattered re
10、ad 2 1 enq: TX - row lock contention 372 1 SQL*Net message to client 0 36 CPU used when call started 10987,我们开启了一个事务并提交，这个过程里，经过了两次db file sequential read，共6ms，一次enq:TX-row lock contention ，共1s，一次log file sync，共6ms，共发生等待1012ms。这些等待在ORACLE里称为wait event，对这些等待进行计数（次数+时间），并且通过各种v$视图进行展现的功能接口叫做OWI。,什么是OW
11、I,各版本等待次数统计,Oracle的等待事件之所以越来越多，一方面是由于新增的功能导致，另一方面也是把之前没纳入到等待事件中的系统调用重新开发，然后增加到新版本中来。比如开车过程中可能会遭遇堵车、红绿灯、行人过马路种种等待，一开始系统的OWI基于这三个等待来进行计数、展示，但是后来可能发现交通事故其实也是等待的一种，因此在下个版本发布的时候，将其纳入进来。,等待事件越来越多,OWI是量化的。OWI记录了所有等待事件的等待次数、等待时间、平均等待时间。在没有OWI的情况下遭遇系统缓慢，可能会通过种种猜测来进行试错，活跃会话数过多？系统可能会有锁等待？buffer cache命中率太低？硬解析过
12、多？但是如果是通过OWI分析，那么就可以理直气壮的得出，分析近半个小时的等待事件，出现了大量的shared pool latch争用，占整个db time的百分之三十，而正常情况这一指标仅仅只占百分之五，并且结合每秒硬解析数看，这个指标也非常高，因此可以推论出是由于硬解析过高导致的数据库性能下降。由此可以看出，熟练使用OWI后，能够摆脱以往优化性能问题时候的”猜测性“，将复杂的性能优化问题，解释为任何人都容易理解的量化的值。,OWI优点,OWI是更贴近“自然”的分析理论。拿我举的开车的例子来说，大部分人都会想到细分出等待过程中的各个环节，然后找出最耗时的几个环节，有目的性的进行优化。 OWI是
13、征兆学的。,OWI优点,不包含CPU统计，可以通过v$sesstat弥补 早期版本缺少历史数据 不完全的等待时间 以OWI为出发点优化数据库性能总不失为一个好的开始。但是它不能告诉你全部。,OWI的缺点,OWI相关工具,理论很简单，转变思路很难,转变思路,LOG FILE SYNC,commit操作 rollback操作 DDL操作（DDL操作实施前都会首先进行一次commit） DDL操作导致的数据字典修改所产生的commit 某些能递归修改数据字典的操作：比如查询SEQ的next值，可能会导致修改数据字典。一个典型的情况是，SEQ的cache属性设置为nocache，那么会导致每次调用SE
14、Q都要修改数据字典，产生递归的commit,LOG FILE SYNC,LOG FILE SYNC,LOG FILE SYNC,Group Commit,c1作为一个commit record已经被拷贝到了log buffer里，接着前台进程通知lgwr去写日志，在前台进程post lgwr到lgwr真正开始写之前，非常可能存在着时间差，就在这个时间差里，c2,g1,c3也已经把相应的日志拷贝到了log buffer里，其中c1,c2,c3是commit的记录，g1仅仅是普通的事务日志，不是commit日志。在lgwr真正开始写之前，它会去检查当前log buffer的最高点，发现在c3位置处
15、，把这个点作为此次刷新日志的目标，把c1,c2,g1,c3的日志都刷新到磁盘。虽然刷新日志这个操作是由c1出发的，但是c2,g1,c3也是受惠者搭了便车，日志也被刷新到了日志文件里，这个功能叫组提交,LOG FILE SYNC调优,作为通用的log file sync的诊断、调优方法，一般可以通 过诊断系统的IO延迟为多大，cpu资源是否充足来判断哪 里出现了问题。 IO延迟的诊断、调优（IO抖动造成log file sync虚高，拼吞吐？IOPS？） cpu资源的诊断、调优（调高LGWR优先级有用？） 调优应用（减少commit） 数据库调优（块大小、减少logmember、redo siz
16、e、log switch,sequence） 操作系统调优：内存、网络（lgwr内存page out,lgwr async DG）,v$event_histogram,新的调优手段,10G后，事务的提交操作可以不等待日志持久化的完成（看不到log file sync等待）。10GR1的时候，ORACLE公司默默的推出了一个参数：commit_logging，这个参数可以有四种组合：commit write batch|immediatewait|nowait，其中wait/nowait与事务的持久化相关。10GR2版本发布的时候，这个参数被拆成了2个参数，commit_logging，commit_write，10GR2拆分后的参数，更能准确表达参数的意图。,参考文献,
