本文将按照复制技术的分类以及复制组件的逻辑顺序来对 DB2 V9.1 中复制技术的新特性和改进做一个总体介绍。DB2 V9.1是IBM最新推出的数据库系统，除了延续以前版本对DB2数据库治理的特性，还提供了新的查询语言、新的存储技术、新的索引技术以及支持纯XML数据及其固有层次结构的其他相关特性，等等。关于上述新特性的具体介绍，请参见DW的相关系列文章，本文将要介绍的是DB2 V91在数据库复制技术方面的改进和相关新特性。首先，在DB2 V9.1中，复制相关的产品取了一个新的名字，叫做“WebSphere Replication Server”，通过这个名字，IBM更加强调了"复制"功能作为一个Server和服务的重要性。其次，从大的体系结构来说，DB2 V91的数据库复制技术仍然分为SQL复制和Q复制，而相关的复制组件也仍然是SQL复制的Capture、Apply和Monitor，以及Q复制中的Q Capture、Q Apply和Q Monitor，这一点和V8的差别不大。本文将按照复制技术的分类以及复制组件的逻辑顺序来对V91中的新特性和改进做一个总体介绍。因此下面将分为如下三大部分：SQL复制的新特性和改进1、Q复制的新特性和改进；2、其它方面的新特性和改进；3、SQL复制的新特性和改进。由于SQL复制是发展比较成熟的一种复制技术，所以其在V91中的改进主要体现在Capture这个组件上，而Capture的改进又主要体现在性能上。通过在并行处理方面的完善，Capture的吞吐量比原来有更优的表现，从而提高了相关性能。假如对V8比较熟悉的话，那么应该知道，在V8中，日志的读取的连续性并不是太好，这是因为日志的读取需要和Capture程序中其他相关的内部函数（这个函数和日志读取线程不属于同一个线程）进行直接同步。在V91中，为了提高Capture程序的性能，就必须提高日志读取的连续性，这是通过增加了一个新的线程（叫做transaction thread）来实现的。这样，日志读取的线程就不需要直接和其他内部函数进行同步，籍由新增加的专门的线程来隔离并处理相关的逻辑，从而使得日志的读取更加高效和连续。这就有助于在各种环境中提高Capture的性能，非凡是在z/OS的数据共享环境和LUW平台下的数据分区环境中。
1234567下一页
由于SQL复制是相对比较成熟的一种复制技术，所以其改进的地方相对于Q复制来说， 更少。下面将要介绍在V91中改进较多的Q复制。Q复制的新特性和改进在V91中，对Q复制有比较大的改进和完善。1．Q Capture的改进和完善首先，上述SQL复制中的Capture的改进同样适用于Q复制中的Q Capture。其次，在Q Capture status方面，在原来的V8版本中，在LUW平台下，有时候很难知道Q Capture当前所需要用到的最老的日志是哪个部分。而到了V91版本，在治理LUW平台上的DB2日志文件方面有了较大提高，当Q Capture不再需要某个日志文件的时候，那么用户将会得到更好的相关信息（通过Q Capture status命令实现），具体说来，Q Capture status命令可以对如下方面的信息有更加具体的显示：1、DB2日志文件的路径2、Q Capture重新启动时所需要的最老的DB2日志文件3、当前正在被捕捉的DB2日志文件通过上面这些信息，用户就能更好的判定和决定哪些日志文件不再被使用从而可以删除之。此外，V9版本也将会对transaction的应用处理方面（如忽略和过滤掉某些transaction）有更多完善。2．Q Apply的改进和完善在Q Apply方面，新增加的特性和相关的改进最多，主要为如下几个方面：1、Load的改进2、Spill queue名字的可定制化的改进3、删除spill queue方面的灵活性增强4、监控数据的改进5、时间参数粒度方面的改进6、改进的status命令7、数据转换方面的改进在load阶段，Q Apply将会创建和使用叫做“spill queue”的model queues，在V8的前期版本中，用户没有办法控制Apply去选择哪一个model queue，因为所有的预定集都只有一个单一的并且已经被系统硬编码的model queue （IBMQREP.SPILL.MODELQ），用户只能使用唯一的那个model queue （但是在V8的比较新的版本中，已经开始可以用户自己指定相关的model queue了）。
上一页1234567下一页
而在V91中，model queue的定制化得到了进一步增强，主要体现在：用户可以通过相关选项在预定集的级别来指定想要的MODELQ的名字，也因此，不同的预定集可以有不同的model queue。如下图所示，说明了相关的改进和变化，用户可以在Model queue对应的空格里面添上自己想要的名字。
Q Apply program status
Server name (SERVER) = QTEST
Schema name (SCHEMA) = ASN
Program status(STATUS) = Up
Time since program started(UP_TIME) =
0d0h0m 29s
Log file location (LOGFILE) =
/home/tolleson/mylogs
Number of active Q subscriptions(ACTIVE_QSUBS) = 2
Time period used to calculate average
(INTERVAL_LENGTH) =
0h0m0.50s
Receive queue : Q2
Number of active Q subscriptions(ACTIVE_QSUBS) = 1
All transactions applied as of (time)
(OLDEST_TRANS) =
2005-07-30-12.52.42.000001
All transactions applied as of (LSN)
(OLDEST_TRANS) =
0000:0000:0000:0000:0000
Oldest in-progress transaction
(OLDEST_INFLT_TRANS) =
2005-07-30-12.52.42.000001
Average end-to-end latency (END2END LATENCY) =
0h0m1.476s
Average Q Capture latency(CAPTURE_LATENCY) =
0h0m0.661s
Average WSMQ latency (QLATENCY) =
0h0m0.786s
Average Q Apply latency(APPLY_LATENCY) =
0h0m0.29s
Current memory (CURENT_MEMORY) = 0 MB
Current queue depth(QDEPTH) = 92
==========================================================
上一页1234567下一页
从上面的输出可以看到，这里的输出信息更加具体和完备，包括了current queue depth， average end-to-end latency以及Number of active subscriptions等重要信息。通过这些信息，用户可以更好的判定出当前Q Apply的运行情况。3．Q Monitor的改进和完善Q Monitor在V9中主要增加了暂停监控的功能。一旦定义好，不需要人工干预，可以给系统治理和维护带来很多便利之处。在原来的V8中，假如想使Alert Monitor停止发送相关的通知（notification），唯一的办法就是关掉Alert Monitor。这就意味着Alert Monitor在某些时候，譬如系统维护期间，假如忘记关闭的话，将会发送一些不必要的信息，从而浪费系统资源。在V9中，用户可以对Alert Monitor自定义相关的属性，如暂停时段的相关属性等等。另外，一个Alert Monitor还能监测多个Capture和Apply程序，并且，假如有需要的话，Alert Monitor还可以对那些Capture和Apply分别设置独立的暂停时段的相关属性，从而灵活治理和维护复制环境。不过需要注重的一点就是，目前暂时只支持通过asnclp命令行的方式来创建和定义相关的暂停监控的时段属性，图形界面（复制中心）目前还不支持这一功能。而相应新增加的asnclp命令为如下两种：“CREATE MONITOR SUSPENSION”和“CREATE MONITOR SUSPENSION TEMPLATE”。通过这两个命令，可以为特定的Capture或者Apply指定暂停监控的时间段，或者为其指定合适的模版来定义其暂停监控的模式。关于这个暂停监控的功能的应用，举下面这个例子来简单说明一下。假设用户有下面这样一个需求：1、Alert Monitor需要24x7不间断运行2、Alert Monitor监控一个叫做QSRVR2的Q Capture Server
上一页1234567下一页
3、系统停用的时间安排计划如下：. 从2005年3月1号开始停用. 在2005年12月1号恢复使用. 在上述开始时间和结束时间期间的每个星期天开始连着的2天暂停监控要完成上述要求，相应的asnclp命令如下：1、首先创建一个MONITOR SUSPENSION TEMPLATE：SET SERVER MONITOR TO DB SAMPLE;
SET OUTPUT MONITOR SCRIPT monperiod1.sql;
CREATE MONITOR SUSPENSION TEMPLATE SUNDAYT1
REPEATS WEEKLY DAY OF WEEK SUNDAY FOR DURATION 2 DAYS;这段脚本中，我们设定了Alert Monitor控制服务器，然后创建了一个叫做SUNDAYT1的模版，这个模版定义了满足上述时间安排计划（第3点）的暂停监控的时间要求。2、创建MONITOR SUSPENSION：SET SERVER MONITOR TO DB SAMPLE;
SET OUTPUT MONITOR SCRIPT monperiod1.sql;
CREATE SUSPENSION NAME S2 FOR SERVER QSRVR2
STARTING DATE 2005-03-01
USING PATTERN SUNDAYT1
ENDING DATE 2005-12-01;这段脚本主要创建了一个叫做S2的suspension，它指定了Server为QSRVR2，同时指定了开始时间和结束时间，以及使用的模版。通过上面的简单脚本，就可以实现该用户的上述需求了。关于Alert Monitor，还需要提及的就是，Alert Monitor现在可以给z/OS console发送警报消息了。假如是V8版本，可以通过一个PTF来增加这个功能。其具体实现就是在已有的asnclp中加入了两个新的选项，即“CREATE ALERT CONDITIONS”和“ALTER ALERT CONDITIONS”。4．CCD方面的改进和完善CCD方面的改进和完善是Q复制中很重要的一部分。CCD是Consistent Change Data的缩写，它是单向复制中的目标表的类型之一。事实上，该类型的目标表在SQL复制中早已存在，通过CCD类型的目标表，可以记录下源表所有的数据变化历史信息，进一步的，可以在此基础上将相应的所需要的子集数据分发到其他需要的表里面，从而实现类似于数据审核等这样的功能需求，如下面两个图所示。
上一页1234567下一页
上一页1234567下一页
1、复制中心（图形界面）的增强--对MQ支持的增强2、Live Monitor3、Exceptions table formatter4、即将发布的Q Replication Dashboard当V8刚发布时，在操作Q复制的时候，所有关于MQ的相关对象，都必须由用户手动敲入相关的名字，譬如用户必须手动敲入像queue manager、admin queue和restart queue等对象的名字，这就很轻易造成键盘敲入不慎带来的低级错误，使得相关问题的诊断变得困难。为了解决这类问题，在V9中对复制中心和asnclp做了改进，用户可以通过列表的方式来选择已经存在的相关的MQ对象。实际上，在DB2 V8 FP10（LUW平台）以及z/OS版本9中，已经集成了这个功能，不过用户需要到相关网站去下载几个相应的文件补丁。一个示例性的图形界面如下图所示。center>
上一页1234567
