软件测试中Oracle决策支持系统下的性能调整和优化原则

软件测试中Oracle决策支持系统下的性能调整和优化原则

DSS 系统的特征是从大量的数据中产生有意义的报告。DSS 应用可能会经常与 OLTP 一起使用，但因为它们的设计要求差异很大，把 OLTP 系统用于决策支持不是好的主意。OLTP 的用户一般很多，而 DSS 系统的用户一般较少。决策支持系统的例子有与定单录入系统（OLTP系统）一起工作的现金流预测工具，该工具可以帮助决定需要多大的现金储备。另一个决策支持的例子是客户需求分析工具，该工具可以找出某个地域客户对哪个产品购买量最大。

　　决策支持系统的主要特征是：

• 读取大容量的数据，经常使用全表扫描作为存取数据的方法。
• 极少量地更新数据。一般而言，从OLTP 系统的数据（也可能是其它的数据源）会以批的方式流向 DDS 系统，用户自己极少会更新 DSS 的数据。

　　下图反映了DSS系统的特征：

　　DSS系统在运行时，有如下的一些要求：

• 合理的响应时间。
• 结果是准确的。
• 可以在白天使用。

　　为了满足上面的要求，应当从以下几个方面考虑调节数据库DSS应用系统。

1. 在使用应用逻辑和声明约束来维护完整性方面，切记声明完整性约束的代价要小。在DSS系统中，相关完整性约束和表的check 约束是主要使用的约束形式。

2. 尽量要使代码被存储过程对象共享。

3. 即使一条SQL语句在不同的运行环境下捆绑变量（bind variable）取了不同的值，Oracle认为他们是同样的SQL语句。因此，要使分析SQL语句的工作减少到最抵，应当使用捆绑变量，而不是将这些不同的值直接放到SQL语句中（使用 literal）（如果这样做了，Oracle 认为它们之间是不同的SQL，需要重新分析）。但是，这样做会有如下的损失：优化器无法知道列的可选择性。而完全写出来的SQL 语句（使用 literal），可使基于成本的Oracle优化器使用直方图统计（histogram）。

4. 无论如何，对DSS系统来说，分析 SQL 用的时间要比执行SQL语句用的时间要少的多。工作重点应当是优化SQL语句执行计划的存取路径上。这里的微小调节可能会带来几分钟，甚至是几小时性能的提高。开发人员必须考虑：

• 使用并行查询（parallelized query）。这可以使多个处理器工作在一起，同时处理一条SQL语句。使用镜像多处理（Symmetric Multiprocessors，SMP）、集群、大规模并行处理（massively parallel processing，MPP）会极大地提高DSS系统的性能，因为这样做可以将工作分在多个 CPU 上完成。
• 应当用提示来控制SQL 语句的存取路径，并利用 explain plan 来调节SQL 语句。

5. 因为DSS系统的数据更新以定时的批处理为特征，所以，DBA 在进行性能调节时有很多选择。DSS系统可以使用索引和簇（特别是哈稀簇），因为数据更新并不经常发生。在批量的数据更新完成后，可以重新创建索引和簇，以避免修改索引和簇的负面影响。如果不能在批量处理完成后重新创建簇，则为存取性能考虑，不应为在装入时不断增长的表创建簇。

6. 应当将索引存放到一起。

7. 因为大多数查询是全表扫描，应当仅在有选择性查询的表上加索引。

8. 应当经常用 analyze 进行统计。对那些数据分布不均匀的表，应当经常产生统计直方图（Histogram）。

9. 对那些不同值很少的列，使用 bitmap 索引。

10. 对于块插入和修改，必须设置如下的初始化参数：SORT_AREA_SIZE、BITMAP_MERGE_AREA_SIZE、CREATE_BITMAP_AREA_SIZE。

11. 对那些需要用键列做条件做准确匹配的查询或范围查询，如果要将行的信息全部查出，应考虑使用组织索引表。

12. 在一些情况下，一些表根本不变化，此时可以将这些表放到一个特殊的表空间中，并使该表空间只读。

13. 因为DSS应用经常进行全表扫描，所以应当将 DB_BLOCK_SIZE 的值设得高一些，即使这需要重新创建数据库也应这样做。因为大量读是DSS系统的基本特征，这样做会使DSS系统的性能发生根本改变。还应当注意参数 DB_FILE_MUTIBLOCK_READ_COUNT 的设置，该参数决定了全表扫描和快速全索引扫描每次操作系统读调用操作的数据库块数。盘区的尺寸应当是DB_BLOCK_SIZE* DB_FILE_MUTIBLOCK_READ_COUNT的倍数

原文转自：http://www.ltesting.net