簡介
最近您可能經常聽說雙核心處理器，以及最流行的數據庫環境中對這種處理器的許可方式。Microsoft 在 2004 年末宣稱，對於一個雙核心芯片，他們只按一個處理器收費。從那以後，對於供應商應該如何順應硬件技術的變更而為他們的軟件計價這個問題，人們紛紛作出辯論、預測和討論。就在本文撰寫之前，Oracle 宣稱，對於任何服務器上的軟件，他們將按每個核心來計價，擺出與市場強者 Microsoft 針鋒相對的姿態。
自從 Microsoft 宣布了對雙核心處理器的計價方式之後，雖然當時在任何雙核心架構服務器上都還沒有可用的 Microsoft 軟件，但還是有越來越多的客戶問到關於雙核心服務器和 IBM DB2 Universal Database for Linux™、UNIX® 及 Windows® (DB2 UDB) 的許可問題。除此之外，他們還問到在利用用於服務器整合的硬件技術時，有關隨需添加（sub-capacity）的計價問題。
不同的供應商使用不同的或相似的術語來表示影響許可的不同事物，從而造成更多的費解。例如，對於某些供應商而言，一個核心就是一個處理器，而另一些供應商則認為處理器就是插在一個插座中的芯片，當然還有其他的說法。為硬件服務器增加了創建靜態和動態分區的能力。 （在本文中我將它們稱作邏輯分區，或者 LPAR，但是不同的硬件供應商可能有不同的叫法），您可能還有更多的問題要問。
在本文中，我將討論 DB2 UDB 在雙核心環境中的許可授權考慮，並深入闡述這種技術及其相關術語，使您更好地從總體上理解該領域。在本文的結尾處，我還討論了隨需添加的計價問題，這在如今的服務器整合領域是一個熱門話題。
IBM 對核心的定義
很簡單， 核心（core） 就是執行計算機命令的電路部件。而 芯片（chip） 是將核心封裝起來的一塊硅片。雙核心是指一種芯片設計和制造能力，它可以使兩個處理器核心共存於一個物理芯片中（有人甚至將其稱為 'SMP 芯片'）。而對於目前常見的工作站（很可能您桌上放著的那台機器就是），更多的情況是一個芯片中只有一個核心。
下面的圖 1 展示了單核架構：
圖 1. 單核處理器
我們可以放心地假設，在當今市場上，從許可授權的角度來看，每個人都將上圖看作一個處理器。而在單核架構上又實現了一些性能提升技術，可以幫助提升實際處理速度或吞吐率。
例如，Intel 的超線程（hyper-threading）就是這樣一種技術，對於一些關鍵工作負載，它最多可以將性能提升 30%。在繼續我們的話題之前，首先來看一下術語：
線程 是指令序列。處理器中的線程是一種設計技術，允許兩組或多組指令同時執行，從而提高性能。
超線程 是以一種高效的方式實際調度不同線程執行計劃的能力。
DB2 UDB 支持超線程，但由於該項技術並沒有成倍地提升 DB2 UDB 服務器的總體性能，所以對此沒有額外收費。（基於同樣的原因，對於任何數據庫服務器都不會為此收取額外費用。當然，我相信某個人在某種服務器上用某種工作負載也許可以證明我錯了。）其他基於性能的芯片增強，例如 SMT，在 DB2 UDB 同樣也受支持，並且不收取額外費用。
在 2000 年 10 月，IBM 引入了一種新的高可伸縮性微處理器，即 Power® 芯片（起初是 Power4 系列，後來被 Power5 代替，之後還有 Power6 計劃，等等）。這些 Power 芯片實現了單芯片（插入到主板上的部件）上的雙核心（所以能夠讓兩個獨立的電路單元執行計算指令）。實際上，如今的 Power5 架構擁有超過 50 項產業標准和應用 基准記錄，涵蓋廣泛的技術和商業工作負載。不久之後，其他硬件供應商也紛紛效仿，例如 HP 和 Sun。最近，Intel 和 AMD 也已經將這項技術引入到他們的芯片家族。
雙核心芯片的優點是，它們可用於提高性能，減少電源要求，同時還減少其單核心同類產品由於越來越高的時鐘速度而產生的熱量。雙核心芯片同時也更為緊湊，這意味著它們的物理需求更能符合其單核同宗芯片的生產線，因為他們具有相同的構成因子。雙核心芯片還顯得更加適合於環境更加友好，它們的電力和冷卻（HVAC）需求更低。此外，緩存內存的接近也能產生性能優勢。
就性能而言，專家已經叫停了摩爾定律（預測計算機芯片的處理能力大約每 18 個月翻一番），這導致業界對雙核心處理器的廣泛關注。最近，像 Intel 和 AMD 之類的商業芯片制造商宣布了他們的 2005 產品，將推出他們的第一代雙核心芯片，以幫助通過近幾代中增加的芯片處理能力贏得先機。
下面的圖 2 展示了雙核心架構：
圖 2. 雙核心處理器
實際上並沒有很多的不同之處。插入到主板插座上的硅片仍然是一片。然而，如前所述，在這種架構中，有兩塊電路用於執行計算指令。
DB2 UDB 如何針對雙核心芯片進行許可授權？
隨著雙核心技術的出現，圍繞處理器這個術語有很多混淆的地方。例如，IBM Power5 服務器（和它們的基准）在官方是按核心數量報告的。所以，16 路 Power5 SMP 服務器有 16 個核心，但是實際上只有 8 個插座用於插入物理處理器。而上次經過我的查證，Sun 將雙核心芯片稱作可以運行兩個線程的一個處理器。帶有 4 個雙核心處理器的 Sun 機器被稱作 4 路 SMP 機器。相反，IBM 將此稱作 8 路機器（因為它有 4 個雙核心處理器，相對於 8 個核心）。所以，Sun 所謂的 4 路機器與 IBM 所謂的 4 路機器是不同的 - 千萬要小心。此外，HP 將一個雙核心芯片稱作一個處理器。所以，8 核 HP 系統被稱作 4 路 SMP 服務器，更令人費解的是，處理器和雙核心芯片這兩個術語在他們的文檔中是可以交換使用的。
SAP 和 TPC 基准不要求硬件供應商在公布他們的結果時列出所使用的核心數量。然而，SPEC 基准規則（例如 SPECfp_rate 2000）要求按處理器核心數量表述結果。例如，Sun Fire V40z SPECfp_rate 在 4 路機器上的結果被列在 8 路結果的類別之下。也許這就是為什麼 IBM 決定按核心而不是物理處理器來標識服務器的 SMP 屬性的一個原因。建議在比較解決方案的性能結果時查看處理器核心。
通常，對於 IBM Software Group 而言，一個 處理器 是一台計算設備中用於解釋和執行指令的一個功能部件。對於其他各方而言，在多核技術下，每個核心被認為是一個處理器。例如，在一個雙核心 Power5 芯片中，如果按每處理器的方式進行軟件許可授權，那麼要計為兩個處理器（不要因為某些地方發生了變化就拋開本文，稍後有更多討論）。
如今，對於基於 Power5 的系統（以及其他具有雙核心架構的非 IBM 高端處理器 - 基本上，只要不是 Intel/AMD 的 OpenPower 710/720 服務器或 x86 架構的服務器都屬於此類），IBM 將一個核心定義為一個處理器。這樣看起來比較合理，因為不但每個核心都能獨立執行軟件，而且標准性能測試也顯示，在這些雙核心架構下，處理能力大約是以前的兩倍甚至兩倍以上。
例如，考慮 IBM 在 2004 年 7 月（這個時間到本文撰寫之際大約是一年，基准領域的一個生命期）宣布的 DB2 UDB TPC-C 16 路結果。用於該基准的 Power5 雙核心架構產生了令人印象深刻的結果。特別地，這個 DB2 UDB 基准在一個 16 路 IBM eServer p5 570 服務器上運行，取得了 809,144 tpmC - 這超出了那些擁有多達 4 倍以上的經過許可授權的 CPU 的系統上的結果。
例如， 當前 SQL Server's best overall TPC-C result 在一個64 路 SMP 服務器上運行，取得 786,646 tpmC 的結果；而 DB2 僅僅用了四分之一的處理器就勝過了這個結果。（記住，在 Power5 雙核心架構下，每個核心都被認為是一個處理器，而不是每個插座對應一個處理器。IBM 16 路結果引用核心數量，所以實際上機器上有 8 個插座。有些供應商會將此稱作 8 路雙核心系統，而 IBM eServer 稱之為 16 路服務器，這是由於他們對處理器這個術語的不同解釋而導致的。）
這只是前沿雙核心服務器性能特征的一個例子。在 2004 年 11 月，IBM 發布了 64-way TPC-C result，其性能比 SQL Server 64-way result 高出 400%，比使用 64 個處理器的 Oracle's top TPC-C result with the Real Application Clusters (RAC) technology 高出 270%，比使用 64 個處理器的 Oracle's best 64-way SMP TPC-C 高出 318%。所有這些競爭結果都是在單核架構上取得的。
這次討論的目的不是要吹噓 DB2 UDB 的性能（我承認有那麼一點），而是說明一個設計良好的雙核心架構的潛在威力。
由於上面所說的原因，IBM Software Group 對基於 Power5 和其他非 x86 或 OpenPower 710/720 架構的機器按每個核心計價。如果一個 Power5 服務器有 8 個物理處理器（不過它不會被稱作 8 路機器），那麼就必須購買 16 個 DB2 許可（因為每個處理器有兩個核心）。記住，不同的供應商有不同的術語框架。我盡力說明 IBM 如何對基於處理器的產品進行許可授權，以使這些術語能關聯起來。由於 eServer 機器出售時可能不是用處理器這個術語，這裡為了簡單起見我作了映射。
在前面提到的 16 路 TPC-C 結果中，當和 Microsoft SQL Server 作比較時，即使少購買 48 個 CPU 的 DB2 UDB 數據庫軟件許可，也仍可以取得更好的性能（在此服務器上，8 處理器 x 2 = 16 個許可）。這裡不僅少了 48 個 CPU 的軟件許可，而且需要的維護也更少，同時潛在的硬件成本也更低。
雖然這不是 IBM 的官方說法，但據說現有基於 Power 的芯片，以及將來基於任何具有高雙核心對單核心性能比率的架構的芯片，都將征收兩個許可的費用。很簡單，對於這些強大的處理器家族，IBM 繼續按核心授權許可，而不是按芯片授權許可。
在 2004 年末，Microsoft 聲明，它將把一個處理器定義為一個芯片（插入到計算機主板中的一個硅片） -- 不管芯片上的核心數量。同是數據庫服務器，但不同於 IBM 和 Oracle 對於這種架構的計價策略。對於這份聲明有大量的媒體報道，但實際上沒有任何服務器能提供具有雙核心架構的服務器來運行 Microsoft SQL Server。
就在這段時間，IBM 有很多機會為新的基於 x86 Intel 和 AMD 雙核心架構建立性能基准，但是沒有發現它們各自的第一代技術產生了與 Power5 的雙核心架構同類的結果（很多公共的基准也將認為這句話是對的）。預測的雙核心對單核性能比率顯得和一般兩代之間的性能提升一樣，代表用於進一步性能增強（不應該受到計算能力需求和產生熱量限制的約束）的極好的架構變換。
在 2005 年 4 月 21 日，IBM 聲明，在 x86 架構和 OpenPower 710/720 平台上，對於一個雙核心芯片上的兩個核心，只需要一個 IBM 中間件軟件處理器許可。
IBM 作出這份聲明是因為我們用於這些雙核心系統的內部基准與其他系統的核心對性能比率不相符。仔細考慮這份聲明就可以發現，它和過去的計價策略是一致的。（像超線程技術之類的增強，它們永遠不會產生雙倍或接近雙倍的性能優勢，雖然據稱這些技術能使一個服務器有如此表現，它們也不會增加客戶的每處理成本。）
回到我們的雙核心與單核心比較的例子中來。如果您有一個使用雙核心 AMD 芯片的 8 路 SMP 服務器，那麼只需購買 8 個 DB2 UDB 處理器許可。如果同一種機器是在雙核心 Power5 服務器上，那麼就需要購買 16 DB2 UDB 個許可。同樣，這樣的計價似乎又維護了許可的價值。8 路 Power5 雙核心 服務器（記住，這是 8 個核心，所以有 4 個插座）上的 DB2 UDB 取得的結果是 429,900 tpmC。這超出了頂級 SQL Server 在單核上的 8 路結果 240%，後者只取得 175,366 tpmC 的結果。
總之，按每處理器計價的 IBM 軟件產品要求用戶具有服務器上每個可用處理器的授權（按 IBM 的定義）。這是 IBM 自引入處理器計價方式以來一貫使用的方法。從 2005 年 4 月 21 日起，對於基於 x86 的 AMD/Intel 雙核心處理器，基於來自 IBM 的 OpenPower 710/720 服務器中的處理器，計價方式有所不同，雖然 IBM 將每個核心定義為一個處理器，但您只需為這些機器上的每個物理處理器購買許可。
IBM 關於雙核心架構及其優點的聲明
最近，雙核心架構按相對性能的分類法有助於支持軟件相對於所選硬件技術獲得的價值關系。實際上，這份聲明可以幫助您在日益前進的硬件技術面前維護價值，並讓您和一個類實用程序的計算模型聯系起來（可以運行多少事務）。
雖然有市場上的極度興奮和 FUD（恐懼、不確定和懷疑），DB2 UDB （以及相關 IBM 中間件）仍保持比當今市場更具競爭性的計價。
什麼是隨需添加技術？
面對硬件供應商同時提供硬件層靜態和動態分區，從而創建虛擬服務器的新能力，隨需添加計價是軟件公司必須解決的挑戰。例如，想像有一個 4 路服務器，並將其分割成 2 個 2 路服務器，如下面的圖 3 所示：
圖 3. 隨需添加技術
在上面的圖中，您可以將數據庫服務器安裝在藍色分區（容納處理器 1 和 2），而將應用程序服務器軟件安裝在紅色分區（容納處理器 3 和 4）。每個分區本身就像一台機器：它有自己的處理器、內存等等。在 IBM，當它們是靜態的時，我們將它們稱作邏輯分區（Logical Partitions，LPAR）。所謂靜態的意思是，分配到每個分區上的資源不會隨著時間而改變。另一種形式的分區是動態邏輯分區（Dynamic Logical Partitions，DLPAR），這種分區技術可以靈活地根據業務需求或策略動態重新分配計算資源。從 DB2 UDB V8.1.2 開始，DB2 UDB 已經支持用於不同供應商的硬件分區策略的特性 - 包括動態分區策略。
LPAR 和 DLPAR 都允許用戶使用一台機器解決多系統需求。這可以用於提供如下優點：服務器整合、業務單元整合以及混合生產/測試環境。LPAR 長期被用於那些實現 zSerIEs® 技術的機器，但對於分布式領域還是新事物。
您應該清楚，LPAR 本身並不會顯著提升系統的可用性。然而，LPAR 可以用於彌補其他可用性策略。
由於每個分區被當作一個獨立的服務器，您可以用單個分區上的單個系統鏡像來運行單個環境。這樣可以提供更具性價比的解決方案，因為您可以分配資源到部門、數據庫服務器、集群等等。
顯然，隨需添加技術使客戶能夠在面臨技術變更時維持它們軟件的價值。由於成本更貼近實際的能力需求，所以當對應用的使用增加時，只需為額外的能力支付成本。這樣更易於試驗新的應用，更易於支持更小的工作負載。同時您也更容易優化 IT 環境和設計系統，以最大限度提高利用率，同時最小化軟件成本。IBM 是惟一在 IBM eServer p5 和 IBM eServer i5 服務器系統中支持這種高級服務器虛擬化功能的供應商（采用單獨處理器，將它們分成多個運行時環境 - 即使是在部分處理級別）。
考慮本文前面討論過的那些 Power5 服務器上的結果，可以想像一個開發環境，其中一個 4 路服務器被虛擬成 20 個服務器，用於開發、Q/A 等。
在隨需添加環境中如何對 DB2 進行許可授權
就在 IBM 宣布對 x86 和 OpenPower 硬件實行雙核心計價的同一天，IBM 正式宣布，對運行在 UNIX、i5/OS™ 或 Linux 上的 DB2 家族解決方案，如果它們在受支持的 IBM 和非 IBM 系統上創建的分區中運行，將 對部分 DB2 家族解決方案實行隨需添加的許可方式。
您將注意到，Windows 不屬於具有正式隨需添加計價方式的產品和平台之列。和其他系統不同，x86 和基於 Itanium 的系統專門依靠像 EMC 的 VMWare ESX 和 GSK 服務器或 Microsoft 的 Virtual Server 之類的虛擬分區技術。IBM 的意圖是，當這些技術具有對 IBM Tivoli® License Manager for IBM Software 產品（用於在這個程序下跟蹤使用情況 - 稍後會有更多介紹）的完全支持時，將來再支持這些系統。如果在此期間您對於 DB2 UDB 環境有這種許可考慮，請聯系 IBM 代表。
為了使客戶更易於跟蹤隨需添加的一致性情況，IBM 還宣布了一個版本的 IBM Tivoli License Manager (ITLM) for IBM Software，這是一個免費版的 ITLM。該版本完全與現有付費版本的 ITLM 兼容，但是只能用於在該程序下跟蹤 IBM 軟件解決方案。想要跟蹤非 IBM 軟件的客戶可以在一致性過程中換用付費版本。想使用隨需添加許可的客戶需要向 IBM 生成和提交關於隨需添加使用情況的季度報告。
從本文撰寫之際算起，正式支持隨需添加許可的 DB2 家族產品有：
DB2 UDB Enterprise Server Edition v8.2
DB2 UDB Data Warehouse Enterprise Edition v8.2
DB2 Data Links Manager v8.2
DB2 Net Search Extender v8.2
如果您使用其他 DB2 產品，並且想在隨需添加環境中調查對它們的使用，請與您的 IBM 代表聯系。
當在 LPAR 環境（在本文後面提供了受支持硬件平台的列表）中為具有受支持隨需添加硬件技術的受支持的 DB2 產品授權許可時，必須考慮在 ITLM 報告期間為 DB2 軟件使用的最大處理器數量。換句話說，您必須為將要使用的最大處理器數購買 DB2 許可。
如果您在使用虛擬引擎，那麼服從相同的原則。然而，您永遠不會為比在服務器上更多的處理器付費。例如，如果有一個 4 路服務器，並創建 20 個分區，每個分區上有一個 DB2 UDB 副本，那麼您只需購買 4 個 DB2 UDB ESE 許可。
有些技術允許將軟件執行分配到一組處理器上（有時候也叫做 processor pinning）。這不是硬件分區，所以不提供本文中列出的隨需添加許可的優點。實際上，對於其中大多數技術，軟件的執行可以發生在一組處理器上，但是當其他處理器閒置時，它將也在那裡執行指令。
下面的小節給出一些詳細的典型例子，演示隨需添加許可的使用和需要為之授權許可的處理器總數。簡而言之，這些例子不考慮處理器上核心的數量。
LPAR 隨需添加的例子
LPAR 提供靜態地隔離計算資源和在相同系統上運行相同或不同類型操作系統的能力。一個典型的例子可能包括一個 12 路服務器，該服務器使用 LPAR 技術創建 3 個虛擬服務器。圖 4 和圖 3 展示了 3 個 LPAR（紫色、淺綠色和粉紅色）以及分配在各個 LPAR 上的處理器（8、2 和 2）。在這個例子中，您將需要 4 個 DB2 UDB 許可（2 個用於 DB2 Enterprise Server Edition (ESE) on AIX®，兩個用於 DB2 ESE on Linux）。
圖 4. 使用隨需添加技術和 LPAR 的 SMP 機器的技術視圖
DLPAR 隨需添加例子
如前所述，DLPAR 提供實時響應業務需求變化的能力。當為軟件授權許可時，這顯然創造了一定的復雜性。
IBM eServer i5 和 eServer p5 系統都能夠運行 DLPAR。例如，考慮圖 5 中顯示的拓撲：
圖 5. 使用隨需添加技術和 DLPAR 的 SMP 機器的拓撲視圖
在這個例子中，您可以看到，分配給 DB2 UDB 的計算資源隨著業務需求或業務周期中的位置而變化。實際上，這個例子有適當的復雜性，處理器在不同操作系統之間動態分配。
為確定每個產品所需的隨需添加許可數量，在這個例子中，必須在三種可能的配置之間確定每個產品運行時所占用的最大處理器數量 。在這個例子中，運行 DB2 Enterprise Server Edition 的處理器數量隨著業務周期的位置而變化。在業務周期中分配給 DB2 的最大處理器數量出現在運行圖 5 底端模擬工作負載的時候。在此模式中，總共需要 6 個許可（4 個在 AIX 之下，2 個在 Linux 之下），因此在任何時候，即使其他時期分配給 DB2 軟件的計算資源更少一些，仍需要得到 DB2 軟件的 6 個許可 。如果有一個環境，您想在其中更緊密地將這些因素關聯起來，IBM 還提供了 On Off Capacity on Demand (OOCOD) 計價模型。
虛擬化隨需添加例子
這個例子展示在利用允許創建共享處理器池的 IBM eServer p5 和 IBM eServer i5 系統上可用的虛擬化能力時，如何計算許可數。在這種拓撲中，可以基於客戶建立的規則動態地分配共享池中的處理器。
在這個高級的隨需添加場景中，當您想弄清楚如何為 DB2 軟件授權許可時，必須清楚一些特定於硬件的術語。 capped 分區（如下面圖 6 所示）是對其可以使用的處理器數量有固定限制的一種分區。這個固定限制是由 Processing Value Unit (PrU) 度量標識的（也可以看作物理處理器同等物）。另一種度量叫做 Virtual Processor Value Unit (VP) ，表示（只用於 capped 分區）可共享的物理處理器數量，以得到 PrU 值。在 capped 分區中，需要根據該分區的 PrU 值來為軟件授權許可。
圖 6. 虛擬化例子
例如，capped 分區 E 有 PrU = 2 和 VP = 4。這意味著這個分區上的 DB2 工作負載將運行在 2 個處理器的同等物上，但是那兩個處理器被虛擬成在包含最多 4 個處理器的處理器池中的部分處理器上運行（例如，如果系統從池中的 4 個處理器借了 50% 的處理器能力，那麼在那個系統上的資源分配將是： 0.5 + 0.5 + 0.5 + 0.5 = 2.0）。在圖 6 中，您可以看到分區 E 是一個 capped 分區，來自包含 9 個處理器的一個共享池。由於分區 E 的 PrU 為 2，這意味著任何時候分區 E 都不能使用這個池中 2 個以上的處理器（不過這兩個處理器可以是至多 4 個處理器的組合）。在這個例子中，分區 E 需要 2 個 DB2 處理器許可。
相反， uncapped 分區在共享池中的額外處理能力出現時，可以利用這些額外處理能力，最大限度由 VP 度量指定。Uncapped 分區通常被預留給更高優先級的工作負載，當服務器的某些部分未充分使用時，這些工作負載可以從額外計算能力獲益。對於 uncapped 分區，PrU 單位是任何時候指派給分區的最新處理器數，而 VP 是分區將嘗試從池中獲得的最大處理器數。對於 uncapped 分區，VP 度量有點不同，因為假設 uncapped 分區將在處理器可用時使用全部處理器。換句話說，對於 capped 分區，VP 表示可以提供 PrU 度量定義的能力的處理器數量，在 uncapped 分區中，它的意思是分配給分區的最大物理處理器數量。在 uncapped 分區中，需要根據分區的 VP 值為軟件授權許可。
例如，在圖 6 中，分區 H 將有最少 1 個處理器分配給它，在處理器可用時，最多可以獲得 3 個處理器。在這個例子中，對於 DB2，您將需要 3 個 DB2 許可，因為 VP=3。記住，在 uncapped 分區中，VP=3 是通過全部處理器，而不是像在 capped 分區例子中的部分組件來獲得的。
現在讓我們總結一些圖 6 中的例子。您需要為 DB2 軟件對該服務器正確地授權多少個 DB2 許可？答案是 8。這和您的預期一樣嗎？如果不一樣，那麼考慮：
分區 B 的 1 個處理器
capped 分區 E 和 F 的 4 個處理器（(PrU E = 2) + (PrU F = 2) = 4），每個分區最多有兩個處理器的聚合計算能力（不過它們各自可以累加相當於共享池中最多 4 個處理器中的兩個處理器的能力。）
uncapped 分區 H 的 3 個處理器（VP=3），雖然 1 個處理器是它的計算能力底線（PrU=1），該分區將嘗試從處理器池獲得 3 個處理器的計算能力。
PrU 和 VP 限制是由客戶和 IBM 共同設置的。記住，客戶永遠不需要購買多於系統中處理器數量的許可數。 （這一斷言的一個推論是，共享池中所需的許可數上限為共享池中的處理器數。）
微分區隨需添加例子
最後這個例子展示當使用 IBM eServer p5 和 IBM eServer i5 系統上的微分區功能時，如何計算許可。微分區允許將單個處理器再分為處理器池中一個處理器的數個部分。圖 7 中的這個例子與圖 6 類似，因為計算所需許可的過程是一樣的。然而，在確定所需 DB2 許可數量時，需要理解和考慮微分區的優點。
圖 7. 微分區例子
簡單的經驗法則是，使用與圖 6 中用到的相同方式聚合所需許可，考慮 capped 和 uncapped 分區的細微差別，然後去掉小數部分，整數部分加一。
在講我們這個例子之前還要注意最後一件事。在 uncapped 分區中，處理器分配總是整數值。 換句話說，一個 uncapped 分區不可能用小數（比如 2.5）作為它的處理器分配（不管是底線還是目標 - 這就是為什麼在分區 G 和 H 只看到整合的原因）。
現在讓我們總結一下圖 7 中的例子。您需要為 DB2 軟件對該服務器正確地授權多少個 DB2 許可？答案是 7。這和您的預期一樣嗎？如果不一樣，那麼考慮：
分區 B 上的 1 個處理器
capped 分區 E 和 F 上的 3 個處理器（1.6 + 1.3 = 2.9 取整 = 3），兩個分區的最大聚合計算能力分別是 1.6 和 1.3（不過它們各自可以累加它們從共享池中最多 4 個處理器中分配到的處理能力）。
uncapped 分區 H 的 3 個處理器（VP=3），雖然其計算能力底線是 1 個處理器（PrU=1），但該分區將嘗試從處理器池獲得 3 個處理器的計算能力。
PrU 和 VP 限制是由客戶和 IBM 共同設置的。記住，客戶永遠不需要購買多於系統中處理器數量的許可數。
關於 ITLM for IBM Software 的更多細節
如前所述，IBM Tivoli License Manager for IBM Software 將被安裝，並由所有實現隨需添加許可的客戶運行。實際上，IBM 是第一個為客戶提供用於衡量軟件一致性情況的工具的供應商。客戶只需運行一個版本的 ITLM 服務器，但是如果部署有保證，則可以運行附加的副本。在注冊隨需添加解決方案之後，ITLM 將通過他們的部件登記號監視所有隨需添加許可的使用情況，並記錄每個月的高水位標記，這表示支持隨需添加的產品同時運行的最多副本數量。在隨後的季度中，客戶需要生成一個報告，檢查報告，然後將它以電子文檔格式提交給 IBM。如果使用級別在您的應有級別之內，那麼不需要做任何事情，您可以繼續操作，在下一個季度中提交接下來的使用報告。如果您的使用級別超出了應得級別，那麼 IBM 會為您生成一個報價，其中含有需要追加的許可費用。
受支持的分區技術
下表展示了正式支持如今 DB2 UDB 的隨需添加計價的硬件技術。如果您的硬件不受支持，請和您的 IBM 代表聯系。要了解最近受支持的硬件配置和支持隨需添加許可的 DB2 版本和產品，請訪問 IBM Passport Advantage 網站。
表 1. 用於隨需添加許可的受支持硬件配置
硬件 操作系統 分區技術 隨需添加資格 pSerIEs AIX 5.1 LPAR
AIX WLM
有沒有
AIX 5.2 LPARDLPAR
AIX WLM
有有
沒有
AIX 5.3 LPARDLPAR
AIX WLM
Virtualization Engine
有有
沒有
有
RHEL 3 u3 LPAR虛擬化引擎
有有
SUSE 8 LPAR 有 SUSE 9 LPARDLPAR
虛擬化引擎
有有
有
i5/OS LPARDLPAR
虛擬化引擎
有有
有
HP HP-UX 11i nPARvPAR
HP PRM
有沒有
沒有
有
Sun Solaris 8 動態系統域 有 Solaris 9 動態系統域SRM
有沒有
Solaris 10 動態系統域SRM
容器
沒有沒有
沒有
