DB2 最佳实践: 最小化计划下线最佳实践

内容提要

对于最小化甚至消除计划的数据库停机本文描述了几种最佳实践。停机就是数据库不能响应用户请求的所有情况，无论是数据库完全下线，还是在不可接受的性能情况下部分下线。有计划停机包括在你的数据库系统中常规数据库维护或升级活动。

停机对你数据库环境的可用性有直接的影响。可用性是一个对系统服务用户应用请求的能力的衡量标准。一些数据库环境在可用性上能承受偶尔的中断，而其他环境必须随时可用。你选择的可用性策略和为了达到这个可用性目的而花费的资源，这应该由你的商业来驱动。

DB2 数据服务器包含可以帮助你 消除某些类型的计划停机并减少其他影响。这篇文章将讨论这些功能，以及什么时候如何使用它们来达到一个高级别的可用性。

介绍

这篇文章侧重于管理有计划的数据库停机策略，尤其是在执行维护操作时。目的是达到一个数据库可用性级别，能满足你的商业需求。

本文具体侧重的范围包括：

表和索引维护

数据装载或数据吸收

升级

备份

本文也将提供一个概要战略来提高可用性，通过：

调优功能和配置

存储管理

可用性

在你的商业流程以及你的底层数据库解决方案的背景下，可用性是对数据库及时的为用户应用程序处理事务的能力的衡量。

一个数据库解决方案的可用性需求是由你的业务需求决定的。例如，如果一个数据库解决方案服务于一个从上午 9:00 到下午 5:00 的单个的店面业务，那么数据库可在下午 5:01 到次日上午 8:59 期间下线而仍被认为是高可用的。另一方面，如果相同的数据库解决方案提供了一个跨多个时区的存储链，可能的停机时间窗口就变得更小了。如果数据库解决方案服务一个需要每天 24 小时对服务客户的在线业务，那么数据库不能在影响客户的情况下下线。

停机

停机破坏了数据库方案服务用户应用程序的能力。停机可以很彻底，就像在一个数据库处于下线或部分下线状态，或由于在系统资源上的高需求导致不可接受的低性能。

停机可以分成两类：一类是意外停机，这将是“对意外停机和恢复做好准备”最佳实践关注的；另外一类是计划停机，这将是本文关注的。

意外停机

意外停机的例子包括：

系统的一个或多个关键组件失败，包括硬件或软件的失败。

疏于管理或用户应用程序行为，比如意外删除了一个核心业务事务需要表。

由于不理想的数据库配置导致的低性能，或者不合适的硬件或软件。

计划停机

计划停机的例子包括：

维护操作需要你把数据库下线，或者维护活动可以在不停止数据库的情况下执行，不过这样做会对性能产生负面影响。这些是最常见的计划停机类型。

你的软件或硬件升级，比如安装 DB2 Fix Pack，这可能需要数据库部分或全部停机。

可用性策略

你选择的可用性策略应该基于计划停机可能会对你的业务产生的影响。在某些情况下，在一个策略上投入大量资源以保证你的数据库的高可用性可能是正确的；而在其他情况下可能不需要一个高可用性系统。

判断你的可用性策略的一个关键因素是你的业务，或在业务中的一个特定系统，对发生停机的容忍程度。例如，一个上面有饭店的菜单信息的网站可能可以容忍发生计划停机。在其他情况下，任何停机（计划或意外）对于处理交易相关事务的股票交易服务器可能都是灾难。投入大量的资源来确保饭店的服务器 99.99% 可用，可能是没有成本效益的，然而在股票交易这种情况下，这是非常必要的。量化停机的影响、在这期间损失的收入、损失的生产力，甚至丧失的客户信心和信誉，将有助于你对可用性策略投资的程度做出决定。

当然，只要有可能你都应该通过执行例程维护任务尽量避免计划停机，比如在数据库处于在线状态进行数据库备份。在进行升级的时候，你也可以显著的降低计划停机的时间。

一些数据库维护任务可能总是需要完全或部分计划停机，不过你可以采取步骤来减少这些停机的影响。对这些维护任务完成的时间来说，可以通过最小化这些数据库任务消耗的系统资源来减少影响。例如，对一个表或索引进行过多的重组，会毫无必要的消耗系统资源，在这个时间点你的终端用户会感受到对他们的请求不可接受的响应时间减慢。理论上数据库可能仍然是在线的，但是处于“brown out”症状，可能导致应用程序在事务提交之前就发生超时。说到升级，你可以通过使用 DB2 的功能（比如高可用性灾难恢复“HADR”或利用在相同系统上的分开的 DB2 安装）明显的减少停机持续时间（因此产生的影响）。

下面的章节将讨论最小化或消除计划停机的影响的最佳实践。

提高在表和索引维护过程中的可用性

在表或索引上的重组操作（reorgs）是资源集中的行动，会限制表的能力以及减少并发。然而，如果你遵循这些普通的指南，就应该可以减少 reorg 相关的停机影响：

只在必要的时候执行重组

只使用 2 类索引

减少执行重组的需求

将重组操作的影响最小化

只在必要的时候执行索引和表的重组。

重组不应该仅作为历程周期性执行。事实上很多 DB2 索引和表，永远不需要被重组。这个主题的其他信息请参见 DB2 信息中心“Determining when to reorganize tables and indexes”部分。

如果你使用 REORGCHK 命令来判读是否需要执行重组，并确保阀值公式和你的工作负载相关。使用下面的经验法则来解释公式，你应该可以显著地限制重组的频率和影响：

F1:为 PCTFREE设置一个中性值

这个公式和溢出记录的百分比相关。考虑调整每页空闲空间的百分比（PTCFREE）来降低以后重组的需求。设置一个中性值，比如 5% 就被证明很好。溢出记录会增加处理时间，这是因为溢出域需要作为所有对表操作的一部分被访问。如果在你的工作负载中溢出记录不被频繁访问，那么你可以忽略这个公式。你可以通过使用 overflow_accesses 监控元素来判断溢出有多频繁。

F2,F3:如果你不需要空间，可以忽略它们

这些公式与重组表获得的空闲空间相关。如果你不需要使用别处的空间而且也不需要为其它表释放空间，或者如果更多数据将被添加进这个表中你可以忽略这两个公式。如果表趋于再次增长，明智的选择是不释放空间。

F4：使用一个 MDC表或者一个集群索引

这个公式是和一个索引的集群率相关的。如果你为了好的性能而需要集群，就可以考虑使用一个多维集群（MDC）表或者一个集群索引。如果你的工作负载包含不重要或不太重要的语句而它们可以从集群获得好处，就可以忽略这个公式。

F5,F6：如果你不需要空间，或是使用 CLEANUP选项，则可以忽略它们

这些公式是关于你是否需要重建索引的。如果你不需要释放空间在别处使用，可以忽略这两个公式。如果你的确想执行一个重组来重建索引，那你应该首先尝试使用有 CLEANUP ONLY ALL 的重组，来精炼索引。有 CLEANUP ONLY ALL 的重组速度更快、资源消耗更少，以及产生的影响更小，因为没有涉及对象切换阶段，所以这个阶段需要加表级别的锁。

F7：如果 pseudo-deleted键没有影响

这个公式关于在 non-pseudo-empty pages 上的 pseudo-deleted 的 RIDs。它描述了对最低影响的需求，CLEANUP ONLY ALL 的索引是最佳匹配。虽然这个公式可能建议你执行一个重组，但你仍然可以忽略它。例如，如果 pseudo-deleted 键的出现不会对在线工作负载产生负面影响而且你也不需要 pseudo-deleted 键占用额外空间的话，你就不需要进行重组。

F8:如果 pseudo-empty叶子页面没有影响则忽略

这个公式是和 pseudo-empty 叶子页面相关的。它描述了最低影响的需求，使用 CLEANUP PAGES 的索引重组是最佳匹配。就像 F7，就算这个公式建议你执行一个重组，你仍然可以忽略它。

把所有 type-1 索引转换成 type-2 索引。

在 DB2 Universal Database™ Version 8.1 之前，所有的索引都是 type-1 索引。即使所有新的索引是 type-2 索引 type-1 索引仍然可以出现在你的数据库中。 因为 type-2 索引有很多好处，比如增加并发特征和允许附加函数，比如在线表重组，所以你应该转换所有剩余的 type-1 索引。对 REORG 命令指定 CONVERT 选项来执行这个转换。

减少执行重组的需求。

问问你自己重组真的必要吗，是否有其他方法可以达到重组的效果？

你不应该在没有理解能从它那里得到什么的情况下执行一个重组。例如数据库系统的一般智能可以显示索引重组需要做很多事情，包括（并不完全）：

在索引中减少大小和级别数目

在索引中减少 pseudo-deleted 键的数目

提高索引页面的序列性，并因此提高索引按距扫描的 I/O 性能

当这些理由是一个重组的有效理由时，记住在大多数情况下 DB2 索引管理算法会争取消除显式进行重组的需求。例如，pseudo-deleted 键在数据操作语言 (DML) 处理时被自动删除。

同样的，你也有执行表重组的理由，包括：

估计索引键的数据行重组，并会因此在某些查询计划中提高 I/O 性能。

释放内嵌的空闲空间。

消除溢出行

压缩一个表

在不需要重组的情况下，你可以使用很多策略来达到这个结果。

使用集群技术。多维集群（MDC）表和集群索引能帮助你避免重新集群的重组需求。MDC 表在任何时候都保持表的集群以及遵守所有指定维度。如果你决定使用 MDC 表，为了最小化它们在存储上的开销，你必需小心的为你的表选择维度。使用设计顾问来检测你的数据和工作负载，并提供一个推荐的具有最优性能和空间需求的维度集合。

集群索引将基于指定的索引保持表的集群，在一个最大努力的基础上，这减少了重组的需求并保证了高集群率。虽然这会明显的减少对个表重组的需求，但是集群缩影会严重影响插入和更新速度。

利用 DB2MAXFSCRSEARCH注册变量。在某些情况下，这会减少释放空间的重组需求。这个注册变量可以控制插入过程中的插入速度和空间释放的速度。在表中添加新页面之前限制为了容纳被插入行对页面数目的需求，因为较低的值有利于更快的插入。通过搜索更多的表，使得较高的值有更好的空间利用率。它的默认值 5 是一般情况下很好的折中。然而，如果你有非常大的表，并且经常进行删除操作，就应该考虑对 DB2MAXFSCRSEARCH 设置更高的值。如果有足够的连续可用空间，那么值 -1 将确保这些空间在表中添加一个新页面之前使用。

注意，设置较大的值以及 -1 并不意味着每次插入都要对整个表进行搜索。作为替代，表中空闲空间是被缓存了的，而且会在搜索空间时提供。例如，当表中的所有页面都满了时（这些信息都是被缓存了的），一个后续的插入将不进行搜索，一个页面将立刻被添加进表中，即使在注册变量被设置为 -1 的情况下。

让你的交易越短越好。短期运行的事务减少了重组释放空间的需求，因此尽可能多的执行提交操作。长期事务的出现延缓了表中被删除空间的重用。

减少或消除频繁的 UPDATEs这会增大行数。这可以减少执行重组表带来的删除溢出的行的需求。例如，如果可能的额外空间消耗允许的话，就可以在一个经常更新的列上使用 CHAR(8) 来替代 VARCHAR(8)。更新 VARCHAR(8) 列，可能改变行的长度，而更新 CHAR(8) 则不会。

利用 PCTFREE参数。这可以减少经常执行重组，来删除溢出的记录。这个空闲空间可以在不需要产生溢出记录的情况下，用来调节行增长。通常情况下，如果你知道行数在后面会扩大（例如通过一个后续的更新操作），那么你就应该使用 PCTFREE。如果你知道行数在后面不会增长，例如果是固定长度的行，那么你就不要使用 PCTFREE 参数。

使用自动压缩。压缩的目的是为了可以减少或消除重组需求。使用自动压缩，当表增长到一定大小时，表压缩就开始自动行压缩了。

另外，如果你对一个常做大量插入和删除的表使用 ALTER TABLE APPEND ON，那么你应该尤其小心。当你使用附加模式，删除操作会在表中间产生中断，而且插入将不使用这些空间，因为数据值添加在表最后。因此对表使用 APPEND 模式会导致更多的表片段，并需要更频繁的重组。

最小化重组的影响。

如果你不得不对你的表或索引执行一次重组，那么尽量不要执行离线重组。使用在线（也叫 implace）重组或一个清除重组来达到相同的结果，并保持最大可用性。

使用一个在线表重组。一个在线重组常常是在重组操作时保持数据可用性的理想方法。所有的读取和写入都不会中断，除了在裁剪阶段，在此阶段所有写入操作都暂停了，不过读取操作仍然保留。在这里做出的妥协就是在线重组的性能更差，而且会增加日志空间的消耗。然而，你可以通过更改重组操作来缓解它。例如，如果你只是为了释放空间而进行重组，并且如果集群在工作负载中并不重要的话，就可以执行一个不指定索引的在线重组（并确保在表中没有定义集群索引）来最大化重组期间的可用性。

执行 cleanup来替代完全索引重组。一个实际的例子，如果一大批删除操作刚刚在一个表中删除了大量的行，这会留下伪删除的索引键。索引管理器通常将在稍后自动清除这些伪删除键值。然而，如果你希望确保下次通过索引的访问不会因为伪删除键的出现而受到不利影响的话，就使用有 ALLOW WRITE ACCESS … CLEANUP ONLY 选项的 REORG INDEXES 命令来有效的删除伪删除键，并保持表和索引的读写访问。如果你不需要这些空间而且你的工作负载没有命中这些键值，那最好不要管它们，让索引管理器来处理对它们的删除就好了。

提高在数据装载或数据吸收过程中的可用性

在你向表中导数时，可以使用很多策略来最大的保证目标表中未受影响数据的可用性。这些方法按它们提供的可用级别、从高到低是：

使用 SQL INSERTs

使用 ATTACH 选项来转入数据

使用在线装载

使用 INSERTs 向一个表中插入数据。

虽然高速装载实用工具可以以很快的速度装载数据，但是 SQL INSERT 转换率非常高而且常常能满足大多数需求。然而，使用 INSERT 进程的好处是保持你的表完全可读写。在 SQL INSERt 不能满足你的性能需求情况下，可以考虑使用其他插入方法，比如缓冲插入和批量插入，或编写你的应用程序，从多个连接并行插入。

使用 ATTACH 或 ADD/LOAD 来转入数据到分区表。

表分区让你能有效的把一个新表或不用的表，关联或附加到一个分区表中。或者，你把一个表作为一个新的数据分区添加并装载数据。

你可以使用 ATTACH 子句来合理化数据吸收，通过装载新分区的数据到一个新的或不使用的表，然后通过 SQL 执行任何数据净化的操作，而数据仍然在这个表中。这些活动对在线工作负载访问分区表没有影响，因为新的或未使用的表还没有和分区表关联。一旦数据准备活动完成，就可以使用 ALTER 语句的 ATTACH 子句，把这个表作为分区表的一个新的分区被附加。这是一个高效操作，因为它简单的把现有表作为分区表中的分区关联，而不需要移动任何数据。

在这个事务被提交后，新的分区在你发出有 ALLOW WRITE ACCESSZ 子句的 SET INTEGRITY 之前，对于在线访问是不可见的。这将在表中定义的所有索引和 MQTs 中反映新分区的数据，同时允许对这个表进行读写操作。然而，如果你关心 attach 操作需要的 SET INTEGRITY 的日志需求，那这个可能不是最好的办法。

另外一个选择是，把一个表作为新的数据分区添加到其他的分区表中然后装载数据。如果这个表没有约束或 MQTs 定义的话，这就避免了 SET INTEGRITY 语句。如果在这个操作过程中你只需要这个表的读取访问的话，就可以使用这个选项。

使用在线装载。

在一个标准的装载操作过程中，装载实用工具用一个超级排它锁将目标锁定，然而在线装载允许读取访问。在你需要最快数据装载以及某种程度的可用性的情况下，使用在线装载。对你的 LOAD 命令指定一个在线装载选项，包括 ALLOW READ ACCESS 选项。

提高在升级过程中的可用性

使用高可用性灾难恢复（HADR）滚动升级功能。

你使用 HADR 来升级到一个更高的 DB2 补丁版本只会造成监控中断。

步骤如下：

停止备用数据库

升级备用数据库

激活备用数据库

一旦那备用数据库处于对等状态，在备用数据库上执行 TAKEOVER HADR 命令。

把客户端定向到新的主数据库

像上面步骤 1-3 一样升级原来的主数据库。

在相同系统的不同的位置安装新的 DB2 软件。

从 DB2 Version 9 开始你可以在同一个系统中安装多个 DB2 服务器和客户端副本。你可以使用这个能力，在不同的路径上安装一个新的 Fix Pack，并把你的生产实例转存到新的实例路径。如果你没有使用 HADR，那么这将是一个有效的方法来加速升级过程。

用一个现有 DB2 数据库生产安装介质，在不同的路径上，新安装一个 DB2 产品。

停止你的生产数据库实例。

从新的安装路径调用 db2iupdt 命令来升级这个实例。

启动新的数据库实例。

执行所有需要后升级的操作，像调用 db2updv8 或 db2updv9、或像 DB2 信息中心安装修订包主题中的直接重新绑定包。

可选，卸载你不再需要的 DB2 产品的早期版本。

在备份过程中提高可用性

备份操作可以在数据库在线或离线状态下执行。一个在线备份允许应用程序在数据库备份过程中有完全的读写操作访问权限。虽然一个在线备份可能比离线备份长很多，但是有些步骤可以让你缩短它。

有两个方法允许你减少在线备份的时间：表空间级别备份和增量备份。一个表空间基本的备份，仅备份了指定集合的表空间，而不是整个数据库。一个增量备份只读取在最后一次备份后更改了的页面。

就像在线备份和其他实用工具的兼容性中描述的一样，在线备份不能和一些其他操作一起并行运行。然而，有两个你可以用来防止这些不兼容的注册变量：DB2_OBJECT_TABLE_ENTRIES和 DB2_TRUNCATE_REUSESTORAGE。

如果你的表空间包含大量对象（表、索引、大对象列），在你创建 DMS 自动存储之前把，DB2_OBJECT_TABLE_ENTRIES 设置为 65532 会帮助你避免备份过程中和在线创建索引以及在线重组索引的不兼容。如果你计划在在线备份过程中使用有 RELPACE 选项的导入实用工具，那就设置这个注册变量为 IMPORT。Import replace 操作通常用来截去表内容，而且使用这个注册变量你可以提高在线备份过程中的可用性。

在“Preparing for unplanned outages and recovery”最佳实践文档中，有对数据库恢复更详细的讨论，恢复操作一般在主数据库系统发生计划外停机情况下执行。

提高在性能调优过程中的可用性

另外一个可以潜在影响可用性的维护任务是更改数据库配置参数。幸运的是，DB2 有自动调整能力、动态（在线）配置能力和注册便利设置，能够让你在调整性能时不会导致停机。

利用 DB2 的自动调整能力。

若干 DB2 配置参数可以被自动调整，这让你可以在不停机的情况下优化性能。虽然自动调整算法可以存为永久性的，但是一个常用的最佳实践是临时启用自动调整，允许自动调整算法判断工作负载的最佳设置。然后，一旦这些最佳设置被确定下来后，你可以取消自动调整以确保不再有自动的更改发生。这个策略试用于相对稳定的工作负载。

设置若干参数为 AUTOMATIC 的另外一个好处是，防止了停机错误的情况。例如，AUTOMACTIC 设置消除了指定一个最大值的需求。就算系统中有足够的内存，设定最大值可能会因为一个堆被耗尽而产生错误信息。虽然系统仍然保持运行，但是这些类型的错误可能以一个应用程序错误显示给用户。从用户的角度，这些错误可能意味着系统不可用，即使可能不是这样。

下面的参数可以被设置为 AUTOMATIC：

Applheapsz：应用程序可以持续增长直到达到了 appl_memory 或 instance_memory 的限制。

database_memory：从 DB2 Version 9.5 开始，自动调整内存管理器（STMM）可以在 instance_memory 限制下，根据需要调整分配到数据库的内存。

Dbheap：数据库堆现在可以在 database_memory 和 instance_memory 的限制内根据需要增长。如果你有很多的表在数据库中活跃（像在 SAP 数据库）的话，这就非常重要。TCB（表控制块）需要一些 dbheap 空间。

Instance_memory: 从 DB2 Version 9.5 开始，这个参数限制所有数据库和数据库相关应用程序的内存消耗。如果其他应用程序有内存需求，那么要设置这个值为自动调要谨慎。如果其他应用程序消耗越来越多的内存，那么数据库可能释放过多内存，这也可能减少数据库处理大量交易或复杂查询的能力。

mon_heap_sz：这个参数可以避免的由于事件监控器缺少内存错误信息。

stat_heap_sz：RUNSTATS 和实时的统计信息在搜集时的内存需求。他与评估一个最大值不同，因此它最好被设置为自动，这样可以避免 runstats 操作失败。

stmtheap：复杂语句需要大量的语句堆来编译。设置这个值为自动将有助于避免语句编译时没必要的错误。

设置 DB2_OPT_MAX_TEMP_SIZE 为 1024。

如果其他访问模式（例如，索引排序）可用的话，就设置 DB2_OPT_MAX_TEMP_SIZE 变量来启用 DB2 优化器，以避免大量临时表空间用来排序。这减少了临时表空间的文件系统满的可能性，并因此减少了 SQL 错误的可能性，增加了系统总的可用性。

使用 DB2 的动态配置能力。

在数据库可用时，很多 DB2 配置参数可以在线更改。数据库（或数据库管理器）配置参数在线更改，必须在数据库连接（或数据库管理器 attachment）中进行。

设置 DB2 注册变量 DB2_OPTPROFILE 为 YES。

如果这个变量在你启动实例之前设置了，那么你可以在不需要重启数据库实例的情况下，绕过 DB2 优化器问题。许多优化器问题可以通过更改像 DB2_REDUCED_OPTIMIZATION 这样的注册变量或通过应用一个新的 DB2 补丁来解决，然而，这两种方法都需要一个短暂的停机。

提高存储管理中的可用性

使用自动存储或对 DMS 表空间启用自动 auto-resize 能力。

这两种技术通过自动扩展现有容器或自动添加新容器，根据需要自动添加存储到表空间。允许数据库管理器自动处理整个文件系统情况。在这两种情况中，完全读写能力受到保护，并且最小化了 I/O 带宽开销。

使用自动存储并且每个表空间一个表。

当一个 DMS 表空间中有多个表存在时，回收一个单独被删除表的空间可能不方便。如果每个表空间只有表的情况就可以通过删除表空间来回收空间。在自动存储出现之前，这个建议可能会带来过多的管理开销，因为每个表空间需要关心它自己的存储管理。对于自动存储，这个情况就不存在了，因为自动存储表空间是一个可以在上面创建表的逻辑上的条目。所有自动存储表空间的存储管理都在一个地方，在数据库层面。

要牢记表空间大小必须是 4、8、16、32 K。这些值决定了一个表在给定表空间中，允许的行的最大长度。

在 ALTER TABLESPACE 语句中使用 REDUCE 子句。

REDUCE 子句可以被用来在表空间的高水位标记（这是，表空间中曾经使用过的最高的地址）之上释放未使用的空间。在确定情况下，这个更改语句也可以在不需要数据库下线的情况下，减少高水位标记。

结论

为了实现它们，你选择的数据库可用策略和你需要投入的资源，反映了你的事务可以容忍的相关数据库停机。

DB2提供了若干功能和能力，让你能减少甚至消除某些类型的停机带来的影响，这些类型和例程维护活动相关，比如重组、装载、备份、升级、数据库配置和调优测试，还有就是存储管理。减少停机持续时间或频率，将增加你的数据库解决方案支持你的事务需要的时间。

最后请注意在开发策略中为了避免计划停机：无论多么精心进行设计或处理，它们的成功执行取决于对这篇文章中提到的技术的正确理解，并依赖于严格的测试。你可以通过利用下面列出的资源来学习更多关于 DB2 高可用性能力。