而在V91中，model queue的定制化得到了进一步增强，主要体现在：用户可以通过相关选项在预定集的级别来指定想要的MODELQ的名字，也因此，不同的预定集可以有不同的model queue。如下图所示，说明了相关的改进和变化，用户可以在Model queue对应的空格里面添上自己想要的名字。
在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 ====================================================================== |
从上面的输出可以看到，这里的输出信息更加详细和完备，包括了current queue depth， average end-to-end latency以及Number of active subscriptions等重要信息。通过这些信息，用户可以更好的判断出当前Q Apply的运行情况。