级别: 初级
developerWorks 中国网站编辑团队, 编辑, IBM
2009 年 10 月 22 日
这篇最佳实践侧重于管理有计划的数据库停机策略,尤其是在执行维护操作时。目的是达到一个数据库可用性级别,能满足你的商业需求。
对于最小化甚至消除计划的数据库停机本文描述了几种最佳实践。停机就是数据库不能响应用户请求的所有情况,无论是数据库完全下线,还是在不可接受的性能情况下部分下线。有计划停机包括在你的数据库系统中常规数据库维护或升级活动。
停机对你数据库环境的可用性有直接的影响。可用性是一个对系统服务用户应用请求的能力的衡量标准。一些数据库环境在可用性上能承受偶尔的中断,而其他环境必须随时可用。你选择的可用性策略和为了达到这个可用性目的而花费的资源,这应该由你的商业来驱动。
DB2 数据服务器包含可以帮助你 消除某些类型的计划停机并减少其他影响。这篇文章将讨论这些功能,以及什么时候如何使用它们来达到一个高级别的可用性。
最佳实践 |
维护表和索引:
|
|
这篇文章侧重于管理有计划的数据库停机策略,尤其是在执行维护操作时。目的是达到一个数据库可用性级别,能满足你的商业需求。
本文具体侧重的范围包括:
本文也将提供一个概要战略来提高可用性,通过:
在你的商业流程以及你的底层数据库解决方案的背景下,可用性是对数据库及时的为用户应用程序处理事务的能力的衡量。
一个数据库解决方案的可用性需求是由你的业务需求决定的。例如,如果一个数据库解决方案服务于一个从上午 9:00 到下午 5:00 的单个的店面业务,那么数据库可在下午 5:01 到次日上午 8:59 期间下线而仍被认为是高可用的。另一方面,如果相同的数据库解决方案提供了一个跨多个时区的存储链,可能的停机时间窗口就变得更小了。如果数据库解决方案服务一个需要每天 24 小时对服务客户的在线业务,那么数据库不能在影响客户的情况下下线。
停机破坏了数据库方案服务用户应用程序的能力。停机可以很彻底,就像在一个数据库处于下线或部分下线状态,或由于在系统资源上的高需求导致不可接受的低性能。
停机可以分成两类:一类是意外停机,这将是“对意外停机和恢复做好准备”最佳实践关注的;另外一类是计划停机,这将是本文关注的。
意外停机的例子包括:
计划停机的例子包括:
你选择的可用性策略应该基于计划停机可能会对你的业务产生的影响。在某些情况下,在一个策略上投入大量资源以保证你的数据库的高可用性可能是正确的;而在其他情况下可能不需要一个高可用性系统。
判断你的可用性策略的一个关键因素是你的业务,或在业务中的一个特定系统,对发生停机的容忍程度。例如,一个上面有饭店的菜单信息的网站可能可以容忍发生计划停机。在其他情况下,任何停机(计划或意外)对于处理交易相关事务的股票交易服务器可能都是灾难。投入大量的资源来确保饭店的服务器 99.99% 可用,可能是没有成本效益的,然而在股票交易这种情况下,这是非常必要的。量化停机的影响、在这期间损失的收入、损失的生产力,甚至丧失的客户信心和信誉,将有助于你对可用性策略投资的程度做出决定。
当然,只要有可能你都应该通过执行例程维护任务尽量避免计划停机,比如在数据库处于在线状态进行数据库备份。在进行升级的时候,你也可以显著的降低计划停机的时间。
一些数据库维护任务可能总是需要完全或部分计划停机,不过你可以采取步骤来减少这些停机的影响。对这些维护任务完成的时间来说,可以通过最小化这些数据库任务消耗的系统资源来减少影响。例如,对一个表或索引进行过多的重组,会毫无必要的消耗系统资源,在这个时间点你的终端用户会感受到对他们的请求不可接受的响应时间减慢。理论上数据库可能仍然是在线的,但是处于“brown out”症状,可能导致应用程序在事务提交之前就发生超时。说到升级,你可以通过使用 DB2 的功能(比如高可用性灾难恢复“HADR”或利用在相同系统上的分开的 DB2 安装)明显的减少停机持续时间(因此产生的影响)。
下面的章节将讨论最小化或消除计划停机的影响的最佳实践。
|
在表或索引上的重组操作(reorgs)是资源集中的行动,会限制表的能力以及减少并发。然而,如果你遵循这些普通的指南,就应该可以减少 reorg 相关的停机影响:
重组不应该仅作为历程周期性执行。事实上很多 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,就算这个公式建议你执行一个重组,你仍然可以忽略它。
在 DB2 Universal Database™ Version 8.1 之前,所有的索引都是 type-1 索引。即使所有新的索引是 type-2 索引 type-1 索引仍然可以出现在你的数据库中。 因为 type-2 索引有很多好处,比如增加并发特征和允许附加函数,比如在线表重组,所以你应该转换所有剩余的 type-1 索引。对 REORG 命令指定 CONVERT 选项来执行这个转换。
问问你自己重组真的必要吗,是否有其他方法可以达到重组的效果?
你不应该在没有理解能从它那里得到什么的情况下执行一个重组。例如数据库系统的一般智能可以显示索引重组需要做很多事情,包括(并不完全):
当这些理由是一个重组的有效理由时,记住在大多数情况下 DB2 索引管理算法会争取消除显式进行重组的需求。例如,pseudo-deleted 键在数据操作语言 (DML) 处理时被自动删除。
同样的,你也有执行表重组的理由,包括:
在不需要重组的情况下,你可以使用很多策略来达到这个结果。
集群索引将基于指定的索引保持表的集群,在一个最大努力的基础上,这减少了重组的需求并保证了高集群率。虽然这会明显的减少对个表重组的需求,但是集群缩影会严重影响插入和更新速度。
注意,设置较大的值以及 -1 并不意味着每次插入都要对整个表进行搜索。作为替代,表中空闲空间是被缓存了的,而且会在搜索空间时提供。例如,当表中的所有页面都满了时(这些信息都是被缓存了的),一个后续的插入将不进行搜索,一个页面将立刻被添加进表中,即使在注册变量被设置为 -1 的情况下。
另外,如果你对一个常做大量插入和删除的表使用 ALTER TABLE APPEND ON,那么你应该尤其小心。当你使用附加模式,删除操作会在表中间产生中断,而且插入将不使用这些空间,因为数据值添加在表最后。因此对表使用 APPEND 模式会导致更多的表片段,并需要更频繁的重组。
如果你不得不对你的表或索引执行一次重组,那么尽量不要执行离线重组。使用在线(也叫 implace)重组或一个清除重组来达到相同的结果,并保持最大可用性。
|
在你向表中导数时,可以使用很多策略来最大的保证目标表中未受影响数据的可用性。这些方法按它们提供的可用级别、从高到低是:
虽然高速装载实用工具可以以很快的速度装载数据,但是 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 来升级到一个更高的 DB2 补丁版本只会造成监控中断。
步骤如下:
从 DB2 Version 9 开始你可以在同一个系统中安装多个 DB2 服务器和客户端副本。你可以使用这个能力,在不同的路径上安装一个新的 Fix Pack,并把你的生产实例转存到新的实例路径。如果你没有使用 HADR,那么这将是一个有效的方法来加速升级过程。
|
备份操作可以在数据库在线或离线状态下执行。一个在线备份允许应用程序在数据库备份过程中有完全的读写操作访问权限。虽然一个在线备份可能比离线备份长很多,但是有些步骤可以让你缩短它。
有两个方法允许你减少在线备份的时间:表空间级别备份和增量备份。一个表空间基本的备份,仅备份了指定集合的表空间,而不是整个数据库。一个增量备份只读取在最后一次备份后更改了的页面。
就像在线备份和其他实用工具的兼容性中描述的一样,在线备份不能和一些其他操作一起并行运行。然而,有两个你可以用来防止这些不兼容的注册变量: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 配置参数可以被自动调整,这让你可以在不停机的情况下优化性能。虽然自动调整算法可以存为永久性的,但是一个常用的最佳实践是临时启用自动调整,允许自动调整算法判断工作负载的最佳设置。然后,一旦这些最佳设置被确定下来后,你可以取消自动调整以确保不再有自动的更改发生。这个策略试用于相对稳定的工作负载。
设置若干参数为 AUTOMATIC 的另外一个好处是,防止了停机错误的情况。例如,AUTOMACTIC 设置消除了指定一个最大值的需求。就算系统中有足够的内存,设定最大值可能会因为一个堆被耗尽而产生错误信息。虽然系统仍然保持运行,但是这些类型的错误可能以一个应用程序错误显示给用户。从用户的角度,这些错误可能意味着系统不可用,即使可能不是这样。
下面的参数可以被设置为 AUTOMATIC:
设置 DB2_OPT_MAX_TEMP_SIZE 为 1024。
如果其他访问模式(例如,索引排序)可用的话,就设置 DB2_OPT_MAX_TEMP_SIZE 变量来启用 DB2 优化器,以避免大量临时表空间用来排序。这减少了临时表空间的文件系统满的可能性,并因此减少了 SQL 错误的可能性,增加了系统总的可用性。
在数据库可用时,很多 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 高可用性能力。
http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0910planoutages/index.html
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论