DB2 最佳实践: DB2 成本削减策略

核心提示：概要介绍DB2 开发和规划团队很久以前就认识到降低维护成本的必要性，这种认知促使他们开始关注许多行业领先的特性，DB2 最佳实践: DB2 成本削减策略，比如 Configuration Advisor、Design Advisor 和一些自治特性（如自调优内存管理器），这些特性可以帮助减少与 DB2 维护有关的人力成

概要介绍

DB2 开发和规划团队很久以前就认识到降低维护成本的必要性。这种认知促使他们开始关注许多行业领先的特性，比如 Configuration Advisor、Design Advisor 和一些自治特性（如自调优内存管理器），这些特性可以帮助减少与 DB2 维护有关的人力成本。与硬件成本削减有关的特性（比如数据压缩）以及虚拟化支持也构成了向低成本演变的一部分。

DB2 数据库不仅包含了旨在降低成本的特性，它始终保持在行业性能基准之上。DB2 性能基准页面 描述了这种性能领先性。

由于具有旨在帮助削减成本的行业领先特性、性能领先性和一个开放标准，因此，DB2 数据库在低成本演变方面也保持领先优势。

本文将全面审视成本削减策略，并提供针对以下各种主题的指导：

规划

安装

设置和配置

维护和操作

降低硬件成本

减少故障诊断成本

某些小节包含了指向其他最佳实践文章的链接，这些文章描述了针对特定主题的具体技术或最佳实践。其他小节则重点介绍了有关这些主题的关键考虑事项。

最后，通过提供简单的方法来找出可以在 DB2 环境中削减成本的特性，本文档描述了如何轻松地在企业标准中确定成本削减策略。要确保使用远程监控技术在数百个或数千个系统之间监视成本削减特性，检测是一个非常重要的环节。这可以帮助您在企业范围内扩展您的成本削减策略。

DB2 数据库和总拥有成本

本白皮书主要针对数据库管理员（DBA），侧重于 DB2 数据库的快速成本削减实践。本白皮书的目标是解放 DBA，使他们能够将更多的注意力、时间和精力集中到业务发展方面。以降低成本为宗旨，我们将跳过繁琐的介绍，直接切入主题。

我们将首先讨论企业成本削减，它涉及三个关键方面：

IT 实践（包括标准化）

业务策略（比如主数据管理，可以整合和 / 或精简业务）

成本削减特性和技术

我们将简要介绍每一个方面，但是将对最后一个主题进行深入探讨，因为这是本文的主要关注点。

标准化

标准化对于减少各个系统和 DB2 实例的复杂性和特殊性至关重要。特殊性只有在驱动业务价值时才对业务有价值。除此以外，其他任何原因的特殊性只会带来不必要的复杂性。例如，拥有 100 个专门系统和 DB2 实例会增加维护成本，因为每一个系统都有它自身所特有的计划表、特性以及挑战或机遇。另一方面，100 个标准化系统可以更好地共享计划表、基本原则、最佳实践以及已知的改进。企业标准化提供了增强的一致性、改进的可预测性和更低的风险，所有这些改进都有助于降低您的业务成本。对于数据仓库需求，IBM Balanced Warehouse™ 为企业范围内的应用提供了一个标准化平台。

业务策略

有许多种业务策略，比如整合、虚拟化、主数据管理（MDM）以及流线化开发。IBM 在每一种策略方面都拥有行业领先技术，包括其 MDM 解决方案、Data Studio 以及旨在流线化业务的各种技术。请咨询 IBM 的本地销售代表，详细了解这些技术如何帮助您节省业务资金。

IBM 的业务和技术顾问可以为您的企业提供出色的标准化实践，他们非常乐意帮助您流线化您的业务运营，从而最终实现成本削减。

成本削减特性和技术

DB2 数据库是行业内的性能领先者。通过结合旨在帮助缩减成本的行业领先特性，比如压缩，DB2 数据库是帮助您削减 IT 部门的成本的最佳选择。性能和特性（比如压缩）都能帮助您最大程度地利用您的硬件投资成本。请参考以下最佳实践，了解如何利用 DB2 数据库的出众性能以及它如何帮助您实现硬件成本节约：

DB2 最佳实践: 编写并调试查询语句以优化性能最佳实践

DB2 最佳实践: 性能调优和问题诊断最佳实践

DB2 最佳实践: 在 DB2 for Linux, Unix, and Windows 中的行压缩的最佳实践

DB2 最佳实践：使用虚拟化来提高数据服务器利用率和对数据服务器的管理

除了硬件成本外，人力成本也构成了平均 IT 预算的一个重要部分。可以实现自动化的任务越多，花在繁琐任务方面的时间就越少。这可以空出更多的时间来关注业务发展（更不用说可以令 DBA 大大减轻负担）。DBA 和企业认识到利用成本削减技术的团队能够将他们的时间重新投入到积极的企业增长中，这对公司的盈利以及 DBA 对公司的价值将产生实质的影响。事实上，企业将获得双重受益：降低日常成本并提高生产力，从而推动业务向前发展。还有比这更划算的事情吗？

DB2 数据库成本削减特性一览表

下表列出了旨在帮助企业削减成本的 DB2 特性，并指出了每一种特性所在的版本。

	DB2 UDB Version 8.2	DB2 Version 9.1	DB2 Version 9.5	DB2 Version 9.7
Configuration Advisor	X	X	X	X
Design Advisor	X	X	X	X
自调优内存管理器		X	X	X
自动备份	X	X	X	X
自动统计数据收集	X	X	X	X
工作负载管理			X	X
数据压缩		X	X	X
自动存储	X	X	X	X
自动重组	X	X	X	X
非根安装			X	X
pureXML®		X	X	X
低内存占用线程化架构			X	X
自调优备份	X	X	X	X
自调优负载	X	X	X	X
查询重写	X	X	X	X
数据库管理工具（Data Studio）			X	X

本文提供了有关上表提及的一些关键特性的说明。

规划您的系统

容量规划是开始实现成本削减实践的良好开端。与容量有限的系统相比，一个针对工作负载及其预期增长进行了适当容量调整的系统将经历更少的问题。超大容量的系统不会引起问题，但是会浪费宝贵的硬件资源。实现两者的平衡是一个重要目标，而这可以通过一组最佳实践实现。

如果系统和实例已经启动并运行，那么您可以使用诸如 DB2 Performance Expert 历史归档之类的技术收集各种关键性能指标（KPI）。DB2 Performance Expert 可以给出一些推断，比如工作负载随时间的增长、这种增长对系统资源的影响，以及 DB2 系统的最佳调优。另一方面，如果您从零开始且没有任何可供利用的系统指标，那么最好咨询熟悉其他系统的专家，以帮助您确定初始大小并选择必需的硬件。DB2 最佳实践: 性能调优和问题诊断最佳实践 中的“硬件配置”小节介绍了有关容量规划的一些方面。

安装 DB2 系统

有关安装的最佳实践，请参考 DB2 最佳实践: 部署 IBM DB2 产品 一文中的部署 DB2 产品的最佳实践。本文介绍了来自 IBM 主题专家的安装规划、安装方法和大型部署。大型部署方法对于那些包含数百或数千个 DB2 实例的企业环境尤其重要。

配置 　DB2 系统

本节将概述关键的 DB2 成本削减特性，它们可以帮助配置和调优您的实例和数据库。本节包括针对每个特性的最佳实践以及有关它们使用状况的检测方式。后一部分内容可以简化对标准实践的监视以及整个企业内潜在的成本削减机会的识别。

DB2 Configuration Advisor

由于 DB2 客户库极其复杂，因此任何硬编码的默认配置只适合一小部分系统。DB2 数据库包含一个名为 Configuration Advisor 的特性，该特性可用于通过一组最简单的步骤来执行点击操作，从而在最短的时间内配置一个新的或已有的数据库。Configuration Advisor 可以帮助在默认配置值的基础之上实现显著的性能改进。

当自动运行在一个新数据库之上时，Configuration Advisor 将做出一些假设，比如数据库中混合了 OLTP 和 DSS 工作负载。如果在创建数据库并使用了一段时间后运行 Configuration Advisor，您可以提供有关目前已知的工作负载的信息，这将生成更好的配置。

Configuration Advisor 不会持续修改配置参数来响应不断变化的工作负载。如果希望它这样做的话，那么可以使用自调优内存管理器（STMM），我们将稍后介绍这一主题。然而，Configuration Advisor 确实调优了一些 STMM 没有修改的参数。下表显示了分别由 Configuration Advisor 和 STMM 调优的参数：

参数	类型	Configuration Advisor	STMM
AGENT_STACK_SZ	DBM	√
ASLHEAPSZ	DBM	√
FCM_NUM_BUFFERS	DBM	√
INTRA_PARALLEL	DBM	√
MAX_QUERYDEGREE	DBM	√
MAXAGENTS	DBM	√
NUM_POOLAGENTS	DBM	√
NUM_INITAGENTS	DBM	√
PRIV_MEM_THRESH	DBM	√
RQRIOBLK	DBM	√
SHEAPTHRES	DBM	√
APP_CTL_HEAP_SZ	DB	√
APPGROUP_MEM_SZ	DB	√
APPLHEAPSZ	DB	√
CATALOGCACHE_SZ	DB	√	√①
CHNGPGS_THRESH	DB	√
DBHEAP	DB	√	√①
DFT_DEGREE	DB	√
DFT_EXTENT_SZ	DB	√
DFT_PREFETCH_SZ	DB	√
DFT_QUERYOPT	DB	√
LOCKLIST	DB	√	√
LOGBUFSZ	DB	√
LOGFILSIZ	DB	√
LOGPRIMARY	DB	√
LOGSECOND	DB	√
MAXAPPLS	DB	√
MAXLOCKS	DB	√	√
MINCOMMIT	DB	√
NUM_IOCLEANERS	DB	√
NUM_IOSERVERS	DB	√
PCKCACHESZ	DB	√	√
SOFTMAX	DB	√
SORTHEAP	DB	√	√
STMTHEAP	DB	√
STAT_HEAP_SZ	DB	√
UTIL_HEAP_SZ	DB	√	√①
SELF_TUNING_MEM	DB	√
AUTO_RUNSTATS	DB	√
AUTO_MAINT	DB	√
AUTO_TBL_MAINT	DB	√
SHEAPTHRES_SHR	DB	√	√
DATABASE_MEMORY	DB		√
(Buffer pool sizes)	Buffer pool	√	√

① ：DB2 数据库将调优在这些堆耗尽内存的情况下可用的空闲数据库内存量。

从 DB2 Version 9 开始，在默认情况下将为新数据库激活 AUTOCONFIGURE（Configuration Advisor 实用工具的命令行调用）。还可以运行 AUTOCONFIGURE 命令来对现有数据库使用 Configuration Advisor。

注意：Configuration Advisor 不会在升级期间自动运行，因此您需要在必要时手动使用它。

研究表明，使用非自动化或非默认特性的次数要比使用自动化和默认特性的次数少 20 倍。如果您的企业也是这种情况的话，那么在没有企业标准且不受鼓励的情况下，不太可能出现在创建数据库后手动运行 Configuration Advisor 的情况。这将导致出现许多未得到调优的系统，或者需要花费额外的时间手动调优每一个系统。确保您的组织了解运行 Configuration Advisor 的价值，且至少需要在最开始考虑一些推荐实践。

下面是关于使用 Configuration Advisor 的一些一般规则：

如果使用 Data Partitioning Feature，那么使用注册表变量禁用 AUTOCONFIGURE。每个节点都应该使用相同的调优设置。可以专门在一个节点上调优 AUTOCONFIGURE 以为此节点获得最佳性能，然后在其他节点（分区）中手动复制这些设置。

如果在创建一个新数据库时没有特意运行 AUTOCONFIGURE，那么在数据库相对较新时尽早使用 Configuration Advisor GUI。该 GUI 会带领您了解有关数据库参数调优的其他信息。最后，您应当记录下 GUI 中显示的有关您的数据库的 10 个问题的答案，这样就可以调度一个任务以便稍后自动执行。

当数据库运行一个典型的工作负载时，或者当它一旦被用于生产中时，那么每月使用一个计划好的任务运行 AUTOCONFIGURE 命令（包含 APPLY NONE 关键字）。确保对此命令使用全部 10 个输入关键字，这样计划任务就可以提醒您以及其他 DBA 有关这个数据库的调优情况。由于许多 DBA 默认情况下从其他人那里继承数据库，因此对每个生产数据库每月运行一次 AUTOCONFIGURE 任务将使这些刚接触环境的 DBA 有机会了解数据库的预期任务。这不会对数据库产生配置修改，但是会提出一组合理的配置建议。查看这些修改并在适当的时刻应用最有益的修改。

在使用该数据库的应用程序中，将 AUTOCONFIGURE 命令的 ISOLATION 参数设置为任意查询中使用的最高隔离级别。这将影响与并发性有关的 locklist等配置参数，因此需要谨慎地设置这一项，选择推荐使用的最高隔离级别。如果 locklist被设置为 AUTOMATIC，那么 STMM 稍后始终可以调整 locklist 配置参数。

BP_RESIZABLE 参数确定是否允许 AUTOCONFIGURE 命令对缓冲池的大小提出建议。将 BP_RESIZABLE 设置为 YES 将为每个缓冲池建议最佳初始大小。如果这些参数都是被自动设置的话，那么 STMM 总是可以在稍后调整这些参数。允许 AUTOCONFIGURE 和 STMM 修改您的缓冲池的例外情况就是那些使用 DPF 的数据库以及 ISV 禁止您作出修改的数据库。

检测 DB2 Configuration Advisor

要检测 Configuration Advisor 是否处于活动状态（在 DB2 Version 9.1 及以上版本中），查看 DB2_ENABLE_AUTOCONFIG_DEFAULT 注册表变量。只要 DB2_ENABLE_AUTOCONFIG_DEFAULT 注册表变量没有被设置为 NO，那么在数据库创建期间将默认调用 Configuration Advisor，即使没有指定 AUTOCONFIGURE 关键字。在脚本中，您可以检查 AUTOCONFIGURE APPLY NONE，可以在 CREATE DATABASE 命令期间使用它关闭 Configuration Advisor。如果没有使用该注册表变量关闭 AUTOCONFIGURE，那么在脚本中使用 APPLY NONE 运行 AUTOCONFIGURE 实用工具并生成一个推荐报告；然而，并没有应用参数和缓冲池建议。

如果希望禁用 configuration advisor，可以设置注册表变量：

　db2set　DB2_ENABLE_AUTOCONFIG_DEFAULT=NO　

或者，在使用 CREATE DATABASE 命令期间，可以指定 “AUTOCONFIGURE APPLY NONE”

　db2　CREATE　DB　db_nameAUTOCONFIGURE　APPLY　NONE　

注意：虽然 STMM 自动调优重要的内存参数，但是它不提供与环境性能有关的所有配置选项。请参考自调优内存一节，进一步了解 STMM。

通过预取程序和页面清理程序改善缓冲池的使用

预取大小曾被设置为一个固定的默认值，该值可能只适合某个非常具体的环境。从 DB2 Version 8.2 起，预取大小将根据以下算法自动计算：

预取大小　=　(　容器数量　)　X(　每个容器中的物理磁盘的数量　)　X　盘区大小　

这可以使面向各种配置的值更加动态和准确。通常没有必要再进一步进行调优。

在 DB2 Version 9 之前的版本中，您需要手动设置预取程序和页面清理程序的数量。如果该值设置得过低或过高，性能就会受到影响。

从 DB2 Version 9 开始，预取程序（NUM_IOSERVERS）和页面清理程序（NUM_IOCLEANERS）的数量将在数据库激活期间由配置参数 AUTOMATIC 的值自动设置（默认值）。有许多关于预取程序（IOSERVERS）和页面清理程序（IOCLEANERS）的文档，因此这里不会详细描述这些程序的功能和工作方式。

不需要对这些参数进行复杂的手动调优，NUM_IOCLEANERS 和 NUM_IOSERVERS 的设置远远好过默认值。对预取程序和页面清理程序使用自动设置对于企业成本削减标准是一种不错的选择。

检测预取程序和页面清理程序自动设置

要检测预取程序和页面清理程序的设置，使用 GET DATABASE CONFIGURATION 命令：

　db2　get　database　configuration　for　db_nameshow　detail　

在输出中查找 NUM_IOCLEANERS 和 NUM_IOSERVERS：

…　
　
　Number　of　asynchronous　page　cleaners　(NUM_IOCLEANERS)　=　AUTOMATIC(1)　
　
　Number　of　I/O　servers　(NUM_IOSERVERS)　=　AUTOMATIC(3)　
　
…　

当将两者的值设置为 AUTOMATIC 时，将在数据库激活时自动选择预取程序和页面清理程序的数量。

DB2 Design Advisor

可以使用 DB2 Design Advisor 改善工作负载性能。当为 DB2 Design Advisor 提供工作负载中的一组 SQL 语句时，它将为复杂的工作负载提供有关索引、Materialized Query Tables (MQTs)、集群维度或数据分区的建议。您可以让 Design Advisor 立即或稍后实现它的推荐设置。

Design Advisor 可用于新数据库或现有数据库。对于新数据库，Design Advisor 可以减少用于设置或改进性能所需的时间。对于现有数据库，在很多情况下，您可以显著地改进性能。

如果正在设计一个单分区数据库，那么可以使用 Design Advisor 在测试环境中生成更多的设计选择。还可以使用它来评估已生成的索引、MQT、多维集群（MDC）表，或者数据库分区策略。

DB2 Design Advisor 使用技巧

使用 Design Advisor 从您的测试系统中创建推荐配置。如果不希望对生产系统运行 Design Advisor，那么对您的测试系统运行它。Design Advisor 需要三项内容来完成计算：

当前的数据库结构

针对这些结构运行的工作负载

统计数据

如果您的测试环境包含所有与生产环境相同的数据库结构，那么可以对测试环境运行 Design Advisor。然而，由于测试环境通常并没有全部填满数据，因此测试统计数据不可能与生产统计数据相同，即使您对测试环境中的所有内容运行了 RUNSTATS。您可以模拟生产统计数据（或者从生产系统中复制它们），然后在测试系统上运行 Design Advisor。为此，使用下面的 DB2LOOK 实用命令来模拟生产统计数据：

　db2look　-d　db_name-a　-m　-c;　

该命令为您提供了合适的 UPDATE 命令来针对测试数据库中的可更新视图运行。对视图进行更新后，对您的测试数据库运行 Design Advisor。Design Advisor 将给出与在生产数据库中相同的建议。然后您可以在生产数据库中实现 Design Advisor 的建议。

这里有一个例外：需要使用 MDC 建议的测试表。要想使 Design Advisor 能够给出 MDC 建议，测试表必须具有良好的数据表示，即使您将生产统计数据复制到测试环境中。如果没有对表数据进行良好的抽样，那么就没有足够的统计数据来给出可能的 MDC 值。要确保 Design Advisor 可以针对具体的表给出最佳 MDC 建议，尝试完全填充它们（如果可能的话，使用生产数据）。

获得 MQT 建议以改善工作负载性能，而不是刷新性能。
Design Advisor 不建议逐步刷新 MQT，因为它没有将 MQT 的刷新看作是工作负载的一部分。这一情况也适用于 MQT 建议的索引，道理是一样的。索引用于 MQT 性能以及使用它的工作负载，没有必要对 MQT 刷新使用它。

必须确定是否希望创建 staging 表来实现逐步 MQT 刷新。还将需要判断刷新是否会受到建议索引的不利影响。

从 DB2 Version 9.5 开始，Design Advisor 还可以接受来自 DB2 Workload Manager 的输入。只需使用 COLLECT ACTIVITY DATA WITH DETAILS 或 COLLECT ACTIVITY DATA WITH DETAILS AND VALUES 选项捕捉感兴趣的特定工作负载，并使用如下命令将结果加载到 Design Advisor：

　db2advis　-d　db_name-wlm　DB2ACTIVITIES　

面向分区数据库的 DB2 Design Advisor

如果正在设计一个分区数据库，那么可以使用 Design Advisor 完成下面的任务：

在将数据加载到数据库之前确定分区策略。

帮助从单分区数据库迁移到多分区数据库。

帮助从另一个数据库产品迁移到 DB2 数据库。

当设置好数据库后，可以使用 Design Advisor 完成下面的操作：

帮助改进特定语句或工作负载的性能。

使用样例工作负载的性能作为标尺，帮助改进数据库性能。

帮助改进最常执行的查询的性能，例如，如 Activity Monitor、应用程序快照或应用程序管理视图所标识的查询。

确定如何优化新的关键查询的性能。

响应 Health Center 或 Data Studio Administration Console 的建议，这些建议与共享内存实用工具或排序密集型工作负载中的堆排序问题有关。

查找工作负载中没有使用的对象。

在成本削减标准中包含 Design Advisor，因为它可以帮助您极大地缩短设计数据库对象所需的时间，并改进工作负载性能。

维护 DB2 系统

本节将描述一些特性和实践，它们可用于显著地降低与实例和数据库的维护和运作相关的成本。

自调优内存管理器

无论您是初级还是高级 DBA，自调优内存管理器（STMM）都可以帮助您节省许多用于调优方面的时间，因为它利用了来自最优秀的 DB2 性能专家的专门技术。

STMM 是行业内最高级的自调优技术之一。与 Configuration Advisor（只能在数据库创建时或由用户调用）不同，STMM 可以适应环境中的实际工作负载和修改，并相应地调整 DB2 内存配置。Configuration Advisor 和 STMM 是两款互补的工具。Configuration Advisor 调优所有与性能有关的参数（包括许多与内存无关的参数），但是只有在收到请求时才这样做。STMM 对 DB2 数据库最大的内存区进行调优，并且是持续进行的。但是它不会处理与性能有关的其他参数。

自调优内存对于那些动态的或难于预测的工作负载尤其有用。STMM 的目的始终是改善内存使用，这使您从频繁的更改以及对调优的密切监视中解放出来。

自调优内存的表现极为出色，因此最近的一些基准测试使用它来帮助调优数据库以获得最佳性能。STMM 最初是由 IBM Toronto Lab 的一些顶级性能调优专家设计的。在 DB2 Version 9 中，在默认情况下将为新的单分区数据库启用 STMM。对于 DB2 UDB Version 8 升级版，STMM 则继续保持关闭状态，除非您手动启用它。有关在升级后启用

在分区数据库环境中，STMM 默认情况下是关闭的。在这类环境中，自调优内存有一些特殊的考虑事项。例如，STMM 将所有数据库分区都看作是类似的结构。如果所有数据库分区都是相似的，或者针对一组特定的相似的数据库分区启用它，那么 STMM 将非常高效。

下表展示了 STMM 如何随着工作负载的变化动态调优 DB2 数据库，同时将内存保持在一定范围内。手动执行这种持续的调优是不现实的，这也是自调优内存在节省时间和改进性能方面表现良好的原因。

图 1. 缓冲池分配

检测自调优内存管理器

使用 GET DATABASE CONFIGURATION 命令检测 STMM：

　db2　get　database　configuration　for　db_name　

查找下面的条目：

　Self　tuning　memory　(SELF_TUNING_MEM)　=　ON　

此外，两个或多个 STMM 配置参数必须被设置为 AUTOMATIC，这样才能够启用 STMM。

如果仍然希望手动调优内存，那么可以在一个工作负载下将 STMM 运行 12 到 24 小时，在关闭它之前作出有关内存参数的最佳推测，然后实现您认为合适的建议。这项实践有时也应用于分区实例中，以为手动调优环境获得一个良好的建议配置。

常见问题解答

问题 #1：自调优内存可以用于 AIX Virtualization 吗？

是的。一些白皮书介绍了这一问题，包括来自 developerWorks 的文章：Implementing System p virtualization with DB2 and WebSphere using IBM Enterprise Workload Management。

问题 #2：STMM 可以用于只有少量内存（４ＧＢ或８ＧＢ）的系统吗？

是的，STMM 的设计初衷就是面向各种大型或小型系统。

问题 #3：STMM 在生产环境中的开销怎么样呢？

ＳＴＭＭ 的开销非常小，且通常与显著的性能增益相抵消。

问题 #4：我一直看到的这些 STMM 诊断日志是什么？

2008-01-03-10.32.55.634423-300　I27429A459　LEVEL:　Event　
　　
PID　:　798770　　TID　:　1　　PROC　:　db2stmm　(SAMPLE)　0　
　　
INSTANCE:　db2inst1　NODE　:　000　　DB　:　SAMPLE　
　　
APPHDL　:　0-203　　APPID:　*LOCAL.DB2.080151576421　
　　
AUTHID　:　WILDING　　
　
FUNCTION:　DB2　UDB,　config/install,　sqlfLogUpdateCfgParam,　probe:20　　
　　
CHANGE　:　STMM　CFG　DB　SAMPLE:　"Database_memory"　From:　"592000"　
　　
<automatic>　To:　"615200"　<automatic>　

这是在ＳＴＭＭ调优系统时自动发生的配置更改。

问题 #5：STMM 可以用于同一个 ＬＰＡＲ 下的多个数据库吗？

STMM 是特定于数据库的，因此可以用于同一台计算机或 ＬＰＡＲ 中的多个数据库。

自动存储

存储是四种关键资源（CPU、内存、网络和存储）之一，并且是削减成本的重要部分。一个自动存储数据库包含完全由 DB2 数据库管理员管理的表空间。在最基本的层面，针对自动存储启用了的数据库具有一组一个或多个与它们有关的存储路径。表空间可以被定义为 MANAGED BY AUTOMATIC STORAGE，并且它们的容器可以由数据服务器根据这些存储路径进行指定和分配。在 DB2 Version 9.5 中，自动存储是非 ＤＰＦ 系统的默认选项。

对于使用 DB2 9.7 创建的数据库，可以在任何时候启用自动存储。对于已经启用了自动存储的数据库，可以将任何表空间移入到自动存储池中，从而实现了更多的灵活性。对于 ９ . ７ 以前的 DB2 版本，必须在数据库创建期间启用自动存储，并且不能将表空间移入到自动存储池中。

命令行处理器（CLP）提供了一种方式可以在数据库创建期间禁用自动存储，即显式地使用 AUTOMATIC STORAGE NO 子句。如果在 Control Center 中使用创建数据库向导，那么可以通过单击 I want to manage my storage manually 按钮禁用自动存储。如果使用的是 Data Studio Administration Console，那么取消选中 Manage storage automatically with DB2 框。

存储管理：自动调整大小

您还可以启用自动存储表空间来自动调整大小，从而允许数据库管理员通过添加新的容器带区集（stripe set）来自动处理所有文件系统环境。

您可以使用 CREATE DATABASE 命令或通过 Control Center Wizard（通过单击 Let DB2 manage my storage）启用自动存储。在 DB2 Version 9 中，数据库在创建时默认启用了自动存储，但是在 DB2 UDB Version 8 中，需要在创建数据库时指定自动存储。

下面是一些通过显式或隐式方式启用的自动存储示例：

CREATE　DATABASE　DB1　
　
CREATE　DATABASE　DB4　ON　D:\PathToStorage　DBPATH　ON　C:　
　
CREATE　DATABASE　DB2　AUTOMATIC　STORAGE　YES　ON　E:　
　
CREATE　DATABASE　DB3　ON　/data/pathA,　/data/pathB　

检测针对表空间的自动存储

要检测是否对表空间使用了自动存储，获取一个快照。该快照将显示正在使用的自动存储路径。

使用下面的命令获取表空间快照并在命令输出中查找“Using automatic storage”：

　db2　get　snapshot　for　tablespaces　on　db_name　

其中，db_name表示目标数据库的名称。例如，在 UNIX 或 Linux 系统上，您可以使用 grep 实用工具来过滤输出，如下所示：

　db2　get　snapshot　for　tablespaces　on　
　
　db_name|　grep　'Tablespace　name|Using　automatic　storage'　

查看自动存储的另一种方式是获取数据库快照并查找 “Automatic storage”。

　db2　get　snapshot　for　database　on　
　db_name|　grep　–　i　‘　automatic　storage　’　
　
　Number　of　automatic　storage　paths　=　1　
　Automatic　storage　path　=　/data/db2/db2inst1　

结果显示自动存储特性的存储路径。

最后，还可以使用 db2pd命令来检测是否已使用 db2pd – tablespaces命令启用了自动存储。具体来讲，需要在输出中查看有关表空间自动调整大小的统计数据。

注意：当对数据库启用自动存储后，不一定要对该数据库中的每个表空间使用自动存储。可以通过两种方式对已创建的表空间使用自动存储，即在表空间创建期间指定 MANAGED BY AUTOMATIC STORAGE 或去掉 MANAGED BY DATABASE 或 MANAGED BY SYSTEM 关键字。

对于 DPF 实例，自动存储的存储路径在默认情况下是类似的。例如，下面的命令在实例中的所有物理系统中使用路径 /path1、/path2 和 /db1：

　CREATE　DATABASE　mydb　ON　/path1,/path2,　DBPATH　ON　/db1　

要创建类似的路径，按照如下所示使用 $N 分区标识符：

　CREATE　DATABASE　mydb　ON　/p$N,/p$N,DBPATH　ON　/db1　

这将采用路径 /p1、/p2、/p3 等等，其中 1、2、3 表示实际的分区号。

常见问题解答

问题 #1：如何确定 DB2 目录中的表空间的最大大小？

DB2 Version 9 及更新版本提供了一个可以使用 SQL 进行查询的管理视图。

视图的名称为 SYSIBMADM.TBSP_UTILIZATION 并且它包含以下列：TBSP_MAX_SIZE、TBSP_INCREASE_SIZE 和 TBSP_LAST_RESIZE_TIME。还可以使用该视图查看已使用页面的百分比和当前大小，以确定您与最大大小之间的距离。

问题 #2：如何从 SMS 转换到 DMS 存储？

使用 db2look 重新创建用于生成表空间以及其中的表的 DDL。使用 DMS 重新创建表空间（和表），然后使用 db2move 将数据从 SMS 中移动到 DMS 存储。或者，可以使用 EXPORT 和 IMPORT 移动数据。

注意：还可以使用表空间备份，包含一个重定向的恢复。

问题 #3：当使用自动存储填充 DMS 文件系统时，应用程序会怎样？

应用程序将等待（暂停）执行重新调整大小。

问题 #4：当 DB2 数据库处于等待状态（直到文件系统变满）时，如何设置一个有关表空间变满的警告？

不需要监视 “table space full” 趋势，而是监视空闲空间并确保对表空间启用了自动调整大小。使用名为 SYSIBMADM.TBSP_UTILIZATION 的管理视图来查看已用页面的百分比。

问题 #5：可以通过增加文件系统下的磁盘空间量来增长存储池吗？

可以。根据情况扩展文件系统（或多个文件系统）可以保持对应的容器大小。

自动维护

DB2 数据库包含一些自动维护特性，可以进一步简化数据库管理。这些特性帮助 DBA 管理备份、收集数据库统计数据，以及处理数据库重组。

使用自动维护

要查看自动表维护设置，只需要使用以下命令查看数据库配置参数：

　db2　get　database　configuration　

查看以下自动维护条目：

　Automatic　maintenance　　　(AUTO_MAINT)　=　ON　
　Automatic　database　backup　　(AUTO_DB_BACKUP)　=　OFF　
　Automatic　table　maintenance　　(AUTO_TBL_MAINT)　=　ON　
　　Automatic　runstats　　(AUTO_RUNSTATS)　=　ON　
　　Automatic　statement　statistics　(AUTO_STMT_STATS)　=　OFF　
　　Automatic　statistics　profiling　(AUTO_STATS_PROF)　=　OFF　
　　　Automatic　profile　updates　(AUTO_PROF_UPD)　=　OFF　
　　Automatic　reorganization　(AUTO_REORG)　=　OFF　

如以上条目的缩进格式所示，配置参数存在一个层次结构。AUTO_MAINT 配置参数设置最高一层，而 AUTO_TBL_MAINT 配置参数涵盖了表维护选项。

注意：自动备份和自动重组通常应用于较小的系统和实例，特别是那些需要高度自动化的系统和实例。对于企业用户，更好的选择是按需执行 REORG 并通过其他途径实现自动化备份。我们将关注自动 RUNSTATS 和实时统计。

使用自动 RUNSTATS 和实时统计维护统计数据

DB2 优化器使用分类统计数据为任何给定的查询确定最有效的访问计划。准确、完整的统计数据对于实现有效的数据访问和最优工作负载性能至关重要。可以使用 DB2 自动统计数据收集特性来更新和维护相关数据库统计数据。对于在单一处理器上运行单一数据库分区的环境，可以有选择地增强这一功能，方法就是收集查询数据和统计数据概要文件，这些内容可以帮助 DB2 数据服务器自动收集工作负载所需的精确统计数据集。

自动统计数据收集按照您设置的刷新间隔对所需的表调用 RUNSTATS 实用工具。自动完成统计数据收集后，RUNSTATS 实用工具将自动更新有关某个表、其相关索引或统计视图的统计数据。更新后的信息包括记录的数量、页面的数量，以及对象的平均记录长度。优化器随后使用这些信息来确定最佳数据访问路径。

自动 RUNSTATS 可以很好地保持统计数据的时效性，但是有些时候需要更实时的统计数据。在 DB2 Version 9.5 中引入了实时统计数据收集功能，它可以同步地收集统计数据（即在查询运行时开始收集）。实时统计数据收集通过动态配置参数 AUTO_STMT_STATS 启用。其中有一个查询敏感度分析，可以确定某个特殊的语句是否需要更实时的统计数据。

对用于收集统计数据的时间有一个限制；默认值为 5 秒。如果收集时间长于这个值，一个异步统计数据收集将作为后台请求启动。

如果当前的统计数据不可用，那么优化器可能会根据不太准确的默认统计数据选择一个低效的访问计划。

您应当：

对查询有可能访问的所有表和索引执行自动化统计数据收集。

对具有显著更新行为或自上一次更新统计数据后创建了新索引的表执行自动化统计数据收集。

在更新完统计数据或修改配置参数后重新绑定应用程序（并有选择地重新解释它们的语句）。如果出现新的统计数据或配置值更改，查询优化器可能会选择一个不同的访问计划。

遵循这些实践将为优化器提供最准确的信息，这些信息可以帮助确定最佳访问计划。

要加快统计数据更新（并节省用于存储统计数据的磁盘空间），考虑只指定那些需要为其收集数据分布统计数据的列。

如果手动执行统计数据收集的话，确保索引统计数据与表同步，在同一时间更新表和索引统计数据。如果自上一次收集表统计数据后对表进行了大量的修改，那么只对该表收集索引统计数据将使两组统计数据无法实现同步。

从 DB2 Version 9 开始，自动统计数据在默认情况下是启用的。您应当将自动统计数据更新作为成本削减过程的一部分，因为更准确的统计数据可以帮助优化器为查询和应用程序选择最佳的可用数据访问路径。

要启用自动统计数据收集，使用 Configure Automatic Maintenance 工具或命令行来配置您的数据库实例：

要使用 Configure Automatic Maintenance 工具：

a. 打开该工具，通过右键单击数据库对象从 Control Center 中打开或者通过右键单击数据库实例从 Health Center 中打开。

b. 从弹出窗口选择 Configure Automatic Maintenance。在工具内部，可以启用自动统计数据收集，指定对哪个表收集统计数据，以及用于统计数据更新的维护窗口。

要使用命令行，使用 UPDATE DATABASE CONFIGURATION 命令将以下每一个数据库配置参数设置为 ON：

　DB2　UPDATE　DB　CFG　FOR　db_nameUSING　AUTO_MAINT　ON　
　DB2　UPDATE　DB　CFG　FOR　db_nameUSING　AUTO_TBL_MAINT　ON　
　DB2　UPDATE　DB　CFG　FOR　db_nameUSING　AUTO_RUNSTATS　ON　

要通过命令行设置策略，使用提供的存储过程 AUTOMAINT_GET_POLICY、AUTOMAINT_GET_POLICYFILE、AUTOMAINT_SET_POLICY 和 AUTOMAINT_SET_POLICYFILE。如果已经使用 Configure Automatic Maintenance 工具成功配置了数据库并且对配置很满意，那么通过一个命令行方法使用这些存储过程对所有其他类似的数据库设置相同的策略。

可选：如果希望启用自动统计数据概要文件生成功能，那么将 AUTO_STATS_PROF 和 AUTO_PROF_UPD 数据库配置参数设置为 ON。

可选：如果您希望启用实时统计数据收集功能，那么将 AUTO_STMT_STATS 数据库配置参数设置为 ON。该配置参数被设置为 ON 之后，不管何时需要用表统计数据优化查询，都会在语句编译时对其进行自动编译。

注意：自动统计数据收集功能在分区数据库环境、某些联合环境或启用了分区内并行性（parallelism）的环境下是不可用的。在这些环境中，您应当手动调用 RUNSTATS 来定期地更新统计数据（还可以从 ADMIN_CMD 过程调用 RUNSTATS）。

当在一个分区数据库环境中收集表统计数据时，RUNSTATS 将只对在其中执行收集的数据库分区中的表收集统计数据。由这个数据库分区产生的 RUNSTATS 将被推广到其他数据库分区。如果在其中执行 RUNSTATS 的数据库分区没有包含某个特定表的一部分，那么请求将被发送给数据库分区组中第一个包含这个表部分的数据库分区。

由于 RUNSTATS 只对单一数据库分区收集统计数据，因此如果数据在所有数据库分区之间的分布不一致的话，那么统计数据的准确性就会降低。如果怀疑出现了不一致的数据分布，那么可能需要在执行 RUNSTATS 命令之前使用 REDISTRIBUTE DATABASE PARTITION GROUP 命令在数据库分区之间重新分布数据。

在高活跃度期间对生产系统手动调用 RUNSTATS 可能会对生产工作负载的性能产生负面影响。可以控制 RUNSTATS 实用工具以限制 RUNSTATS 的执行在数据库活跃期间产生的性能影响。

检测自动统计数据更新

要检测是否启用了自动统计数据收集，使用 GET DATABASE CONFIGURATION 命令：

　db2　get　database　configuration　for　db_name　

该命令将返回如下所示的信息：

　Automatic　maintenance　　(AUTO_MAINT)　=　ON　
　Automatic　table　maintenance(AUTO_TBL_MAINT)　=　ON　
　　Automatic　runstats　(AUTO_RUNSTATS)　=　ON　

如果您使用了自动统计概要文件生成功能，您还会看到下面的内容：　

　Automatic　statistics　profiling　(AUTO_STATS_PROF)　=　OFF　
　Automatic　profile　updates　(AUTO_PROF_UPD)　=　OFF　

要关闭自动统计数据收集，使用 UPDATE DATABASE CONFIGURATION 命令来关闭 AUTO_TBL_MAINT 和 AUTO_RUNSTATS。

硬件成本削减策略

本节将描述帮助您削减硬件成本的特性和实践。硬件成本显然是总拥有成本的一个重要组成部分。好的一面是硬件正在变得越来越便宜、越来越快速、越来越可靠。当然，这并不表示我们现在不需要进一步削减硬件成本。如下所示的各种最佳实践有助于进一步降低成本：

DB2 最佳实践: 编写并调试查询语句以优化性能最佳实践

DB2 最佳实践: 性能调优和问题诊断最佳实践

DB2 最佳实践: 在 DB2 for Linux, Unix, and Windows 中的行压缩的最佳实践

DB2 最佳实践：使用虚拟化来提高数据服务器利用率和对数据服务器的管理

检验成本削减策略

取决于具体的平台，有很多极其有用的工具和技术可用于帮助诊断问题。对于 AIX、Solaris 和 HP-UX 操作系统，大部分问题诊断工具都是操作系统附带的，但是还有一些非常重要的免费工具。它们包括：

lsof：lsof 工具可以列出操作系统（OS）中所有打开的文件。当一个文件打开时，OS 将向进程返回一个数值文件描述符以供使用。该工具将列出 OS 上的所有已打开文件，并显示它们的进程 ID 和文件描述符。

某种类型的调试器。调试器对于更高级的诊断非常有帮助。

对于 Linux 操作系统，可供使用的强大、免费的故障排除工具有很多。使用这些工具可以防止简单的问题演变成为长期的、令人痛苦的麻烦，这会影响您的业务和生产力。下面是一些比较有用的诊断工具：

strace：strace 工具跟踪系统调用、与操作系统交互的特殊函数。可以使用该工具解决多种类型的问题，特别是那些与操作系统有关的问题。

ltrace：ltrace 跟踪进程调用的函数。这与 strace 类似，但是所调用的函数提供了更多细节。

lsof：lsof 工具可以列出操作系统（OS）中所有打开的文件。当一个文件打开时，OS 将向进程返回一个数值文件描述符以供使用。该工具将列出 OS 上的所有已打开文件，并显示它们的进程 ID 和文件描述符。

top：该工具列出正在系统中运行的“顶级”进程。默认情况下，它将按照进程当前使用的 CPU 量排序。

traceroute/tcptraceroute：这些工具可用于跟踪一个网络路由（或至少跟踪网络路由的一个方向）。

ping：Ping 只是查看某个远程系统能否响应。有时，防火墙会阻挡 ping 使用的网络数据包，但是即便如此，ping 工具仍然十分有用。

hexdump（或同类工具）：这个工具可以显示文件的原始内容。

tcpdump（或 ethereal）：用于解决网络问题，这些工具可以显示网络流量数据包。

GDB：这是一个功能强大的调试器，可用于解决一些更复杂的问题。

readelf：这款工具可用于读取和显示有关 Executable and Linking Format (ELF) 文件的不同方面的信息。

这些工具不一定都用得到，但是将它们全部安装到机器中会很有用，因为说不准什么时候会用到它们。有关 Linux 系统一般故障排除的更多细节，请参考本文其中一位作者编著的图书 “ Self-Service Linux: Mastering the Art of Problem Determination”，ISBN: 013147751X。

Windows 操作系统还提供了一些有价值的诊断工具，包括以下来自 Microsoft TechNet 的工具： TCPView for Windows operating systems Process Explorer。

务必要了解这些不同的工具，以便在需要时使用它们。可以将这些知识与好的研究实践相结合，进一步改进研究工作。

结束语

DB2 是一种低成本、高性能的数据库。它有许多最佳实践和特性，能够帮助减少总拥有成本，并且始终领先于行业性能基准。熟悉了各种成本削减技术和策略之后，您就可以节省大量时间和精力，然后将这部分时间和精力重新投入到推动业务发展当中去。