Oracle数据库的性能模型

在此特别感谢：

源地址：http://soft.chinabyte.com/database/334/11592834.shtml

提供 ↑
　Oracle数据库的大恢复技巧介绍

　Java命令参数说明大全

　　最近一直在思考一个问题：如何为一个数据库创建性能模型？做为一名DBA来讲，咱们面临的一个巨大挑战是：如何保证数据库的性能能够知足快速变化的应用的需求，如何在数据量和访问量持续增加的状况下，保证应用的响应时间和数据库的负载处在合理的水平下。咱们可能会常常面对如下的问题：某个SQL每秒要执行100次，响应时间是多少？某个应用发布后，对数据库的影响如何？因此，评估应用对数据库所产生的影响，优化应用并预测风险，保证数据库的可用性和稳定性，这是应用DBA真正有价值的地方。

　　响应时间为中心：

　　若是要选择一个评价系统优劣的性能指标，毫无疑问应该是响应时间。响应时间是客户体验的第一要素，全部的优化都应该为下降响应时间而努力。对于数据库系统也是如此，咱们优化系统，优化SQL，最终目标都是为了下降响应时间，单位时间内能够处理更多的请求。

　　数据库时间模型：

　　响应时间通常分为服务时间(Service time)和等待时间(Wait time)，服务时间指进程占用CPU的时间，包括前台进程(Server process)和后台进程(Backgroud process)，咱们通常只关注前台进程占用的CPU time。等待时间包括不少类型，通常最多见的是IO等待和并发等待，IO等待包括sequential read，scattered read和log file sync等等，而并发等待主要是latch和enqueue。SQL execute elapsed time指用户进程执行SQL的响应时间，包含CPU time和wait time。

　　如下是Oracle数据库的时间模型：

 

　　在Oracle系统中，咱们能够利用AWR或Statspack报告，看到数据库的时间信息：

　　Statistic NameTime (s)% of DB Time

　　sql execute elapsed time3,062.1791.52

　　DB CPU2,842.0884.95

　　parse time elapsed25.870.77

　　PL/SQL execution elapsed time11.750.35

　　sequence load elapsed time7.550.23

　　hard parse elapsed time5.060.15

　　connection management call elapsed time3.130.09

　　hard parse (sharing criteria) elapsed time0.040.00

　　repeated bind elapsed time0.010.00

　　PL/SQL compilation elapsed time0.000.00

　　DB time3,345.74

　　background elapsed time204.91

　　background cpu time72.30

　　DB time是整个数据库用户进程消耗的总时间，是从第一项到第十项时间的总和(从sql execute elapsed time到PL/SQL compilation elapsed time)，可是咱们会发现这十项时间的总和比DB Time要大一些，这是由于部分时间信息有重叠的部分，好比SQL execute elapsed time就包括了很大一部分DB cpu的时间。而background elapsed time和background cpu time则是Oracle后台进程消耗的时间和cpu time。

　　数据库响应时间分析：

　　数据库系统的响应时间由四个要素决定：CPU，IO，内存和网络，其中CPU和IO是最重要的因素。与之相比，内存与网络则简单不少，由于一般状况下，对于一个调优的系统来讲，内存访问的延迟时间很是小(100 ns如下，1 ms=1000000 ns)相比较CPU和IO几乎能够忽略。而网络延迟则一般是一个常数，好比在一个数据中心的状况下，网络的延迟通常在3ms如下，若是存在多数据中心的状况，网络延迟可能会超过20ms，因此对于一个分布式系统来讲，网络延迟是必需要考虑的问题。

　　在这里，咱们不考虑分布式系统，而且忽略内存的访问延迟，重点分析CPU和IO，咱们看如下数据库的AWR片断：

 

　　咱们看到这个系统中DB CPU占整个DB time的87.21%，User I/O占整个DB time的9.12%，commit相关的IO等待占2.35%(主要是log file sync)，CPU和IO占用了整个DB time的96.68%。因为DB CPU所占的比例很高，因此这个数据库系统是CPU intensive类型，这里的DB CPU主要是执行SQL的服务时间。

　　咱们再看另外的一个数据库的AWR片断：

 

　　咱们看到，Commit和User I/O占DB time的81.46%，而DB CPU只占13.82%，因此这个数据库系统是IO instensive类型的。

　　Physical read

　　Physical read是指Oracle在buffer cache中没有找到相应的block，须要从IO子系统读取相应的block的过程，对应的IO称为物理IO，物理读数量表明物理IO读取的block数量。由于通常IO子系统都是慢速的磁盘，因此物理IO对总体响应时间的影响很是大，若是发生大量的物理IO，整个系统的响应时间会变得不好。系统的IO子系统多是文件系统，裸设备或者ASM，底层硬件多是SAN存储，NAS存储或者普通SAS磁盘等等。为了提升响应时间，一般在物理磁盘与Oracle之间增长cache层，对于Oracle来讲，物理IO并不必定是真正访问磁盘，极可能是访问文件系统cache，存储的cache等等。

　　无论IO subsystem是什么，Oracle只关心物理IO的响应时间。经过AWR报告，咱们能够看到物理IO的响应时间：

 

　　db file sequential read(单块读，随机IO)的平均响应时间为3ms，db file scattered read(多块读，连续IO)的平均响应时间是4ms，logfile file sync的平均响应时间是3ms，前二者的Wait class是User I/O，表明用户进程读操做的响应时间，logfile sync的wait class是Commit，表明lgwr进程写redo的响应时间，由于用户commit必须完成log file sync的操做，因此它也会直接影响用户进程写操做的响应时间。

　　关于物理IO的响应时间，咱们有一个经验值。对于Sequential read和Scattered read，咱们认为小于10ms属于正常状态，而大于10ms则认为IO subsystem的响应延迟过大。因此咱们在衡量存储系统的性能时，只有响应时间在10ms如下的IO咱们认为是有效的。这里有一个有趣的现象，就是sequential read和scattered read的响应时间几乎相差无几，也就是说随机IO读取8K数据和连续IO读取128K数据，响应时间差异很小，这是由磁盘的机械特性形成的，延迟时间=寻道时间+

　　对于log file sync的响应时间，由于用户commit必须完成log file sync，因此整个系统的写操做的响应时间都取决于它的响应时间，并且从整个数据库系统的角度去看，log file sync几乎是串行的，因此这个响应时间对写操做影响很是大，咱们的经验值是必须保证在5ms如下，若是超过5ms整个系统的写操做都会受到严重的影响。

　　Logical read

　　Logical read是Oracle从buffer cache中读取block的过程，对应的IO称为逻辑IO，逻辑读数量表明逻辑IO读取的block数量。由于Oracle必须首先将block读入buffer cache中(direct path read除外)，因此逻辑读数量包含了物理读数量。对于一个SQL来讲，逻辑读数量是衡量其性能的标准，而不是物理读。虽然物理IO的响应延迟比逻辑IO大不少，可是物理读数量会随着执行次数而变化(频繁读取致使block被缓存在buffer cache中)。对于一个系统也是如此，逻辑读应该是数据库性能评估模型的核心，咱们须要创建逻辑读与响应时间的对应关系。

　　每一个逻辑读的响应时间是多少，这是一个巨大的挑战。由于每一个逻辑读背后隐藏了不少动做，可能包括物理读，等待事件，CPU time等等。我对不少数据库的AWR报告作了分析，指望根据经验值创建一个简化的模型。咱们假设一个数据库若是是充分调优的，除CPU time和IO之外的等待时间应该尽量少(应小于DB time 10%)。在这个前提下，咱们只关心CPU time和IO的影响，并将系统分为三类：CPU密集型，IO密集型和混合型：

　　1.IO密集型

　　User IO 85%

　　DB CPU 5%

　　每逻辑读响应时间0.1-0.5ms

　　2.CPU密集型

　　DB CPU 85%

　　User IO 10%

　　每逻辑读响应时间小于0.01ms

　　3.混合型

　　User I/O 60%

　　DB CPU 20%

　　每逻辑读响应时间0.05-0.1ms

　　以上数据是根据不少个典型数据库的AWR报告计算出来的经验值，计算公式很简单：DB time/逻辑读=每逻辑读响应时间。由于并无考虑硬件和OS上的差别，因此这个数值并非特别准确，但咱们仍是能够发现一些规律：随着IO所占比例从10%增长到85%，响应时间也从小于0.01ms到0.5ms。

　　预测系统瓶颈

　　对于数据库来讲，IO子系统对性能影响很是大，必须保证在必定的IO的压力下，响应延迟控制在合理的范围内(前面说的10ms和5ms)。由于每块磁盘能够承受的IOPS是基本肯定的，好比15K的SAS磁盘，在响应延迟不超过10ms的前提下，能够提供150个IOPS，若是不考虑cache的影响，整个存储子系统的IOPS是比较容易计算的。咱们能够在系统上线前，进行大量充分的测试，创建存储IOPS与响应延迟的模型，这样咱们就能够预测出性能出现拐点的风险，提早作出扩容的判断。在AWR报告中，咱们能够获得每秒的物理IO的数量和响应时间，能够方便的实现性能监控和趋势预警。

　　评估CPU的容量瓶颈相对简单，Oracle中CPU time的计算是每一个CPU耗费时间的总和，若是有16颗(核)CPU，1个小时理论上能够提供3600×16=57600s CPU time，不超过57600s CPU time咱们能够认为不会在CPU上排队，系统不会出现CPU瓶颈。可是须要注意的是，除了用户进程使用CPU之外，操做系统也须要占用CPU资源，用来管理内存和进程调度等。咱们在OS上看到的CPU使用率中的sys部分就是系统占用的CPU资源，因此应该考虑至少保留10-20%的CPU资源给OS使用。

　　并发访问对数据库的影响

　　Oracle是一个Disk-based database，设计的出发点就是大部分数据在外部存储中，而只有小部分数据被cache在buffer中，它既不一样于Memcache这类KV cache，也不一样于timesten这类In-memory database。因此，就算是全部的数据均可以被cache在buffer中，在高并发访问的状况下，也可能会出现大量的latch等待，最多见的状况就是cache buffer chain。当大量并发访问同一块数据时，就极可能会出现cache buffer chain的latch争用，也就是咱们常说的“热点”。

　　须要注意的是：Oracle中的latch等待分为spin和sleep两个部分，spin消耗cpu time，而sleep则是等待时间。因此大量的latch等待不只仅会产生大量的等待时间，并且会消耗大量的CPU time。

　　Oracle是一个为并发操做而设计的数据库，大量的并发读写请求，可能会带来额外的性能消耗。好比读取一部分频繁修改的数据，Oracle为了保证一致性读的须要，会利用undo信息构造产生大量CR block，同时会产生大量的逻辑读，这样会消耗额外的CPU和响应时间。

　　存储也可能存在热点的问题，须要前期对存储系统充分的优化，常见的手段是利用RAID技术，将数据分散在不一样的磁盘上，防止出现“热点”盘。Oracle ASM提供了Rebalance的功能，容许DBA将存储中的的数据从新分布，达到消除热点的目的。

　　总之，Oracle是一个能够提供大量并发读写访问的数据库系统，可是在不少地方，Oracle又不得采用一些串行的控制手段，好比latch，enqueue和mutex，咱们要作的就是尽可能下降这些串行控制对数据库总体性能的影响。

　　数据库优化原则

　　基于响应时间的Oracle优化原则：尽可能减小等待时间(Wait time)，提升服务时间(Service time)。这也是基于Oracle等待事件的分析方法的基本原则：尽可能消除各类等待事件对系统的影响，从而提升系统性能和响应时间。

　　若是数据库系统除了CPU和IO之外的等待时间超过DB time的5%以上的话，可能存在某些性能问题，须要DBA采用等待事件的分析方法，对系统或应用进行优化。

原文出自【比特网】，转载请保留原文连接：http://soft.chinabyte.com/database/334/11592834.shtml