DB2 9 分布式管理的正确操作流程

作者：佚名 2010-08-04 10:03:37

数据库

分布式以下的文章主要是介绍DB2 9 分布式管理的实际操作过程，以及对其在实际操作中值得我们大家注意的相关事项的具体描述。

以下的文章主要描述的是DB2 9 分布式管理，在此篇专栏文章中，我们将解释执行自动维护的实际操作步骤，并说明如假如需要在DB2数据库正在处理工作负载时执行维护操作，应该如何利用实用程序节流。

前言

DB2 9 的适应性实用程序节流系统使维护可以在繁忙时间段进行。

如果您希望保持汽车状态良好，就必须定期进行一些维护，比如更换机油和火花塞。对于数据库，也是如此;如果希望保持良好的性能，就必须定期执行维护操作，比如重新安排数据布局、更新数据库统计数据和重组表/索引。

在 DB2 中，这些维护操作是通过运行各种实用程序来执行的。因为这些实用程序会消耗宝贵的系统资源，所以维护操作通常在非高峰时间段的 “维护窗口” 中执行。但是，如今的业务越来越需要不间断地运行，所以让数据库离线以执行这些重要的操作变得越来越困难了。现在，一些维护任务可以在数据库在线的情况下执行，但是许多任务消耗的资源仍然非常多，会影响数据库的正常工作。

IBM 为这个问题提供了一个解决方案，可以自动执行某些应该定期执行的日常维护活动。IBM 开发人员还创建了一种细粒度的资源控制机制，这种机制称为实用程序节流(utility throttling)。它允许选择一些实用程序，让它们在某些时间占用更多资源，在其他时间占用比较少的资源。

在这篇专栏文章中，我将解释如何执行自动维护，并说明如果需要在数据库正在处理工作负载时执行维护操作，应该如何利用实用程序节流。

维护

自动维护是 DB2 9 中引入的一个新特性。通过使用这个特性，您可以指定维护目标，DB2 Database Manager 决定是否需要执行维护活动来实现这些目标。如果 Database Manager 认为需要执行维护操作，就可以在下一个维护时间窗中自动执行此操作;维护时间窗是由您指定的一个时间段，所有自动维护活动都在这段时间内执行。

可以使用自动维护执行以下任务：

生成数据库备份映像。自动数据库备份解决方案可以确保适当地定期备份数据库，用户不需要总是关注备份时间或如何正确地编写 BACKUP 命令。

数据碎片整理(表或索引重组)。这种维护活动可以提高 DB2 Database Manager 访问表的效率。自动重组DB2 9 分布式管理离线表和索引重组，用户不需要关心何时以及如何重组数据。

数据访问优化(运行 RUNSTATS)。DB2 Database Manager 会自动更新关于表数据、表索引数据或者这两者的系统编目统计数据。在响应查询时，DB2 Optimizer 使用这些统计数据决定使用哪个路径访问数据。自动统计数据收集过程会维护***的表统计数据，从而提高数据库的性能。其目标是让 DB2 Optimizer 总是根据准确的信息选择访问计划。

统计数据分析。自动统计数据分析过程会探测过时、缺失或不准确地指定的统计数据，根据查询反馈生成统计数据分析，从而建议何时以及如何收集表统计数据。

在创建 DB2 9 数据库时，会默认启用自动维护;通过自动维护专用的数据库配置参数(auto_maint、auto_db_backup、auto_tbl_maint、auto_runstats、auto_stats_prof、auto_prof_upd 和 auto_reorg)启用可用的自动维护特性。这些参数是一组层次化的开关，可以设置为 ON 或 OFF。

用程序节流

自动维护活动(备份、统计数据收集、统计数据分析和表/索引重组)在运行时会消耗系统资源，所以会影响数据库性能。另外，离线数据库备份和表/索引重组操作会限制对表、索引或整个数据库的访问。为了尽可能减少对系统的影响，可以使用 DB2 的适应性实用程序节流系统对某些自动维护活动的资源使用量进行调节。

适应性实用程序节流系统是在 DB2 8.1.2 中引入的。这个系统使维护实用程序可以在工作负载比较高的时间段运行，同时把它们对系统的影响限制在可接受的范围内。这个节流系统还使实用程序在非高峰时间段自动地获得更多的计算资源，而在高峰时间段减少资源使用量。在 DB2 9.5 中，以下维护操作可以利用适应性实用程序节流系统：

统计数据收集

备份操作

数据重新布置操作

异步索引清理

您可能已经使用实用程序进行节流，只是没有意识到而已;在默认情况下，DB2 自动地对一些自动调用的维护实用程序进行节流，比如自动的 RUNSTATS。

设置和影响策略

为了控制实用程序节流，必须建立一个影响策略。影响策略是指实例范围限制，所有节流实用程序对生产性工作负载的积累影响不能超越这个限制;建立这样的策略之后，就由系统负责确保实施这个策略。

对于在一个实例中运行的启用节流的所有实用程序，通过 DB2 Database Manager 配置参数 util_impact_lim 控制它们的影响策略。(这个参数是动态的，所以不需要停止并重新启动实例就能够修改它;甚至可以在启用节流的实用程序正在运行时设置它。)要想为所有节流的实用程序定义影响策略，只需为配置参数 util_impact_lim 指定一个 1 到 100 之间的值。

例如，要想把实例范围的影响限制设置为 10%(换句话说，要确保所有节流的实用程序对系统工作负载造成的性能影响不超过 10%)，只需执行下面的 UPDATE DATABASE MANAGER 命令，把配置参数 util_impact_lim 设置为 10：

UPDATE DATABASE MANAGER USING UTIL_IMPACT_LIM 10

如您所料，与未节流的实用程序相比，节流的实用程序通常要花费更长时间才能执行完成。如果发现某个实用程序的运行时间过长了，就可以增加配置参数 util_impact_lim 的值，或者通过把配置参数 util_impact_lim 设置为 100 来完全禁用节流。(如果 util_impact_lim 设置为 100，实用程序就不会受到节流。在这种情况下，实用程序可以尽可能快地运行，但是它们很可能对工作负载性能产生严重影响。)

执行节流的实用程序

定义影响策略并不意味着所有实用程序的运行都会受到节流。实际上，即使已经定义了影响策略，在默认情况下实用程序都是以非节流模式运行的。要想以节流模式运行一个实用程序，就必须在调用这个实用程序时启用节流，或者在启动这个实用程序之后启用节流。有些实用程序无法在调用时启用节流，只能在启动之后启用节流，例如 REBALANCE。

要想在调用实用程序时启用节流，必须在执行这个实用程序所用的命令中指定 UTIL_IMPACT_PRIORITY 选项。例如，为了调用 Backup 实用程序并启用节流，应该执行下面的 BACKUP DATABASE 命令：

BACKUP DATABASE sample UTIL_IMPACT_PRIORITY

当前，只有 BACKUP DATABASE 和 RUNSTATS 命令能够识别 UTIL_IMPACT_PRIORITY 子句。另外，必须先定义影响策略(通过设置配置参数 util_impact_lim)，然后 UTIL_IMPACT_PRIORITY 子句才能对这些命令起作用。

UTIL_IMPACT_PRIORITY 子句有一个可选的相对优先级参数(0 到 100 之间的值;0 表示关闭)，这个参数用来区分节流的实用程序的重要性。与具有较低优先级的节流实用程序相比，高优先级的实用程序会占用更多资源。IBM 建议不指定相对优先级值，而是接受默认的优先级值 50。(请记住，所有节流实用程序的累积影响仍然受到影响策略的限制。)以上的相关内容就是对DB2 9 分布式管理的介绍，望你能有所收获。

【编辑推荐】