分类:
2008-05-17 16:51:41
| ||
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 3、系统停用的时间安排计划如下: . 从2005年3月1号开始停用 . 在2005年12月1号恢复使用 . 在上述开始时间和结束时间期间的每个星期天开始连着的2天暂停监控 要完成上述要求,相应的asnclp命令如下: 1、首先创建一个MONITOR SUSPENSION TEMPLATE:
这段脚本中,我们设定了Alert Monitor控制服务器,然后创建了一个叫做SUNDAYT1的模版,这个模版定义了满足上述时间安排计划(第3点)的暂停监控的时间要求。 2、创建MONITOR SUSPENSION:
这段脚本主要创建了一个叫做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类型的目标表,可以记录下源表所有的数据变化历史信息,进一步的,可以在此基础上将相应的所需要的子集数据分发到其他需要的表里面,从而实现类似于数据审核等这样的功能需求,如下面两个图所示。
在V9中,对CCD做的重大改进就是,用户可以对如下两个方面通过图形界面的方式进行设定: 1、“complete”或者“noncomplete” 2、“condensed”或者“noncondensed” 所谓complete,就是指目标表是源表的一个完全的拷贝;而noncomplete则是指目标表仅包含源表的变化的部分(目标表数据初始为空)。所谓condensed,就是指对应于源表的每一行数据,目标表仅有一行数据对应之,并且该行是源表相应的那行数据的最近操作后的结果数据;而noncondensed则包含了对应于源表的每一行数据的所有的操作的对应的结果数据(每一个操作对应于目标表中的一行)。因此,CCD类型的目标表和其他类型的目标表的不同之处在于:CCD包含了除用户数据本身之外的关于源表的操作信息,这些操作包括插入、删除和更新以及他们的操作顺序等信息。为了支持这个功能,CCD表额外增加了一些相应的列,通过那些列,Q Apply程序从而可以实现相应功能。 具体操作界面如下所示,这个界面是在创建Q预定集的时候出现的。在目标表这个步骤的时候,用户可以指定目标表类型为CCD并且设置相关的属性。具体操作细节不再赘述。
其它方面的新特性和改进 除了上面这些主要组件的新特性和改进外,V9中还有一些其他的新特性和改进。主要列举如下: 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提供的复制技术更加稳定易用,也更加强大快捷,从而可以为企业数据环境带来更高更稳定的生产效率。 |