浅析DB2 中的DBMS CLUSTER技术

题目有点煽情，但是我想说的是的很多时候，我们看问题就像盲人摸象，自己以为自己获得了真知---其实还是还是冰山一角。当然本文也有可能是其中的冰山一角，但是对你理解DATA SHARING GROUP或许有一定的帮助。那么我们就从头开始说起吧----long long ago----

DBMS architecture

DBMS的发展也经历了合久必分，分久必合的历史趋势，从最开始的SHARING NOTHING,到SHARE  (DISHK)EVERYTHING 然后到最后的SHARING DATA,在这三个阶段中比较典型的代表如下：

SHARING NOTHING : DB2 FOR LUW, TERADATA,SYABASE,SQL SERVER ,INFORMIX

SHARING DISK(EVERY THING) ORACLE RAC

SHARING DATA   DATA SHARING GROUP FOR DB2

从上面的发展趋势，我们可以DSG相比较oracle 的RAC还是技高一筹，但是DSG与oracle的RAC其实本质上差别不是太大，只不过是实现的机制不同，一个主要基于硬件实现一个主要基于软件实现。或者说DSG与硬件的结合更加的纯粹。

但是从系统的架构（scalable,available，reliable）角度考虑，DSG的优势还是比较明显的。

这里只是个人的理解，如有偏颇，请指正。

下面我们继续讨论我们的DSG，看看他的RAS如何实现，一遍帮助你更好的理解DSG，从而成为一名合格的系统运维人员。从DSG的对比图我们可见DSG的大体实现，但是具体到细节，还是有很多部分值得咀嚼，我们慢慢揭开它的面纱吧。

从下图，我们看出DSG主要的硬件组成如下：

Stp timer

Sysplex

Db2 node

Cf

Links

第二幅图是则描述了软硬件的实现，这才是我们的菜

在何种需求下，用户可以考虑使用DSG呢？DRIVER

lCapacity: outgrow single system size 

–Avoid splitting the databases 

lNeed higher availability 

–Increasingly important requirement for web access 

–"Five nines" means 5 minutes of outage per year! 

lEasier growth accommodation 

–Need scalable, non?disruptive growth: 

–Dynamic workload balancing 

–Effective utilization of "white space" for mixed workloads 

–Increased thruput, consistent response times 

lSystem consolidation for easier systems management 

–High performance alternative to distributed data or data 

Replication

使用DSG的advantage：

?Efficiently scale beyond a single 

SMP for OLTP and mixed workloads 

?Eliminates single points of failure to 

achieve high availability 

?Non disruptively add capacity 

?Preserve application investment 

?Maximize use of available machine 

resources 

?Dynamic workload balancing 

?Operate the cluster as a "single 

system image" 

说了这么多，So what is  DSG

Allows concurrent R/W access data from multiple DB2s 

?Data on shared devices 

–Single DB2 Catalog/Directory database 

?DDL/BIND/Application can run on any DB2 

?Single system image for operational control 

?Runs in a zOS Parallel Sysplex 

environment
其实说到对DSG的理解，其实还得从整个系统的architecture说起。

我们就一点一点的进行剖析，DSG引入CF，并共享了一套CATALOG directory以及data，不可避免的引入的问题就是数据的一致性问题，这里的一致性问题主要包括如下两个部分：

1事务之间的并发控制concurrent

2 再者就是不同的member之间buffer数据的一致性问题 coherency

这两个问题的引入，使得DB2不得不引入新的设计方案

相比较而言，第一个问题事务之间的并发控制是通过锁机制实现，与non-data sharing不同的，先前一个IRLM可以控制自己所管辖数据的一致性，但是现在由于多个member之间含有多个IRLM，如何分配锁就是需要考虑的问题，该机制是通过’DSNGRPLOCK1’来实现的。注意这里并没有增加一个全局仲裁者，而是通过将所有的必要信息保存于CF中，将该信息通过XCF notify 给GLM，---拿到资源X锁的IRLM作为该资源的仲裁者---GLOBAL LOCK MANAGER.

当拿锁机制解决后，出现的另一个问题就是，当一个member的数据被修改后，其它member如何及时知道自己保存的数据已经invalidated?这个主要是通过GBPcache 来实现，为此DB2引入了physical lock的概念。该概念主要是区别于logical lock.其中 logical lock主要是保证事务之间的并发性。二physical lock 的主要目的是保证数据之间的coherency----个人理解多个buffer page之间数据的一致性。

    可以尝试这么理解，假如不存在physical lock，当两个member先后修改同一PAGE后，如何已最快的速度告知其中一个数据已经invalid，当存在多个member时，就需要存在一个大家都能访问得到的地方----couple facility---stored in cache ，也就为的GBP cache是主要应该是从性能上考虑。写入磁盘很明显不能满足该要求。那么什么样的数据需要写入GBP呢?即存在数据可能会不一致的情况------这就引入Physical lock，就page set p-lock，它主要是用来HELP DB2 track the level of data in different members,represent member interest(注意这里引入了两个概念，一个是PAGE SET P-LOCK,一个是GBP-DEPENDENT PAGE---GROUP BUFFER POOL DEPENDENT PAGE,二者不是直接相关，其中PAGE SET P-LOCK代表的是member level的interest).当IDRW interest存在时，update的page就需要写入GBP。那么何时写呢？在commit之前写入，由于各个系统已经在Cf register了自己的interest，当其中一个updated，并写入GBP后，CF会通知其它所有的member数据已经invalid，如果有需要就需要从CF获得。
注意这里说的GBP dependentpage ，当logical lock为row ，又会出现新的问题，即： 
m1     page1  update r1
m2     page1 update   r2
即使含有Page SET P-LOCK,在事务上，资源并不冲突，但是，二者是不能并发执行的，否则就会出现数据不一致的情况，为了解决这种情况，DSG引入了PAGE P-LOCK,update的member只有在持有PAGE P-LOCK的同时才能update  r1,否则无法修改
上述仅是给出了一个简单的理解方向，具体的请参考具体的实现
后续如有更好的理解方式将补充上
PAGE SET P-LOCK 独立于事务锁，且针对partition表，不同的partition之间的PAGE SET P-LOCK 也是独立的，同样
index space 的Page set  lock 也独立

需要注意的是：由于CF没有直接通磁盘相连，因此GBP中的数据最后仍是通过DB2 member写入 CAST OUT DISK。
REF:
IBM RED BOOKS OF DB2