基本上来说，猜测Oracle的性能对每一个数据库治理员的理解和工作都具有绝对的重要性。当性能开始下降的时候，是数据库治理员对其进行审查，是数据库治理员来进行修复。
是数据库治理员最熟悉数据库服务器的知识，所以他们难道不能对性能进行猜测吗?当系统要添加一些新的用户的时候，最快询问的就是数据库治理员，“这不会出现问题，是吗?”因此，数据库治理员需要有快速猜测性能的能力。不甚精确的猜测可以飞快的完成，这是开始猜测Oracle性能的一个很好的方式。
我们想要猜测的一个要害点就是利用率、队列长度，以及响应时间。仅仅通过上述的三个因素，作为数据库治理员，你可以执行各种类型的较低精度的what-if 场景。要得到价值，你基本上需要一下的三项内容:
一些简单的公式
一些基本的操作系统统计数字
一些基本的Oracle统计数字
在你开始利用这些公式之前，理解一些概念并熟悉它们的标记是很重要的。
S:为一个工作单元服务的时间。它通常是服务时间或者服务需求。是CPU为一个单独的事务服务的时间长度。例如，每个事务1.5秒，或者是1.5 sec/trx 。获得Oracle系统的这个数值的最好方式就是计算。
U:利用率或者CPU繁忙度。一般来说，这个数是一个百分数，也是它在这个公式中的出现方式。例如，在公式中，它应该是类似75% 或者 0.75这样的数字，而不是75。收集CPU利用率的一个简单方式就是运行sar –u 60 1。这将给你在过去的60秒中CPU的平均利用率。
λ:工作到达率。这是每个单元时间内进入系统的事务的数量(例如，每秒150个事务，或者150 trx/sec)。当使用Oracle工作的时候，有许多可能的统计数字可以用来计算“事务”到达率。使用v$sysstat 收集到的一般的统计数字是针对逻辑读取、块交换、物理写入、用户调用、登录、执行、用户提交，以及用户回滚。你还可以根据你的经验将上述操作进行混和和匹配。在这篇文章里，我们将会简单使用地使用用户调用。
Q:队列长度。这是正在等待服务的事务的数量。其中排除了当前正在被服务的事务的数量。我们将会导出这个数值。
M:CPU的数量。你可以从cpu_count 这个环境参数中得到数值。
计算平均数的CPU公式，如下所示:
U = ( S λ ) / M (1)
R = S / (1-U) (2)
Q = R λ – M (3)
在我们采用现实生活中的例子之前，让我们先通过以下的理论实验来检查一下公式。
理论实验1:使用公式(1)，假如1CPU的利用率是50%，那么用2个CPU就是25%。公式的结果也是如此。因为你已经计算出来了，可测量性就不再予以考虑。
理论实验2:使用公式(1)，假如我们增加到达率，CPU的利用率也应该上升。
理论实验3:使用公式(1)，假如我们使用更快的CPU，那么服务时间应该减少，那么利用率应该下降。
理论实验4:使用公式(2)，假如利用率上升，分母就下降，应该导致响应时间增加。
理论实验5:使用公式(3)，假如CPU的数量增加，那么队列长度就应该减少。
理论实验6:使用公式(3)，假如到达率上升，队列长度就应该上升。
现在，你可以对公式有些感觉，并认为它是争取的了吧，下面让我们看看实际的例子。
例子1:让我们说一下在过去的60秒中，你在单CPU的Linux机器上收集到的CPU平均利用率和用户调用的数量。你发现平均利用率是65%，Oracle处理了750个用户调用。每秒钟用户调用的数量就是12.5(即，750/60 = 12.5)。
因此
S = 0.052 sec/call ; U = ( S λ ) / M ; 0.65 = ( S * 12.500 ) / 1
R = 0.149 sec/call ; R = S / (1-U) ; R = 0.052 / ( 1 – 0.65 )
Q = 0.863 calls ; Q = R λ – M ; Q = ( 0.149 sec/call * 12.5 calls/sec ) – 1
我们能够立即用到的惟一一个数字就是队列长度。平均来说，大概有一个等待CPU周期的进程。这对于性能和用户来说是不好的。假如用户对性能不满足的话也没什么惊奇的。假如他们认为性能还不错，那么现在就开始为未来做一个计划是一个不错的主意。
当我们使用不同的配置或者工作场景来重新计算响应时间和服务时间会更有用。例如，我们考虑一下当你的工作量每15分钟会增加20%的情况。当响应时间明显增加的时候，会经过多少个15分钟?第二个例子中，我们将会看到这个效果。
例子2:我们假设目前的性能是可以接受的，但是数据库治理员不知道这种情况将持续多久。假设工作量每15分钟都会增加20%，使用上面描述的情景作为我们的基本线，并使用上面的三个基本公式，下面是每15分钟的情况。
我们可以立即看到在第三个15分钟，利用率超过了100%(即，104%)。
这导致饿了不稳定的系统，因为队列一直在增加。响应时间和队列长度计算也都会受到负面影响，显示了现在的系统很不稳定。
我们回答下面这个问题，“系统什么时候会崩溃?”，答案类似“在第二个和第三个15分钟之间的某个时间。”然而，这是个非常明显并且非常乐观的具有高风险的答案。下面让我们挖掘得更深一些。
当利用率达到100%之前性能下降就发生了，正如响应时间和队列长度的变化显示的。所以，当系统在第二个15分钟中陷入技术性活动的时候，响应时间已经显著增加了，并且用户毫无疑问会感到不兴奋。基于以上的情况，假如用户对当前的性能表示满足的话，那么他们很有可能不会在下一刻仍然感到满足。响应时间差不多增加一倍，队列长度也会达到灾难性的2.55!
那么选项是什么?在这一点上，有许多的选项，但是我们在另一篇文章中讨论这些问题。
在猜测之前清楚地理解精确需求和可获得的准确度是重要的。使用上面描述的方法来获得的准确度是非常低的。这是因为以下几个原因，其中的几个愿意就是:只收集了一个数据样本，猜测是无效的，工作量没有仔细地描述，并且我们的模型只考虑了CPU子系统。当需要做出更加精确的猜测的时候，可以用到HoriZone 这样的产品。但是许多时候，一个快速但是准确度较低的猜测是必需的。在这种情况下，你可以使用上面列出的公式对当前环境有一个大概的概念。
正如你看到的，仅仅利用上面几个基本公式和一些性能数据，可以做出有用的猜测结果结果。性能猜测将会是扩展到数据库治理员的专业领域的猜测领域，可以用往返答那些我们在星期五下午的4点半被问到的刁钻的问题，还可以帮助预见到糟糕的性能。
