如何有效应用时间的有限和无限

排队时间是不固定的，并且只被工作负载所限制。如果工作负荷相对比较小，排队时间就可能接近于0。但是当工作负载不断增加，排队时间就会达到无限——它没有限制。

有关排队时间无限的说法提出了两个我们需要思考的概念。首先，如果Oracle消耗了所有可用的CPU，那么要求更多的CPU就需要增加服务时间，同时也有可能增加Oracle等待时间。结果就是响应时间的增加。这是不好的，非常不好。这意味着我们的解决方案需要仔细权衡它们是如何影响CPU子系统的。(这个概念在我的新论文《Oracle等待接口详解》中有详细的解释。)第二个概念就是我们现在有另一种方式来查看一个非常动态的系统。这不仅可以帮助我们理解系统，还可以让我们帮助其他人来理解潜在的非常复杂的基于Oracle的系统。

例如，考虑下面的图。数据是从实际生活中的Oracle系统上收集到的。每个小时、响应时间组件都会被收集并且总结。排队时间从v$system_event中收集，服务时间是从v$sysstat中收集。通过查看这幅图，如果性能是糟糕的，所有的非Oracle服务器体系组件都表明不是瓶颈，瓶颈就应该是在Oracle服务器中了。通过以下的图，我们可以推断，IO子系统有很严重的瓶颈，或者锁定/阻塞问题。也许2200左右就是CPU的瓶颈，但是剩余的时间肯定是IO瓶颈或者锁定/阻塞问题。

让我们更仔细地看一下。问题都集中在可用的Oracle消耗的操作系统的CPU能力百分比。仔细查看上述的图形。我们从CPU子系统开始。因为在一个小时里面大概消耗了大约1000分钟的最大CPU时间，我们知道那肯定至少有17个CPU。最糟糕的情况就是使用的CPU资源相当于可用的CPU资源。这一点可以结合从上述图形中的数字得到:

可用的CPU = 使用的CPU

X CPUs * 60 分钟/小时 = 1000分钟/小时

X CPUs = 1000分钟/小时 / 60分钟/小时

X CPUs = 16.67

所以，数据库服务器上至少有17个CPU。如果我们从对操作系统的监控中发现，CPU的利用率在50%左右，大概是2200，我们还可以推断出大概有34个CPU(16.67 X 2)。

现在让我们把信息放在一起，这样它们就有用了。请注意在午餐时间附近，Oracle每小时消耗的CPU时间达到1000分钟。我们知道服务器可以每小时提供1000个CPU分钟，在午餐时间，它提供的时间少于每小时500个CPU分钟，用户并不满意这样的性能。因此，我们可以推断出排队时间(例如，Oracle等待事件)并不是CPU相关的， 而是与I/O有关的，或者是相关锁定/阻塞(例如排队等待)。有力的信息!

我们知道理解和应用Oracle响应时间组件可以增加我们的性能威力。但是理解了Oracle服务时间是如何与CPU的操作系统相关联的，就是另一个级别的了。在没有理解Oracle从操作系统中消耗的可用的CPU的百分比的时候，我们就无法了解是否有足够的CPU可用。对CPU百分比的了解可以让我们的性能诊断更加准确，可以得出更加有力的解决方案。理解了时间的有限和无限，不仅仅可以帮助你，还有你的同事，以及你需要影响的人们。他们越好的理解这个情况，他们就越同意你的行动建议。换句话说，它使得你的性能分析更加有力，构建了信任。这也是所有的数据库管理员们都用得最多的。