Oracle DB性能优化：概览
常规优化会话
优化会话的过程都是相同的：
1. 定义问题并陈述目标。
2. 收集当前统计信息。
3. 考虑一些常见的性能错误。
4. 制定试用解决方案。
5. 实施并度量更改。
6. 决定：“该解决方案是否达到目标？”
– 否？转到步骤3 并重复相关过程。
– 是？创建新基线。
常规优化会话
进行优化时，应将重点放在可为优化工作带来最大回报的特定方面。步骤是通用的，适用于所有性能监视工具。自动数据库诊断监视程序 (ADDM) 可自动执行优化方法中的许多步骤。
通常，经验丰富的 DBA 可以在用户尚未注意到问题之前就已经解决了问题。例如，公司知道访问数据库的用户数将要增加。此时，DBA 就可以开始规划必须进行的修改，以避免因为资源有限而造成整个系统的速度变慢。此类主动式优化要求 DBA 熟悉数据库、用户群和应用程序的所有方面。
建议的优化方法如下：
1. 定义问题并确定目标。此步骤是分析步骤。无论信息来源是用户、数据库统计信息还是度量，均将收集与问题对应的准确真实的数据。使用量化的并与数据库操作直接相关的术语来表述问题。例如，如果“XYZ”报表的运行时间是基线的两倍，则优化目标为：使“XYZ”报表的运行时间等于或小于基线。
2. 收集当前统计信息：检查主机系统和数据库的统计信息。收集操作系统和数据库的完整统计信息，并将其与基线统计信息进行比较。基线统计信息是实例的运行处在一种可接受状态时所获取的一组统计信息。检查不同之处，以确定系统中发生了哪些更改。“XYZ”报表是否发生了更改？数据是否发生了更改？生成报表的会话是否正在等待某个事件？
3. 考虑常见的性能错误：通过所收集的统计信息中的差异列表，与常见的性能错误进行比较。确定你的系统中是否出现其中某种错误。
4. 制定试用解决方案。在解决方案中包含概念模型。此模型的目的是通过展示数据库的总体状态来提供帮助。你将寻求下列问题的答案：
- 性能为什么会下降？
- 如何才能解决问题以达到目标？
5. 实施和度量更改：制定了试用解决方案之后，进行适当的更改。一次只能执行一项更改。如果同时进行多项更改，就无法知道哪项更改有效。如果更改未能解决问题，则无法知道是不是某些更改其了作用，而其他更改反而起了负作用。收集统计信息以度量更改。
6. “该解决方案是否达到目标？”将当前统计信息集与基线统计信息集进行比较。
如果确定需要进行更多的优化，则返回步骤 3 并重复执行相关过程。
如果解决方案达到目标，则将当前的统计信息集设为新的基线统计信息集。达到了目标。停止优化。
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 则进一步将重点放在可带来最大潜在好处的组件上。
倾听用户的反馈
检查预警日志和跟踪文件以发现错误
检查参数文件中的所有诊断设置或不适合的参数设置
检查内存、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 或在运行队列中
等待（被阻塞）：
- 等待某个资源可用
- 等待所请求的活动完成
通过完成工作（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% 。实际的提高可能会小得多，这取决于可从该方面获得的提高量。
-> 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 语句
会话管理
SQL 语句
会话管理