在V8中，直到Q Apply将相应的spill queue删除掉，它才能激活相应的subscription。然而，假如Q Apply程序没有删除MQ队列的权限，那么subscription就不能被激活。这个问题唯一的解决办法就是把相应的权限赋给Q Apply程序。在V91中，这个问题得到了更好的处理，用户可以不用将相应权限赋给Q Apply程序，同时也能使之激活相应的subscription。 在监控数据的改进方面，主要体现在粒度更加精细化。在V8中，有些监控数据的粒度是以秒为单位，但是在众多客户的使用过程中发现，这个粒度在某些情形下过于粗糙，他们需要更细的粒度单位。因此，在V91中，有3个参数的粒度被细化到毫秒级，即MONITOR_INTERVAL（监控数据的时间间隔），MEM_FULL_TIME（内存满时间）和APPLY_SLEEP_TIME（Apply的睡眠时间）。 对于status命令（主要用来检查Q Apply等状态的命令程序），在V8中其提供的输出信息非常少，但是在V9中，该程序功能已经大大加强，可以通过设置相关参数（show details）来显示更加全面和有用的Q Apply当前信息。不过目前仅在LUW平台下支持这个增强的功能。下面是V9中该命令的一个示例：asnqacmd apply_server=qtest status show details。 下面是该命令的一个示例输出：=======================================================
Q Apply PRogram status
Server name (SERVER) = QTEST
Schema name (SCHEMA) = ASN
Program status (STATUS) = Up
Time since program started (UP_TIME) =
0d 0h 0m 29s
Log file location (LOGFILE) =
/home/tolleson/mylogs
Number of active Q subscriptions(ACTIVE_QSUBS) = 2
Time period used to calculate average
(INTERVAL_LENGTH) =
0h 0m 0.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) =
0h 0m 1.476s
Average Q Capture latency (CAPTURE_LATENCY) =
0h 0m 0.661s
Average WSMQ latency (QLATENCY) =
0h 0m 0.786s
Average Q Apply latency (APPLY_LATENCY) =
0h 0m 0.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下一页 
图a
图b 在V9中，对CCD做的重大改进就是，用户可以对如下两个方面通过图形界面的方式进行设定： 1、“complete”或者“noncomplete” 2、“condensed”或者“noncondensed” 所谓complete，就是指目标表是源表的一个完全的拷贝；而noncomplete则是指目标表仅包含源表的变化的部分（目标表数据初始为空）。所谓condensed，就是指对应于源表的每一行数据，目标表仅有一行数据对应之，并且该行是源表相应的那行数据的最近操作后的结果数据；而noncondensed则包含了对应于源表的每一行数据的所有的操作的对应的结果数据（每一个操作对应于目标表中的一行）。因此，CCD类型的目标表和其他类型的目标表的不同之处在于：CCD包含了除用户数据本身之外的关于源表的操作信息，这些操作包括插入、删除和更新以及他们的操作顺序等信息。为了支持这个功能，CCD表额外增加了一些相应的列，通过那些列，Q Apply程序从而可以实现相应功能。 具体操作界面如下所示，这个界面是在创建Q预定集的时候出现的。在目标表这个步骤的时候，用户可以指定目标表类型为CCD并且设置相关的属性。具体操作细节不再赘述。
其它方面的新特性和改进 除了上面这些主要组件的新特性和改进外，V9中还有一些其他的新特性和改进。主要列举如下： 上一页1234567下一页 1、复制中心（图形界面）的增强--对MQ支持的增强 2、Live Monitor 3、Exceptions table formatter 4、即将发布的Q Replication Dashboard 当V8刚发布时，在操作Q复制的时候，所有关于MQ的相关对象，都必须由用户手动敲入相关的名字，譬如用户必须手动敲入像queue manager、admin queue和restart queue等对象的名字，这就很轻易造成键盘敲入不慎带来的低级错误，使得相关问题的诊断变得困难。 为了解决这类问题，在V9中对复制中心和asnclp做了改进，用户可以通过列表的方式来选择已经存在的相关的MQ对象。实际上，在DB2 V8 FP10（LUW平台）以及z/OS版本9中，已经集成了这个功能，不过用户需要到相关网站去下载几个相应的文件补丁。一个示例性的图形界面如下图所示。 center>
Q replication Live Monitor是一个用来实时显示系统延迟和系统吞吐量的图形工具。每一个Q Capture和Q Apply都可以有一个Live Monitor。如下图所示，显示了相关的Q Capture、Q Apply甚至MQ的延迟和吞吐量等实时信息。通过Live Monitor，也可以探测Q Capture或者Q Apply是不是处于非活动状态，等等。
Exception Table Formatter是一个命令行工具，主要从Apply控制服务器的异常表中选择相关数据并且以用户友好的可读方式将相关信息显示出来。其输出信息可以通过网络浏览器以文本方式显示出来。 Dashboard是一个新的小窗口式的图形界面，主要可以用来显示Q Capture和Q Apply的运行状态。如下图所示，我们能看到每一个Server上面的Q Capture和Q Apply的运行状态，绿色表示处于正常运行状态，红色处于停止状态，没有内容的空白项（如GREEN（ASN1）的Q Apply单元格），表示该Server上没有相应的Q Capture或者Q Apply。
当点击图中的相应Server时，可以进一步显示该Server更加具体的信息。下图是其中界面之一（还有其他的一些类似的界面，这里不再赘述），包括了相应的表所处的预定集的状态、复制的类型、节点信息等等。这些信息对于问题和环境的诊断是非常有帮助的。
结束语 本文主要介绍了DB2 V9版本在复制技术方面的一些改进、完善以及新特性。通过对SQL复制的新特性和改进、Q复制的新特性和改进以及其它方面的新特性和改进三个大方面来讲述。从文中可以发现，DB2 V9提供的复制技术更加稳定易用，也更加强大快捷，从而可以为企业数据环境带来更高更稳定的生产效率。 上一页1234567 新闻热点
疑难解答
