Oracle 10g 具有允许限制各种资源的配置文件。为了清楚起见，这里有一些引用 - orafaq.com , Oracle Documentation .我对限制 CPU_PER_CALL、LOGICAL_READS_PER_CALL 和 COMPOSITE_LIMIT 特别感兴趣，目的是防止格式不正确的语句破坏其他所有 session 的性能。
我的问题是，我不知道为这些参数使用什么值可以允许典型的长时间运行的资源密集型操作，同时防止真正糟糕的操作。我意识到这些值会根据所涉及的硬件、容错级别和查询而有所不同，这就是为什么我对一种可用于确定最佳值的方法更感兴趣。
最佳答案
有多种方法，视情况而定。最简单且可行的方法是询问运行时间最长的实际操作将运行多长时间(这显然取决于系统，并且取决于这是您正在构建的系统还是现有系统)并返回到基于该时间限制和并行度的 CPU_PER_CALL。假设单线程操作，如果你可以合理地说如果一个查询在 30 分钟内没有返回你想杀死它，你可以设置 CPU_PER_CALL 分配 30 分钟的 CPU(显然大多数查询不会使用 100 % 不断，所以 30 分钟的限制会给你一些喘息的空间)。
如果这是现有系统，您(或您的 DBA)可以在合理的天数内查看 AWR/statspack 报告(某些系统需要确保查看月/季度/年末的报告，其中可能会进行额外的处理)并找到使用最多 CPU 和 I/O 的真实语句。然后，您可以适本地设置您的配置文件限制(即在过去一个月中为语句记录的最大 CPU + 30% 的喘息空间)。
当然，对于您选择的任何限制，都必须有人监控系统以确保限制与时俱进。例如，如果查询由于数据量的增加而随着时间的推移变得越来越昂贵，那么 max + 30% 的限制在 6 个月内可能是不够的。您不想在夜间处理中止时发现这一点，必须有人掌握这一点。
如果您使用的是企业版，那么查看资源管理器而不是配置文件可能会更好。配置文件允许您终止失控的 session ，而资源管理器允许您根据各种因素更改 session 优先级。与其终止使用超过 30 分钟 CPU 的查询，不如降低它的优先级，这样它就不会在不终止它的情况下干扰其他 session ，以防它运行时间过长。
关于performance - 如何将 Oracle 用户配置文件投入实际使用？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/883099/