在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
========================================================== 上一頁1234567下一頁 從上面的輸出可以看到，這里的輸出信息更加具體和完備，包括了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指定暫停監控的時間段，或者為其指定合適的模版來定義其暫停監控的模式。 關于這個暫停監控的功能的應用，舉下面這個例子來簡單說明一下。假設用戶有下面這樣一個需求： 1、Alert Monitor需要24x7不間斷運行 2、Alert Monitor監控一個叫做QSRVR2的Q Capture Server 上一頁1234567下一頁 3、系統停用的時間安排計劃如下： . 從2005年3月1號開始停用 . 在2005年12月1號恢復使用 . 在上述開始時間和結束時間期間的每個星期天開始連著的2天暫停監控 要完成上述要求，相應的asnclp命令如下： 1、首先創建一個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點）的暫停監控的時間要求。 2、創建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”。 4．CCD方面的改進和完善 CCD方面的改進和完善是Q復制中很重要的一部分。CCD是Consistent Change Data的縮寫，它是單向復制中的目標表的類型之一。事實上，該類型的目標表在SQL復制中早已存在，通過CCD類型的目標表，可以記錄下源表所有的數據變化歷史信息，進一步的，可以在此基礎上將相應的所需要的子集數據分發到其他需要的表里面，從而實現類似于數據審核等這樣的功能需求，如下面兩個圖所示。 上一頁1234567下一頁 
圖a
圖b 在V9中，對CCD做的重大改進就是，用戶可以對如下兩個方面通過圖形界面的方式進行設定： 1、“complete”或者“noncomplete” 2、“condensed”或者“noncondensed” 所謂complete，就是指目標表是源表的一個完全的拷貝；而noncomplete則是指目標表僅包含源表的變化的部分（目標表數據初始為空）。所謂condensed，就是指對應于源表的每一行數據，目標表僅有一行數據對應之，并且該行是源表相應的那行數據的最近操作后的結果數據；而noncondensed則包含了對應于源表的每一行數據的所有的操作的對應的結果數據（每一個操作對應于目標表中的一行）。因此，CCD類型的目標表和其他類型的目標表的不同之處在于：CCD包含了除用戶數據本身之外的關于源表的操作信息，這些操作包括插入、刪除和更新以及他們的操作順序等信息。為了支持這個功能，CCD表額外增加了一些相應的列，通過那些列，Q Apply程序從而可以實現相應功能。 具體操作界面如下所示，這個界面是在創建Q預定集的時候出現的。在目標表這個步驟的時候，用戶可以指定目標表類型為CCD并且設置相關的屬性。具體操作細節不再贅述。
其它方面的新特性和改進 除了上面這些主要組件的新特性和改進外，V9中還有一些其他的新特性和改進。主要列舉如下： 上一頁1234567下一頁 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提供的復制技術更加穩定易用，也更加強大快捷，從而可以為企業數據環境帶來更高更穩定的生產效率。 上一頁1234567 新聞熱點
疑難解答
