Oracle DB性能优化：概览(三)

1. 优化设计。
2. 优化应用程序。
3. 优化内存。
4. 优化I/O 。
5. 优化争用。
6. 优化操作系统。

活动周期期间的优化步骤
开发新系统期间采用的优化方法与生产系统采用的方法相同。对于一个新系统，可能存在许多未知的因素；因此，应认真执行以上步骤顺序。争用问题的根源可能是在设计中有多个进程在一个资源（如序列号生成器）上进行序列化。修复设计是解决该问题的最佳方式。
此结构的原理是先在序列中进行改进，从而避免以后处理问题。例如，如果应用程序使用了多个全表扫描，则可能会因为 I/O 过量而减慢速度。但是，如果可以重写查询，使其只访问四个块而不是 4,000 个块，则不需要考虑调整缓冲区高速缓存大小或重新分配磁盘文件。
前两个步骤通常是系统架构设计师和应用 程序开发员的职责；不过，DBA 通常会参与应用程序的优化。优化活动周期后续阶段的区别主要在于允许的操作。生产环境中的许多DBA 都不允许更改 SQL 或数据结构。但是，为了提高性能所做的设计更改可能会生成更改请求，发送给应用程序供应商或开发小组。

即使在设计和开发阶段，也可以通过构建和优化测试案例来优化应用程序。
根据主要功能检查规范化。
根据访问时间检查数据结构。
查看发生进程序列化的点。
优化主要报表。
优化大批量进程。

应用程序的设计和开发
在设计和开发阶段采用的优化方法以各种系统的常见瓶颈为重点：规范化、数据结构、序列化点、主要报表和大批量请求。刚开始设计的时候，就已确定应用程序的主要功能。数据的规范化级别对性能有重大影响。过度规范化可能会产生大量多路联接，从而会占用所有可用的主机资源。规范化不足则会带来另一组问题：不一致的数据、复杂的数据检查以及难以将数据迁移到其他方案或数据库。该解决方案需要采用完全规范化的设计，并使用内置的一致性检查进行谨慎的逆规范化。
选择正确的数据结构对性能有很大好处，例如对大型数据集使用分区表。在设计中避免资源争用，可以提高应用程序的可伸缩性。应用程序所需的主要报表应针对预期的运行时间建立原型并进行优化。还应为大批量功能（在数据或执行方面）建立原型。
每个方面都有测试案例。这些测试案例使用生产数据库中采用的相同方法进行优化：收集统计信息、优化瓶颈、测试，进行重复直至达到目标。

测试阶段允许在更深的层次进行优化：
检查物理布局。
监视资源争用。
– 内存利用率
– 锁定
– 磁盘热点
测试资源耗尽。

测试：数据库配置
测试阶段允许在更深的层次进行测试。测试案例应运行应用程序功能、预期的负载以及对不大可能的负载的压力测试。通过这些类型的测试，可以在最佳物理布局以及最佳 OS 和硬件配置方面获得有价值的信息。监视热点（即使在快速磁盘上），这一点很重要。应规划数据配置，使其可以缩短恢复时间和加快数据访问速度。尽量考虑业务对恢复时间和可用性的要求，以便留出这些要求所需的开销。
通过可以耗尽计算机资源的负载进行测试。这些测试可确定占用最多的资源。这些资源就是限制系统的可伸缩性的资源。
DBA 在每个阶段使用时间模型来确定瓶颈，并使用优化会话来消除每个层次的瓶颈。

部署：
部署新的应用程序和数据库
– 获取基线。
– 监视增长和性能。
在现有数据库中部署新应用程序
– 获取部署前的基线。
– 获取部署后的基线。
– 比较基线。

部署
初次部署新的应用程序时，预期的性能与实际情况通常会有所不同。
这里要考虑两种差异：
第一种是对于新数据库上的新应用程序，第二种是对于添加到现有数据库中的应用程序。
新数据库上的新应用程序没有基线，因此要根据当前性能进行优化。定期获取性能基线报表。随着应用程序在数据集规模或用户数方面的增长，可将增加的性能报表与基线进行比较。这样一来，就可以在性能下降到无法接受的水平之前进行优化。
将新应用程序添加到现有数据库中时，可以在部署应用程序之前的基线性能报表与部署应用程序之后的基线性能报表之间进行比较。这些报表可以显示新应用程序正在使用的资源，以及可能与现有应用程序发生的资源争用。

优化是被动式的。你需要了解：
发生了哪些变化？
基线在哪里？

生产
对应用程序活动周期中的其他阶段的优化通常是主动式优化。你所做的是在用户注意到问题之前发现可能出现的问题。
对生产数据库的优化通常是被动式优化。出现了一些问题：以前需要数分钟即可运行完的报表，现在需要数小时，响应时间延长，用户不断抱怨未在分配的时间内完成备份。某些事情发生了改变。是否存在其他用户？是否正在运行新的报表或应用程序？OS 中是否发生某些改变？
若要优化以前在可接受状态下运行而现在出现问题的生产系统，需要了解或推断发生了哪些改变。将数据库在可以接受的状态下运行时获取的基线统计信息报表，与发现问题时获取的新报表进行比较。差异之处应当可以显示。
在没有基线统计信息时优化生产数据库会比较困难，但是仍可实现。所用的方法相同，并对确定了优先级的组件进行优化。使用时间模型确定问题。按从上至下的步骤，从设计开始考虑可能的解决方案。使用优化会话测试解决方案。

基线统计信息集用于：
提供系统在设置的界限内运行时收集的一组统计信息
将基线统计信息与当前统计信息进行比较
创建与系统已发生的改变相关的前提

收集基线统计信息集
每个生产数据库至少应存储一个基线统计信息集，以便在数据库性能下降时参考。使用此统计信息集可以确定是性能确实下降，还是用户判断情况已改变。
如果性能确实下降，则可以确定数据库的哪个方面已改变，并针对这个方面进行优化。可以创建问题原因以及如何解决问题的前提。
创建了前提之后，针对系统进行测试，并收集新的统计信息集。将新的统计信息集与基线统计信息集进行对比，确定是否得到了改进。
如果新的统计信息集实现了为系统制定的性能目标，则使用该统计信息集作为新的基线统计信息集。应保留以前的基线统计信息集，以便可以对系统的长期变化进行观察。
收集统计信息和创建基线统计信息集的方式取决于所使用的工具。除了收集统计信息之外，自动数据库诊断监视程序 (ADDM) 还分析不同之处并推荐解决方案。

影响性能的因素包括：
多控制文件
组中有多个重做日志成员
频繁的检查点检查
备份数据文件
执行存档
块校验和
并发用户和事务数

性能与安全性的折衷
在性能与安全性之间始终要进行折衷。提高数据库性能时，可能会对安全性产生负面影响。
反之，提高数据库的安全性，则会降低运行的速度。
Oracle 建议至少需要两个控制文件，其中一个是必需文件。许多 DBA 使用三个或四个控制文件。控制文件越多，要求执行的写入就越多，开销也就越多。多个重做日志成员会降低因为磁盘故障而丢失数据的机率，但是增大了写入重做的开销。频繁的检查点可以缩短平均恢复时间，但是会增加物理写入的