当您初次登录到 developerWorks 时，将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人，但您可以随时修改这些信息的显示状态。您的姓名（除非选择隐藏）和昵称将和您在 developerWorks 发布的内容一同显示。

所有提交的信息确保安全。

当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

所有提交的信息确保安全。

My developerWorks:

我的通知：

退出

选择语言：

DB2 pureScale 的新特性介绍 -- Group Crash Recovery

武翠霞, 软件工程师, IBM

武翠霞，IBM 中国软件开发中心软件工程师，Business Intelligence 项目组，两年商业智能项目经验，目前从事 DB2 产品的测试。

张玉颖, 软件工程师, IBM

张玉颖，高级软件工程师，熟悉 IBM Data Warehouse 相关产品，具有丰富的项目实施经验，尤其擅长数据建模和 ETL 架构设计。

简介： 本文主要介绍了 DB2 pureScale 的结构，以及新特性 Group Crash Recovery ，并通过 DB2 V9.8 的实例进行了详细说明。

标记本文！

发布日期： 2012 年 5 月 08 日 (最初发布 2010 年 6 月 12 日)
级别： 初级
访问情况： 1776 次浏览
评论：

引言

DB2 V9.8（pureScale）最重要特性就是其高度的伸缩性，这是 DPF，HADR 所不能满足的。在 pureScale 中所有的数据都是在一个共享的地方存放，这点与 DB2 for z/OS 的存储结构类似。

在 pureScale 中引入了 member 的概念，相当与 DPF 的 partition。一组 member 的集合就是一个 Cluster（集群）。

在 pureScale 中还有 Cluster Facilitator，它来确保 cross member 数据的一致性，可以配置一个或者两个 CF。CF 的主要组件包括以下三部分。

Global Buffer Pool (GBP) ：保证集群上缓存中的共享数据页的一致性
Global Lock Manager (GLM) ：保证集群上共享数据更改的一致性
Shared Communications Area (SCA) ：对 DB2 控制数据（比如：控制块，日志序列数（LSN））提供一致机制。

回页首

Shared Data 结构介绍

Shared Data（SD）是一种全新的数据存储方式。在这种方式中，所有的数据都是共享的，member1 可以读取 member2 的数据，但每个 member 只能在自己的日志路径上写日志。图 1 显示了 SD 结构。

图 1. SD 结构图

可见数据是共享的，每个 member 都使用相同的 log 参数，日志放在集群文件系统中，member 各自写各自的日志，但可以读其他 member 的日志。以三个 member 为例，其日志路径分别为：

 yourinstance/TESTDB/DBPARTITION0000/LOGSTREAM0000, 
yourinstance/TESTDB/DBPARTITION0000/LOGSTREAM0001, 
yourinstance/TESTDB/DBPARTITION0000/LOGSTREAM0002

在 pureScale 中最多支持 128 个 member，以三个 member 和两个 CF 为例，数据库配置如清单 1 和清单 2 所示。

清单 1. 逻辑配置（member 和 CF 在一个物理机器上）

				
 cd /home/wucuixia/sqllib_shared 
 cat db2nodes.cfg 
 0 coral253 0 - - MEMBER 
 1 coral253 1 - - MEMBER 
 2 coral253 2 - - MEMBER 
 128 coral253 0 - - CF 
 129 coral253 0 - - CF

清单 2. 物理配置（member 和 CF 在多个物理机器上）

				
 cd /home/wucuix2/sqllib_shared 
 cat db2nodes.cfg 
 0 coralxib14 0 - - MEMBER 
 1 coralxib15 0 - - MEMBER 
 2 coralxib16 0 - - MEMBER 
 128 coralxib17 0 - - CF 
 129 coralxib16 0 - - CF

回页首

Group Crash Recovery 介绍

DB2 现有的恢复方式有 HADR，Version Recovery，Crash Recovery，Rollforward Recovery，现在 Group/Member Crash Recovery 是 pureScale 引入的新的 Crash Recovery。

在只有一个 CF 的情况下，如果 CF Down 掉了，就需要进行 Group Crash Recovery；如果 CF 正常工作，某一个或多个 member 不能工作，则需要进行 Member Crash Recovery。如果有一个主 CF 和一个辅助 CF，在两种情况下需要进行 Group Crash Recovery。一种是如果双工运行，当主 CF 和辅助 CF 同时不能工作，或者主 CF 不能工作同时辅助 CF 未达到 peer 状态时，需要 Group Crash Recovery；另一种情况是在非双工运行时，当主 CF 和辅助 CF 同时不能工作时需要 Group Crash Recovery。

本文主要介绍 Group Crash Recovery 新特性。在数据库中，Group Crash Recovery 可以在任何一个 member 上发生，并且只能在一个 member 上进行。如果不指定 member，默认是第一个 member，连接数据库来触发 Group Crash Recovery。

在共享数据环境中，会有 Cluster Manager 的概念。它的一个职责是确保数据库是尽可能是一直可用的，这就包含了自动启动 Group Crash Recovery 的功能。因此只有 CM 出问题时，才需要手动执行 Group Crash Recovery。

如果要手动启动 Group Crash Recovery，如果 AUTORESTART 参数为 ON, 可以使用 CONNECT TO 或者 ACTIVATE DATABASE 命令，如果 AUTORESTART 是 OFF, 则可以使用 RESTART DATABASE 命令。

回页首

Group Crash Recovery 过程

出现不一致情况的数据库具备了 Group Crash Recovery 的触发条件，则 Group Crash Recovery 在某一个 member 上进行。Group Crash Recovery 在某一个 member 发生时，数据库是 offline 状态，不能接受任何连接。如果其他 member 有请求，则数据库恢复后才能接受这些请求。

由于每个 member 只能维护自己的日志文件，并且可以更改数据库的任何对象，所以每个 member 上的日志文件可以包含任何一个对象的一个日志记录。日志文件在两个不同的 member 上可以有多个记录操作同一对象交叉出现的情况，因此，每个 member 上的日志文件必须汇合成正确的顺序，然后才能进行重新执行。Group Crash Recovery 需要调用汇合各个 member 上日志流的功能，这里注意汇合日志流是在内存中进行的。

在 Group Crash Recovery 进行中，先调用汇合日志流的功能把各个 member 的日志流汇合成一个日志流，然后用这个汇合后的日志流进行 redo 所有还没写到磁盘上的操作。

Redo 结束后，undo 没有提交的事务。undo 阶段不会涉及归并好的日志流，只从日志中读取相应的未提交记录。Compensation log records 是在 undo 阶段写入的，并且是写在当前执行 Group Crash Recovery 的 member 的日志中的。undo 和以前的 undo 有很大不同，做 Group Crash Recovery 的 member 会写 pseudo compensation log records，即在自己的日志上写别的 member 未提交的事务。

Undo 结束后，数据库可以接受新的事务。如果有必要，还要进行 in-doubt 事务的处理来释放这些含有待处理 in-doubt 事务的数据页。

回页首

Group Crash Recovery 的特点

与以前版本的 Crash Recovery 相比，Group Crash Recovery 有以下几点不同：

可能从 log archive 中恢复文件

即使没有指定 infinite active logging，某些时候 Group Crash Recovery 仍然会从 log archive 中获取文件。比如当一个 member Down 掉了，并长时间没有重新起动。这个 member 会保持这个恢复起点，如果其他活动的 member 的 active log space 满了，这个时候又需要进行 Group Crash Recovery，在这种情况下，就会从 log archive 中获取文件日志。这和以前的 Crash Recovery 是不同的。以前只有在 infinite logging 情况下才会从 log archive 中恢复文件。

pseudo compensation log records 的概念

回滚自己未提交的事务日志是 compensation log records，在 Group Crash Recovery 中，一个 member 可以把其它 member 未提交的事务在自己的日志中进行回滚，这就是 pseudo compensation log records。

回页首

模拟发生 Group Crash Recovery 的实例

比如在insert,update,delete等数据操作中，如果有未提交的事务存在，此时发生 Crash CF，则在创新启动数据库，并试图进行连接时，就会发生 Group Crash Recovery。以下举个最简单的例子来说明 Group Crash Recovery。清单 3 用来启动和创建数据库。

清单 3. 启动和建立数据库

				
 => db2start 
 03/04/2010 00:55:44 2 0 SQL1063N DB2START processing was successful. 
 03/04/2010 00:55:44 1 0 SQL1063N DB2START processing was successful. 
 03/04/2010 00:55:45 0 0 SQL1063N DB2START processing was successful. 
 SQL1063N DB2START processing was successful. 
 => db2 create db testdb 
 DB20000I The CREATE DATABASE command completed successfully.

清单 4，5，6 分别是三个 member 上的操作。

清单 4. M1 执行事务

				
 export DB2NODE=0 
 connect to testdb, 
 update command options using c off, 
 create table t1(a int,b int), 
 insert into t1 values(1, 2), 
 insert into t1 values(2, 4), 
 commit, 
 insert into t1 values(10, 20),

清单 5. M2 执行事务

				
 export DB2NODE=1 
 connect to testdb, 
 update command options using c off, 
 insert into t1 values(3, 2), 
 insert into t1 values(4, 4), 
 commit, 
 insert into t1 values(20, 20),

清单 6. M3 执行事务

				
 export DB2NODE=2 
 connect to testdb, 
 update command options using c off, 
 insert into t1 values(5, 2), 
 commit, 
 insert into t1 values(30, 20),

接下来产生触发 Group Crash Recovery 的条件，比如断电，使用 kill -9。

清单 7 来查询 Group Crash Recovery 后数据库表的结果。

清单 7. 查询结果

				
 db2 => select * from t1 

 A B 
 ----------- ----------- 
  1 2 
  2 4 
  3 2 
  4 4 
  5 2 

  5 record(s) selected.

清单 8 显示了 db2diag 中关于 Group Crash Recovery 的信息。

清单 8. db2diag 的关于 Group Crash Recovery 的信息

				
 2010-03-04-01.43.43.538263+480 I3980161E770 LEVEL: Info 
 PID : 17993 TID : 47441067895104 KTID : 18157 
 PROC : db2sysc 1 
 INSTANCE: wucuixia NODE : 001 DB : TESTDB 
 APPHDL : 1-55 APPID: *N1.DB2.100303174336 
 EDUID : 24 EDUNAME: db2agnti (TESTDB ) 1 
 FUNCTION: DB2 UDB, recovery manager, sqlpresr, probe:401 
 DATA #1 : <preformatted> 
 Group crash recovery started. 
 Recovery status for log stream 1 
  lowtranlsn: 000000000002E5C1 
  minbufflsn: 000000000002E5C4 
  headlsn: 000000000002E570 
  groupHeadLsn: 000000000002E570 
  groupMinBuffLSN: 000000000002E570 
  HeadExtentID: 0 
 GroupHeadExtentID: 0 
  nextLso: 4173825 
  nextLsn: 000000000002E56B 

 2010-03-04-01.43.43.547061+480 I3980932E771 LEVEL: Info 
 PID : 17993 TID : 47441067895104 KTID : 18157 
 PROC : db2sysc 1 
 INSTANCE: wucuixia NODE : 001 DB : TESTDB 
 APPHDL : 1-55 APPID: *N1.DB2.100303174336 
 EDUID : 24 EDUNAME: db2agnti (TESTDB ) 1 
 FUNCTION: DB2 UDB, recovery manager, sqlpresr, probe:400 
 DATA #1 : <preformatted> 
 Group crash recovery started. 
 Recovery status for log stream 0 
  lowtranlsn: 000000000002E5BD 
  minbufflsn: 000000000002E5C4 
  headlsn: 000000000002E570 
  groupHeadLsn: 000000000002E570 
  groupMinBuffLSN: 000000000002E570 
  HeadExtentID: 0 
 GroupHeadExtentID: 0 
  nextLso: 36781825 
  nextLsn: 0000000000000000 

 2010-03-04-01.43.43.555777+480 I3981704E770 LEVEL: Info 
 PID : 17993 TID : 47441067895104 KTID : 18157 
 PROC : db2sysc 1 
 INSTANCE: wucuixia NODE : 001 DB : TESTDB 
 APPHDL : 1-55 APPID: *N1.DB2.100303174336 
 EDUID : 24 EDUNAME: db2agnti (TESTDB ) 1 
 FUNCTION: DB2 UDB, recovery manager, sqlpresr, probe:402 
 DATA #1 : <preformatted> 
 Group crash recovery started. 
 Recovery status for log stream 2 
  lowtranlsn: 000000000002E5C4 
  minbufflsn: 000000000002E5C4 
  headlsn: 000000000002E570 
  groupHeadLsn: 000000000002E570 
  groupMinBuffLSN: 000000000002E570 
  HeadExtentID: 0 
 GroupHeadExtentID: 0 
  nextLso: 8347649 
  nextLsn: 0000000000000000 
 2010-03-04-01.43.43.608423+480 I3985671E797 LEVEL: Info 
 PID : 17993 TID : 47441067895104 KTID : 18157 
 PROC : db2sysc 1 
 INSTANCE: wucuixia NODE : 001 DB : TESTDB 
 APPHDL : 1-55 APPID: *N1.DB2.100303174336 
 EDUID : 24 EDUNAME: db2agnti (TESTDB ) 1 
 FUNCTION: DB2 UDB, data protection services, 
 sqlpSetRecoveryStartingPoint, probe:101 
 
 DATA #1 : <preformatted> 
 Set recovery starting point. 
 Recovery status for log stream 1 
  lowtranlsn: 000000000002E570 
  minbufflsn: 000000000002E570 
  headlsn: 000000000002E570 
  groupHeadLsn: 000000000002E570 
  groupMinBuffLSN: 0000000000000000 
  HeadExtentID: 0 
 GroupHeadExtentID: 0 
  nextLso: 4173825 
  nextLsn: 000000000002E570 

 2010-03-04-01.43.43.626339+480 I3986469E798 LEVEL: Info 
 PID : 17993 TID : 47441067895104 KTID : 18157 
 PROC : db2sysc 1 
 INSTANCE: wucuixia NODE : 001 DB : TESTDB 
 APPHDL : 1-55 APPID: *N1.DB2.100303174336 
 EDUID : 24 EDUNAME: db2agnti (TESTDB ) 1 
 FUNCTION: DB2 UDB, data protection services, 
 sqlpSetRecoveryStartingPoint, probe:100 
 
 DATA #1 : <preformatted> 
 Set recovery starting point. 
 Recovery status for log stream 0 
  lowtranlsn: 000000000002E570 
  minbufflsn: 000000000002E570 
  headlsn: 000000000002E570 
  groupHeadLsn: 000000000002E570 
  groupMinBuffLSN: 0000000000000000 
  HeadExtentID: 0 
 GroupHeadExtentID: 0 
  nextLso: 36781825 
  nextLsn: 000000000002E570 

 2010-03-04-01.43.43.635045+480 I3987268E797 LEVEL: Info 
 PID : 17993 TID : 47441067895104 KTID : 18157 
 PROC : db2sysc 1 
 INSTANCE: wucuixia NODE : 001 DB : TESTDB 
 APPHDL : 1-55 APPID: *N1.DB2.100303174336 
 EDUID : 24 EDUNAME: db2agnti (TESTDB ) 1 
 FUNCTION: DB2 UDB, data protection services, 
 sqlpSetRecoveryStartingPoint, probe:102 
 
 DATA #1 : <preformatted> 
 Set recovery starting point. 
 Recovery status for log stream 2 
  lowtranlsn: 000000000002E570 
  minbufflsn: 000000000002E570 
  headlsn: 000000000002E570 
  groupHeadLsn: 000000000002E570 
  groupMinBuffLSN: 0000000000000000 
  HeadExtentID: 0 
 GroupHeadExtentID: 0 
  nextLso: 8347649 
  nextLsn: 000000000002E570 

 2010-03-04-01.43.47.247910+480 E4053435E467 LEVEL: Info 
 PID : 17993 TID : 47441067895104 KTID : 18157 
 PROC : db2sysc 1 
 INSTANCE: wucuixia NODE : 001 DB : TESTDB 
 APPHDL : 1-55 APPID: *N1.DB2.100303174336 
 EDUID : 24 
 EDUNAME: db2agnti (TESTDB ) 1 
 FUNCTION: DB2 UDB, recovery manager, sqlpresr, probe:3110 
 MESSAGE : ADM1528I Group crash recovery has completed successfully. 

 2010-03-04-01.43.47.262001+480 I4053903E478 LEVEL: Info 
 PID : 17993 
 TID : 47441067895104 KTID : 18157 
 PROC : db2sysc 1 
 INSTANCE: wucuixia NODE : 001 DB : TESTDB 
 APPHDL : 1-55 APPID: *N1.DB2.100303174336 
 EDUID : 24 EDUNAME: db2agnti (TESTDB ) 1 
 FUNCTION: DB2 UDB, recovery manager, sqlpresr, probe:3170 
 DATA #1 : <preformatted> 
 Crash recovery completed. Next LSN is 000000000002E5CB

回页首

结束语

本文简单的对 DB2 pureScale 的结构进行了描述，并重点介绍了新特性 Group Crash Recovery 新特性，并使用 DB2 V9.8 做了简单的实例说明。

参考资料

学习

通过 developerWorks Information Management 专区学习关于 Information Management 的更多知识。在这里可以找到技术文档、how-to 文章、培训、下载、产品信息等等。
通过 Information Management 专区 DB2 9 技术资源中心了解 DB2 产品家族的更多产品信息和相关技术。
通过“ DB2 V9.8 信息中心”，了解更多关于 DB2 pureScale 新特性的介绍。
随时关注 developerWorks 技术活动和网络广播。

获得产品和技术

使用可直接从 developerWorks 下载的 IBM 产品评估试用软件构建您的下一个开发项目。
现在可以免费使用 DB2。下载 DB2 Express-C，这是为社区提供的 DB2 Express Edition 的免费版本，它提供了与 DB2 Express Edition 相同的核心数据特性，为构建和部署应用程序奠定了坚实的基础。

讨论