• 制定恰当的优化目标
• 应用优化方法
• 平衡性能和安全性
• 确定常见的优化问题
• 使用Oracle Support 记录性能服务请求
- 常规优化会话
优化会话的过程都是相同的：
1. 定义问题并陈述目标。
2. 收集当前统计信息。
3. 考虑一些常见的性能错误。
4. 制定试用解决方案。
5. 实施并度量更改。
6. 决定：“该解决方案是否达到目标？”
– 否？转到步骤3 并重复相关过程。
– 是？创建新基线。
常规优化会话
进行优化时，应将重点放在可为优化工作带来最大回报的特定方面。步骤是通用的，适用于所有性能监视工具。自动数据库诊断监视程序 (ADDM) 可自动执行优化方法中的许多步骤。
通常，经验丰富的 DBA 可以在用户尚未注意到问题之前就已经解决了问题。例如，公司知道访问数据库的用户数将要增加。此时，DBA 就可以开始规划必须进行的修改，以避免因为资源有限而造成整个系统的速度变慢。此类主动式优化要求 DBA 熟悉数据库、用户群和应用程序的所有方面。
建议的优化方法如下：
1. 定义问题并确定目标。此步骤是分析步骤。无论信息来源是用户、数据库统计信息还是度量，均将收集与问题对应的准确真实的数据。使用量化的并与数据库操作直接相关的术语来表述问题。例如，如果“XYZ”报表的运行时间是基线的两倍，则优化目标为：使“XYZ”报表的运行时间等于或小于基线。
2. 收集当前统计信息：检查主机系统和数据库的统计信息。收集操作系统和数据库的完整统计信息，并将其与基线统计信息进行比较。基线统计信息是实例的运行处在一种可接受状态时所获取的一组统计信息。检查不同之处，以确定系统中发生了哪些更改。“XYZ”报表是否发生了更改？数据是否发生了更改？生成报表的会话是否正在等待某个事件？
3. 考虑常见的性能错误：通过所收集的统计信息中的差异列表，与常见的性能错误进行比较。确定你的系统中是否出现其中某种错误。
4. 制定试用解决方案。在解决方案中包含概念模型。此模型的目的是通过展示数据库的总体状态来提供帮助。你将寻求下列问题的答案：
- 性能为什么会下降？
- 如何才能解决问题以达到目标？
5. 实施和度量更改：制定了试用解决方案之后，进行适当的更改。一次只能执行一项更改。如果同时进行多项更改，就无法知道哪项更改有效。如果更改未能解决问题，则无法知道是不是某些更改其了作用，而其他更改反而起了负作用。收集统计信息以度量更改。
6. “该解决方案是否达到目标？”将当前统计信息集与基线统计信息集进行比较。
如果确定需要进行更多的优化，则返回步骤 3 并重复执行相关过程。
如果解决方案达到目标，则将当前的统计信息集设为新的基线统计信息集。达到了目标。停止优化。
- 定义问题
发现和定义问题：
• 倾听用户的反馈
• 检查预警日志和跟踪文件以发现错误
• 检查参数文件中的所有诊断设置或不适合的参数设置
• 检查内存、I/O 和CPU的使用情况。确定资源使用情况异常的进程
• 确定并优化大量占用CPU 或I/O 的SQL语句
• 收集实例和操作系统(OS) 的统计信息
定义问题
问题随时可能出现。积极的 DBA 会监视问题，并在用户注意到问题之前将其解决。过去发现问题和定义步骤很拖沓，有时会依赖于收听用户的反馈。用户反馈非常重要，但却经常是主观的，并且无法重现。在 Oracle Database 10 g 中，下列许多信息源都可以在Enterprise
Manager 界面中查看到。
• 检查日志中的错误消息，这些错误消息可能会为发现问题的性质提供快速的线索。
不要忽略特定于系统和应用程序的日志。
• 确保初始化参数设置对系统有意义。建议一天中的不同时段采用不同的设置（如果这样做有帮助的话）。
• 检查CPU 队列和磁盘队列、磁盘利用率以及内存交换情况。这些都会有系统超负荷的迹象。如果应用程序优化得相当好，那么，最好的建议也许只能是增加硬件了。
• 使用可用的工具（如 Statspack 或ADDM），确定应用程序中占用资源最多的 SQL 语句。
• 收集实例和 OS 的统计信息。Statspack 报表指向等待时间最长并且占用资源最多的组件。ADDM 则进一步将重点放在可带来最大潜在好处的组件上。
- 设置优先级
选择影响最大的问题：
• 通过完成工作（CPU 时间或服务时间）与等待工作所用时间（等待时间）的对比来分析系统性能。
• 确定占用时间最长的组件。
• 细化以优化该组件（如果适合）。
设置优先级
确定要首先优化的问题。在性能报表中，可以看到许多统计信息，甚至优化得很好的数据库也会显示一组顶级等待事件。Oracle 服务器为空闲或正在等待的进程提供一组等待事件统计信息。Oracle 服务器还会记录正在运行的进程的 CPU 利用率。为了确定特定事件的影响，必须将其与所用的总时间进行比较。
对数据库服务器发出的每个请求的响应时间包括等待时间和服务时间。服务时间是实际处理请求所用的时间（CPU 时间）。按照定义，等待时间是由于各种原因而等待的时间。服务时间和等待时间均可优化。若要优化服务时间，必须更改处理、SQL 、访问路径或数据存储结构。在等待即要发生的地方减少资源争用可以优化等待时间。
每个服务器进程通常处于下列三种状态之一：
• 空闲：等待执行（休眠）
• 正在运行代码：正在使用 CPU 或在运行队列中
• 等待（被阻塞）：
- 等待某个资源可用
- 等待所请求的活动完成
- 优化方法：设置优先级示例
Time Model System Stats DB/Inst: ORCL Snaps: 1-11
-> Ordered by % of DB time desc, Statistic name
Statistic Time (s) % of DB time
--------------------------- --------- ---------
sql execute elapsed time 467.0 77.1
DB CPU 414.2 68.4
parse time elapsed 200.5 33.1
hard parse elapsed time 109.0 18.0
…
DB time 605.8
优化方法：设置优先级示例
通过将各种等待时间和任务所用时间与总等待时间和服务时间进行比较，可以确定优先级最高的优化任务。两种主要工具都会报告此比较结果，引导你使用时间模型系统统计信息进行优化。例如，图中的 Statspack 报表显示了数据库 CPU 时间为 414.2 秒。用户调用所花费时间占总数据库时间的
68.4% 。sql execute elapsed time 显示为 467 秒，此时间包含等待时间。仅从这个有限的视图来看，SQL 执行的等待时间比例就很大，因此可能会引导你检查与 SQL 执行有关的等待统计信息。
进一步的调查表明，等待是应用程序设计中固有的，无法更改。然后对 parse time elapsed重复该过程。
%ofDBtime的值指示对此方面进行优化可能会产生的相关影响。如果可以消除 hardparse elapsed time，则最多可能提高 109 秒或 18% 。实际的提高可能会小得多，这取决于可从该方面获得的提高量。
- 常见的优化问题
最常见的优化问题包括：
• SQL 语句
• 会话管理
• 共享池大小调整和争用
• 缓冲区高速缓存大小调整和争用
• 数据块争用
• 重做日志和重做缓冲区优化
• 还原优化
• I/O 问题
• 锁定问题
常见的优化问题
任何Oracle 数据库中最常见的优化问题是 SQL 语句或应用程序的优化。SQL 问题可能源于应用程序设计，例如资源过度规范化或序列化。
会话管理也是应用程序层的问题，通常表现为大量连接和断开事件，但是可能会包含打开的游标数以及游标高速缓存问题。
在实例优化问题列表中，内存问题比例很高。这些问题包括系统全局区 (SGA) 各个部分的大小调整以及内存资源的争用。一次只能有一个进程访问数据块和头部块。如果多个进程尝试访问同一个索引块或表头部块，则会造成争用。
在OLTP 应用程序中，产生的重做量和还原量可能会造成内存或 I/O 出现瓶颈。在任何数据库中，I/O 问题（例如磁盘或 RAID 设备上的数据库文件布局）可能是性能问题的根源。
锁定问题通常算不上问题，但是一旦出现了锁定问题，就会是一个非常重要的问题。
- ADDM 优化会话
ADDM 优化会话与常规优化会话的过程相同，但是组合了下列步骤：
1. 查看ADDM 报表。
A.收集当前的统计信息；与以前的统计信息集进行比较。
B.与性能问题知识库进行比较。
C.定义问题并提供建议。
2. 复查建议。
D.制定试用解决方案。
3. 实施建议。
E. 实施并度量更改。
4. 复查下一个ADDM 报表。
F. 决定：“该解决方案是否达到目标？”
ADDM 优化会话
自动数据库诊断监视程序 (ADDM) 会在内部执行常规优化会话的步骤。使用 ADDM 时执
行的步骤如示例中所示。常规步骤显示为 ADDM 步骤的子步骤。
- 有效的优化目标
有效的优化目标包括：
• 具体
• 可量化
• 可实现
有效的优化目标
消除确定的问题成为优化目标。相关的服务级别协议 (SLA) 也会派生出目标。SLA 通常是必须达到的合同要求或业务要求。目标可能以 SLA 或问题为出发点。SLA 表明，用户响应特定请求的时间不得超过 30 秒。问题在于，平均响应时间为 25 秒，并且还在增加。优化目标是用户响应特定请求的时间为
20 秒。
优化目标和 SLA 均须具有三个特征才能生效。它们必须：
• 具体
• 可量化
• 可实现
“使实例运行速度尽可能快”不够具体。具体的目标应是“月末报表套件完成时间必须少于4 个小时”。
可量化的目标具有可以度量的客观数量。如果目标是可量化的，那么目标是否达到就很清楚了。具体的目标也很容易成为可量化目标。很容易陈述“用户响应请求的时间为 10 秒”
目标，但此目标是否针对所有用户请求？是否为平均响应时间？如何度量平均响应时间？
对目标中的用词进行具体的定义是十分必要的。如果将目标表述改为“用户响应特定请求的时间为 20 秒或更短”，可以客观地确定何时达到了目标。
可实现的目标是可能的，并且在优化负责人的控制范围内。
下列示例是在典型 DBA 控制范围内无法实现的目标：
• 如果目标是优化实例以创建高性能的应用程序，但是不允许你更改 SQL 或数据结构，那么可实现的优化量就会受到限制。
• 如果目标响应时间为 1 秒，但是服务器与客户机之间的网络延迟为 2 秒，如果不对网络进行更改，就不可能实现 1 秒的响应时间。
即使上述情况并非绝对无法更改，但是 DBA 总是会有业务约束，对解决方案可使用的资金和资源量进行限制。
始终应制定可量化的优化目标。没有优化目标，将很难确定是否有了足够的优化。
- 优化目标
优化目标包括：
• 尽可能缩短响应时间
• 增大吞吐量
• 提高负载能力
• 缩短恢复时间
优化目标
优化目标可以归纳为“以更短的时间完成更多的工作”。根据你所处的环境，可作如下解释：
• 尽可能缩短响应时间或缩短用户等待时间
• 增大吞吐量，即缩短执行一个或一组作业的时间
• 提高负载能力，即可以执行更多的任务，或为其他任务释放处理能力
在某些环境中，需要进行折衷。在大批量联机事务处理 (OLTP) 环境中，可以允许更长的用户响应时间，以便从多个用户获取更多的总事务数。研究表明，在基于 Web 的环境中，用户响应时间必须小于 7 秒，否则，用户就会放弃使用。在这种情况下，任何其他条件都将服从于响应时间。
业务需求会影响优化目标。性能可能会受到安全问题的限制，比如在“缩短恢复时间”目标。
如果业务环境中每分钟的停机可能需要付出数百或数千美元的代价，则防止实例失败和缩短恢复时间的开销比用户响应时间更加重要。
- 数据库时间
数据库时间
优化不仅仅是缩短等待时间。优化旨在缩短最终用户的响应时间和（或）尽可能减少每个请求占用的平均资源。有时这些目标可同时实现，而有时则需要进行折衷（例如并行查询）。通常可以认为，优化就是避免以浪费的方式占用或保留资源。
对数据库发出的任何请求由两个不同的段组成：等待时间（数据库等待时间）和服务时间（数据库 CPU 时间）。等待时间是各种资源的所有等待时间的总和。CPU 时间是实际处理请求或在 OS 队列中等待所用的时间的总和。这些时间不一定由一个等待时间和一个CPU
时间块组成。
优化包括缩短或消除等待时间以及缩短 CPU 时间。此定义适用于任何应用程序类型、联机事务处理 (OLTP) 或数据仓库 (DW)。
注：非常繁忙的系统因为要在运行队列中等待，所以数据库 CPU 时间也更长。过载的系统将导致进程在运行队列中等待，从而会增大所有进程的数据库 CPU 时间。
- CPU 时间和等待时间优化范围
CPU 时间和等待时间优化范围
优化系统时，应将 CPU 时间与系统的等待时间进行比较，这一点很重要。通过将 CPU 时间与等待时间进行比较，可以确定用于有效工作的响应时间，以及用于等待可能由其他进程占用的资源的时间。通常情况下，与等待时间占主导地位的系统相比，CPU 时间占主导地位的系统需要的优化较少。此外，SQL
语句编写不佳也可能导致高 CPU 使用率。
虽然随着系统负载的增加，等待时间与 CPU 时间的比值会一直增大，但是，等待时间的迅速增加是争用的迹象，必须解决这一问题才能获得良好的可伸缩性。
增加的等待时间表明发生争用时，在节点中增加 CPU 或在群集中增加节点的作用将非常有限。相反地，CPU 时间的分配比例不会随着负载增大而明显减小的系统，可伸缩性会更好。并且最有可能取得效果的是通过添加 CPU 或Real Application Clusters (RAC) 实例（如果需要）。
注：自动工作量资料档案库 (AWR) 和Statspack 报表在“Top 5 Event ”部分显示CPU 时间和等待时间（如果 CPU 时间部分处在前五个事件中）。
- 优化活动周期阶段
应用程序活动周期可以分为不同的阶段：
• 应用程序的设计和开发
• 测试：数据库配置
• 部署：在现有数据库中添加新的应用程序
• 生产：故障排除和优化
优化活动周期阶段
开发：应用程序的设计和编程
应尽可能在此阶段开始优化。通过良好的设计，许多优化问题都不会出现。例如，虽然在一般情况下，完全规范化表是减少冗余的很好做法，但这样做可能会产生大量的表联接。通过逆规范化表，应用程序的性能可以明显提高。
测试：数据库配置
测试阶段是开发的延续，更实际的测试应包含生产硬件和操作系统。
部署：在现有数据库中添加新的应用程序
在现有系统中添加新的应用程序时，工作量会发生变化。应对工作量的任何重大变化提供性能监视。
生产：排错和优化
使用工具来确定瓶颈。检查报表，确定形成瓶颈的前提原因。根据该前提原因，可以开发和实施解决方案。对数据库运行测试负载，以确定解决方案是否消除了瓶颈。
- 活动周期期间的优化步骤
1. 优化设计。
2. 优化应用程序。
3. 优化内存。
4. 优化I/O 。
5. 优化争用。
6. 优化操作系统。
活动周期期间的优化步骤
开发新系统期间采用的优化方法与生产系统采用的方法相同。对于一个新系统，可能存在许多未知的因素；因此，应认真执行以上步骤顺序。争用问题的根源可能是在设计中有多个进程在一个资源（如序列号生成器）上进行序列化。修复设计是解决该问题的最佳方式。
此结构的原理是先在序列中进行改进，从而避免以后处理问题。例如，如果应用程序使用了多个全表扫描，则可能会因为 I/O 过量而减慢速度。但是，如果可以重写查询，使其只访问四个块而不是 4,000 个块，则不需要考虑调整缓冲区高速缓存大小或重新分配磁盘文件。
前两个步骤通常是系统架构设计师和应用程序开发员的职责；不过，DBA 通常会参与应用程序的优化。优化活动周期后续阶段的区别主要在于允许的操作。生产环境中的许多DBA 都不允许更改 SQL 或数据结构。但是，为了提高性能所做的设计更改可能会生成更改请求，发送给应用程序供应商或开发小组。
- 应用程序的设计和开发
即使在设计和开发阶段，也可以通过构建和优化测试案例来优化应用程序。
• 根据主要功能检查规范化。
• 根据访问时间检查数据结构。
• 查看发生进程序列化的点。
• 优化主要报表。
• 优化大批量进程。
应用程序的设计和开发
在设计和开发阶段采用的优化方法以各种系统的常见瓶颈为重点：规范化、数据结构、序列化点、主要报表和大批量请求。刚开始设计的时候，就已确定应用程序的主要功能。数据的规范化级别对性能有重大影响。过度规范化可能会产生大量多路联接，从而会占用所有可用的主机资源。规范化不足则会带来另一组问题：不一致的数据、复杂的数据检查以及难以将数据迁移到其他方案或数据库。该解决方案需要采用完全规范化的设计，并使用内置的一致性检查进行谨慎的逆规范化。
选择正确的数据结构对性能有很大好处，例如对大型数据集使用分区表。在设计中避免资源争用，可以提高应用程序的可伸缩性。应用程序所需的主要报表应针对预期的运行时间建立原型并进行优化。还应为大批量功能（在数据或执行方面）建立原型。
每个方面都有测试案例。这些测试案例使用生产数据库中采用的相同方法进行优化：收集统计信息、优化瓶颈、测试，进行重复直至达到目标。
- 测试：数据库配置
测试阶段允许在更深的层次进行优化：
• 检查物理布局。
• 监视资源争用。
– 内存利用率
– 锁定
– 磁盘热点
• 测试资源耗尽。
测试：数据库配置
测试阶段允许在更深的层次进行测试。测试案例应运行应用程序功能、预期的负载以及对不大可能的负载的压力测试。通过这些类型的测试，可以在最佳物理布局以及最佳 OS 和硬件配置方面获得有价值的信息。监视热点（即使在快速磁盘上），这一点很重要。应规划数据配置，使其可以缩短恢复时间和加快数据访问速度。尽量考虑业务对恢复时间和可用性的要求，以便留出这些要求所需的开销。
通过可以耗尽计算机资源的负载进行测试。这些测试可确定占用最多的资源。这些资源就是限制系统的可伸缩性的资源。
DBA 在每个阶段使用时间模型来确定瓶颈，并使用优化会话来消除每个层次的瓶颈。
- 部署
部署：
• 部署新的应用程序和数据库
– 获取基线。
– 监视增长和性能。
• 在现有数据库中部署新应用程序
– 获取部署前的基线。
– 获取部署后的基线。
– 比较基线。
部署
初次部署新的应用程序时，预期的性能与实际情况通常会有所不同。
这里要考虑两种差异：
第一种是对于新数据库上的新应用程序，第二种是对于添加到现有数据库中的应用程序。
新数据库上的新应用程序没有基线，因此要根据当前性能进行优化。定期获取性能基线报表。随着应用程序在数据集规模或用户数方面的增长，可将增加的性能报表与基线进行比较。这样一来，就可以在性能下降到无法接受的水平之前进行优化。
将新应用程序添加到现有数据库中时，可以在部署应用程序之前的基线性能报表与部署应用程序之后的基线性能报表之间进行比较。这些报表可以显示新应用程序正在使用的资源，以及可能与现有应用程序发生的资源争用。
- 生产
优化是被动式的。你需要了解：
发生了哪些变化？
基线在哪里？
生产
对应用程序活动周期中的其他阶段的优化通常是主动式优化。你所做的是在用户注意到问题之前发现可能出现的问题。
对生产数据库的优化通常是被动式优化。出现了一些问题：以前需要数分钟即可运行完的报表，现在需要数小时，响应时间延长，用户不断抱怨未在分配的时间内完成备份。某些事情发生了改变。是否存在其他用户？是否正在运行新的报表或应用程序？OS 中是否发生某些改变？
若要优化以前在可接受状态下运行而现在出现问题的生产系统，需要了解或推断发生了哪些改变。将数据库在可以接受的状态下运行时获取的基线统计信息报表，与发现问题时获取的新报表进行比较。差异之处应当可以显示。
在没有基线统计信息时优化生产数据库会比较困难，但是仍可实现。所用的方法相同，并对确定了优先级的组件进行优化。使用时间模型确定问题。按从上至下的步骤，从设计开始考虑可能的解决方案。使用优化会话测试解决方案。
- 收集基线统计信息集
基线统计信息集用于：
• 提供系统在设置的界限内运行时收集的一组统计信息
• 将基线统计信息与当前统计信息进行比较
• 创建与系统已发生的改变相关的前提
收集基线统计信息集
每个生产数据库至少应存储一个基线统计信息集，以便在数据库性能下降时参考。使用此统计信息集可以确定是性能确实下降，还是用户判断情况已改变。
如果性能确实下降，则可以确定数据库的哪个方面已改变，并针对这个方面进行优化。可以创建问题原因以及如何解决问题的前提。
创建了前提之后，针对系统进行测试，并收集新的统计信息集。将新的统计信息集与基线统计信息集进行对比，确定是否得到了改进。
如果新的统计信息集实现了为系统制定的性能目标，则使用该统计信息集作为新的基线统计信息集。应保留以前的基线统计信息集，以便可以对系统的长期变化进行观察。
收集统计信息和创建基线统计信息集的方式取决于所使用的工具。除了收集统计信息之外，自动数据库诊断监视程序 (ADDM) 还分析不同之处并推荐解决方案。
- 性能与安全性的折衷
影响性能的因素包括：
• 多控制文件
• 组中有多个重做日志成员
• 频繁的检查点检查
• 备份数据文件
• 执行存档
• 块校验和
• 并发用户和事务数
性能与安全性的折衷
在性能与安全性之间始终要进行折衷。提高数据库性能时，可能会对安全性产生负面影响。
反之，提高数据库的安全性，则会降低运行的速度。
Oracle 建议至少需要两个控制文件，其中一个是必需文件。许多 DBA 使用三个或四个控制文件。控制文件越多，要求执行的写入就越多，开销也就越多。多个重做日志成员会降低因为磁盘故障而丢失数据的机率，但是增大了写入重做的开销。频繁的检查点可以缩短平均恢复时间，但是会增加物理写入的次数。以上列出的每个项目都有关联的性能成本。必须决定数据库的安全级别以及所需的性能级别，然后对数据库进行相应的配置和优化。数据库的安全性要求通常由业务需求决定。运行时间要求、平均恢复时间以及磁盘或系统崩溃时可能会丢失的数据量都属于安全问题。一般情况下，先解决安全问题，然后再按照适当的安全性要求优化数据库的性能。
- 记录性能服务请求
记录性能服务请求：
• 问题针对整个实例还是只针对查询？
• 确定根本原因。
• 提供Statspack 或AWR 报表和OS 统计信息。
• 提供远程诊断代理(RDA) 报表。
• 提供SQL_TRACE 报表。
记录性能服务请求
Oracle Support Services (OSS) 提供了一个文档“Note: 210014.1 How to Log a Good Performance Service Request ”，用于引导你记录性能服务请求 (SR) 。
遇到的性能问题通常是你的应用程序和数据库配置特有的。有时，问题是无法通过优化解决的。
OSS 需要某些信息：
• 问题针对整个实例还是只针对查询？何时出现该问题？什么有效？什么无效？提供性能可接受的 SQL 和性能很差的 SQL 的示例。
• 根本原因是什么？在性能为“好”时和性能为“差”时创建 Statspack 或AWR 报表，然后进行比较。检查 OS 日志文件、网络日志文件和数据库日志文件中的线索。删除最近的更改，一次删除一项，并记录结果；即使某些事情对问题没有任何改变，也可帮助缩小搜索根本原因的范围。你也许无法确定根本原因。
• 在数据库出现问题时提供 Statspack 或AWR 报表和OS 统计信息，在未出现问题时提供基线统计信息集（如果可能）。在确定问题时，获取短时间内的快照。
- RDA 报表
RDA 报表
远程诊断代理 (RDA) 报表为 Oracle Support Services 提供一组全面的信息。并非所有服务请求都需要此报表，但是此报表对于与性能有关的请求非常有帮助，支持分析员可能会请求获得此报表。RDA 是用于从 Oracle 数据库环境中收集详细信息的一组脚本。这些脚本旨在收集有助于诊断问题的信息。但是，也可以使用输出来查看总体系统配置。
图中只显示 RDA 报表的一部分“摘要”。RDA 报表非常大并且详细。使用常用的浏览器就可以查看该报表。
- 监视和优化工具：概览
监视和优化工具：概览
浅色的框表示包含原始数据元的工具。较深的框是已使用原始数据派生出更有用的信息的工具。通常，这些信息使用报表格式，例如活动会话历史记录 (ASH) 报表。
性能视图是动态性能视图或 V$(v-dollar) 视图的另一个名称，这些视图可展示内存中的原始统计信息。
跟踪文件在使用 tkprof 实用程序进行格式化之前很难解释。trcsess实用程序为组合和筛选跟踪文件提供了一种独特的工具，以便提取单个会话、服务或模块的统计信息。
“服务”框表示性能监视的指令按服务进行组织。统计信息是按服务汇总的，并可按服务报告多个报表。按服务（而不是按方案、实例或会话）收集的统计信息可以提供独特的应用程序性能视图。
- 监视和优化工具：概览
图中列出的工具可对数据进行格式化，使其成为更有用的信息。其中几种工具可对数据进行分析，从而提供主动的问题检测和建议。
- 小结
• 制定适合的优化目标
• 确定适合不同开发阶段的优化方法
• 平衡性能和安全性的折中关系
• 确定常见的优化问题
• 使用Oracle Support 记录性能服务请求