转自http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-1006wucx/index.html
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（SD） 是一种全新的数据存储方式。在这种方式中，所有的数据都是共享的，member1 可以读取 member2 的数据，但每个 member 只能在自己的日志路径上写日志。图 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 |
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，可以使用 export DB2NODE=2 来设定 member2, 然后连接数据库来触发 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 命令。当 RESTART DATABASE, ACTIVATE DATABASE 或者 CONNECT TO 命令完成后，执行命令的 member 就可以接受新的请求，数据库也就可以使用了，但没有解决 in-doubt transaction 的数据页还是不能建立连接。
与以前版本的 Crash Recovery 相比，Group Crash Recovery 有以下几点不同：
即使没有指定 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 的触发条件，则 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 事务的数据页。
比如在创建 buffer pool，table space, table, index 等等数据操作中，如果有未提交的事务存在，此时发生 Crash CF，则在创新启动数据库，并试图进行连接时，就会发生 Group Crash Recovery。以下举个最简单的例子来说明 Group Crash Recovery。清单 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 上的操作。
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 的条件，比如断电，这里我们使用 killdbm。
killdbm – killca |
清单 8 来查询 Group Crash Recovery 后数据库表的结果。
db2 => select * from t1 A B ----------- ----------- 1 2 2 4 3 2 4 4 5 2 5 record(s) selected. |
清单 9 显示了 db2diag 中关于 Group Crash Recovery 的信息。
清单 9. 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 : |
本文简单的对 DB2 pureScale 的结构进行了描述，并重点介绍了新特性 Group Crash Recovery 新特性，并使用 DB2 V9.8 做了简单的实例说明。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/15082138/viewspace-665983/ ，如需转载，请注明出处，否则将追究法律责任。
最新文章
- Optim Development Studio 的新增功能，第 2 部分
- 编写高效 SQL 语句的最佳实践
- DB2 pureScale 实战
- 整合 DB2 与 AIX 的 WLM 功能进行工作负载管理
- IBM solidDB and IBM solidDB Universal Cache认证指南，第 4 部分
- IBM solidDB and IBM solidDB Universal Cache认证指南，第 3 部分: 安装与配置
- 深入探索 IBM 数据分析和预测软件 - PASW Modeler
- 数据架构师: 您要治理什么？
- 在 DB2 Database Partitioning Feature 环境中选择分区键
- 在DB2 for Linux, UNIX, Windows OLTP环境中使用Enterprise Flash Drives的好处
