DB2 V9.1 复制技术新特性

在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
======================================================================

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"。