究竟是否需要升级到Oracle 11g？

核心提示： 有不止一种方式来量化某个失去控制的工作负荷，Oracle有能力对付这种局面，究竟是否需要升级到Oracle 11g？(3)，当工作负荷出错，引起这种错误的原因通常是服务器性能三大主要因素之一：CPU、内存、磁盘I/O，仅仅由于传递的参数不同而使得查询不同(大多数的OLTP请求也是一样的)，

有不止一种方式来量化某个失去控制的工作负荷，Oracle有能力对付这种局面。当工作负荷出错，引起这种错误的原因通常是服务器性能三大主要因素之一：CPU、内存、磁盘I/O。通常资源控制器通过测量CPU或者内存来量化失控的工作负荷，但是Oracle 11g也能通过查看一段时间的I/O极限来测定。

这些I/O极限能够允许你设定工作负荷的最大值(无论是以I/O请求或是兆字节的方式)，这样一来服务器上的最大连接数就可以确定。I/O极限是一个非常重要的附加功能，尤其是在大型仓库的情形下，因为这些系统能够很容易达到磁盘的容量极限，并且CPU或者内存资源上限(capping)不能充分的解决磁盘争用(disk contention)。

I/O限制还能够帮助DBA中途结束长时间运行的查询。由于没有别的办法来定义这种策略：是否这个查询在20分钟内占用CPU的20%，那么这种I/O限制就很有用了。举个例子，DBA将会经常写他们自己的check，接着写一些代码来中断这些长时间的运行结果。能够给整个I/O消耗加一个限制意味着不需要再手动来管理这些check。

按照惯例来说，当出现问题时，你可以将这些长期运行的查询任务移到低级别的资源组中去。有些像曲棍球比赛中，将其遣送到受罚席去。如果你通过写SQL语句，来阻止系统故障，那么你将只有很少的资源可用，因为故障已经占用了很多资源了。最终结果是你需要花上更多的时间。

Result Cache这个功能特性，要么是你使用得非常成功，要么彻底失败，关键是看谁来掌舵。Result Cache能够让你非常高效的将一个查询结果集插入到内存中的一个专门的缓冲器中，因此当以后请求同一个查询的时候，就能对磁盘查找起到分路的作用。你能缓存整个查询，子查询，甚至PL/SQL函数。当然，随后调用的查询请求必须和高速缓存的查询一致。在大多数情况下，仅仅由于传递的参数不同而使得查询不同(大多数的OLTP请求也是一样的)，因此你必须要缓存很多的查询，实际上也只有很少的查询能重用。