《Oracle数据库性能模型》由会员分享，可在线阅读，更多相关《Oracle数据库性能模型（7页珍藏版）》请在金锄头文库上搜索。
1、Oracle 数据库性能模型数据库性能模型6 16th, 2010 | Posted by jacky | Filed under 大话技术发表评论 | Trackback最近一直在思考一个问题：如何为一个数据库建立性能模型如何为一个数据库建立性能模型？作为一名 DBA 来说，我们面临的一个巨大挑战是：如何保证数据库的性能可以满足快速变化的应用的需求，如何在数据量和访问量持续增长的情况下，保证应用的响应时间和数据库的负载处在合理的水平下。我们可能会经常面对以下的问题：某个SQL 每秒要执行 100 次，响应时间是多少？某个应用发布后，对数据库的影响如何？所以，评估应用对数据库所产生的影响，优化
2、应用并预测风险，保证数据库的可用性和稳定性，这是应用 DBA 真正有价值的地方。响应时间为中心：响应时间为中心：如果要选择一个评价系统优劣的性能指标，毫无疑问应该是响应时间响应时间。响应时间是客户体验的第一要素，所有的优化都应该为降低响应时间而努力。对于数据库系统也是如此，我们优化系统，优化 SQL，最终目标都是为了降低响应时间，单位时间内可以处理更多的请求。数据库时间模型：数据库时间模型：响应时间一般分为服务时间(Service time)和等待时间(Wait time)，服务时间指进程占用 CPU 的时间，包括前台进程(Server process)和后台进程(Backgroud proc
3、ess)，我们一般只关注前台进程占用的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)
4、% of DB Timesql execute elapsed time3,062.1791.52DB CPU2,842.0884.95parse time elapsed25.870.77PL/SQL execution elapsed time11.750.35sequence load elapsed time7.550.23hard parse elapsed time5.060.15connection management call elapsed time3.130.09hard parse (sharing criteria) elapsed time0.040.00repea
5、ted bind elapsed time0.010.00PL/SQL compilation elapsed time0.000.00DB time3,345.74background elapsed time204.91background cpu time72.30DB time 是整个数据库用户进程消耗的总时间，是从第一项到第十项时间的总和（从 sql execute elapsed time 到 PL/SQL compilation elapsed time），但是我们会发现这十项时间的总和比 DB Time 要大一些，这是因为部分时间信息有重叠的部分，比如 SQL execute
6、elapsed time 就包括了很大一部分 DB cpu 的时间。而 background elapsed time 和 background cpu time 则是 Oracle 后台进程消耗的时间和 cpu time。数据库响应时间分析：数据库响应时间分析：数据库系统的响应时间由四个要素决定：数据库系统的响应时间由四个要素决定：CPU，IO，内存和网络，内存和网络，其中其中 CPU 和和 IO 是最重要的因素。是最重要的因素。与之相比，内存与网络则简单很多，因为通常情况下，对于一个调优的系统来说，内存访问的延迟时间非常小（100 ns 以下，1 ms=1000000 ns）相比较 CPU
7、 和 IO 几乎可以忽略。而网络延迟则通常是一个常数，比如在一个数据中心的情况下，网络的延迟一般在 3ms 以下，如果存在多数据中心的情况，网络延迟可能会超过 20ms，所以对于一个分布式系统来说，网络延迟是必须要考虑的问题。在这里，我们不考虑分布式系统，并且忽略内存的访问延迟，重点分析 CPU 和 IO，我们看以下数据库的AWR 片段：WaitWait ClassClassWaitsWaits%Time%Time - - outsoutsTotalTotal WaitWait TimeTime (s)(s)AvgAvg waitwait (ms)(ms)%DB%DB timetimeDBDB
8、 CPUCPU3,3513,35187.2187.21UserUser I/OI/O257,450257,4500 03503501 19.129.12CommitCommit127,672127,6720 090901 12.352.35Cluster53,77001000.27Concurrency25,6527900.24System I/O3,6230620.15Network2,069,0010500.14Application6790570.13Other20,82878400.10Configuration2,3530210.06我们看到这个系统中 DB CPU 占整个 DB t
9、ime 的 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 片段：WaitWait ClassClassWaitsWaits%Time%Time - - outsoutsTotalTotal WaitWait TimeTime (s)(s)Avg
10、Avg waitwait (ms)(ms)%DB%DB timetimeCommitCommit817,470817,4700 05,2325,2326 667.4967.49UserUser I/OI/O238,850238,8500 01,0831,0835 513.9713.97DBDB CPUCPU1,0711,07113.8213.82Configuration4,1501403975.20Concurrency42,626273110.40System I/O23,7420600.07Network1,838,0620200.03Application1250020.00Other
11、2,02682000.00我们看到，Commit 和 User I/O 占 DB time 的 81.46%，而 DB CPU 只占 13.82%，所以这个数据库系统是 IO instensive 类型的。Physical readPhysical read 是指 Oracle 在 buffer cache 中没有找到相应的 block，需要从 IO 子系统读取相应的block 的过程，对应的 IO 称为物理 IO，物理读数量代表物理 IO 读取的 block 数量。因为一般 IO 子系统都是慢速的磁盘，所以物理 IO 对整体响应时间的影响非常大，如果发生大量的物理 IO，整个系统的响应时间会
12、变得很差。系统的 IO 子系统可能是文件系统，裸设备或者 ASM，底层硬件可能是 SAN 存储，NAS 存储或者普通 SAS 磁盘等等。为了提高响应时间，通常在物理磁盘与 Oracle 之间增加 cache 层，对于 Oracle 来说，物理 IO 并不一定是真正访问磁盘，很可能是访问文件系统 cache，存储的 cache 等等。不管 IO subsystem 是什么，Oracle 只关心物理 IO 的响应时间。通过 AWR 报告，我们可以看到物理IO 的响应时间：EventEventWaitsWaits%Time%Time TotalTotal AvgAvg WaitsWaits % %
13、DBDB -outs-outsWaitWait TimeTime (s)(s)waitwait (ms)(ms)/txn/txntimetimedbdb filefile sequentialsequential readread4,315,8034,315,8030 011,20211,2023 329.6529.6553.0653.06dbdb filefile scatteredscattered readread320,148320,1480 01,4341,4344 42.202.206.796.79direct path read683,70701,23924.705.87SQL*
14、Net more data from client145,678079151.003.75loglog filefile syncsync145,656145,6560 04394393 31.001.002.082.08db file sequential read（单块读，随机 IO）的平均响应时间为 3ms，db file scattered read（多块读，连续 IO）的平均响应时间是 4ms，logfile file sync 的平均响应时间是 3ms，前两者的 Wait class 是 User I/O，代表用户进程读操作的响应时间，logfile sync 的 wait cla
15、ss 是 Commit，代表lgwr 进程写 redo 的响应时间，因为用户 commit 必须完成 log file sync 的操作，所以它也会直接影响用户进程写操作的响应时间。关于物理 IO 的响应时间，我们有一个经验值。对于 Sequential read 和 Scattered read，我们认为小于 10ms 属于正常状态，而大于 10ms 则认为 IO subsystem 的响应延迟过大。所以我们在衡量存储系统的性能时，只有响应时间在 10ms 以下的 IO 我们认为是有效的。这里有一个有趣的现象，就是sequential read 和 scattered read 的响应时间几
16、乎相差无几，也就是说随机 IO 读取 8K 数据和连续IO 读取 128K 数据，响应时间差别很小，这是由磁盘的机械特性造成的，延迟时间=寻道时间+延迟时间，顺序读和离散读的寻道时间一致，只是延迟时间有很小的差异，所以两者的响应时间差异很小。对于 log file sync 的响应时间，因为用户 commit 必须完成 log file sync，所以整个系统的写操作的响应时间都取决于它的响应时间，而且从整个数据库系统的角度去看，log file sync 几乎是串行的，所以这个响应时间对写操作影响非常大，我们的经验值是必须保证在 5ms 以下，如果超过 5ms 整个系统的写操作都会受到严重的影响。Logical readLogical read 是 Oracle 从 buffer cache 中读取 block 的过程，对应的 IO 称为逻辑 IO，逻辑读数量代表逻辑 IO 读取的 block 数量。因为 Oracle 必须首先将 block 读入 buffer cache 中
