维护产生价值：只需加以注意即可降低数据库成本的五种方法

核心提示： 一种解决方案是提前完成工作并把结果存储在磁盘上，对于 DB2 8 系统，维护产生价值：只需加以注意即可降低数据库成本的五种方法(7)，一种解决方案是用 SELECTS DATE(col_TS)as NEW_COL FROM TABLE 创建物化查询表 (MQT) 并在 NEW_COL 列上创建索

一种解决方案是提前完成工作并把结果存储在磁盘上。对于 DB2 8 系统，一种解决方案是用 SELECTS DATE(col_TS)as NEW_COL FROM TABLE 创建物化查询表 (MQT) 并在 NEW_COL 列上创建索引。现在，所有动态查询将使用这个索引。对于 DB2 9 系统，另一个基于磁盘的解决方案是使用 Index on Expression 特性 — CREATE INDEX on DATE(col_TS)。这只用一个结构产生相同的结果，而且静态和动态查询都可以使用它。

这些技术也适用于运行开销极大、计算极复杂或运行极频繁的非冻结查询。如果您的站点无法采用这两种结构中的一种，那么在减少 CPU 需求方面就没什么好办法了。

另一个目前还不可用的解决方案是基于内存的，根据 IBM 实验室和客户的 beta 测试经验，这可以把长时间运行的查询的速度加快 5 到 10 倍，而不需要修改应用程序。具体方法是：使用 IBM Data Studio（可免费使用）把一个事实表和维表预先装载到内存中。这把数据仓库的一部分复制并压缩成一个完全位于内存中与网络相连的用具，形成一个加速查询表 (AQT)。这个特性称为 IBM Smart Analytics Optimizer，当前处于 beta 测试阶段。把查询由基本表/索引转向 MQT/索引所用的 DB2 9 Query Router 将能够透明地让 INNER/LEFT JOIN 查询使用 AQT。这种基于内存的技术将随着时间的推移逐渐增强，能够重定向更多的查询，实现更显著的查询加速。可伸缩性需要一个智能的性能层；MQT、Index on Expression 和 AQT 将组成这个性能层。

5. 根据工作负载模式创建最优的模式设计

可伸缩性还需要智能的模式设计，它应该能够高效地适应工作负载模式。例如，联机事务处理 (OLTP) 和内部网应用程序最好采用第三范式表设计，从而减轻无规律的更新/删除操作的影响，还应该经常检查索引。这种规范的设计适用于静态的集中的业务问题。联机分析处理 (OLAP) 和商业智能 (BI) 应用程序最好采用星形模式和非规范化。事实表和维表设计适用于涉及海量数据的特殊业务问题。这些环境应该采用完全不同的基本表设计、索引设计、MQT、 Index on Expression 和 AQT，从而根据工作负载模式充分利用 DB2 提供的特性（见图 5）。

图 5. Web 和 OLTP 应用程序需要智能的索引策略（包括 Index on Expression）以处理大量小查询。OLAP 和 BI 应用程序应该利用 MQT 和 AQT 处理涉及海量数据的宽泛的业务问题

了解您照料的数据库

组织应该非常熟悉他们的 DBMS，对数据库进行适当的维护并注意细节。为了保持可伸缩性，打包的 DB2 应用程序也需要符合性能规则。应该使用适当的 SQL、索引、访问路径、MQT、表设计和 AQT，只要遵守这些简单的规则，就能大大降低数据管理成本。实现这些规则需要花费时间和精力，在当今快速的应用程序开发周期中往往顾不上考虑它们。但是，如果忽视这些工作，您的 DBMS 很快就会不堪重负。