前言
我们见到过很多带有巨大性能问题的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底层的几个级别上发现很大的性能问题，如下所示：
* 输入输出和物理数据库结构
* 资源竞争
* 底层操作系统平台
藏宝图
在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语句的输入输出减少，我们会不考虑高索引计数的问题而加入这个索引。
CPU
减小并发管理池的宽度，至今我们还没发现这会阻塞任务的进行。我们经常会看到的情景是：减小并发管理池的宽度实际上增加了批处理任务的吞吐量，它也使CPU不那么忙碌。有许多包含对等进程的任务必须被完成。如果一个任务的池宽度过窄，所需的任务可能永远也得不到处理，从而阻塞整体任务。
我们和Oracle应用程序安装小组、培训者打过交道，他们喜欢增加并发管理池的宽度，而无视对CPU的影响，这种设置一直保持到产品发布时仍然存在。在训练和测试环境中，安全问题的大门是开着的，并且安装者增加并发管理池的宽度以期望他们的批处理任务可以尽早完成。他们这样做或许根本没有考虑到对CPU的影响，CPU可能会因此而被完全占用。
CPU运行队列不应该比你的CPU计数的两倍还深。如果CPU在一天中被经常性完全占用，就必须放弃某些设置。寻找这个需要被放弃的设置的第一位置就应该是并发管理池。
结论:
Oracle日常维护和性能调优,不是单纯的技术,指定科学严谨的管理维护计划更重要,一定要将调优,维护过程中的所有为难题记录,形成文档,在知识经验上得到积累,不至于同样的错误犯两次;
记录运行日志,什么时候系统性能差,速度慢;然后分析找出原因,指定解决的办法;
调优分两部分:
一.应用层,包括逻辑数据库结构,数据库操作,访问路径（SQL）,内存分配等.优化的方法有,分解大表,修改关键表结构,分析应用层的sql语句,优化,使之达到最优执行;配置参数,恰当地分配内存;定期分析,重建索引,移动表,消除碎片;
二.系统层,包括输入输出和物理数据库结构,资源竞争,底层操作系统平台等;根据系统应用的规模,选择恰当的文件系统,这样可以达到减少io操作的次数;操作系统是支撑大规模的吞吐量,window是微内河,linux/unix是宏内核,造成了在系统内进程间通信的速度和操作性能的差异等.
根据需求->指定运维计划->分析运行日志->更该运行计划->分析运行日志....这样一个反复的过程
|
