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复制的新特性和改进；
Q复制的新特性和改进；
其它方面的新特性和改进。
SQL复制的新特性和改进:
由于SQL复制是发展比较成熟的一种复制技术，所以其在V91中的改进主要体现在Capture这个组件上，而Capture的改进又主要体现在性能上。
通过在并行处理方面的完善，Capture的吞吐量比原来有更优的表现，从而提高了相关性能。如果对V8比较熟悉的话，那么应该知道，在V8中，日志的读取的连续性并不是太好，这是因为日志的读取需要和Capture程序中其他相关的内部函数（这个函数和日志读取线程不属于同一个线程）进行直接同步。在V91中，为了提高Capture程序的性能，就必须提高日志读取的连续性，这是通过增加了一个新的线程（叫做transaction thread）来实现的。这样，日志读取的线程就不需要直接和其他内部函数进行同步，籍由新增加的专门的线程来隔离并处理相关的逻辑，从而使得日志的读取更加高效和连续。这就有助于在各种环境中提高Capture的性能，特别是在z/OS的数据共享环境和LUW平台下的数据分区环境中。
由于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命令可以对如下方面的信息有更加详细的显示：
DB2日志文件的路径
Q Capture重新启动时所需要的最老的DB2日志文件
当前正在被捕捉的DB2日志文件
通过上面这些信息，用户就能更好的判断和决定哪些日志文件不再被使用从而可以删除之。
此外，V9版本也将会对transaction的应用处理方面（如忽略和过滤掉某些transaction）有更多完善。
2．Q Apply的改进和完善
在Q Apply方面，新增加的特性和相关的改进最多，主要为如下几个方面：
Load的改进
Spill queue名字的可定制化的改进
删除spill queue方面的灵活性增强
监控数据的改进
时间参数粒度方面的改进
改进的status命令
数据转换方面的改进
在load阶段，Q Apply将会创建和使用叫做"spill queue"的model queues，在V8的前期版本中，用户没有办法控制Apply去选择哪一个model queue，因为所有的预定集都只有一个单一的并且已经被系统硬编码的model queue （IBMQREP.SPILL.MODELQ），用户只能使用唯一的那个model queue （但是在V8的比较新的版本中，已经开始可以用户自己指定相关的model queue了）。
而在V91中，model queue的定制化得到了进一步增强，主要体现在：用户可以通过相关选项在预定集的级别来指定想要的MODELQ的名字，也因此，不同的预定集可以有不同的model queue。如下图所示，说明了相关的改进和变化，用户可以在Model queue对应的空格里面添上自己想要的名字。
在V8中，直到Q Apply将相应的spill queue删除掉，它才能激活相应的subｓｃｒｉｐｔion。然而，如果Q Apply程序没有删除MQ队列的权限，那么subｓｃｒｉｐｔion就不能被激活。这个问题唯一的解决办法就是把相应的权限赋给Q Apply程序。在V91中，这个问题得到了更好的处理，用户可以不用将相应权限赋给Q Apply程序，同时也能使之激活相应的subｓｃｒｉｐｔion。
在监控数据的改进方面，主要体现在粒度更加精细化。在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 subｓｃｒｉｐｔions (ACTIVE_QSUBS) = 2
Time period used to calculate average (INTERVAL_LENGTH) = 0h 0m 0.50s
Receive queue : Q2
Number of active Q subｓｃｒｉｐｔions (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
