Oracle DB性能优化：概览(二)
共享池大小调整和争用
缓冲区高速缓存大小调整和争用
数据块争用
重做日志和重做缓冲区优化
还原优化
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 步骤的子步骤。
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 总是会有业务约束，对解决方案可使用的资金和资源量进行限制。
始终应制定可量化的优化目标。没有优化目标，将很难确定是否有了足够的优化。
具体
可量化
可实现
有效的优化目标
消除确定的问题成为优化目标。相关的服务级别协议 (SLA) 也会派生出目标。SLA 通常是必须达到的合同要求或业务要求。目标可能以 SLA 或问题为出发点。SLA 表明，用户响应特定请求的时间不得超过 30 秒。问题在于，平均响应时间为 25 秒，并且还在增加。优化目标是用户响应特定请求的时间为 20 秒。
优化目标和 SLA 均须具有三个特征才能生效。它们必须：
具体
可量化
可实现
“使实例运行速度尽可能快”不够具体。具体的目标应是“月末报表套件完成时间必须少于4 个小时”。
可量化的目标具有可以度量的客观数量。如果目标是可量化的，那么目标是否达到就很清楚了。具体的目标也很容易成为可量化目标。很容易陈述“用户响应请求的时间为 10 秒”
目标，但此目标是否针对所有用户请求？是否为平均响应时间？如何度量平均响应时间？
对目标中的用词进行具体的定义是十分必要的。如果将目标表述改为“用户响应特定请求的时间为 20 秒或更短”，可以客观地确定何时达到了目标。
下列示例是在典型 DBA 控制范围内无法实现的目标：
如果目标是优化实例以创建高性能的应用程序，但是不允许你更改 SQL 或数据结构，那么可实现的优化量就会受到限制。
如果目标响应时间为 1 秒，但是服务器与客户机之间的网络延迟为 2 秒，如果不对网络进行更改，就不可能实现 1 秒的响应时间。
即使上述情况并非绝对无法更改，但是 DBA 总是会有业务约束，对解决方案可使用的资金和资源量进行限制。
始终应制定可量化的优化目标。没有优化目标，将很难确定是否有了足够的优化。
优化目标
优化目标包括：
尽可能缩短响应时间
增大吞吐量
提高负载能力
缩短恢复时间
优化目标
优化目标可以归纳为“以更短的时间完成更多的工作”。根据你所处的环境，可作如下解释：
尽可能缩短响应时间或缩短用户等待时间
增大吞吐量，即缩短执行一个或一组作业的时间
提高负载能力，即可以执行更多的任务，或为其他任务释放处理能力
在某些环境中，需要进行折衷。在大批量联机事务处理 (OLTP) 环境中，可以允许更长的用户响应时间，以便从多个用户获取更多的总事务数。研究表明，在基于 Web 的环境中，用户响应时间必须小于 7 秒，否则，用户就会放弃使用。在这种情况下，任何其他条件都将服从于响应时间。
业务需求会影响优化目标。性能可能会受到安全问题的限制，比如在“缩短恢复时间”目标。
如果业务环境中每分钟的停机可能需要付出数百或数千美元的代价，则防止实例失败和缩短恢复时间的开销比用户响应时间更加重要。
尽可能缩短响应时间
增大吞吐量
提高负载能力
缩短恢复时间
优化目标
优化目标可以归纳为“以更短的时间完成更多的工作”。根据你所处的环境，可作如下解释：
尽可能缩短响应时间或缩短用户等待时间
增大吞吐量，即缩短执行一个或一组作业的时间
提高负载能力，即可以执行更多的任务，或为其他任务释放处理能力
在某些环境中，需要进行折衷。在大批量联机事务处理 (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 时间部分处在前五个事件中）。
优化活动周期阶段
应用程序活动周期可以分为不同的阶段：
应用程序的设计和开发
测试：数据库配置
部署：在现有数据库中添加新的应用程序
生产：故障排除和优化
优化活动周期阶段
开发：应用程序的设计和编程
应尽可能在此阶段开始优化。通过良好的设计，许多优化问题都不会出现。例如，虽然在一般情况下，完全规范化表是减少冗余的很好做法，但这样做可能会产生大量的表联接。通过逆规范化表，应用程序的性能可以明显提高。
测试：数据库配置
测试阶段是开发的延续，更实际的测试应包含生产硬件和操作系统。
部署：在现有数据库中添加新的应用程序
在现有系统中添加新的应用程
应用程序的设计和开发
测试：数据库配置
部署：在现有数据库中添加新的应用程序
生产：故障排除和优化
优化活动周期阶段
开发：应用程序的设计和编程
应尽可能在此阶段开始优化。通过良好的设计，许多优化问题都不会出现。例如，虽然在一般情况下，完全规范化表是减少冗余的很好做法，但这样做可能会产生大量的表联接。通过逆规范化表，应用程序的性能可以明显提高。
测试：数据库配置
测试阶段是开发的延续，更实际的测试应包含生产硬件和操作系统。
部署：在现有数据库中添加新的应用程序
在现有系统中添加新的应用程