本文將按照復(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ù)制的新特性和改進1、Q復(fù)制的新特性和改進；2、其它方面的新特性和改進；3、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)境中。 1234567下一頁 由于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當(dāng)前所需要用到的最老的日志是哪個部分。而到了V91版本，在治理LUW平臺上的DB2日志文件方面有了較大提高，當(dāng)Q Capture不再需要某個日志文件的時候，那么用戶將會得到更好的相關(guān)信息（通過Q Capture status命令實現(xiàn)），具體說來，Q Capture status命令可以對如下方面的信息有更加具體的顯示：1、DB2日志文件的路徑2、Q Capture重新啟動時所需要的最老的DB2日志文件3、當(dāng)前正在被捕捉的DB2日志文件通過上面這些信息，用戶就能更好的判定和決定哪些日志文件不再被使用從而可以刪除之。此外，V9版本也將會對transaction的應(yīng)用處理方面（如忽略和過濾掉某些transaction）有更多完善。2．Q Apply的改進和完善在Q Apply方面，新增加的特性和相關(guān)的改進最多，主要為如下幾個方面：1、Load的改進2、Spill queue名字的可定制化的改進3、刪除spill queue方面的靈活性增強4、監(jiān)控數(shù)據(jù)的改進5、時間參數(shù)粒度方面的改進6、改進的status命令7、數(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了）。 上一頁1234567下一頁 而在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的睡眠時間）。對于status命令（主要用來檢查Q Apply等狀態(tài)的命令程序），在V8中其提供的輸出信息非常少，但是在V9中，該程序功能已經(jīng)大大加強，可以通過設(shè)置相關(guān)參數(shù)（show details）來顯示更加全面和有用的Q Apply當(dāng)前信息。不過目前僅在LUW平臺下支持這個增強的功能。下面是V9中該命令的一個示例：asnqacmd apply_server=qtest status show details。下面是該命令的一個示例輸出：=======================================================Q Apply program statusServer name (SERVER) = QTESTSchema name (SCHEMA) = ASNProgram status　(STATUS) = UpTime since program started　(UP_TIME) =　0d　0h　0m 29sLog file location　 (LOGFILE) =/home/tolleson/mylogsNumber of active Q subscriptions(ACTIVE_QSUBS) = 2Time period used to calculate average(INTERVAL_LENGTH) =　0h　0m　0.50sReceive queue : Q2Number of active Q subscriptions(ACTIVE_QSUBS) = 1All transactions applied as of (time)(OLDEST_TRANS) =2005-07-30-12.52.42.000001All transactions applied as of (LSN)　　 (OLDEST_TRANS) =　 0000:0000:0000:0000:0000Oldest in-progress transaction　　 (OLDEST_INFLT_TRANS) =　 2005-07-30-12.52.42.000001Average end-to-end latency (END2END LATENCY) =　　 0h　0m　1.476sAverage Q Capture latency　(CAPTURE_LATENCY) =　　 0h　0m　0.661sAverage WSMQ latency　 (QLATENCY) =　　 0h　0m　0.786sAverage Q Apply latency(APPLY_LATENCY) =　　 0h　0m　0.29sCurrent memory (CURENT_MEMORY) = 0 MBCurrent queue depth(QDEPTH) = 92========================================================== 上一頁1234567下一頁 從上面的輸出可以看到，這里的輸出信息更加具體和完備，包括了current queue depth， average end-to-end latency以及Number of active subscriptions等重要信息。通過這些信息，用戶可以更好的判定出當(dāng)前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è)用戶有下面這樣一個需求：1、Alert Monitor需要24x7不間斷運行2、Alert Monitor監(jiān)控一個叫做QSRVR2的Q Capture Server 上一頁1234567下一頁 3、系統(tǒng)停用的時間安排計劃如下：. 從2005年3月1號開始停用. 在2005年12月1號恢復(fù)使用. 在上述開始時間和結(jié)束時間期間的每個星期天開始連著的2天暫停監(jiān)控要完成上述要求，相應(yīng)的asnclp命令如下：1、首先創(chuàng)建一個MONITOR SUSPENSION TEMPLATE：SET SERVER MONITOR TO DB SAMPLE;SET OUTPUT MONITOR SCRIPT monperiod1.sql;CREATE MONITOR SUSPENSION TEMPLATE SUNDAYT1REPEATS WEEKLY DAY OF WEEK SUNDAY FOR DURATION 2 DAYS;這段腳本中，我們設(shè)定了Alert Monitor控制服務(wù)器，然后創(chuàng)建了一個叫做SUNDAYT1的模版，這個模版定義了滿足上述時間安排計劃（第3點）的暫停監(jiān)控的時間要求。2、創(chuàng)建MONITOR SUSPENSION：SET SERVER MONITOR TO DB SAMPLE;SET OUTPUT MONITOR SCRIPT monperiod1.sql;CREATE SUSPENSION NAME S2 FOR SERVER QSRVR2STARTING DATE 2005-03-01USING PATTERN SUNDAYT1ENDING 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ù)制中的目標(biāo)表的類型之一。事實上，該類型的目標(biāo)表在SQL復(fù)制中早已存在，通過CCD類型的目標(biāo)表，可以記錄下源表所有的數(shù)據(jù)變化歷史信息，進一步的，可以在此基礎(chǔ)上將相應(yīng)的所需要的子集數(shù)據(jù)分發(fā)到其他需要的表里面，從而實現(xiàn)類似于數(shù)據(jù)審核等這樣的功能需求，如下面兩個圖所示。 上一頁1234567下一頁 圖a圖b在V9中，對CCD做的重大改進就是，用戶可以對如下兩個方面通過圖形界面的方式進行設(shè)定：1、“complete或者“noncomplete2、“condensed或者“noncondensed所謂complete，就是指目標(biāo)表是源表的一個完全的拷貝；而noncomplete則是指目標(biāo)表僅包含源表的變化的部分（目標(biāo)表數(shù)據(jù)初始為空）。所謂condensed，就是指對應(yīng)于源表的每一行數(shù)據(jù)，目標(biāo)表僅有一行數(shù)據(jù)對應(yīng)之，并且該行是源表相應(yīng)的那行數(shù)據(jù)的最近操作后的結(jié)果數(shù)據(jù)；而noncondensed則包含了對應(yīng)于源表的每一行數(shù)據(jù)的所有的操作的對應(yīng)的結(jié)果數(shù)據(jù)（每一個操作對應(yīng)于目標(biāo)表中的一行）。因此，CCD類型的目標(biāo)表和其他類型的目標(biāo)表的不同之處在于：CCD包含了除用戶數(shù)據(jù)本身之外的關(guān)于源表的操作信息，這些操作包括插入、刪除和更新以及他們的操作順序等信息。為了支持這個功能，CCD表額外增加了一些相應(yīng)的列，通過那些列，Q Apply程序從而可以實現(xiàn)相應(yīng)功能。具體操作界面如下所示，這個界面是在創(chuàng)建Q預(yù)定集的時候出現(xiàn)的。在目標(biāo)表這個步驟的時候，用戶可以指定目標(biāo)表類型為CCD并且設(shè)置相關(guān)的屬性。具體操作細節(jié)不再贅述。其它方面的新特性和改進除了上面這些主要組件的新特性和改進外，V9中還有一些其他的新特性和改進。主要列舉如下： 上一頁1234567下一頁 1、復(fù)制中心（圖形界面）的增強--對MQ支持的增強2、Live Monitor3、Exceptions table formatter4、即將發(fā)布的Q Replication Dashboard當(dāng)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)的文件補丁。一個示例性的圖形界面如下圖所示。center>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)，紅色處于停止?fàn)顟B(tài)，沒有內(nèi)容的空白項（如GREEN（ASN1）的Q Apply單元格），表示該Server上沒有相應(yīng)的Q Capture或者Q Apply。當(dāng)點擊圖中的相應(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)效率。 上一頁1234567