Oracle数据库性能模型.docx

DBA来说，我们最近一宜在思考一个问题：如何为一个数据库建立性能模型？作为一名面临的一个巨大挑战是：如何保证数据库的性能可以满足快速变化的应用的需求，如何在数据量和访问量持续增长的情况下，保证应用的响应时间和数据库的负载处在合理的水平下我们可能会经常面对以下的问题：某个SQL每秒要执行100次，响应时间是多少？某个应用发布后，对数据库的影响如何？所以，评估应用对数据库所产生的影响，优化应用并预测风险，保证数据库的可用性和稳定性，这是应用DBA真正有价值的地方响应时间为中心：如果要选择一个评价系统优劣的性能指标，亳无疑问应该是响应时间响应时间是客户体验的第一要素，所有的优化都应该为降低响应时间而努力对于数据库系统也是如此，我们优化系统，优化SQL,最终目标都是为了降低响应时间，单位时间内可以处理更多的请求数据库时间模型：响应时间一般分为服务时间(Servicetime)和等待时间(Waittime),服务时间指进程占用CPU的时间，包括前台进程(Serverprocess和后台进程(Backgroudprocess),我们一般只关注前台进程占用的CPLltimeo等待时间包括很多类型，一般最常见的是10等待和并发等待，10等待包括sequentialread,scatteredread和logfilesync等等，而并发等待主要是latch和enqueueoSQLexecuteelapsedtime指用户进程执行SQL的响应时问，包含CPUtime和waittime。

以下是Oracle数据库的时间模型:BackgroupprocessServerprocessIOwailConcurrencyDBCPULogfiBesyncSequentialreadScatteredreadLatchLock在Oracle系统中，我们可以利用AWR或Statspack报告，看到数据库的时间信息sqlexecutee1apsodtime3.062.1791.52DBCPU2.842.0884.95parsetimeelapsed25.870.77PL/SQLexecutione1apsedtimo11.750.35sequeneeloade1apsedtime7.550.23hardparseelapsedtime5.060.15connectionmanagementcal1elapsedtime3.130.09hardparse(sharingcriteria)elapsedtime0.010.00repeatedbindelapsedtime0.010.00PL/SQI.pilationelapsedtime0.000.00DBtime3?345?74backgroundelapsedtime201.91backgroundcputime72.30DBtime是整个数据库用户进程消耗的总时间，是从第一项到第十项时间的总和(从sqlexecuteelapsedtime到PL/SQLpilationelapsedtime),但是我们会发现这十项时间的总和比DBTime要大一些，这是因为部分时间信息有重叠的部分，比如SQLexecuteelapsedtime就包括了很大一部分DBcpu的时间。

而backgroundelapsedtime禾口backgroundcputime贝U是Oracle后台进程消耗的时间禾口cputime数据库响应时间分析：数据库系统的响应时间由四个要素决定：CPU,10,内存和网络，其中CPU和10長最重要的因素与之相比，內存与网络则简单很多，因为通常情况下，对于一个调优的系统来说，内存访问的延迟时间非常小（100ns以下，1ms二1000000ns）相比较CPU和10几乎可以忽略而网络延迟则通常是一个常数，比如在一个数据中心的情况下，网络的延迟一般在3ms以下，如果存在多数据中心的情况，网络延迟可能会超过20ms所以对于一个分布式系统来说，网络延迟是必须要考虑的问题在这里，我们不考虑分布式系统，并且忽略内存的访问延迟，重点分析CPU和10,我们看以下数据库的AWR片段：WaitClassWaitsQ4)TimG-outsTotalWaitTime(s)Avgwait(ms)忱DBtimeDBCPU3,35187.21UserI/O257,450035019.12Commit127,672□9012.35Cluster53,77001000.27Concurrency25z6527900.24SystemI/O3.,6230620.15Network2.-069,0010500.14Application6790570.13Other20z82878400.10Configuration23530210.06我们看到这个系统中DBCPU占整个DBtime的87.21%,UserI/O占整个DBtime的9.12%,mit相关的10等待占2.35%（主要是logfilesync）.CPU和10占用了整个DBtime的96.68%。

由于DBCPU所占的比例很高，所以这个数据库系统是CPUintensive类型，这里的DBCPU主要是执行SQL的服务时间我们再看另外的一个数据库的AWR片段:WaitClassWaits%Time-outsTotalWaitTime(s)Avgwait(ms)%DBtimeCommit817r47005f232667.49UserI/O238,8500lz083513.97DBCPUlz07113.82Configuration4,1501403975.20Concurrency42,626273110.40SystemI/O23J420600.07Network1,838,0620200.03Application1250020.00Other2,02682000.00我们看到，mit和UserI/O占DBtime的81.46%,而DBCPU只占13.82%,所以这个数据库系统是IOinstensive类型的PhysicalreadPhysicalread是指Oracle在buffercache中没有找到相应的block,需要从10子系统读取相应的block的过程，对应的10称为物理10,物理读数量代表物理10读取的block数量。

因为一般10子系统都是慢速的磁盘，所以物理10对整体响应时间的影响非常大，女口果发生大量的物理10,整个系统的响应时间会变得很差系统的10子系统可能是文件系统，裸设备或者ASM,底层硬件可能是SAN存储，NAS存储或者普通SAS磁盘等等为了提高响应时间，通常在物理磁盘与Oracle之间增加cache层，对于Oracle来说，物理10并不一定是真正访问磁盘，很可能是访问文件系统cache存储的cache等等不管10subsystem是什么，Orscle只关心物理10的响应时间通过AWR报告，我们可以看到物理10的响应时间：EventWaitsQATimG-outsTotalWaitTime(s)Avgwait(ms)Waits/txn%DBtimedbfilesequentialread4z215z803Ollr202329.6553.06dbfilescattArpdread320,14801,43442.206.79directpathread683..70701,23924.705.87SQLANAtmoredatafromclient145,678079151.003.75logfilesync145,656043931.002.08dbfilesequentialread（单块读,随机10）的平均响应时间为3ms,dbfilescatteredread（多块读，连续IO）的平均响应时间是4ms,logfilefilesync的平均响应时间是3ms,前两者的Waitclass是UserI/O,代表用户进程读操作的响应时间，logfilesync的waitclass是mit,代表lgwr进程写redo的响应时间，因为用户mit必须完成logfilesync的操作，所以它也会直接影响用户进程写操作的响应时间。

关于物理10的响应时间,我们有一个经验值对于Sequentialread和Scatteredread,我们认为小于10ms属于正常■状态，而大于10ms则认为10subsystem的响应延迟过大所以我们在衡量存储系统的性能时，只有响应时间在10ms以下的10我们认为是有效的这里有一个有趣的现象，就是sequentialread和scatteredread的响应时间几乎相差无几，也就是说随机10读取8K数据和连续10读取128K数据，响应时间差别很小，这是由磁盘的机械特性造成的，延迟时间二寻道时间+对于logf订esync的响应时间,因为用户mit必须完成logfilesync,所以整个系统的写操作的响应时间都取决于它的响应时间，而且从整个数据库系统的角度去看，logfilesync几乎是串行的，所以这个响应时间对写操作影响非常大，我们的经验值是必须保证在5ms以下，如果超过5ms整个系统的写操作都会受到严重的影响LogicalreadLogicalread是Orac1e从buffercache中读取block的过程，对应的10称为逻辑10,逻辑读数量代表逻辑10读取的block数量因为Oracle必须首先将block读入buffercache中（directpathread除外），所以逻辑读数量包含了物理读数量。

对于一个SQL来说，逻辑读数量是衡量其性能的标准，而不是物理读虽然物理10的响应延迟比逻辑10大很多，但是物理读数量会随着执行次数而变化（频繁读取导致block被缓存在buffercache中）对于一个系统也是如此，逻辑读应该是数据库性能评估模型的核心，我们需要建立逻辑读与响应时间的对应关系每个逻辑读的响应时间是多少，这是一个巨大的挑战因为每个逻辑读背后隐藏了很多动作，可能包括物理读，等待事件，CPUtime等等我对很多数据库的AWR报告做了分析,期望根据经验值建立一个简化的模型我们假设一个数据库如果是充分调优的，除CPUtime和10以外的等待时间应该尽可能少（应小于DBtime10%）在这个前提下，我们只关心CPUtime和10的影响，并将系统分为三类：CPU密集型，10密集型和混合型：1.10密集型User1085%DBCPU5%每逻辑读响应时间0.1-0.5ms2.CPU密集型10%85%每逻辑读响应时间小于0.01msDBCPUUserIO3.混合型60%20%UserI/ODBCPU每逻辑读响应时间0.05-0.1ms以上数据是根据很多个典型数据库的AWR报告计算出来的经验值，计算公式很简。