使用扩展SQL跟踪数据

核心提示： 检查重做日志是否与其他所有数据库文件进行了适当的隔离 等等， 对于某些工作来说，使用扩展SQL跟踪数据(2)，使用检查内容清单也许很好，但是对于判断性能问题这样的工作，还是这些调用中也许有一个用了5分钟，而其余9999次调用每次只用0.02秒，试图确定理论上可能会出错的每一件事，从而对这个

检查重做日志是否与其他所有数据库文件进行了适当的隔离

等等。

对于某些工作来说，使用检查内容清单也许很好。但是对于判断性能问题这样的工作，试图确定理论上可能会出错的每一件事，从而对这个问题进行处理的做法的效率会很低。更有效的方法就是找到这个简单问题的答案：

是什么花了这么长时间？

用于优化Oracle程序的好的策略就如同日常生活中用到的策略。就像这样：

1. 使用专门的仪器来测定程序的性能，从而监视运行速度慢的程序。

2. 为运行慢的程序创建资源描述，把程序的响应时间细分为几种有用的类型。

3. 通过首先处理响应时间最长的部分来缩短程序的响应时间。

当你了解了若干技术细节之后，这个方法就非常简单了。如果你真的这样做，那么每次你都能获得一个有用的方法，久而久之，你将能在进行性能改进之前预知其结果。

跟踪

如果你有用于收集程序中每个执行步骤的时间统计信息的高级工具，那就用吧。但只收集汇总数据（如通过对系统全局区[SGA]或其基础共享存储段采样获得的数据）的工具对于某些类型的问题就不适合。

使用昂贵的监控工具时最常见的汇总错误是它们会跨整个Oracle数据库实例来汇总某一给定时间间隔内资源的使用情况。但是，运行速度慢的程序实际上可能不受资源争用问题的影响，而这个问题却完全控制着系统中一些不太重要的程序的性能。

即便是那些在Oracle数据库会话级上汇总信息的工具在诊断一些重要的问题类型时也存在着缺陷。例如，假设一个程序运行10分钟，调用了10000次Oracle SQL*Net message from client 这一"等待事件"，会话等待该事件的总用时为8.3分钟。这意味着会话对SQL*Net message from client事件的等待时间平均为3秒。但是单从汇总数据看，你无法知道这10000次调用是否每次都用3秒，还是这些调用中也许有一个用了5分钟，而其余9999次调用每次只用0.02秒。这两种情况需要进行完全不同的处理。