全面解析DB2 V9.1复制技术的新特性和改进

个问题唯一的解决办法就是把相应的权限赋给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

======================================================================

从上面的输出可以看到，这里的输出信息更加详细和完备，包括了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指定暂停监控的时间段，或者为其指定合适的模版来定义其暂停监控的模式。

关于这个暂停监控的功能的应用，举下面这个例子来简单说明一下。假设用户有下面这样一个需求：

Alert Monitor需要24x7不间断运行

Alert Monitor监控一个叫做QSRVR2的Q Capture Server

系统停用的时间安排计划如下：

1. 从2005年3月1号开始停用

2. 在2005年12月1号恢复使用

3. 在上述开始时间和结束时间期间的每个星期天开始连着的2天暂停监控

要完成上述要求，相应的asnclp命令如下：

首先创建一个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点）的暂停监控的时间要求。

然后创建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"。