本文將按照復(fù)制技術(shù)的分類以及復(fù)制組件的邏輯順序來對 DB2 V9.1 中復(fù)制技術(shù)的新特性和改進做一個總體介紹。

DB2 V9.1是IBM最新推出的數(shù)據(jù)庫系統(tǒng)，除了延續(xù)以前版本對DB2數(shù)據(jù)庫管理的特性，還提供了新的查詢語言、新的存儲技術(shù)、新的索引技術(shù)以及支持純XML數(shù)據(jù)及其固有層次結(jié)構(gòu)的其他相關(guān)特性，等等。關(guān)于上述新特性的詳細介紹，請參見DW的相關(guān)系列文章，本文將要介紹的是DB2 V91在數(shù)據(jù)庫復(fù)制技術(shù)方面的改進和相關(guān)新特性。

首先，在DB2 V9.1中，復(fù)制相關(guān)的產(chǎn)品取了一個新的名字，叫做'WebSphere Replication Server'，通過這個名字，IBM更加強調(diào)了'復(fù)制'功能作為一個Server和服務(wù)的重要性。其次，從大的體系結(jié)構(gòu)來說，DB2 V91的數(shù)據(jù)庫復(fù)制技術(shù)仍然分為SQL復(fù)制和Q復(fù)制，而相關(guān)的復(fù)制組件也仍然是SQL復(fù)制的Capture、Apply和Monitor，以及Q復(fù)制中的Q Capture、Q Apply和Q Monitor，這一點和V8的差別不大。本文將按照復(fù)制技術(shù)的分類以及復(fù)制組件的邏輯順序來對V91中的新特性和改進做一個總體介紹。因此下面將分為如下三大部分：

·SQL復(fù)制的新特性和改進；

·Q復(fù)制的新特性和改進；

·其它方面的新特性和改進。

SQL復(fù)制的新特性和改進:

由于SQL復(fù)制是發(fā)展比較成熟的一種復(fù)制技術(shù)，所以其在V91中的改進主要體現(xiàn)在Capture這個組件上，而Capture的改進又主要體現(xiàn)在性能上。

通過在并行處理方面的完善，Capture的吞吐量比原來有更優(yōu)的表現(xiàn)，從而提高了相關(guān)性能。如果對V8比較熟悉的話，那么應(yīng)該知道，在V8中，日志的讀取的連續(xù)性并不是太好，這是因為日志的讀取需要和Capture程序中其他相關(guān)的內(nèi)部函數(shù)（這個函數(shù)和日志讀取線程不屬于同一個線程）進行直接同步。在V91中，為了提高Capture程序的性能，就必須提高日志讀取的連續(xù)性，這是通過增加了一個新的線程（叫做transaction thread）來實現(xiàn)的。這樣，日志讀取的線程就不需要直接和其他內(nèi)部函數(shù)進行同步，籍由新增加的專門的線程來隔離并處理相關(guān)的邏輯，從而使得日志的讀取更加高效和連續(xù)。這就有助于在各種環(huán)境中提高Capture的性能，特別是在z/OS的數(shù)據(jù)共享環(huán)境和LUW平臺下的數(shù)據(jù)分區(qū)環(huán)境中。

由于SQL復(fù)制是相對比較成熟的一種復(fù)制技術(shù)，所以其改進的地方相對于Q復(fù)制來說， 更少。下面將要介紹在V91中改進較多的Q復(fù)制。

Q復(fù)制的新特性和改進

在V91中，對Q復(fù)制有比較大的改進和完善。

1．Q Capture的改進和完善

首先，上述SQL復(fù)制中的Capture的改進同樣適用于Q復(fù)制中的Q Capture。其次，在Q Capture status方面，在原來的V8版本中，在LUW平臺下，有時候很難知道Q Capture當前所需要用到的最老的日志是哪個部分。而到了V91版本，在管理LUW平臺上的DB2日志文件方面有了較大提高，當Q Capture不再需要某個日志文件的時候，那么用戶將會得到更好的相關(guān)信息（通過Q Capture status命令實現(xiàn)），具體說來，Q Capture status命令可以對如下方面的信息有更加詳細的顯示：

DB2日志文件的路徑

Q Capture重新啟動時所需要的最老的DB2日志文件

當前正在被捕捉的DB2日志文件

通過上面這些信息，用戶就能更好的判斷和決定哪些日志文件不再被使用從而可以刪除之。

此外，V9版本也將會對transaction的應(yīng)用處理方面（如忽略和過濾掉某些transaction）有更多完善。

2．Q Apply的改進和完善

在Q Apply方面，新增加的特性和相關(guān)的改進最多，主要為如下幾個方面：

Load的改進

Spill queue名字的可定制化的改進

刪除spill queue方面的靈活性增強

監(jiān)控數(shù)據(jù)的改進

時間參數(shù)粒度方面的改進

改進的status命令

數(shù)據(jù)轉(zhuǎn)換方面的改進

在load階段，Q Apply將會創(chuàng)建和使用叫做'spill queue'的model queues，在V8的前期版本中，用戶沒有辦法控制Apply去選擇哪一個model queue，因為所有的預(yù)定集都只有一個單一的并且已經(jīng)被系統(tǒng)硬編碼的model queue （IBMQREP.SPILL.MODELQ），用戶只能使用唯一的那個model queue （但是在V8的比較新的版本中，已經(jīng)開始可以用戶自己指定相關(guān)的model queue了）。

而在V91中，model queue的定制化得到了進一步增強，主要體現(xiàn)在：用戶可以通過相關(guān)選項在預(yù)定集的級別來指定想要的MODELQ的名字，也因此，不同的預(yù)定集可以有不同的model queue。如下圖所示，說明了相關(guān)的改進和變化，用戶可以在Model queue對應(yīng)的空格里面添上自己想要的名字。

在V8中，直到Q Apply將相應(yīng)的spill queue刪除掉，它才能激活相應(yīng)的subscription。然而，如果Q Apply程序沒有刪除MQ隊列的權(quán)限，那么subscription就不能被激活。這個問題唯一的解決辦法就是把相應(yīng)的權(quán)限賦給Q Apply程序。在V91中，這個問題得到了更好的處理，用戶可以不用將相應(yīng)權(quán)限賦給Q Apply程序，同時也能使之激活相應(yīng)的subscription。

在監(jiān)控數(shù)據(jù)的改進方面，主要體現(xiàn)在粒度更加精細化。在V8中，有些監(jiān)控數(shù)據(jù)的粒度是以秒為單位，但是在眾多客戶的使用過程中發(fā)現(xiàn)，這個粒度在某些情形下過于粗糙，他們需要更細的粒度單位。因此，在V91中，有3個參數(shù)的粒度被細化到毫秒級，即MONITOR_INTERVAL（監(jiān)控數(shù)據(jù)的時間間隔），MEM_FULL_TIME（內(nèi)存滿時間）和APPLY_SLEEP_TIME（Apply的睡眠時間）。關(guān)于這三個參數(shù)的更詳細解釋，請參見相關(guān)的手冊和文檔。

對于status命令（主要用來檢查Q Apply等狀態(tài)的命令程序），在V8中其提供的輸出信息非常少，但是在V9中，該程序功能已經(jīng)大大加強，可以通過設(shè)置相關(guān)參數(shù)（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中主要增加了暫停監(jiān)控的功能。一旦定義好，不需要人工干預(yù)，可以給系統(tǒng)管理和維護帶來很多便利之處。

在原來的V8中，如果想使Alert Monitor停止發(fā)送相關(guān)的通知（notification），唯一的辦法就是關(guān)掉Alert Monitor。這就意味著Alert Monitor在某些時候，譬如系統(tǒng)維護期間，如果忘記關(guān)閉的話，將會發(fā)送一些不必要的信息，從而浪費系統(tǒng)資源。在V9中，用戶可以對Alert Monitor自定義相關(guān)的屬性，如暫停時段的相關(guān)屬性等等。另外，一個Alert Monitor還能監(jiān)測多個Capture和Apply程序，并且，如果有需要的話，Alert Monitor還可以對那些Capture和Apply分別設(shè)置獨立的暫停時段的相關(guān)屬性，從而靈活管理和維護復(fù)制環(huán)境。

不過需要注意的一點就是，目前暫時只支持通過asnclp命令行的方式來創(chuàng)建和定義相關(guān)的暫停監(jiān)控的時段屬性，圖形界面（復(fù)制中心）目前還不支持這一功能。而相應(yīng)新增加的asnclp命令為如下兩種：'CREATE MONITOR SUSPENSION'和'CREATE MONITOR SUSPENSION TEMPLATE'。通過這兩個命令，可以為特定的Capture或者Apply指定暫停監(jiān)控的時間段，或者為其指定合適的模版來定義其暫停監(jiān)控的模式。

關(guān)于這個暫停監(jiān)控的功能的應(yīng)用，舉下面這個例子來簡單說明一下。假設(shè)用戶有下面這樣一個需求：

Alert Monitor需要24x7不間斷運行

Alert Monitor監(jiān)控一個叫做QSRVR2的Q Capture Server

系統(tǒng)停用的時間安排計劃如下：

1. 從2005年3月1號開始停用

2. 在2005年12月1號恢復(fù)使用

3. 在上述開始時間和結(jié)束時間期間的每個星期天開始連著的2天暫停監(jiān)控

要完成上述要求，相應(yīng)的asnclp命令如下：

首先創(chuàng)建一個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;

這段腳本中，我們設(shè)定了Alert Monitor控制服務(wù)器，然后創(chuàng)建了一個叫做SUNDAYT1的模版，這個模版定義了滿足上述時間安排計劃（第3點）的暫停監(jiān)控的時間要求。

然后創(chuàng)建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;

這段腳本主要創(chuàng)建了一個叫做S2的suspension，它指定了Server為QSRVR2，同時指定了開始時間和結(jié)束時間，以及使用的模版。通過上面的簡單腳本，就可以實現(xiàn)該用戶的上述需求了。

關(guān)于Alert Monitor，還需要提及的就是，Alert Monitor現(xiàn)在可以給z/OS console發(fā)送警報消息了。如果是V8版本，可以通過一個PTF來增加這個功能。其具體實現(xiàn)就是在已有的asnclp中加入了兩個新的選項，即'CREATE ALERT CONDITIONS'和'ALTER ALERT CONDITIONS'。

4．CCD方面的改進和完善

CCD方面的改進和完善是Q復(fù)制中很重要的一部分。CCD是Consistent Change Data的縮寫，它是單向復(fù)制中的目標表的類型之一。事實上，該類型的目標表在SQL復(fù)制中早已存在，通過CCD類型的目標表，可以記錄下源表所有的數(shù)據(jù)變化歷史信息，進一步的，可以在此基礎(chǔ)上將相應(yīng)的所需要的子集數(shù)據(jù)分發(fā)到其他需要的表里面，從而實現(xiàn)類似于數(shù)據(jù)審核等這樣的功能需求，如下面兩個圖所示。

在V9中，對CCD做的重大改進就是，用戶可以對如下兩個方面通過圖形界面的方式進行設(shè)定：

'complete'或者'noncomplete'

'condensed'或者'noncondensed'

所謂complete，就是指目標表是源表的一個完全的拷貝；而noncomplete則是指目標表僅包含源表的變化的部分（目標表數(shù)據(jù)初始為空）。所謂condensed，就是指對應(yīng)于源表的每一行數(shù)據(jù)，目標表僅有一行數(shù)據(jù)對應(yīng)之，并且該行是源表相應(yīng)的那行數(shù)據(jù)的最近操作后的結(jié)果數(shù)據(jù)；而noncondensed則包含了對應(yīng)于源表的每一行數(shù)據(jù)的所有的操作的對應(yīng)的結(jié)果數(shù)據(jù)（每一個操作對應(yīng)于目標表中的一行）。因此，CCD類型的目標表和其他類型的目標表的不同之處在于：CCD包含了除用戶數(shù)據(jù)本身之外的關(guān)于源表的操作信息，這些操作包括插入、刪除和更新以及他們的操作順序等信息。為了支持這個功能，CCD表額外增加了一些相應(yīng)的列，通過那些列，Q Apply程序從而可以實現(xiàn)相應(yīng)功能。

具體操作界面如下所示，這個界面是在創(chuàng)建Q預(yù)定集的時候出現(xiàn)的。在目標表這個步驟的時候，用戶可以指定目標表類型為CCD并且設(shè)置相關(guān)的屬性。具體操作細節(jié)不再贅述。

其它方面的新特性和改進

除了上面這些主要組件的新特性和改進外，V9中還有一些其他的新特性和改進。主要列舉如下：

復(fù)制中心（圖形界面）的增強--對MQ支持的增強

Live Monitor

Exceptions table formatter

即將發(fā)布的Q Replication Dashboard

當V8剛發(fā)布時，在操作Q復(fù)制的時候，所有關(guān)于MQ的相關(guān)對象，都必須由用戶手動敲入相關(guān)的名字，譬如用戶必須手動敲入像queue manager、admin queue和restart queue等對象的名字，這就很容易造成鍵盤敲入不慎帶來的低級錯誤，使得相關(guān)問題的診斷變得困難。

為了解決這類問題，在V9中對復(fù)制中心和asnclp做了改進，用戶可以通過列表的方式來選擇已經(jīng)存在的相關(guān)的MQ對象。實際上，在DB2 V8 FP10（LUW平臺）以及z/OS版本9中，已經(jīng)集成了這個功能，不過用戶需要到相關(guān)網(wǎng)站去下載幾個相應(yīng)的文件補丁。一個示例性的圖形界面如下圖所示。

Q replication Live Monitor是一個用來實時顯示系統(tǒng)延遲和系統(tǒng)吞吐量的圖形工具。每一個Q Capture和Q Apply都可以有一個Live Monitor。如下圖所示，顯示了相關(guān)的Q Capture、Q Apply甚至MQ的延遲和吞吐量等實時信息。通過Live Monitor，也可以探測Q Capture或者Q Apply是不是處于非活動狀態(tài)，等等。

Exception Table Formatter是一個命令行工具，主要從Apply控制服務(wù)器的異常表中選擇相關(guān)數(shù)據(jù)并且以用戶友好的可讀方式將相關(guān)信息顯示出來。其輸出信息可以通過網(wǎng)絡(luò)瀏覽器以文本方式顯示出來。

Dashboard是一個新的小窗口式的圖形界面，主要可以用來顯示Q Capture和Q Apply的運行狀態(tài)。如下圖所示，我們能看到每一個Server上面的Q Capture和Q Apply的運行狀態(tài)，綠色表示處于正常運行狀態(tài)，紅色處于停止狀態(tài)，沒有內(nèi)容的空白項（如GREEN（ASN1）的Q Apply單元格），表示該Server上沒有相應(yīng)的Q Capture或者Q Apply。

當點擊圖中的相應(yīng)Server時，可以進一步顯示該Server更加詳細的信息。下圖是其中界面之一（還有其他的一些類似的界面，這里不再贅述），包括了相應(yīng)的表所處的預(yù)定集的狀態(tài)、復(fù)制的類型、節(jié)點信息等等。這些信息對于問題和環(huán)境的診斷是非常有幫助的。

結(jié)束語

本文主要介紹了DB2 V9版本在復(fù)制技術(shù)方面的一些改進、完善以及新特性。通過對SQL復(fù)制的新特性和改進、Q復(fù)制的新特性和改進以及其它方面的新特性和改進三個大方面來講述。從文中可以發(fā)現(xiàn)，DB2 V9提供的復(fù)制技術(shù)更加穩(wěn)定易用，也更加強大快捷，從而可以為企業(yè)數(shù)據(jù)環(huán)境帶來更高更穩(wěn)定的生產(chǎn)效率。