随着数据库的越来越庞大，开发者是越来越如履薄冰，还是他们不能保持知识技能的更新，与爆炸式的需求增长率同步?不管怎么样，Oracle 11g对于数据库管理员来说，是一个得力助手，帮助他们发现和处理资源扰乱代码(resource-hogging code)。

　　Oracle 11g的启动器，对它的自动SQL调整增加了“自我学习”的功能。现在引擎能够检测高负荷量的SQL语句，并且将其保存下来，以便在维护窗口中调整。他能够实施一些自动修改，或是建议查询进行结构变化，如使用索引。如果你让引擎来做更多的关于查询性能调整的话，你可以让它来捕获你的查询语句，并且进行建议修改。此时，如果引擎大多数时间的实施能够证明是对的话，你就能更加信任他了。有一个问题是Oracle不能考虑整个工作负荷，因此所做的改变或许对某个常见查询的常规数据流造成损害。

　　有不止一种方式来量化某个失去控制的工作负荷，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语句，来阻止系统故障，那么你将只有很少的资源可用，因为故障已经占用了很多资源了。最终结果是你需要花上更多的时间。