最近一直在思考一个问题：如何为一个数据库建立性能模型?作为一名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。 数据库响应时间分析： |