本文將按照復制技術的分類以及復制組件的邏輯順序來對 DB2 V9.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復制的新特性和改進
1、Q復制的新特性和改進；
2、其它方面的新特性和改進；
3、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命令可以對如下方面的信息有更加詳細的顯示：
1、DB2日志文件的路徑
2、Q Capture重新啟動時所需要的最老的DB2日志文件
3、當前正在被捕捉的DB2日志文件
通過上面這些信息，用戶就能更好的判斷和決定哪些日志文件不再被使用從而可以刪除之。
此外，V9版本也將會對transaction的應用處理方面（如忽略和過濾掉某些transaction）有更多完善。
2．Q Apply的改進和完善
在Q Apply方面，新增加的特性和相關的改進最多，主要為如下幾個方面：
1、Load的改進
2、Spill queue名字的可定制化的改進
3、刪除spill queue方面的靈活性增強
4、監控數據的改進
5、時間參數粒度方面的改進
6、改進的status命令
7、數據轉換方面的改進
在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刪除掉，它才能激活相應的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的運行情況。
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：
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類型的目標表，可以記錄下源表所有的數據變化歷史信息，進一步的，可以在此基礎上將相應的所需要的子集數據分發到其他需要的表裡面，從而實現類似於數據審核等這樣的功能需求，如下面兩個圖所示。
圖a
圖b
在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提供的復制技術更加穩定易用，也更加強大快捷，從而可以為企業數據環境帶來更高更穩定的生產效率。
