引子
我们可以看到，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/qiangqiang/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/qiang3/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 的信息
2011-05-07-01.43.43.538263+480 I3980161E770 LEVEL: Info
PID : 17993 TID : 47441067895104 KTID : 18157
PROC : db2sysc 1
INSTANCE: qiangqiang 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 :
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
2011-05-07-01.43.43.547061+480 I3980932E771 LEVEL: Info
PID : 17993 TID : 47441067895104 KTID : 18157
PROC : db2sysc 1
INSTANCE: qiangqiang 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 :
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
2011-05-07-01.43.43.555777+480 I3981704E770 LEVEL: Info
PID : 17993 TID : 47441067895104 KTID : 18157
PROC : db2sysc 1
INSTANCE: qiangqiang 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 :
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 :
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
2011-05-07-01.43.43.626339+480 I3986469E798 LEVEL: Info
PID : 17993 TID : 47441067895104 KTID : 18157
PROC : db2sysc 1
INSTANCE: qiangqiang 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 :
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
2011-05-07-01.43.43.635045+480 I3987268E797 LEVEL: Info
PID : 17993 TID : 47441067895104 KTID : 18157
PROC : db2sysc 1
INSTANCE: qiangqiang 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 :
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
2011-05-07-01.43.47.247910+480 E4053435E467 LEVEL: Info
PID : 17993 TID : 47441067895104 KTID : 18157
PROC : db2sysc 1
INSTANCE: qiangqiang 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.
2011-05-07-01.43.47.262001+480 I4053903E478 LEVEL: Info
PID : 17993
TID : 47441067895104 KTID : 18157
PROC : db2sysc 1
INSTANCE: qiangqiang 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 :
Crash recovery completed. Next LSN is 000000000002E5CB
结束语
本文简单的对 DB2 pureScale 的结构进行了描述，并重点介绍了新特性 Group Crash Recovery 新特性，并使用 DB2 V9.8 做了简单的实例说明。
