可预见的Oracle应用程序的性能调优

核心提示： 在很多大型企业中，统计包的使用仍然被忽视，可预见的Oracle应用程序的性能调优(4)，这可能是带有胁迫性的报道，不要犯试图仅仅读取输出结果，如果CPU在一天中被经常性完全占用，就必须放弃某些设置，就能获取所有信息的错误，即使是第一页就足以告诉你这份报道中剩下的你应该重视的10％在哪儿

在很多大型企业中，统计包的使用仍然被忽视。这可能是带有胁迫性的报道。不要犯试图仅仅读取输出结果，就能获取所有信息的错误，即使是第一页就足以告诉你这份报道中剩下的你应该重视的10％在哪儿。Oracle 9.2版本的统计包，现在包含CPU和消耗时间列。以前，为了将长时间运行的SQL语句排序到最顶端，我们不得不开启“追踪”，连接追踪文件，并将它们交付程序tkprof来处理。对于那些一个简单的“追踪”就要处理多达10GB数据的大型企业而言，这是不现实的。

让用户参与到性能调优中去

将这条建议（即，让用户参与到性能调优中去）写入书中的人应该因其创造性而得到赞誉。让你的用户也参与到性能诊断中去。购买一台Oracle应用程序评测个人电脑，并把它给用户使用。不要使用与个人电脑类似的配置好的笔记本，因为在同样规范的情况下，笔记本没有个人电脑的同样性能特性。配置清单如下：

* 750 MB CPU

* 256 MB 内存

* Windows 2000 企业版（第四版）

* 使用独立的逻辑磁盘

* Jinitiator－锁定版

* 标准软件，例如Office 2003

供评测用的个人电脑不需要以下配置：

* 墙纸

* 屏幕截图

* 工具条

* 常驻程序

将评测用个人电脑送上用户的桌面，带着性能问题。将用户的电脑接入局域网，让用户工作一段时间。然后，再将用户的电脑放进计算机房间，并把它接入中间层，让用户在它上面进行更多的工作。评测用个人电脑消除了用户方对Oracle应用程序性能的主观性，同时也消除了面对用户抱怨性能问题你们的主观性。

索引计数和性能

回到70年代，开发者指南基本上说不要在一个表上建立4到5个索引。今天，开发者指南上的注释如下：

Oracle不限制在一个表上建立索引的个数。尽管如此，你需要考虑索引所带来的性能改善，以及你的数据库应用程序的实际需要，从而决定需要对哪些列建立索引。

事实是：每个Oracle应用程序表可能包含30多个索引。如果我们加入一个索引能将经常需要的SQL语句的输入输出减少，我们会不考虑高索引计数的问题而加入这个索引。

CPU

减小并发管理池的宽度，至今我们还没发现这会阻塞任务的进行。我们经常会看到的情景是：减小并发管理池的宽度实际上增加了批处理任务的吞吐量，它也使CPU不那么忙碌。有许多包含对等进程的任务必须被完成。如果一个任务的池宽度过窄，所需的任务可能永远也得不到处理，从而阻塞整体任务。

我们和Oracle应用程序安装小组、培训者打过交道，他们喜欢增加并发管理池的宽度，而无视对CPU的影响，这种设置一直保持到产品发布时仍然存在。在训练和测试环境中，安全问题的大门是开着的，并且安装者增加并发管理池的宽度以期望他们的批处理任务可以尽早完成。他们这样做或许根本没有考虑到对CPU的影响，CPU可能会因此而被完全占用。

CPU运行队列不应该比你的CPU计数的两倍还深。如果CPU在一天中被经常性完全占用，就必须放弃某些设置。寻找这个需要被放弃的设置的第一位置就应该是并发管理池。