DB2 Universal Database 在双核心处理器和随需添加处理器上的许可授权

核心提示：简介最近您可能经常听说双核心处理器，以及最流行的数据库环境中对这种处理器的许可方式，DB2 Universal Database 在双核心处理器和随需添加处理器上的许可授权，Microsoft 在 2004 年末宣称，对于一个双核心芯片，请和您的 IBM 代表联系，要了解最近受支持的硬件配置和支持随需添加许可的 DB2

简介

最近您可能经常听说双核心处理器，以及最流行的数据库环境中对这种处理器的许可方式。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	LPAR DLPAR AIX WLM	有 有 没有
	AIX 5.3	LPAR DLPAR AIX WLM Virtualization Engine	有 有 没有 有
	RHEL 3 u3	LPAR 虚拟化引擎	有 有
	SUSE 8	LPAR	有
	SUSE 9	LPAR DLPAR 虚拟化引擎	有 有 有
	i5/OS	LPAR DLPAR 虚拟化引擎	有 有 有
HP	HP-UX 11i	nPAR vPAR HP PRM	有 没有 没有 有
Sun	Solaris 8	动态系统域	有
	Solaris 9	动态系统域 SRM	有 没有
	Solaris 10	动态系统域 SRM 容器	没有 没有 没有