ITPub博客

首页 > 数据库 > Oracle > ORACLE OWI介绍

ORACLE OWI介绍

原创 Oracle 作者:wei-xh 时间:2018-05-10 10:06:57 0 删除 编辑


Oracle数据库对于做那些做运维的DBA是非常友好的,在Oracle的数据库中,有着大量的性能视图可以供DBA来进行性能诊断,也有AWR,ADDM这些极易上手的性能诊断工具帮助DBA分析数据库性能问题。但是就我看到的,依然存在着不少的DBA还是以一种毫无章法的方式优化着Oracle的性能问题。记得一次在杭州的面试另我印象深刻,面试我的是一位DBA老者,他说为什么一个根据主键更新的update语句执行了很久,而同样的根据这个主键的查询语句却很快。我当时的回答是:首先需要知道update所在会话在等待什么,然后兴致冲冲的讲了什么是OWI、什么是响应时间模型,但是看得出来老者对于我的回答并不满意,就在我继续滔滔不绝的说着等待事件时,他打断了我,说:其实是因为锁导致的。我当时觉得有点尴尬,我问:你是如何定位到是锁导致的,他面露得意的说:根据他多年的经验通过猜测最后验证确实是锁导致的。可能在其他非ORACLE数据库里,经验的重要性是首屈一指的,但是在ORACLE里,经验虽然重要,但是又不重要,经验这个词,有猜测的成分在。ORACLE提供了大量的性能视图、诊断工具方便我们去做调优、做诊断,让优化的工诊断性作变得有据可依,而不仅仅是只靠试错、猜测+验证。还是拿面试的问题来说,如果了解OWI理论的话,仅仅只需要查看会话的等待事件,就能迅速的定位到问题的根源。本章会介绍OWI的相关理论,并且会提到很早以前ORACLE提供的基于命中率优化的方法,以及这种方法的缺陷和局限性。


1.1 命中率优化方法

命中率是10G之前主流的优化方法,我刚开始做DBA时,经常有带我的老人告诉我这样的准则,要保持buffer cache的命中率在95%以上,共享池的命中率在95%以上,保持latch的命中率在98%以上等等,只有达到这样的命中率,DBA的调优工作才被认可。我们以buffer cache hit ratio为例来说明命中率的含义,当进程访问数据时,如果数据已经存在在buffer cache中了,那么就可以直接使用内存中的数据,而不用通过磁盘物理读取,这样的一次访问称为一次命中,否则的话,server进程就要先把数据从磁盘读入内存才能使用,这样的访问就是未命中。那么命中率的计算公式我们也很容易的得出来:命中率=命中总次数/总的访问次数。那么为什么内存的命中率高一般来说就代表“性能好”呢?因为一般认为磁盘是非常慢的,而CPU和内存都是极快的设备,对于CPU来说,最快获取数据的方式是从其自身的cache中,其次从内存,从磁盘获取往往都是最慢的。但是目前绝大多数的数据库系统都还做不到将其所有的数据都容纳在内存之中,所以数据库系统往往会根据一定的算法比如LRU来将不被经常访问的数据写回(如果是脏数据)磁盘,或者直接淘汰(如果不是脏数据)来挪出地方供其他数据块使用,如果稍后需要这些数据,就会再从磁盘读入内存。如果算法不合理或者内存过于紧张,就会有大量的IO发生,进而影响性能。早期Oracle的性能优化原则基本都是围绕着命中率展开的,你可以看看8I,9I时候的数据库文档,里面定义了N多个命中率相关的指标,明确的告诉你,什么指标应该达到什么样的命中率才算理想。这一时期的DBA优化数据库的思想往往是围绕着提升硬件来展开的,比如增加内存,增大内存后,会提升命中率,进而提高性能。听起来似乎也是有道理的,但是命中率优化论,有诸多的缺陷,在理解OWI调整思想之前,我们先看看旧的这种优化方式存在的问题和局限性。

· 命中率是被平均的

命中率在我们日常生活中也是一个非常常见的指标,某某某曾经说过,我们中国百分之九十九的奶粉都是合格的,另一位某某某曾经说过中国人平均拥有2套房。这种指标是不顾个体差异的。可能你的某几个SQL百分之九十九都是物理读,但是对不起,由于其他某些SQL的命中率极高,导致你的SQL的命中率也被提高了。

· 命中率不是征兆学的,如果你的SQL由于等待锁而一直在等待,这个时候命中率帮不了你任何的忙。但是OWI就能很容易根据“锁”这个征兆,定位到是产生了锁争用。

· 命中率往往通过提升硬件来解决数据库性能问题,技术含量低。在DBA发现命中率低之后,很多会采用加大内存等方式来提升数据库性能、提升命中率,而且通过提升硬件解决性能问题,容易造成问题反复,治标不治本。

· 命中率不容易理解。当开发询问你。他的任务为什么迟迟没有跑完的时候,你告诉他由于数据库的命中率是85%,所以慢,这个可能实在是说服不了他,非常另他费解。就像你打电话给快餐店,为什么你的午餐迟迟没有送到,对方告诉你送餐的命中率是99%一样,莫名其妙!

· 命中率高与系统性能没有直接的因果关系。一个命中率高的系统不一定性能好,同样,一个命中率低的系统,不一定性能就不好。试想一下,一个充斥着大量的锁的系统,虽然命中率可能极高,但是系统的性能却一塌糊涂。

· 命中率是与吞吐量、响应时间无关的


命中率的调优诊断方法对于性能分析和调整并不可靠,因此ORACLE才会引入了OWI调优思想。

1.1 开车与OWI

小王接到领导电话,需要下午2点从无锡新区到市中心参加一个重要会议,他预估了路程30分钟可以到达,于是悠闲的吃过中饭,收拾好东西后,一点半开始出发,但是另他意外的是他足足花了50分钟才到,他迟到了!他感觉到客户对他的迟到产生了反感,他悔恨万分自己错估了时间。如果你是小王,会如何分析这次迟到的原因?

· 红绿灯太多了?

· 刚好路上遇到交通事故,被迫换了路线?

· 堵车太严重?

· 开车速度太慢?

以上的分析是大部分人都能想出来的,也是非常合理的,既然实际到达的时间比预估的长,一定是发生了一些等待导致不能开车,或者是开车速度太慢。这其中其实隐藏了时间模型的方法论。在我们的例子里就是:

总的路程时间=开车时间+等待时间,如下图:

 

我用不同的颜色标识出了开车时间和等待时间,等待时间包含了两次堵车的10分钟,红灯的3分钟。假如再给小王一次机会,他该如何调整方案来保证半个小时可以到达呢?

· 降低开车时间,可以通过加快开车速度来实现,或者选择较短的路程,如上图,如果有直线的路程,可以明显减少开车的路程,进而降低开车时间。

· 降低等待时间,比如是不是可以绕一个红绿灯比较少的路,或者在行人、车辆比较少的情况下的出行。

Oracle的优化思想和这个如出一辙:



 

数据库响应时间=服务时间+等待时间

服务时间是进程占用CPU的时间,对应到我们上面的例子里就是开车时间,等待时间是进程在继续处理任务之前等待某些特定资源可用的时间,对应到我们上面的例子里就是等待红绿灯、堵车的时间。这个公式是基于这样一个事实:在任何时刻,进程或是在CPU上进行任务计算,或是脱离CPU运行队列处于等待状态。作为DBA我们可以通过或缩短服务时间,或缩短等待时间,或缩短两者来降低最终的响应时间。我们上面的例子里,车要不是在正常的在道路上运行,要不是在等待红绿灯、堵车、等待行人通过等等,我们可以通过减少开车时间(提升车速),减少等待时间来缩短到达目的地的时间。对应到数据库里,在会话级别,服务时间对应v$sesstat里的CPU used when call started,等待时间对应v$session_event里特定会话的所有前台进程相关等待事件的time_waited之和。CPU used when call started又被细分为:CPU used for parsingCPU used for recursive callsCPU used for normal work。需要注意的是,CPU相关的统计信息是在一个call结束后才会被统计更新,而统计信息的资料将以实时的模式更新。因此一个耗时很长的SQL将不会更新他的CPU信息直到其执行结束。

如何获得会话级数据库响应时间的数据?

如果想获得完整会话级的数据库响应时间数据,一般需要借助数据库LOGOFF触发器来实现,但是你往往不需要这么做。例如,你想测量:


数据库响应时间模型更加接近终端用户的体验,也将数据库性能调优提升到了一个新的高度。作为DBA在进行性能跟踪诊断的时候,时刻应该把响应时间牢记心中。

为什么关注响应时间比关注命中率重要?因为时间对于终端用户的感受是最直接的,一位开发向你抱怨一个任务执行缓慢,或者网站的一位客户投诉网页打开慢,他们都是对响应时间的不满,他们根本不关心是因为某种命中率低或者你主机的内存、CPU资源、IO资源不足等等原因才来抱怨的。不要把自己当做DBA,把你当做是一个普通的网站客户,网站的打开速度慢,你会如何去抱怨?肯定也是响应时间!

再次看一下我们的响应时间公式:

数据库响应时间=服务时间+等待时间

OWI最大的贡献是通过各种等待事件的次数、等待的时间来解释一个任务执行过程中,时间消耗的分布,让你非常容易定位到耗时最大的等待,进而有的放矢。响应时间模型是非常好理解的,即使一个非专业的DBA也极其容易理解其理论。比如你在十一假期排队购买火车票,你买票的总时间=排队时间+购买时间,如果想缩短购票总时间,可以通过缩短排队时间、或缩短购买时间、或缩短两者来进行尝试,比如在晚上人少的时候排队购买减少排队时间,提前观察一下哪位业务员卖票的速度快,技术熟练,然后选择在她的业务窗口办理购票。 

什么是OWI

OWI表达的内容跟等待时间相关。继续以我们上面的开车为例,如果可以设计一个功能,能够跟踪小王当前开车的状态,并且在他开车发生等待的情况下,提供给你一个接口,通过这个接口可以查询当前他在发生什么等待、发生在这个等待上的时间、次数,并且保留他本次路程里,所有发生的等待的事件(红绿灯、堵车、等待行人通过)、等待的次数、等待的总时间,那么这个功能对应到ORACLE里就叫OWI-oracle wait interface,翻译为中文叫Oracle等待事件接口。我们举一个数据库的例子:

update test set a=1 where id=1;

commit;

我们开启了一个事务并提交,这个过程里,经过了两次db file sequential read,共6ms,一次enq:TX-row lock contention ,共1s,一次log file sync,共6ms,共发生等待1012ms。这些等待在ORACLE里称为wait event,对这些等待进行计数(次数+时间),并且通过各种v$视图进行展现的功能接口叫做OWI。OWI最早出现在ORACLE 7.0.1中,当时的等待事件只有100多个,之后ORACLE不断完善此功能,对很多等待事件进行了细分,截止到目前最新的版本12cr1,这个等待事件已经扩大到了1567个,由此可见ORACLE对于OWI这么一个功能的重视和信心。Oracle的等待事件之所以越来越多,一方面是由于新增的功能导致,另一方面也是把之前没纳入到等待事件中的系统调用重新开发,然后增加到新版本中来。比如开车过程中可能会遭遇堵车、红绿灯、行人过马路种种等待,一开始系统的OWI基于这三个等待来进行计数、展示,但是后来可能发现交通事故其实也是等待的一种,因此在下个版本发布的时候,将其纳入进来。

版本

等待时间总数(大约)

7.0.1

100

8i

220

9i

400

10gr2

874

11gr2

1152

12cr1

1567

OWI思想

OWI对进程在执行任务过程的状态进行跟踪,并且在进程遇到等待时,对其进行计数,以v$视图的形式暴露给用户诊断、分析。常见的等待有EQN锁,latch相关,IO相关的等待,network相关等等。OWI记录进程从开始到结束遭遇的所有的这些等待,DBA可以通过消除、减少这些等待来降低最终的响应时间。对应到我们最开始举的开车的例子里,可以通过消除红绿灯、堵车、等待行人通过等时间来减少到达时间的道理一样。作为ORACLE公司的开发、设计者,需要知道在哪些地方可能产生调用,然后在这些点上设置event计数,最终以各种视图的形式给我们展现出来。例如还是拿开车为例,需要设计出红路灯、堵车、等待行人通过、停车标志、遇到车祸现场等等的等待点。在ORACLE中,如果一个进程在需要等待一个资源时,ORACLE就需要收集这个等待的统计,并且记录到对应的视图中。等待事件能够迅速告诉我们阻扰性能的主要瓶颈,方便DBA找到解决问题的最佳办法。例如如下这些统计:

很清楚的能够看到数据库系统最大的瓶颈在于log file sync,占了整个DB TIME的65.89%.定位到问题后,后续就是如何解决、优化log file sync的问题了。

OWI带来了一种新的监控、测量数据库瓶颈的方法,同时通过一些视图将这些数据展示表达出来。如果现在再有开发咨询你为什么他的任务运行缓慢,你可以从容应对,告诉他这个任务执行过程中,百分之八十的时间都在等待物理IO,百分之十的时间在等待日志写,其他时间为CPU时间,如果想优化任务,必须降低IO,降低log file sync。如下示例,取两次会话v$session_event的快照,然后取delta,就可以很容易得出此会话发生的等待事件、等待次数、等待时间。

execute snap_stats.start_snap

declare

c number;

begin

select count(*) into c from a;

for i in 1 .. 100000 loop

update a set id=1 where rownum<2;

commit write immediate wait;

end loop;

end;

/


在上面的示例中,log file sycn,direct path read占取了数据库时间的绝大部分。优化的方向将需要朝向减少IO等待时间、降低log file sync。

    等待事件通过P1,P2,P3这三个参数表现当前等待的资源

   绝不要根据数量做出调整策略,而应该关注响应时间。因为没有时间消耗的等待次数存在欺骗性。

我们简单总结一下OWI的特点:

· OWI是量化的。OWI记录了所有等待事件的等待次数、等待时间、平均等待时间。在没有OWI的情况下遭遇系统缓慢,可能会通过种种猜测来进行试错,活跃会话数过多?系统可能会有锁等待?buffer cache命中率太低?硬解析过多?但是如果是通过OWI分析,那么就可以理直气壮的得出,分析近半个小时的等待事件,出现了大量的shared pool latch争用,占整个db time的百分之三十,而正常情况这一指标仅仅只占百分之五,并且结合每秒硬解析数看,这个指标也非常高,因此可以推论出是由于硬解析过高导致的数据库性能下降。由此可以看出,熟练使用OWI后,能够摆脱以往优化性能问题时候的”猜测性“,将复杂的性能优化问题,解释为任何人都容易理解的量化的值。

· OWI是更贴近”自然“的分析理论。拿我举的开车的例子来说,大部分人都会想到细分出等待过程中的各个环节,然后找出最耗时的几个环节,有目的性的进行优化。

· OWI是征兆学的。



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

请登录后发表评论 登录
全部评论
Oracle ACE组成员,DBGeeK用户组发起人。曾在DTCC、ORACLE技术嘉年华、Gdevops等公开场合做过数据库技术专题分享,2017年应Oracle邀请在世界最大的数据库会议OOW上做技术分享。组织翻译了《拨云见日,解密Oracle ASM内核》一书。

注册时间:2009-07-04

  • 博文量
    422
  • 访问量
    2304641