隨著 IBM? WebSphere? Information Integrator 8.2 的發(fā)布，IBM 提供了一項(xiàng)稱作隊(duì)列復(fù)制或 Q 復(fù)制的功能，使數(shù)據(jù)庫復(fù)制有了很大的進(jìn)步。新的復(fù)制架構(gòu)是隨著對高性能（高事務(wù)量，低延時(shí)）的需求而出現(xiàn)的。本文將介紹新的 Q 復(fù)制架構(gòu)，預(yù)期它有什么樣的性能，以及哪些因素對性能有影響。此外，我們還將研究實(shí)驗(yàn)室測試時(shí)在 AIX? 和 z/OS? 平臺上所使用的例子。

注意：在閱讀本文之前，請先閱讀免責(zé)聲明。

簡介

隨著 WebSphere Information Integrator 8.2 的發(fā)布，IBM 提供了一個稱作隊(duì)列復(fù)制 或 Q 復(fù)制 的功能，使數(shù)據(jù)庫復(fù)制有了很大的進(jìn)步。這種新的復(fù)制架構(gòu)是隨著對高性能的需求而出現(xiàn)的，高性能是指高事務(wù)量和低延時(shí)，這里的延時(shí)是從在源數(shù)據(jù)庫上提交對源數(shù)據(jù)庫的更改到這些更改在目標(biāo)數(shù)據(jù)庫上完成提交這中間所經(jīng)歷的時(shí)間。

本文描述新的 Q 復(fù)制架構(gòu)，討論預(yù)期的性能水平，以及影響性能的一些因素，并給出在實(shí)驗(yàn)室測試時(shí)在 AIX 和 z/OS 平臺上所使用的例子。文中的信息對于那些有興趣使用 Q 復(fù)制，以及想知道 Q 復(fù)制對性能的影響的客戶來說會有所幫助。

為什么是新的架構(gòu)？

數(shù)據(jù)復(fù)制技術(shù)對于 IBM 或 DB2? 來說并不是什么新技術(shù)，早在十年前，該技術(shù)就第一次被引入到一個稱作 DataPropagator? Relational（DPropR）的產(chǎn)品當(dāng)中。從那以后，它的名稱和包有所變化，產(chǎn)品的廣度和功能有所擴(kuò)展，形成的一組產(chǎn)品也獲得了實(shí)實(shí)在在的商業(yè)上的成功。

現(xiàn)有的復(fù)制架構(gòu)是 SQL 復(fù)制，它依然與 Q 復(fù)制并駕齊驅(qū)，并且在多種客戶場景中很可能仍將是最佳解決方案。

對于 SQL 復(fù)制，數(shù)據(jù)庫的更改可以被捕捉，并臨時(shí)地存儲在稱作關(guān)系中間表（staging table）的關(guān)系表中。然后，從目標(biāo)系統(tǒng)上的一個客戶接口可以讀取這些關(guān)系中間表，并將它們應(yīng)用于目標(biāo)表。SQL Replication 與 DB2 for Linux?、DB2 for UNIX? 和 DB2 for Windows? 一起打包。在 z/OS 上，SQL Replication 以 DB2 Data Propagator 的形式提供給用戶，此外，它還包含在所有具有復(fù)制功能的 WebSphere Information Integrator 產(chǎn)品當(dāng)中。對于某些場景，例如那些以非 DB2 數(shù)據(jù)庫作為源或目標(biāo)的場景，SQL Replication 可能仍是目前的最佳選擇。

雖然 SQL Replication 有這些成功之處，但它也面臨一些技術(shù)上的挑戰(zhàn)，特別是當(dāng)客戶系統(tǒng)有所增長，性能需要日益提高的時(shí)候，挑戰(zhàn)尤為突出。而 Q Replication 就是為滿足這些性能需求而設(shè)計(jì)的，此外，它還增加了一些功能，提高了可管理性。

系統(tǒng)在規(guī)模上不斷增長，打破了吞吐率的限制。與此同時(shí)，客戶需要更多地實(shí)時(shí)訪問被復(fù)制的更改。這些實(shí)時(shí)更改操作常常需要朝多個方向流動，因此造成對同步兩個或更多系統(tǒng)的需要，以及當(dāng)這些系統(tǒng)并發(fā)地更改相同數(shù)據(jù)時(shí)解決沖突問題的需要。

客戶對于數(shù)據(jù)庫復(fù)制有很多方面的需要，數(shù)據(jù)庫復(fù)制這個過程常常需要謹(jǐn)慎地計(jì)劃和調(diào)度。下面是數(shù)據(jù)庫復(fù)制的一些傳統(tǒng)用法和未來的趨勢：

• 維護(hù)數(shù)據(jù)倉庫。這是目前復(fù)制功能最常見的用法之一。數(shù)據(jù)倉庫與操作性數(shù)據(jù)是分離的，這使得它們適合特定查詢，這不會影響生產(chǎn)應(yīng)用的性能。
• 業(yè)務(wù)連續(xù)性和災(zāi)難恢復(fù)。對于數(shù)據(jù)庫復(fù)制在這方面的需求可能是增長最快的需求。當(dāng)前，業(yè)界提供了各種各樣的帶有同步和異步復(fù)制技術(shù)的硬件和軟件實(shí)現(xiàn)，以解決業(yè)務(wù)連續(xù)性的問題。Q 復(fù)制是異步操作的，這意味著更改是在源數(shù)據(jù)庫操作提交之后才傳播出去的。如果因?yàn)榫嚯x較遠(yuǎn)，而使得主數(shù)據(jù)庫和備份數(shù)據(jù)庫不在一起，那么客戶常常會選擇異步方法。距離會增加傳輸延時(shí)，這使得同步方法對于高性能應(yīng)用程序來說不切實(shí)際。然而，同步復(fù)制意味著當(dāng)出現(xiàn)故障時(shí)，應(yīng)用程序可以容忍在過渡階段某些事務(wù)出現(xiàn)失敗。更小的延時(shí)意味著失敗的事務(wù)更少。與其他常用的硬件和軟件解決方案相比，Q 復(fù)制惟一的優(yōu)勢是備份數(shù)據(jù)庫可以連續(xù)處于活動狀態(tài)，這縮短了恢復(fù)時(shí)間。
• 用于負(fù)載均衡的數(shù)據(jù)分發(fā)。只要增加的復(fù)制成本相對于處理總量來說比較小，這種用法就有意義，例如，在某些應(yīng)用程序中，被修改的數(shù)據(jù)所占比例相對于檢索操作或應(yīng)用程序處理來說較小，這就屬于上述情況。
• 數(shù)據(jù)在地理上分布或數(shù)據(jù)的合并。使適當(dāng)?shù)膽?yīng)用程序“接近”終端用戶，或與其他相關(guān)數(shù)據(jù)駐扎在一起，可以提高性能。
• 支持使用多個數(shù)據(jù)庫的應(yīng)用程序。很多基于 Web 的應(yīng)用程序都是由多個數(shù)據(jù)庫構(gòu)成的。進(jìn)行在線交易的客戶可能在做一筆交易的時(shí)候使用其中某個數(shù)據(jù)庫，而通過另一個數(shù)據(jù)庫來驗(yàn)證交易的完成情況。交易數(shù)據(jù)庫可能是為一個遺留應(yīng)用程序而設(shè)計(jì)的，并且在考慮在線事務(wù)處理（online transaction processing,OLTP）的性能的情況下進(jìn)行組織，而交易歷史數(shù)據(jù)庫則考慮查詢性能，并駐留在不同的平臺上。因此，關(guān)鍵是使某些應(yīng)用程序的無縫操作能夠以近乎即時(shí)的速度，將更改過的數(shù)據(jù)從一個數(shù)據(jù)庫轉(zhuǎn)移到另一個數(shù)據(jù)庫。

回頁首

Q 復(fù)制的工作原理

從下面的圖 1 可以看到 Q 復(fù)制使用消息隊(duì)列在源數(shù)據(jù)庫和目標(biāo)數(shù)據(jù)庫之間傳遞事務(wù)數(shù)據(jù)更改的情況。這里所使用的隊(duì)列系統(tǒng)是 IBM 的一個旗艦消息傳遞產(chǎn)品，即 WebSphere MQ。WebSphere MQ 隨用于 Linux、UNIX 和 Windows 平臺的 WebSphere Information Integrator 一起打包，是 z/OS 環(huán)境的必備產(chǎn)品。

Q 復(fù)制有兩大基本組件，Q Capture 和 Q Apply。Q Capture 從數(shù)據(jù)庫恢復(fù)日志讀取數(shù)據(jù)，并用從提交的事務(wù)中選擇的數(shù)據(jù)更改構(gòu)造消息。然后，這些消息被寫入到一個或多個 MQ 隊(duì)列。這意味著這個過程對于源數(shù)據(jù)庫來說是異步的，只有在數(shù)據(jù)庫更改已經(jīng)提交到源數(shù)據(jù)庫時(shí)，那些消息才會發(fā)送到 MQ。每條邏輯消息代表一個完整的、已提交的數(shù)據(jù)庫事務(wù)。Q Apply 從消息隊(duì)列接收事務(wù)消息，并將每條消息作為一個事務(wù)單元應(yīng)用到目標(biāo)系統(tǒng)。

WebSphere MQ 的消息傳遞功能負(fù)責(zé)處理跨異構(gòu)系統(tǒng)和網(wǎng)絡(luò)協(xié)議傳遞消息的問題。在內(nèi)部，MQ 使用日志文件和數(shù)據(jù)文件，以類似于數(shù)據(jù)庫管理系統(tǒng)可能使用的方式，來管理消息的完整性和持久性。這些文件實(shí)質(zhì)上替代了 SQL 復(fù)制中由 DB2 處理的關(guān)系中間表和相關(guān)數(shù)據(jù)庫日志記錄功能。

如前所述，Q 復(fù)制允許有多個數(shù)據(jù)副本，該數(shù)據(jù)可能在多個站點(diǎn)發(fā)生改變，并且數(shù)據(jù)庫更改可以朝多個方向流動。這也意味著可能出現(xiàn)沖突，例如，當(dāng)多個站點(diǎn)更新相同的數(shù)據(jù)行時(shí)就會發(fā)生沖突。Q 復(fù)制為解決那些沖突提供了一種機(jī)制。

Q 訂閱定義源表與目標(biāo)表之間的關(guān)系，而且可以用單向、雙向或點(diǎn)對點(diǎn)這三種映射類型來定義。兩個服務(wù)器之間任意方向的復(fù)制的數(shù)據(jù)更改可以定義為雙向和點(diǎn)對點(diǎn)。雙向映射計(jì)算源數(shù)據(jù)庫和目標(biāo)數(shù)據(jù)庫上的數(shù)據(jù)值，從而提供了一種簡單的、低成本的沖突檢測和沖突解決方法。

點(diǎn)對點(diǎn)映射依靠添加到源應(yīng)用程序數(shù)據(jù)上的版本信息，提供了更健壯的沖突檢測和沖突解決。版本信息是在 Q 復(fù)制內(nèi)部在底層數(shù)據(jù)庫引擎中通過觸發(fā)器實(shí)現(xiàn)的。雖然從性能的角度來看，這種方法成本更高，但它允許兩個或更多可以并行地更新的數(shù)據(jù)庫的聚合（convergence）。本文的第 5 節(jié)比較了這幾種方法的性能。

回頁首

Q 復(fù)制與 SQL replication 相比的性能

下面的 圖 2 和 3 說明了在 AIX 和 z/OS 環(huán)境下 Q 復(fù)制與 SQL 相比的優(yōu)勢。這兩組使用同等工作負(fù)載和配置的測試都表明：Q 復(fù)制的吞吐率幾乎是 SQL 復(fù)制的三倍，而且在吞吐率的峰值處仍然維持著低得多的延遲。在這兩種配置中，Q 復(fù)制每秒可以復(fù)制 12,000 多行，而端到端的延遲低于 2 秒，在吞吐率較低的情況下，這種延遲常常低于 1 秒。在這兩次測試中使用的工作負(fù)載只包含 INSERT，以模擬適度復(fù)雜的事務(wù)，每個事務(wù)有 10 個 INSERT 操作，行大小為 212 字節(jié)。這種非常簡單的工作負(fù)載有它的用處，因?yàn)樗P(guān)注復(fù)制過程執(zhí)行的任務(wù)，而減少了測試中使用的硬件資源。例如，我們不需要像真正的應(yīng)用程序那樣為 SELECT 或應(yīng)用程序處理分配硬件資源。關(guān)于本文中使用的工作負(fù)載和配置的更多信息，請參閱“工作負(fù)載和配置”一節(jié)。

還應(yīng)注意，與 SQL 復(fù)制相比，Q 復(fù)制真正降低的延遲甚至要好于上面圖中顯示的那樣。Q 復(fù)制提供了非常好的性能監(jiān)控功能，包括對端對端延遲的真實(shí)度量，這個延遲是指從源上提交事務(wù)開始到事務(wù)在目標(biāo)上完成提交這之間的時(shí)間。對于 SQL 復(fù)制，這些監(jiān)控功能不存在，因此基準(zhǔn)應(yīng)用程序采用一種技術(shù)來度量平均行延遲。由于每個事務(wù)涉及多個行，SQL 復(fù)制的事務(wù)延遲實(shí)際上要高于圖中顯示的延遲。

對于 z/OS 和 AIX 這兩個測試，Q 復(fù)制測試表明復(fù)制吞吐率限制大約是每秒 12,000 行，當(dāng)吞吐率達(dá)到這個高度時(shí)，各種資源變得飽和，從而導(dǎo)致延遲增加。最為顯著的是，在達(dá)到飽和點(diǎn)之前，延遲一直很穩(wěn)定，我們的經(jīng)驗(yàn)是，大多數(shù)客戶的需求都低于這些限制。但為了保險(xiǎn)起見，建議從每秒復(fù)制的行數(shù)這一角度估計(jì)客戶的吞吐率需求，并確保在峰值情況下仍然低于限制。此外，這些限制并不是絕對的，要受工作負(fù)載和配置變化的影響，這在后面會討論到。

在圖 2 中可以看到，Q 復(fù)制在 z/OS 中有更高的吞吐率和更低的延遲....

...在 AIX 上也同樣如此。

Q 復(fù)制如何提高性能？

有很多因素可以幫助提高 Q 復(fù)制的性能，其中包括：

• 減少與關(guān)系中間表相關(guān)的日志記錄活動
• 減少對處理器的使用
• 增加 Q Apply 處理中的并行度

減少 DB2 日志記錄活動 對于 SQL 復(fù)制，數(shù)據(jù)庫更改是在源數(shù)據(jù)庫上的 DB2 關(guān)系中間表中捕捉的。這要求將附加的日志記錄寫入到 DB2 日志中。（如果捕捉所有數(shù)據(jù)庫更改，那么就會導(dǎo)致在中間關(guān)系表中寫入附加的用于插入和刪除的日志，從而潛在地使 DB2 日志的寫活動增加到原來的三倍。而對于 Q 復(fù)制，關(guān)系中間表是用 MQ 隊(duì)列捕捉的。數(shù)據(jù)文件和日志文件提供 MQ 隊(duì)列的底層存儲，只要這些文件放在與 DB2 日志不同的磁盤上，就可以減少日志文件的內(nèi)容。

減少對處理器的使用 由于多種原因，Q 復(fù)制在源服務(wù)器上比 SQL 復(fù)制要消耗更少的處理器周期，而在目標(biāo)服務(wù)器上消耗得要更多些，但總體上仍然是少一些。這是至關(guān)重要的，因?yàn)樵捶?wù)器最可能運(yùn)行“生產(chǎn)”應(yīng)用程序，在那上面的處理器周期是比較珍貴的。

下面的圖 4 展示了在 z/OS 上 SQL 復(fù)制和 Q 復(fù)制對處理器的使用情況的比較。這個圖給出了源系統(tǒng)和目標(biāo)系統(tǒng)上處理器成本的兩個度量：每個被復(fù)制的行占用的微秒數(shù)，以及每一千個被復(fù)制的行每秒所需的 MIPS(1) (2)。您可以使用這兩個度量來理解不同復(fù)制方法在處理器成本方面的不同之處，以及復(fù)制的粗略的“能力規(guī)劃（capacity planning）”估計(jì)。

這些測試試圖用大致相等但不相同的吞吐量來比較這兩個度量點(diǎn)。在所有情況下，復(fù)制都可以滿足工作負(fù)載的需求，并且延遲要小于 5 秒。

圖 4 說明了 Q 復(fù)制所減少的 CPU 消耗：

• Q capture 對 CPU 的使用減少 2-3 倍。
• Q capture 對 CPU 的使用大約每行 70-80 微秒。
• 在目標(biāo)上對 CPU 的使用要稍微多一些（隊(duì)列管理）。

下面是從這些測試中觀察到的一些方面：

• 將 Q 復(fù)制與 SQL 復(fù)制相比較，在源服務(wù)器上每個被復(fù)制的行所需的處理器成本減少了大約三分之二。Q Capture 成本大約是每行 70-80 微秒，每一千個被復(fù)制的行每秒只需不超過 20 的 MIPS。
• 將 Q 復(fù)制與 SQL 復(fù)制相比較，在目標(biāo)系統(tǒng)上處理器成本有所增加，其原因是，某些內(nèi)務(wù)功能，例如“修剪（pruning）”消息隊(duì)列，現(xiàn)在在目標(biāo)系統(tǒng)上大量地執(zhí)行。然而，在使用 Q 復(fù)制時(shí)，在源系統(tǒng)和目標(biāo)系統(tǒng)上的總體成本通常仍然會有所減少。

增加 Q Apply 處理中的并行度 Q Apply 采用高度的并行性，這是支撐復(fù)制目標(biāo)上源應(yīng)用程序的吞吐率需求的關(guān)鍵。如果一個源應(yīng)用程序采用高度的并行性來取得高吞吐率，那么 Q Apply 組件可以使用并行來跟上步伐。

如下面的圖 5 所示，對于每個傳入的接收隊(duì)列，Q Apply 啟動一個瀏覽器（可以將這個過程看作是“瀏覽隊(duì)列”）。Q Apply 從該隊(duì)列讀取事務(wù)，檢查事務(wù)之間的依賴關(guān)系，并基于這種依賴分析通過并行的 Q Apply 代理應(yīng)用數(shù)據(jù)更改。一個Q Apply 程序可以處理多個消息隊(duì)列（每個隊(duì)列一個瀏覽器），每個瀏覽器可以啟動多個代理。Q Apply 代理可以并行地應(yīng)用事務(wù)，以跟上發(fā)起事務(wù)的源應(yīng)用程序的并行度，從而大大增加復(fù)制吞吐率。

理論上，SQL 復(fù)制可以通過啟動 SQL Apply 程序的多個實(shí)例取得一定程度的并行性，但這需要管理員將表劃分到適當(dāng)?shù)慕M中，并平衡這些組之間的工作負(fù)載。此外，它不能像 Q 復(fù)制那樣允許在一個很活躍的表內(nèi)使用并行。

記住，即使只用一個消息隊(duì)列和一個瀏覽器，Q 也可以使用多個代理（默認(rèn)情況下每個瀏覽器 16 個代理），而不需要管理員做額外的工作。Q Apply 可以自動判斷事務(wù)之間的依賴關(guān)系，因此可以按適當(dāng)?shù)捻樞驊?yīng)用數(shù)據(jù)更改。管理員可以定義附加的隊(duì)列，但這需要格外小心，因?yàn)闆]有事務(wù)可以跨消息隊(duì)列修改表。而對于完全獨(dú)立的應(yīng)用程序來說，這樣做也許是合適的。

下面的圖 6 說明了增加 Q Apply 代理和瀏覽器數(shù)量的影響。在這個測試中，我們使用“預(yù)先裝載”的消息隊(duì)列測試 Q Apply，以排除 Q Capture 方面的任何約束。此外，在 z/OS LPAR(3) 上使用了 6 個處理器。您可以看到，增加代理的數(shù)量可以大大提高吞吐率，增加瀏覽器也可以得到一定的好處。使用一個消息隊(duì)列和默認(rèn)的 16 個代理對于大多數(shù)應(yīng)用程序來說通常已經(jīng)足夠了，在這里，最大工作負(fù)載是每秒 15,000 個事務(wù)（這確實(shí)是一個相當(dāng)大的工作負(fù)載）。

回頁首

雙向和點(diǎn)對點(diǎn)映射對性能的影響

下面的圖 7 比較了不同復(fù)制方案的吞吐率：沒有復(fù)制的 INSERT 工作負(fù)載、單向映射、雙向映射和點(diǎn)對點(diǎn)映射。在這些測試中使用的工作負(fù)載由 8 個并發(fā)的執(zhí)行 INSERT 操作的任務(wù)組成，事務(wù)之間有短暫的應(yīng)用程序延遲(4)。然而，在雙向映射和點(diǎn)對點(diǎn)映射的測試中，相同的工作負(fù)載要在兩個系統(tǒng)上運(yùn)行，這使得總工作負(fù)載翻了一倍。這些工作負(fù)載還要在不同的數(shù)據(jù)上執(zhí)行，以避免為解決沖突問題而導(dǎo)致的成本。在實(shí)際情況中，我們期望客戶設(shè)計(jì)自己的應(yīng)用程序來盡可能避免沖突，減少對性能的影響。

圖 8 采用與圖 4 相同的格式，它展示了每行所需的微秒數(shù)以及每一千個被復(fù)制的行每秒所需的 MIPS 這兩方面的處理器成本。

下面是從這兩個圖中觀察到的一些方面：

• 如果將雙向測試與單向測試相比較，應(yīng)該注意到，當(dāng)我們在第二個系統(tǒng)上運(yùn)行一個克隆的應(yīng)用程序時(shí)，總吞吐率幾乎增加了一倍。記住，每個系統(tǒng)都在運(yùn)行它自己的基本工作負(fù)載，捕捉那些更改，并將更改應(yīng)用到其他系統(tǒng)。雖然這幾乎使每個系統(tǒng)上對處理器的使用量翻了一倍，但每行的成本(5)只是增加了一點(diǎn)點(diǎn)（大約 12%）。對于雙向處理，需要一些附加工作來避免遞歸，確保 Q 復(fù)制不會重復(fù)捕捉 Q Apply 正在作出的更改。每個系統(tǒng)上的吞吐率稍微有些下降，這是因?yàn)樵黾恿藢μ幚砥鞯氖褂谩?
• 如果將點(diǎn)對點(diǎn)測試與雙向測試相比較，每個系統(tǒng)上的吞吐率同樣稍微有些下降（大約 17%），但每一行的 CPU 成本卻大大增多（70%）。這主要是通過數(shù)據(jù)庫觸發(fā)器維護(hù)版本信息時(shí)帶來的內(nèi)部成本所致。在我們的測試中，觸發(fā)器不僅造成額外的處理成本，而且還會造成一定的附加延遲，因?yàn)樗鼈兣c應(yīng)用程序是同步的。還應(yīng)注意，這里顯示的測試是在 z/OS 環(huán)境下的 DB2 中進(jìn)行的。與觸發(fā)器相關(guān)的成本要少于在 DB2/UDB 上的成本，這一點(diǎn)可以通過測量得知。還需記住的是，這種工作負(fù)載非?？鋸垼ㄖ挥?INSERT），因此對于大多數(shù)常見的同時(shí)也會讀取數(shù)據(jù)和處理數(shù)據(jù)的客戶工作負(fù)載來說，延遲被夸大了很多。此外，允許不同系統(tǒng)上的應(yīng)用程序并發(fā)地操作數(shù)據(jù)復(fù)制品可以為用戶全面提高生產(chǎn)率、數(shù)據(jù)可用性和吞吐率。

回頁首

這些結(jié)果是否適合其他工作負(fù)載和配置？

在以往進(jìn)行的所有性能測試當(dāng)中，隨著工作負(fù)載和配置的不同，得到的結(jié)果會有很大的變化。您可能想知道，那些因素對于您對 Q 復(fù)制的中意程度會有怎樣的影響。下面是關(guān)于這些因素的影響力的考慮：

吞吐率 在本文中，我們一直選擇以每秒復(fù)制的行數(shù)來度量復(fù)制。當(dāng)然還有其他一些度量指標(biāo)，例如每秒的事務(wù)數(shù)，但是由于事務(wù)的復(fù)雜性變化多端，我們避免使用那個度量指標(biāo)作為通用的吞吐率度量。然而，事務(wù)的復(fù)雜性的確會影響每秒復(fù)制的行數(shù)。如前所述，大多數(shù)這方面的測試都使用在某些方面走極端（只有 INSERT），但在其他方面較為合理的工作負(fù)載：每個事務(wù)涉及 10 行，每個行 212 字節(jié)，并且共有 14 列。

圖 9 表明，改變這些參數(shù)將影響吞吐率（每秒的行數(shù)）。這個圖展示了當(dāng)每個事務(wù)的行數(shù)變化時(shí)（從 2 行/每個事務(wù)到至多 20 行/每個事務(wù)）取得的吞吐率，以及當(dāng)行的規(guī)模變化時(shí)（從 192 字節(jié)到 2K 字節(jié)）取得的吞吐率。從這個圖中可以看出，當(dāng)每個事務(wù)的行數(shù)增加時(shí)，每秒復(fù)制的行數(shù)也隨之增加。其原因是，復(fù)制需要開銷來處理每個行，另外還要開銷來處理每個事務(wù)。每秒有更多的事務(wù)意味著提交點(diǎn)更少了，因此開銷也就更小了。同樣，復(fù)制更多的數(shù)據(jù)（更大的行規(guī)模）會造成更大的工作量，并會減少每秒復(fù)制的行數(shù)。

延遲 在本文中，我們展示了一些很好的性能結(jié)果，在某些情況下，延遲甚至低于 1 秒。雖然在通過精心優(yōu)化的環(huán)境中，可以獲得這樣的結(jié)果，但還有一些因素很可能會使復(fù)制的真正延遲大于前面得到的值。這些因素包括：

• 更復(fù)雜的事務(wù)（例如每個事務(wù)有成千個行）。我們將延遲（和 Q 復(fù)制的度量）定義為事務(wù)延遲，即從在源系統(tǒng)上提交一個數(shù)據(jù)庫事務(wù)到該事務(wù)在目標(biāo)系統(tǒng)上完成提交這之間的時(shí)間。這個過程只有在源事務(wù)被提交之后才可以開始。非常大的事務(wù)會有更多的工作量，需要更長的時(shí)間來處理。
• 更大的行規(guī)模。
• UPDATE 事務(wù)。與 INSERT 相比，數(shù)據(jù)庫管理系統(tǒng)必須對 UPDATE 做更多的工作，例如檢索相關(guān)的行。
• 更遠(yuǎn)的網(wǎng)絡(luò)距離（廣域網(wǎng)）(6)。
• 數(shù)據(jù)共享。Q replicaiton 必須檢索和處理多個日志文件。

有關(guān)這些監(jiān)控功能的更多信息，以及其他性能調(diào)優(yōu)方面的信息，請參閱在后面參考資料一節(jié)中列出的資料。

當(dāng)然，有很多因素可能影響性能預(yù)期。結(jié)果在很大程度上取決于工作負(fù)載和配置的變化。雖然次秒級（sub-second）的延遲是可能達(dá)到的，但也無法保證。根據(jù)現(xiàn)今技術(shù)的標(biāo)準(zhǔn)，低于 5 秒的復(fù)制延遲仍然可以看作是突出情況，并且在大多數(shù)常見的 Q 復(fù)制場景中都是可以達(dá)到的。

回頁首

工作負(fù)載和配置

本文中給出的測試是由硅谷實(shí)驗(yàn)室 WebSphere Information Integration 的性能分析小組在 Q 復(fù)制的產(chǎn)品開發(fā)期間進(jìn)行的。有些測試是在采用尚未普遍可用的產(chǎn)品代碼級的情況下進(jìn)行的。

測試人員有意地使工作負(fù)載對 Q 復(fù)制施加盡可能大的壓力，同時(shí)減少硬件資源。因此，大多數(shù)測試只包含數(shù)據(jù)庫 INSERT。（由于現(xiàn)實(shí)情況下工作負(fù)載同時(shí)還會包含應(yīng)用程序處理和 SELECT，因此，用于這種 INSERT 工作負(fù)載的復(fù)制部分所消耗的資源可能遠(yuǎn)遠(yuǎn)多于客戶預(yù)計(jì)在類似系統(tǒng)上需要消耗的資源。）

對于 z/OS 測試，配置由下面各部分組成：

• 系統(tǒng)：一個 2064-216 z900 大型主機(jī)的兩個 LPAR。除非特別標(biāo)明，每個 LPAR 由 4 個處理器組成，并有 8 GB 的內(nèi)存。每個處理器大約相當(dāng)于一個 200MIP 的機(jī)器（總共 800 MIP）。
• 軟件：
  
  • DB2 for z/OS V7
  • MQ 5.3.1
    這些測試是在使用一個分成兩個 LPAR 的 2064-216 大型主機(jī)的情況下進(jìn)行的，其中每個 LPAR 使用 4 個處理器。
  • 網(wǎng)絡(luò)：LPAR 之間采用 1 Gb OSA 的網(wǎng)卡（以太網(wǎng)）。
  • 磁盤：Enterprise Storage Server Model 800。

對于 AIX 測試，配置由以下部分組成：

• 系統(tǒng)：一個 IBM pSeries model p690 的兩個 LPAR。每個 LPAR 由 8 個處理器、8GB 的內(nèi)存組成。
• 網(wǎng)卡：10/100 Mbit Ethernet。
• 軟件：AIX 5.2，MQ 5.3，DB2 V8.2。
• 磁盤：帶有快速寫緩存的 SSA 磁盤。

回頁首

性能監(jiān)控和性能調(diào)優(yōu)

雖然對于一個產(chǎn)品來說，取得良好的性能十分重要，但對于一個分析師而言，能夠?qū)π阅苓M(jìn)行監(jiān)控同樣具有重要意義。Q 復(fù)制提供了一些有用的功能，這些功能目前在 SQL 復(fù)制中是沒有的。也許最關(guān)鍵的是，現(xiàn)在可以測量 Q 復(fù)制取得的端到端事務(wù)的延遲。Replication Center 提供了對 Q Capture 和 Q Apply 的報(bào)告，其中包括以下度量指標(biāo)：

• 復(fù)制吞吐率。
• 復(fù)制延遲。這包括對端到端總延遲的度量，以及各個部分的延遲的度量。
• 內(nèi)存使用情況。
• 其他異常情況。

此外，性能統(tǒng)計(jì)信息是在監(jiān)控表（CAPMON、CAPQMON 和 APPLYMON）中維護(hù)的，其他監(jiān)控軟件可以查詢這些表。

在參考資料一節(jié)中可以找到有關(guān)這些監(jiān)控功能的更多信息，以及大量其他性能調(diào)優(yōu)方面的信息。

回頁首

結(jié)束語

我們相信，Q 復(fù)制使數(shù)據(jù)庫復(fù)制技術(shù)有了顯著的進(jìn)步，某些方面要強(qiáng)于 SQL 復(fù)制。在一個測試環(huán)境中，我們發(fā)現(xiàn)：

• 與 SQL 復(fù)制相比，復(fù)制吞吐率提高到了三倍，并且復(fù)制延遲也更好。
• Q 復(fù)制達(dá)到了每秒復(fù)制超過 12,000 行這樣的吞吐率，同時(shí)還能保證延遲持續(xù)低于 5 秒，并且在很多情況下低于 1 秒。
• Q 復(fù)制所需的總處理器周期變得更少，并且在源服務(wù)器上大大節(jié)省了處理器周期。

這些性能上的提高，以及其他功能上的增強(qiáng)，使您可以更好地利用數(shù)據(jù)庫復(fù)制來滿足您的業(yè)務(wù)需要。

回頁首

致謝

Q 復(fù)制開發(fā)和性能小組的很多成員都為本文中的材料作出了貢獻(xiàn)，他們是 John Aschoff、Nhut Bui、Ying Chang、Nguyen Dao 和 Beth Hamel。如果您對于本文有什么疑問和評論，可以發(fā)送郵件給 John Aschoff（aschoffj@us.ibm.com）。

回頁首

腳注

(1) MIPS = Million Instructions per Second（每秒的百萬指令數(shù)），這是用于評價(jià)大型主機(jī)處理器的相對速度的粗略方法。在這些實(shí)驗(yàn)中用到的 4 個處理器中，每個處理器的速度大約是 200 MIPS。MIPS 是對相對速度的非常粗略的度量方法。

(2) 這里用于計(jì)算每行所需微秒數(shù)的技術(shù)，以觀察到的每行所需的總處理器時(shí)間在組成該系統(tǒng)的 4 個處理器上分?jǐn)偟玫降臅r(shí)間為依據(jù)。該技術(shù)的優(yōu)點(diǎn)在于，它可以捕捉所有花費(fèi)的時(shí)間，但缺點(diǎn)是當(dāng)對處理器的使用量比較少時(shí)，由于“低使用量的影響”，它可能會有些夸張。在 Q 捕獲方面，每行被扣除掉了 100 微秒，因?yàn)檫@是在沒有復(fù)制的純 INSERT 工作負(fù)載的情況下觀察到的成本。所需的 MIPS 數(shù)嚴(yán)格地以觀察這種 200 MIPS 處理器得到的一組結(jié)果為依據(jù)。

(3) 本文中大多數(shù)其他的 z/OS 測試都使用 4-處理器的 LPAR。

(4) 這種工作負(fù)載配置不是為發(fā)現(xiàn)最大吞吐率而設(shè)計(jì)的，而是為了可以通過相同的工作負(fù)載需求來比較各種不同的方案。結(jié)果，我們有意地在事務(wù)之間引入了一個較短的延遲（9 微秒）。

(5) 在計(jì)算每行的成本時(shí)，我們將 CPU 成本除以每個系統(tǒng)上捕捉到的并被應(yīng)用的總行數(shù)。

(6) 光和電也只能那么快！

回頁首

免責(zé)聲明

本文包含的信息是在“現(xiàn)狀”的基礎(chǔ)上提供的，沒有經(jīng)過任何形式的 IBM 測試。該信息的使用或這些技術(shù)的實(shí)現(xiàn)是用戶的責(zé)任，可以依靠用戶的能力進(jìn)行評估，并將其集成到客戶特有的操作環(huán)境中。雖然 IBM 已經(jīng)在特定情況下檢查了每一項(xiàng)的準(zhǔn)確性，但不保證在其他地方將獲得相同或相似的結(jié)果。嘗試調(diào)整這些技術(shù)以適應(yīng)自己環(huán)境的用戶必須自擔(dān)風(fēng)險(xiǎn)。

本文顯示的性能信息數(shù)據(jù)基于一個測試環(huán)境中所獲得的結(jié)果。受各種因素的影響，各項(xiàng)結(jié)果和性能可能有所變化。有關(guān)本文中使用的工作負(fù)載和配置的更多信息，可以在“工作負(fù)載和配置”一節(jié)中找到。

參考資料

• 您可以參閱本文在 developerWorks 全球站點(diǎn)上的 英文原文 。
  
  
• DB2 Information Integrator Tuning for Replication and Event Publishing Performance (SC18-9289-00)
  
  
• DB2 Information Integrator Replication and Event Publishing Guide and Reference (SC18-7568-00)
  
  
• DB2 Information Integrator Introduction to Replication and Event Publishing (GC18-7567-00)
  
  
• 要了解關(guān)于 WebSphere Information Integrator 的更多信息，請?jiān)L問 developerWorks 上的 Websphere Information Integrator 頁面。您可以從中發(fā)現(xiàn)技術(shù)性文章、各種文檔和下載的鏈接以及更多內(nèi)容。
  

關(guān)于作者

		John Aschoff 目前是 WebSphere Information Integration Performance 部門的經(jīng)理。他在 IBM 工作了 34 年，在存儲和數(shù)據(jù)管理領(lǐng)域的性能方面有 20 多年的經(jīng)驗(yàn)。他發(fā)表了大量性能方面的文章，包括為 Computer Measurement Group 發(fā)表的一些文章。他和妻子 Marcy 居住在 Monterey Bay 地區(qū)，家里還有一條喚作 Dante 的德國牧羊狗