Oracle数据库应用程序性能优化探究
什么是用户不能告诉你的
针对某个用户的从底向上的方法揭示了一个单独的包消耗的输入输出资源占全部的25％左右。对另一个用户而言，一个单独的查询可能会引起每周4.3TB的缓冲输入输出。性能调优使得缓冲开销降至原先的0.06％。问题是它会耗尽CPU资源，同时，在那种情况下，是否对CPU进行扩充还需慎重考虑。没有人知道系统堆栈正在抵销这个代价。
关于性能调优保守最严密的一个秘密在Oracle性能调优指南中被发现的。作为一个团队，我们发现这个秘密已经多年了。对于beta级或产品系统的性能问题，你应该从系统的最底层堆栈开始诊断。不幸的是，性能诊断经常仅仅集中在系统堆栈中间的四个部分。它们是：
* 逻辑数据库结构
* 数据库操作
* 访问路径（SQL）
* 内存分配
但是，我们经常可以在Oracle底层的几个级别上发现很大的性能问题，如下所示：
* 输入输出和物理数据库结构
* 资源竞争
* 底层操作系统平台
藏宝图
在Oracle性能调优级上，藏宝图就是v$sqlarea视图。如果我是一个IT管理者，我将会记住这个视图的名字。并且，每当我在大厅遇见我的数据库管理员时，我都会问他们这周他们查询这个视图的次数。
Metalink 注释 235146.1给出了对这个视图进行查询的一些样例。例如：
select sql_text, executions, buffer_gets, disk_reads, rows_processed,
sorts, address, first_load_time, HASH_VALUE, module
from v$sqlarea
where executions > 0
order by reads_per desc
最近，越来越多的Oracle 9i版本加入了模块（MODULE）这个列，该列揭示了Oracle应用程序的模块名称。
统计包
在很多大型企业中，统计包的使用仍然被忽视。这可能是带有胁迫性的报道。不要犯试图仅仅读取输出结果，就能获取所有信息的错误，即使是第一页就足以告诉你这份报道中剩下的你应该重视的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语句的输入输出减少，我们会不考虑高索引计数的问题而加入这个索引。
| 
