内容提要
对于最小化甚至消除计划的数据库停机本文描述了几种最佳实践。停机就是数据库不能响应用户请求的所有情况，无论是数据库完全下线，还是在不可接受的性能情况下部分下线。有计划停机包括在你的数据库系统中常规数据库维护或升级活动。
停机对你数据库环境的可用性有直接的影响。可用性是一个对系统服务用户应用请求的能力的衡量标准。一些数据库环境在可用性上能承受偶尔的中断，而其他环境必须随时可用。你选择的可用性策略和为了达到这个可用性目的而花费的资源，这应该由你的商业来驱动。
DB2 数据服务器包含可以帮助你 消除某些类型的计划停机并减少其他影响。这篇文章将讨论这些功能，以及什么时候如何使用它们来达到一个高级别的可用性。
| 最佳实践 |
| 维护表和索引: Reorg 操作是很耗资源，并会限制可用性——在有可能的情况下避免执行它。 使用 DB@ 集群技术，比如 MDC 表或集群索引来防止或减少重组表的需求。 设置 DB2MAXFSCRSEARCH 注册变量或尽可能短的保持你的事务，以降低表重组的空间需求。 使用 PCTFREE 参数或减少行扩大的 UPDATEs 以降低删除溢出记录的需求 。 使用自动压缩替代表重组，来压缩表。 把所有 type-1 索引转换成 type-2 索引。 如果你需要运行一个重组的话，就使用一个在线重组。 使用 CLEANUP 选项来减少你的索引重组的范围。 数据移动和数据摄取: 使用 SQL INSERTs 替代一个装载操作，来保证大型表的读写的可用性。 在使用 range-partitioned 表时，添加一个数据分区或把一个表作为一个数据分区添加。 如果应用程序只需要对目标表的读取进行访问时，那么可以使用一个在线装载。 升级操作: 如果你有 HADR，则使用滚动升级功能。 安装新的 DB2 软件并行化你的现有数据库。 备份操作: 使用在线备份，以保证你的数据库可用性。 通过使用表空间级别或增量备份，来缩短你的备份操作的时间。 把所有数据、索引和大表空间创建为 DMS 或自动存储表空间，并设置 DB2_OBJECT_TABLE_ENTRIES 注册变量为最大值，来减少和其他并行操作的冲突。 在一个在线备份过程中，你正在执行一个非常重要的替换操作，那就把 DB2_TRUNCATE_REUSESTORAGE 设置为导入。 调优和配置: 在配置更改中使用 DB2 的动态配置能力，来保持数据库在线。 使用 DB2 的自动调整能力来提高性能，同时保持数据库可用。 为 AUTOMATIC 设置确定参数，从而防止缺少资源的错误信息。 存储管理: 对 DMS 表空间使用自动存储，或启用 auto-resize 能力来让数据库管理器自动防止文件系统满，同时仍保持完全的读写访问。 对每个只有一个表的表空间，使用自动存储或在 ALTER TABLESPACE 语句中使用 REDUCE 子句来简化空间释放。 |
介绍
这篇文章侧重于管理有计划的数据库停机策略，尤其是在执行维护操作时。目的是达到一个数据库可用性级别，能满足你的商业需求。
本文具体侧重的范围包括：
表和索引维护
数据装载或数据吸收
升级
备份
本文也将提供一个概要战略来提高可用性，通过：
调优功能和配置
存储管理
可用性
在你的商业流程以及你的底层数据库解决方案的背景下，可用性是对数据库及时的为用户应用程序处理事务的能力的衡量。
一个数据库解决方案的可用性需求是由你的业务需求决定的。例如，如果一个数据库解决方案服务于一个从上午 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叶子页面没有影响则