DB2 Capture程序的正确解析，专家答疑版

　　文章主要向大家讲述的是专家答疑之DB2 Capture程序的正确解析，我们大家都知道DB2 Capture程序是一个非常关键的应用程序，在数据库复制的实际解决方案中表现尤为突出  。这个程序的主要的作用就是追踪在DB2服务器上对复制源所做的更改  。

　　如果有更改的话，会将这些更改的记录保存在一张特殊的表中(CD表)  。

　　通常情况下，这个应用程序时运行在控制服务器上  。不过具体运行在哪个位置，根据操作系统的不同可以有不同的选择  。作为数据库管理员，必须要将Capture程序牢牢的掌握在手中  。让其在关键的时候发挥关键的作用  。具体的来说，需要在必要的时候，启动如下几个DB2 Capture程序相关的进程  。

　　一、工程程序进程

　　如上图所示，既然Capture程序主要用来监测数据源表的变动并将相关的记录保存到CD表中，那么必然要有一个进程，好像一只眼睛一样，时刻盯着数据源表数据的的变化情况  。如果有变化的话，即使告知其他进程  。这个进程就叫做工作程序进程  。通常情况下，当启动Capture进程的时候，这个工作程序进程就会启动  。

　　工作程序进程与复制源所驻留的DB2数据库相连，监视复制源的更改情况  。同时，其也决定了Capture程序的启动方式(即根据相关的参数来决定是以热启动方式或者以冷启动方式来启动Capture程序)  。当这个工作程序进程启动的时候，它就会读取活动的数据库日志，以判断相关的复制源(如基础表、视图)等等是否进行了更改  。

　　只要启动了这个进程，那么这个监测会一直持续下去  。也就是说，并不是用户对复制源作了更改，才触发这个进程  。而是无论复制源是否有更改，这个进程一直都存在(只要启动了DB2 Capture程序)  。对于这个进程，笔者认为数据库管理员需要从以下几个方面去了解  。

　　一是其监测的内容来源  。工作程序进程会读取活动的数据库日志  。不过对于DB2数据库来说，数据库日志包括两部分，分别为重做日志缓存与重做日志文件  。由于内存的速度要比硬盘速度快的多，所以为了提高数据库的性能，系统往往是先将数据存储在内存中  。然后在符合一定的条件下，再将内存中的数据保存到数据文件中  。

　　而内存中的事务日志又可以分为两类，分别为已落实的事务记录(即已经递交的事务)与未落实的事务记录(还没有递交的事务)  。工作程序进程在工作过程中，会收集内存中属于每个事务的所有记录，并每个一个固定的时间将收集到的已经落实的事务写入到对应的CD表中  。故其数据源其实是内存中已经落实了的事务记录  。

　　二是需要注意，一个时间间隔的问题  。即隔多少时间，将相关的记录保存到CD表中  。如果这个时间间隔设置的比较长，那么数据的同步性就比较差  。而如果设置的比较短的话，又会影响数据库的性能  。一般情况下，只要采取数据库的默认设置即可  。但是如果数据源表中的数据更改非常频繁，则需要根据实际情况来合理调整这个时间参数，以提高数据库性能  。

　　笔者的建议是，先采用默认的值，并进行数据库性能的监测  。如果发现这个值不合适的话，则可以适当调整并继续监测其对数据库性能的影响  。经过几次调试之后，就可以得到一个相对合理的时间间隔值  。

　　二、修剪进程

　　如上图所示，工作DB2 Capture程序进程会将复制源表的变化都保存到CD表中  。而这个CD表中的数据又会根据不同的应用最终复制到其他的目的表中  。也就是说，这个CD表只是一个中间表  。一般用户不会直接从这个表中读取数据，而是通过其他的表来访问CD表中的相关信息  。此时就会引出一个新的问题  。即随着时间的推移，这个CD表中的数据会越来越多  。

　　这不仅会影响数据库的性能，而且还会浪费存储的空间  。由于CD表中的数据会根据一定的规则复制到目标表中  。为此就需要有一种机制，来不定时的清理CD表中的数据，将垃圾数据清除出去  。此时就需要用到修剪进程  。

　　根据实际的应用，这个CD表中的数据可以分为两种类型  。一是CD表中的数据已经被复制到其他目的表中了，此时这个CD表中的数据已经没有任何作用了  。二是CD表中的数据虽然没有被复制到其他表中，但是已近过了有效期限  。此时这个数据也已经没有用途了，也需要清除  。针对这两种不同的情况，又可以将修剪进程分为正常修剪进程与保留限制进程  。

　　正常修剪进程就是指，当修剪集表和修剪控制表中的值显示已经将组成这些行的事务复制到依赖于该CD表的所有目标表时，就会将CD表中的相关行以及工作单元表中相应的行删除  。简单的说，就是需要用到这个CD表中的目标表已经将数据复制过去了，此时这个CD表中的相关记录就会被删除  。不过需要注意，修剪也不是时刻进行的  。

　　也就是说，不是目的表将CD表中的数据复制过去，这个表中的数据就被删除了  。另外需要注意的是，目的表只是把CD表中的数据复制过去，而不是剪贴过去  。这主要是因为可能有多张目的表需要用到这个CD表中的数据  。修剪进程会没隔一段时间来检查一下，是否满足这个条件  。如果满足的话，就将CD表中的记录删除  。而这个时间间隔是由参数PRUNE_INTERVAL决定的  。

　　很显然这个参数的值会影响到修剪进程的效率  。如何这个参数的值设置的比较大，那么修剪进程作业的时间间隔就会比较长，这在一定程度上会提高数据库的性能  。但是如果设置的太长的话，则CD表中的记录就会比较多，又会给数据库的性能造成负面的影响  。为此数据库管理员必须要根据复制源数据更新的频率，在必要的情况下要手工调整这个参数  。

　　如果目的表永远不从这个CD表中复制记录，难道修剪进程永远不删除CD表中的记录吗？其实不然  。在修剪进程中，除了正常修剪之外，还有一个保留限制修剪  。这个这个修剪中，进程会检查CD表中某些记录的存在时间，是否超过了有效期  。如果超过了的话，则保留限制修剪进程就会删除CD表中的行以及工作单元表中相应的行  。

　　这个CD表中的有效期是有参数RETENTION_LIMIT来控制的  。显然这个参数也非常的重要  。如果这个参数设置的比较短，那么可能还没等用户复制记录，表中记录就会因为过了有效期而导致数据被删除  。但是如果设置的比较长的话，那么垃圾数据就会越来越多，浪费存储空间，影响数据库性能  。

　　对此笔者的建议是，数据库管理员需要在性能、存储空间、RETENTION_LIMIT参数之间取得一个均衡的值  。一般情况下，只要数据库性能与存储空间允许，则最好将这个参数的值设置的比较长一点  。以免这表中的数据在目的表还没有复制之前就被删除  。

　　除了以上这两个进程外，DB2 Capture程序还有管理进程、串行化进程等等  。不过这些进程要么是数据库自动管理的，要么就是对于Capture程序的影响不是很大  。总之，不是数据库管理员关注的重点，为此笔者就不做过多的阐述  。笔者认为，从数据库性能的角度考虑，数据库管理员主要是要关注这个几个进程中涉及到的时间间隔参数  。

　　这些参数是把双刃剑  。设置的好，可以提高数据库性能  。如设置的不好，相反会降低数据库的效率  。