使用脚本和查询来主动监视Oracle 9i的性能

超过250个配置参数、上千个测量值要监视，这些都让Oracle的管理员监视其Oracle数据库整体健康的工作不是一项轻松的任务。Oracle提供了各种工具来监视性能，但是这还是太多。要想有效地监视你Oracle数据库的健康，你就需要熟悉下面的脚本和查询：

• 数据缓冲区命中率警报会报告数据缓冲区命中率低于预设阙值的次数。
• 重做日志空间请求警报会在请求的数量大于0的时候提示出错。如果这种情况发生了，你可能需要增加log_buffer参数的值。
• 共享池争用警报会提示你出现了共享池争用以及和锁定相关的问题。
• 系统等待警报查询会询问Oracle的事件结构，以确定由于争用而出现过多等待的事件。
• 库缓冲失败警报查询会查找库缓冲失败率。如果库缓冲失败率超过.02，你就需要增加shared_pool_size的值来补救。
• 数据库编写器争用警报会查找不良查询总长的值、写入请求和数据库编写器工具（DBWR）的检查点。当写入请求的长度大于3或者大于DBWR 检查点的等待次数，你就需要调整数据库编写器的进程。
• 数据字典失败率警报会提示你对数据字典元数据请求过高的次数。有时你可以通过增加shared_pool_sizeinit.ora这个参数的值来缓解这个问题。
• 数据字典对象警告报告会揭示对Oracle数据字典的内部争用和字典元数据请求过高的次数。

仔细研究一下

现在让我们更加仔细地看一下这些脚本是如何工作的。STATSPACK这个工具按时间来处理Oracle的调配信息，并把这些信息记录在多个表格里。这些表格的名称会反映出Oracle内部查看表v$，这些名字诸如stats$sysstat和stats$sql_summary。知道了这一点，你就可以编写一些简单的Oracle查询，它们会显示性能的走势信息。然后你就可以处理这些性能信息，并把它们送到预示模型，例如线性回归，这会准确地告诉你更改你系统全局区域（System Global Area，SGA）内部结构的正确次数。

Listing A包含有使用这些性能信息的例子。这个脚本会生成一个在一段时间内库缓冲区失败率的连续总计，还会引用stats$librarycache表格。

这个脚本的输出会指出，你需要在这一期间内通过cron job或者dbms_job为shared_pool_size计划安排额外的内存，见图A。

图A

库缓冲失败率脚本的输出

动态性能重新配置

Table A高屋建瓴地查看一些主要的事件，这些事件能够引发动态的调配重新配置。为了说明这一点，我只会把重点放在表格里所出现的SGA的主要区域里。

表A

内存区域	太小的情况	太大的情况
共享池	库缓冲区失败	无失败现象
数据缓冲区	命中率< 90%	命中率> 95%
PGA集合	多次通过执行的次数过高	100%最佳执行

主要的重新配置触发器

很显然，库缓冲失败率过高表示共享池太小，Oracle七个数据缓冲池中任何一个的数据缓冲命中率低于90%都表示，你应该从数据库的其他区域里分一部分内存出来，重新分配给数据缓冲区。对于排序这样的操作，你要看一下程序全局区域（Program Global Area，PGA）里最佳执行的百分率，并在碰到排序操作的最佳执行率低于95%的时侯增加PGA集合目标参数的值。

针对数据缓冲区和共享池大小的规则是直接了当的，而新的pga_aggregate_target参数能够确保（对这些信息）更进一步的研究。作为一个通用的规则，当下列情况发生的时候，你就要更改pga_aggregate_target的值：

• 当v$sysstat的值――用于一次通过的估计PGA静态内存（estimated PGA memory for one-pass）超过pga_aggregate_target时，你就要增加pga_aggregate_target的值。
• 当v$sysstat的值――用于静态工作区执行-多次通过（workarea executions—multipass）大于1%时，数据库就能够从额外的内存获益。

你可能会为PGA分配过多的内存，这样在v$sysstat数据列的值――工作区执行-最佳（workarea executions—optimal）达到100%的时候，可能就要考虑减少pga_aggregate_target的值。

正如你能够看到的那样，对Oracle数据库的主动监视会是相当复杂的。由于有上百个测量值和参数需要监视和重新设置，所以对Oracle的调整将会是非常具有挑战性的。但是有了Oracle的性能测试工具和主要几个重新配置激发器的知识，你就可以开始调整好所有的事了。

　　

原文转自：http://www.ltesting.net