这篇技巧性文章是由
国际Oracle用户组
（IOUG）提供的
它是一个由用户组成的组织
这个组织通过提供高质量的信息
培训
网络和支持
来提高Oracle数据库专家和数据库开发者的水平
这篇文章摘自由David Welch所写的论文《可预见的Oracle应用程序性能调优》
点击这里成为
国际Oracle用户组
的一员
从而获得成千上万的由Oracle用户写的技巧性文章和科技文献
引言
我们见到过很多带有巨大性能问题的Oracle应用程序和电子商务套件安装我们得出的结论是这些安装都可以在性能方面取得进一步的提升换句话说性能已经很高几乎不能得到再得到改善的安装是很少见的
有争议的问题
针对产品系统堆栈而言我们的底部端对端性能调优方法总是很快产生成果比我们认为的遵循广泛的备忘列表要快我提出以下一些问题共讨论
大部分性能改善的可能性都是在应用程序级上这条结论来自Metalink上关于性能调优的一个显着的注释这条结论和我们的经验性能调优系统堆栈没有统计意义上的关系
平均需要两天的时间这是书上做出的结论但我们的经验不支持这个结论我认为得出一个Oracle应用程序性能改善的策略最少应该需要天第一天早晨开会是很常见的事最后两天主要用来完成行政方面和技术级上的有关发现胜利和紧接着的推荐的文档工作可以夸张地说如果一个性能改善不被记录下来形成文档那么以后很难再重复类似的性能改善如果对出现的问题不记录下来形成文档那么很可能它会再次发生如果一个问题及其解决方法不被记录下来形成文档的话对它的监测将非常困难
扩展碎片对于联机事务处理系统这应该不是一个问题我们听过很多有关联机事务处理系统对碎片严重的表（这些表完全是键值惟一的）进行事务处理不会影响性能的说法但是我们应该经常性地重组以消除碎片这会带来性能上的巨大改善Oracle存储管理改善正在向将碎片带来的影响最小化大踏步地迈进
由于缓沖输入输出不是大问题所以需要对磁盘输入输出进行性能调优这里有两点需要说明磁盘输入输出的实际开销并不是内存缓沖输入输出的一万倍真实的比值接近即使你的CPU似乎正在抵销这个代价并且不带来任何显着的性能问题但是这个问题显然会限制你的系统的可伸缩性随着时间的流逝我们越来越重视过高的内存缓沖输入输出同时找寻性能改善的机会
OATablespace模型和迁移工具集已发布的Metalink注释（/）声称这个新模型带来了实时性能改善这个模型的概念是将多个Oracle应用程序表空间合并成一个以计数的表空间这会带来潜在的存储空间节省么？或许这会带来更高的操作效率么？它依赖于其他东西我们还没有讲解这个工具集但是我们已经理解了在白板级上的表空间合并是如何改善性能的
对你的个人电脑客户端进行磁盘碎片整理在这本书中有关这个问题的讨论很多这或许是正确的因为在写作本书时正流行胖客户端但是现在Oracle应用程序客户端是一个瘦客户端（从Oracle废除Jinitiator开始我们称浏览器为瘦客户端）不要期待能从对你的个人电脑客户端硬盘驱动器进行磁盘碎片整理中得到性能提升
载入模块补丁这是Oracle技术支持对于性能问题经常给出的对策其实在很多情况下它并不合适原因是打补丁经常会带来不稳定性如果对于补丁的依赖性没有给予充分考虑你可能会发现你不得不载入整个补丁包而你根本就没打算载入它们结果就是对你系统的堆栈稳定性产生了影响
项目管理
项目管理是很关键的Oracle应用程序性能实施即是技术上的也是行政上的某个人必须出来做掌舵者即项目管理者必须按功能区分出不同的优先次序如果有可能可以按照以下方式商业单位先计算他们选拔人才的时间延迟带来的财政开支然后乘上用户的数量及其每分钟的收入获得应用程序性能改善的开销之一就是要记录文档同时也需要记录大量的纸质文档用户的欲望必须被管理起来因为并不是所有的区域都会产生同样戏剧性的结果必须有一个管理者来划分不同的优先次序有些时候甚至需要对性能团队的访问进行过滤一方面用户会频繁地提出会导致底层性能问题的主意和要求另一方面和用户进行交互可能会妨碍你的工作进度成功也会导致暴露下一层性能问题的出现
什么是用户不能告诉你的
针对某个用户的从底向上的方法揭示了一个单独的包消耗的输入输出资源占全部的％左右对另一个用户而言一个单独的查询可能会引起每周TB的缓沖输入输出性能调优使得缓沖开销降至原先的％问题是它会耗尽CPU资源同时在那种情况下是否对CPU进行扩充还需慎重考虑没有人知道系统堆栈正在抵销这个代价
关于性能调优保守最严密的一个秘密在Oracle性能调优指南中被发现的作为一个团队我们发现这个秘密已经多年了对于beta级或产品系统的性能问题你应该从系统的最底层堆栈开始诊断不幸的是性能诊断经常仅仅集中在系统堆栈中间的四个部分它们是
* 逻辑数据库结构
* 数据库操作
* 访问路径（SQL）
* 内存分配
但是我们经常可以在Oracle底层的几个级别上发现很大的性能问题如下所示
* 输入输出和物理数据库结构
* 资源竞争
* 底层操作系统平台
藏宝图
在Oracle性能调优级上藏宝图就是v$sqlarea视图如果我是一个IT管理者我将会记住这个视图的名字并且每当我在大厅遇见我的数据库管理员时我都会问他们这周他们查询这个视图的次数
Metalink 注释 给出了对这个视图进行查询的一些样例例如
select sql_text executions buffer_gets disk_reads rows_processed
sorts address first_load_time HASH_VALUE module
from v$sqlarea
where executions >
order by reads_per desc
最近越来越多的Oracle i版本加入了模块（MODULE）这个列该列揭示了Oracle应用程序的模块名称
统计包
在很多大型企业中统计包的使用仍然被忽视这可能是带有胁迫性的报道不要犯试图仅仅读取输出结果就能获取所有信息的错误即使是第一页就足以告诉你这份报道中剩下的你应该重视的％在哪儿Oracle 版本的统计包现在包含CPU和消耗时间列以前为了将长时间运行的SQL语句排序到最顶端我们不得不开启追蹤连接追蹤文件并将它们交付程序tkprof来处理对于那些一个简单的追蹤就要处理多达GB数据的大型企业而言这是不现实的
让用户参与到性能调优中去
将这条建议（即让用户参与到性能调优中去）写入书中的人应该因其创造性而得到赞誉让你的用户也参与到性能诊断中去购买一台Oracle应用程序评测个人电脑并把它给用户使用不要使用与个人电脑类似的配置好的笔记本因为在同样规范的情况下笔记本没有个人电脑的同样性能特性配置清单如下
* MB CPU
* MB 内存
* Windows 企业版（第四版）
* 使用独立的逻辑磁盘
* Jinitiator－锁定版
* 标准软件例如Office
供评测用的个人电脑不需要以下配置
* 墙纸
* 屏幕截图
* 工具条
* 常驻程序
将评测用个人电脑送上用户的桌面带着性能问题将用户的电脑接入局域网让用户工作一段时间然后再将用户的电脑放进计算机房间并把它接入中间层让用户在它上面进行更多的工作评测用个人电脑消除了用户方对Oracle应用程序性能的主观性同时也消除了面对用户抱怨性能问题你们的主观性
索引计数和性能
回到年代开发者指南基本上说不要在一个表上建立到个索引今天开发者指南上的注释如下
Oracle不限制在一个表上建立索引的个数尽管如此你需要考虑索引所带来的性能改善以及你的数据库应用程序的实际需要从而决定需要对哪些列建立索引
事实是每个Oracle应用程序表可能包含多个索引如果我们加入一个索引能将经常需要的SQL语句的输入输出减少我们会不考虑高索引计数的问题而加入这个索引
CPU
减小并发管理池的宽度至今我们还没发现这会阻塞任务的进行我们经常会看到的情景是减小并发管理池的宽度实际上增加了批处理任务的吞吐量它也使CPU不那么忙碌有许多包含对等进程的任务必须被完成如果一个任务的池宽度过窄所需的任务可能永远也得不到处理从而阻塞整体任务
我们和Oracle应用程序安装小组培训者打过交道他们喜欢增加并发管理池的宽度而无视对CPU的影响这种设置一直保持到产品发布时仍然存在在训练和测试环境中安全问题的大门是开着的并且安装者增加并发管理池的宽度以期望他们的批处理任务可以尽早完成他们这样做或许根本没有考虑到对CPU的影响CPU可能会因此而被完全占用
CPU运行队列不应该比你的CPU计数的两倍还深如果CPU在一天中被经常性完全占用就必须放弃某些设置寻找这个需要被放弃的设置的第一位置就应该是并发管理池
