前言
我们见到过很多带有巨大性能问题的Oracle应用程序和电子商务套件安装。我们得出的结论是：这些安装都可以在性能方面取得进一步的提升。换句话说，性能已经很高，几乎不能得到再得到改善的安装是很少见的。
有争议的问题
针对产品系统堆栈而言，我们的底部端对端性能调优方法总是很快产生成果，比我们认为的遵循广泛的备忘列表要快。我提出以下一些问题共讨论：
大部分性能改善的可能性都是在应用程序级上：这条结论来自Metalink上关于性能调优的一个显著的注释。这条结论和我们的经验性能调优系统堆栈没有统计意义上的关系。
平均需要两天的时间：这是书上做出的结论。但我们的经验不支持这个结论。我认为得出一个Oracle应用程序性能改善的策略最少应该需要12天。第一天早晨开会是很常见的事。最后两天主要用来完成行政方面和技术级上的有关发现、胜利和紧接着的推荐的文档工作。可以夸张地说，如果一个性能改善不被记录下来形成文档，那么以后很难再重复类似的性能改善。如果对出现的问题不记录下来形成文档，那么很可能它会再次发生。如果一个问题及其解决方法不被记录下来形成文档的话，对它的监测将非常困难。
扩展碎片：对于联机事务处理系统，这应该不是一个问题。我们听过很多有关“联机事务处理系统”对碎片严重的表（这些表完全是键值惟一的）进行事务处理不会影响性能的说法。但是，我们应该经常性地重组以消除碎片，这会带来性能上的巨大改善。Oracle存储管理改善正在向将碎片带来的影响最小化大踏步地迈进。
由于缓冲输入输出不是大问题，所以需要对磁盘输入输出进行性能调优：这里有两点需要说明。磁盘输入输出的实际开销并不是内存缓冲输入输出的一万倍。真实的比值接近70。即使你的CPU似乎正在抵销这个代价，并且不带来任何显著的性能问题，但是这个问题显然会限制你的系统的可伸缩性。随着时间的流逝，我们越来越重视过高的内存缓冲输入输出，同时找寻性能改善的机会。
OATablespace模型和迁移工具集：已发布的Metalink注释（10/03）声称“这个新模型带来了实时性能改善。”这个模型的概念是将100多个Oracle应用程序表空间合并成一个以10计数的表空间。这会带来潜在的存储空间节省么？或许。这会带来更高的操作效率么？它依赖于其他东西。我们还没有讲解这个工具集。但是我们已经理解了在白板级上的表空间合并是如何改善性能的。
对你的个人电脑客户端进行磁盘碎片整理：在这本书中有关这个问题的讨论很多。这或许是正确的，因为在写作本书时正流行“胖客户端”。但是现在，Oracle应用程序客户端是一个“瘦客户端”（从Oracle废除Jinitiator开始，我们称浏览器为瘦客户端），不要期待能从对你的个人电脑客户端硬盘驱动器进行磁盘碎片整理中得到性能提升。
载入模块补丁：这是Oracle技术支持对于性能问题经常给出的对策，其实在很多情况下，它并不合适。原因是打补丁经常会带来不稳定性。如果对于补丁的依赖性没有给予充分考虑，你可能会发现你不得不载入整个补丁包，而你根本就没打算载入它们，结果就是对你系统的堆栈稳定性产生了影响。
项目管理
项目管理是很关键的。Oracle应用程序性能实施即是技术上的也是行政上的。某个人必须出来做掌舵者，即项目管理者。必须按功能区分出不同的优先次序。如果有可能，可以按照以下方式：商业单位先计算他们选拔人才的时间延迟带来的财政开支，然后乘上用户的数量及其每分钟的收入。获得应用程序性能改善的开销之一就是要记录文档。同时，也需要记录大量的纸质文档。用户的欲望必须被管理起来，因为并不是所有的区域都会产生同样戏剧性的结果。必须有一个管理者来划分不同的优先次序，有些时候甚至需要对性能团队的访问进行过滤。一方面，用户会频繁地提出会导致底层性能问题的主意和要求。另一方面，和用户进行交互可能会妨碍你的工作进度。成功也会导致暴露下一层性能问题的出现。
什么是用户不能告诉你的
针对某个用户的从底向上的方法揭示了一个单独的包消耗的输入输出资源占全部的25％左右。对另一个用户而言，一个单独的查询可能会引起每周4.3TB的缓冲输入输出。性能调优使得缓冲开销降至原先的0.06％。问题是它会耗尽CPU资源，同时，在那种情况下，是否对CPU进行扩充还需慎重考虑。没有人知道系统堆栈正在抵销这个代价。
关于性能调优保守最严密的一个秘密在Oracle性能调优指南中被发现的。作为一个团队，我们发现这个秘密已经多年了。对于beta级或产品系统的性能问题，你应该从系统的最底层堆栈开始诊断。不幸的是，性能诊断经常仅仅集中在系统堆栈中间的四个部分。它们是：
* 逻辑数据库结构
* 数据库操作
* 访问路径（SQL）
* 内存分配
但是，我们经常可以在Oracle底层的几个级别上发现很大的性能问题，如下所示：
* 输入输出和物理数据库结构
* 资源竞争
* 底层操作系统平台
