Oracle数据库11g新特性：可管理性

核心提示： 该屏幕显示了如何为量度 Cumulative Logons per second 定义阈值，您可以定义基线的关键阈值（此处定义为 60%），Oracle数据库11g新特性：可管理性(5)，该阈值一旦设定，当任一时间内的累计登录次数超过上周同一天同一时间内登录次数最大值的 60% 且这一情况

该屏幕显示了如何为量度 Cumulative Logons per second 定义阈值。您可以定义基线的关键阈值（此处定义为 60%）。该阈值一旦设定，当任一时间内的累计登录次数超过上周同一天同一时间内登录次数最大值的 60% 且这一情况发生至少两次时，就会触发严重警报。（60% 是一个很低的限制，该值仅用于演示。）

用户数会随着时间的推移而增长，警报阈值也将自动进行调整。您不但可以决定最大值的百分比，而且可以定义具体的值作为临界值和阈值。另一个参数 Occurrences 允许您仅当阈值被突破该参数指定的次数时才触发告警。

右侧的小图是在一段时间内量度出现的地方。注意，小方框是个缩放工具。您可以将它移动和放置到图形的任意区域上以显示详细信息。

正在审核的统计信息

考虑这样一种情况：您已经仔细收集了关于所有表、索引等的统计信息，同时所有查询都有完善的执行计划。但现在有人参与了统计信息收集工作，执行计划一下子变得截然不同。没错，这些计划可能更好（但也可能更糟，虽然概率低些）。

避免这种灾难的一种方法是使用 SQL 计划管理，您可以用它来创建 SQL 计划基线，从而为 SQL 语句锁定计划。但这并不是一个通用的解决方案。看不到的 SQL 语句不会有 SQL 计划基线，因此不会受到 SQL 计划管理的保护。

另外一个问题是何时收集统计信息。统计信息收集是一个大量占用 CPU 和频繁进行 I/O 的过程，您可能希望在相对安静的时间段（如晚上）完成这一工作。但当统计信息收集完毕后，计划立即会受到影响。您可能不希望一大早就要首先完成一个新的计划。相反，您希望统计信息在夜间就能准备好以供使用。矛盾在于，您需要现在就收集好统计信息而使其在以后生效。