Oracle 10g 具有允许限制各种资源的配置文件。为了清楚起见，这里有一些参考资料 - orafaq.com，Oracle 文档。我对限制CPU_PER_CALL,LOGICAL_READS_PER_CALL以及COMPOSITE_LIMIT防止格式不正确的语句破坏其他会话的性能特别感兴趣。
我的问题是我不知道为这些参数使用什么值，这些值将允许您进行典型的长时间运行的资源密集型操作，同时防止真正糟糕的操作。我意识到这些值会根据所涉及的硬件、容差级别和查询而有所不同，这就是为什么我更感兴趣的方法是确定哪些值是最好的。
有多种方法，视情况而定。有任何工作希望的最简单的可能方法是询问运行时间最长的实际操作将运行多长时间（这显然取决于系统，并且取决于这是您正在构建的系统还是现有的系统）并返回基于该时间限制和并行度的 CPU_PER_CALL。假设单线程操作，如果你可以合理地说如果一个查询在 30 分钟内没有返回你想杀死它，你可以设置 CPU_PER_CALL 分配 30 分钟的 CPU（显然大多数查询不会使用 100 % 不断，因此 30 分钟的限制为您提供了一些呼吸空间）。
如果这是一个现有系统，您（或您的 DBA）可以在合理的天数内查看 AWR/statspack 报告（某些系统需要确保查看月/季度/年末的报告，其中可能会进行额外处理完成）并找到使用最多 CPU 和 I/O 的真实语句。然后，您可以适当地设置您的配置文件限制（即，在过去一个月中为语句记录的最大 CPU + 30% 的呼吸空间）。
当然，对于您选择的任何限制，都必须有人监控系统以确保限制保持同步。例如，如果查询由于数据量的增加而变得越来越昂贵，那么在 6 个月内，最大 + 30% 的限制可能是不够的。您不想在夜间处理中止时发现这一点，必须有人继续关注。
如果您使用的是企业版，那么查看资源管理器而不是配置文件可能会更好。虽然配置文件允许您终止失控会话，但资源管理器允许您根据各种因素更改会话优先级。与其杀死一个使用超过 30 分钟 CPU 的查询，不如将其设置为较低的优先级，这样它就不会在不杀死它的情况下干扰其他会话，以防它运行很长时间。