级别： 初级 Paul Zikopoulos (paulz_ibm@msn.com), 高级专家，IBM Database Competitive Technology, IBM
2003 年 1 月 09 日
2005 年 9 月 20 日 更新 您是否正试图确保正确地为高可用性环境中的 IBM® DB2® Universal Database™ for Linux®、UNIX® 和 Windows®（DB2）服务器颁发许可？您是不是没有时间或者不愿意通读公开信（announcement letters）、PLET 或您的协议单（licensing sheet）？作者 Paul Zikopoulos 用简洁易懂的语言对此作了精辟的解释。
注： 本文特地为 DB2 V8.2.3 作出更新。
简介
客户之所以选择 DB2 Universal Database for Linux、UNIX 和 Windows（DB2），是因为它能够在难于置信的时间内实现其价值，能够在各种不同的环境之间伸缩和整合，还有其健壮性以及极少的停机时间（包括计划内的停机和计划外的停机）。在本文中，我们将重点讨论 DB2 的高可用性，但不是从功能的角度来谈（这方面已经有很多的文章了），而是从许可的角度来谈。
要得到关于高可用性环境中 DB2 技术方面的好资料，我们建议您购买一本由 Chris Eaton 和 Enzo Cialini 合著的
The High Availabilty Guide for DB2
（ISBN 0131448307）。（注意：这本书没有包括新的高可用性增强，例如 DB2 V8.2 中具备的 High Availability Disaster Recovery，要了解更多关于这方面的信息，请参阅 DB2 V8.2 网页。）
我们听到了很多关于高可用性（high availability，HA）环境中 DB2 的许可方面的问题，高可用性环境的设计目标是解决意外停机（有时候也包括计划内的停机）情况下的配置问题。通常，人们的第一层困惑是：在为自己的高可用性环境中的数据库产品定价时，不同供应商总是花样百出。令人高兴的是，IBM 在许可方面采取更为体谅人的做法，所以更有可能为您的企业节省资金。
另一层困惑主要集中在讨论高可用性时所使用的术语方面。例如术语 集群。有时候 IT 界将高可用性环境称作集群。而我们不喜欢再使用这个术语，因为该术语用到后来已经有点儿被滥用的感觉，集群可以指可伸缩性方面的集群（例如 DB2 Enterprise Server Edition 中具备的数据库分区特性（DPF）），也可以指可用性方面的集群（例如，在一组 Windows 服务器上使用 Microsoft Cluster Server）。尽管我们不喜欢这个术语，但还是用了它。因此，对于本文，当提到术语 集群 时，我们指的是高可用性方面的集群（另行注明的除外）。为简单起见，在与客户、同事等讨论集群时，我们建议在术语集群前面加上 高可用性 或 可伸缩性。
另一个容易产生困惑的地方源自在讨论出现停机事件情况时，用来描述将用作故障转移服务器的服务器的术语。如果您接触这一方面的时间比较长（并不是说您年龄比较大，而只是说您在这方面有数年的职业生涯），那么很可能对描述这种服务器的术语已经很熟悉了。这些术语包括：idle、active、cold、warm、hot、passive、secondary 等。
大多数情况下，IBM eServer 文献使用 cold、warm 和 hot 这几个术语来描述备用（standby）服务器。不过，在 DB2 这一领域有所不同。DB2 使用术语 idle 和 active 来描述备用数据库服务器。因此，DB2 中采用的定价和许可方面的术语可能与其他 IBM 软件产品有所不同。这也是常常令客户产生困惑的源头。因此，通过阅读本文可以帮助您分清这些术语，并 知其内情。
在 图 1 中，我们将大多数常见的用于描述 HA 环境的术语映射为 DB2 术语：
图 1. 业界高可用性术语与 DB2 术语的对照
在前面的图中，我们在每种类别下面添上了一条 一般经验法则（general rule of thumb ），但是在读完本文之后，这些法则对您来说就一目了然了。而且要记住，这是一般法则，对于某个机器，您可能在 DB2 中称之为 idle 备用机器，而在其他地方又称之为 hot 备用机器。
对于高可用性环境中 DB2 的许可取决于您对一些关键问题的回答，这些问题包括：
- 您安装了什么版本的 DB2 服务器？它是 DB2 Express、DB2 Workgroup Server Edition（DB2
WSE）、DB2 Workgroup Server Unlimited Edition（DB2 WSUE）或者 DB2 Enterprise
Server Edition（DB2 ESE）中的哪一种？
- 您要怎样为 DB2 服务器颁发许可？这取决于您所购买的 DB2
的版本，您可以有这样几种选择：并发用户（功能）许可、注册用户/指定用户许可或者处理器许可。（如果您想看到关于所有分布式 DB2 服务器以及如何为它们颁发许可的概述，请参阅 Paul Zikopoulos 所著的 “哪一个分布式 DB2 UDB V8 版本适合您？”。）
- 当 没有 出现故障时，如何使用备用机器？是将它用作进行 DB2 事务和查询工作的生产服务器吗？它是不是空闲着并等待故障的发生？也许它正在执行某种级别的工作，而只是在出现故障事件时帮助启动恢复？简言之，当一切正常时，备用服务器正在做什么与如何为那个服务器上的
DB2 获得许可有很大的关系。
- 您是否正在使用 DB2 V8.2 中新的 High Availability Disaster Recovery（HADR）产品？
最适合开始我们的讨论的地方是术语 —— 我们大家的看法都是一致的。如前所述，DB2 定义了两种类型的备用服务器：
active
和
idle
。
active 备用
在 active 备用 这种配置中，所有服务器都有用于服务用户事务和查询的、独立的、运行着的 DB2 数据库。这种配置有时候被称作 active/active 配置，因为集群中的所有机器在所有时候都在执行某种级别的有用工作。如果集群中的某一个服务器出现故障，那么集群软件将把出故障的服务器上的工作负载转移到集群中仍然正常的一个服务器上。
如果出现了故障，那么资源的转移将使 active 备份服务器（仍然正常运行的机器）的工作负载加倍，因为现在这个机器必须处理它原先的工作负载再 加上 出故障的服务器的工作负载。因此，在设置高可用性
active/active
环境时，需要考虑这一点。如果您是一名数据库管理员（DBA），并且您所仰仗的只是一个苛刻的服务水平协议（SLA），那么这未必是最好的选择（除非调整其规模）。
总而言之，在 DB2 中，active
备用服务器是在正常运行期间用来服务于用户事务和查询的机器。当集群内另一个服务器出现故障时，active
备用服务器将接过出故障机器上的负载，同时还要处理在正常运行期间它自己所执行的工作。因为 active
备用机器仍被用于处理用户事务和查询，即使没有故障出现，它也必须是被完全许可的。例如，假设有两个数据库分别处在不同的机器上，其中一个机器上运行着一个
ERP 包，另一个机器处理一些 SCM 工作。如果 SCM 数据库出现故障，那么承担着 ERP 工作负载的机器将不得不同时为所有的 SCM
用户提供服务。
图 2 展示了一个
active/active 备用场景。在这个例子中，有两个服务器，在正常运行期间，它们都被用来处理事务和查询工作负载（实心框表示在出现故障之前每台机器上的工作负载，交叉线框是当两个机器分别出现故障时，工作负载所出现的地方）。当机器
2 出现故障时，它的工作负载被转送到它的故障转移伙伴（即机器 1）那里。在这个场景中，相对于机器 2，机器 1 是一个 active
备用服务器（当您仔细观察这个图时，您会发现反过来也是类似的，注意机器 2 上原属于机器 1 的交叉线框）。这种类型的配置常常被称作 高可用性集群对（high-availability
clustering pair）。
在图 2 中，机器 1 和机器 2 一直都被用于自己的事务和查询工作负载需求（实心框），当机器 2 出现故障时，机器 2 上的 DB2 工作负载被传送到机器
1（交叉框）。同样，在这种情况下，如果没有考虑到承担机器 2 出故障的工作负载而对机器 1
的资源进行调整（反之亦然），那么在出现停机情况并导致工作负载的转移之后，就会引起性能问题。
图 2. 机器 1 是机器 2 的 active 备用。当机器 2 出现故障时，机器 2 的工作负载被转移到机器 1
对于 active 备用机器在许可方面的考虑
作为一般经验法则，active/active 配置的定价方式应该与各服务器没有参与高可用性集群情况下的定价方式相同（也存在一些例外，我们在后面会讲到）。接下来的小节将详细介绍对于高可用性集群中不同的 DB2 服务器许可方式，您应该知道的一些许可方面的考虑事项。
处理器许可： 对于任何按照 处理器许可 模型颁发许可的 DB2
服务器产品（例如 DB2 Express、DB2 WSUE 和 DB2 ESE），active 备用服务器（这个例子中是机器
2）上的处理器都必须得到许可。
在 图 2 展示的例子中，假设每台机器在一个双 CPU 的服务器上运行 DB2 Express，则必须获得的许可为：2 台服务器 x 2 个处理器 = 4 个处理器。
授权用户： 对于任何按照 授权用户模型 颁发许可的 DB2
服务器产品（这一次，DB2 WSE 是惟一按此方式进行许可的 DB2 服务器，这是自 DB2 V8.2.3 以后 DB2 ESE 的新选项），则对于将在正常运行期间（也就是发生故障 之前）访问这个机器的所有授权用户，都必须获得许可。但是要注意，DB2 ESE 的授权用户许可条款要求，对于服务器上的每个处理器，必须至少为 25 个用户颁发许可，或者按照实际用户数（多于 25 个）颁发许可。如果使用连接集中软件或多路器，则必须在可识别用户被集中为单个 ID 之前，把这些可识别用户计算在内。例如，当在 DB2 环境中使用 Microstrategies 时，它常常以单个用户 ID 连接到 DB2，实际上这是很多其他用户连接的集中。必须在发生向连接到 DB2 的单个用户 ID 的集中之前，计算授权用户数量。在发生故障时，出故障的机器（机器 2）上的授权用户许可可以免费转移到 active 备用（机器 1）。很简单，每个服务器按照它们各自的工作负载环境颁发许可，当发生故障时，授权用户许可可以免费转移到仍在运行的机器上。与注册用户和指定用户模型（我将在后面谈到）不同，对于授权用户许可模型，不需要服务器许可。注意，授权用户许可仅用于特定用户，并不能在连接时（像并发用户许可那样）动态地转移。
在 图 2 展示的例子中，如果每个 DB2 ESE 服务器都处在一个单 CPU 的服务器上，并且每个服务器有 50 个用户，那么将需要：（2 个服务器 x 50 个授权用户) = 100 个授权用户许可（每个服务器 50 个）。当机器 2 未运行时，active 备用服务器（这里就是机器 1）要有 100 个授权用户许可。也就是说，机器 1 上原有的 50 个授权用户许可加上来自机器 2 的另外 50 个授权用户许可。当两个服务器都正常运行时，每个服务器各需 50 个授权用户许可。记住，在授权用户许可模型中，不需要考虑服务器许可。
然而，让我们来考虑一个更复杂的例子，假设每个 DB2 ESE 服务器处于一个 4 CPU 的服务器上，并且各有 50 个用户。在这种情况下，则需要：（2 个服务器 x （4 CPU x 25 = 100 个授权用户）） = 200 个授权用户许可（每个服务器 100 个）。前面的例子是否让您失去警惕呢？记住，在这种许可模型中，对于每个处理器，必须至少有 25 个用户许可（如果实际用户数大于 25，则按照实际用户数）。在这个更为复杂的例子中，由于每个服务器上有 4 个 CPU，虽然每个服务器上只有 50 个用户，但是每个服务器上需要 25 x 4 = 100 个授权用户许可。当机器 2 未运行时，active 备用服务器（即机器 1）需要 200 个授权用户许可。也就是机器 1 原有的 100 个授权用户许可加上来自机器 2 的另外 100 个授权用户许可。当两个服务器都正常运行时，则每个服务器各自需要 100 个授权用户许可。记住，在授权用户许可模型中，不需要考虑服务器许可。
并发用户： 对于任何按照 并发用户模型 颁发许可的 DB2
服务器产品（这一次，DB2 WSE 是惟一按此方式进行许可的 DB2 服务器，这是自 DB2 V8.2.3 以后 DB2 ESE 的新选项），为了为 active 备用服务器颁发许可，必须用一个 DB2 服务器许可，并且，对于将在正常运行期间（也就是发生故障 之前）访问这个机器的所有并发用户，都必须获得许可。（如果使用连接集中软件或多路器，则必须在进行集中 之前 计算用户数量。）当发生故障时，出故障的机器上的并发许可可以免费转移到仍在运行的 active 备用（这里就是机器 1）上。很简单，每个服务器按照它们各自的工作负载环境颁发许可，当发生故障时，并发用户许可可以免费转移到仍在运行的机器上。
在 图 2 展示的例子中，如果每个 DB2 WSE 服务器需要 50 个并发用户许可，则一共需要：（2 个服务器 x 50 个并发用户） = 100 个并发用户许可 + 2 个 DB2 WSE 服务器许可（每个服务器一个）。
当机器 2 未运行时，active 备用服务器（这里就是机器 1）需要 100 个并发用户许可。也就是机器 1 原有的 50 个并发许可加上来自机器 2 的另外 50 个并发许可。当两个服务器都正常运行时，每个服务器各需要 50 个并发许可。
注册用户或指定用户： 对于任何按照 指定用户模型（例如 DB2 Express）或 注册用户模型（例如 DB2 WSE）颁发许可的 DB2
服务器产品，只需用一个服务器许可来为 idle 备用服务器颁发许可。（说白一点儿，DB2 Express 指定用户许可和 DB2 WSE 注册用户许可是一回事，但两者都不同于 DB2 ESE 上的授权用户许可）。DB2
注册用户许可和指定用户许可是为特定个体提供的一种权利，使他们可以访问公司中任何为指定用户或注册用户颁发许可的 DB2 服务器。例如，您可以让一个指定用户访问在您环境中的 10 个不同的 DB2 数据库服务器，前提是这些服务器是按照指定用户或注册用户模型颁发许可的。
在 图 2展示的例子中，假设有 100 个注册用户，2 个 DB2 WSE 服务器，那么需要：100 个注册用户许可 + 2 个 DB2 WSE 服务器许可。记住，注册用户许可和指定用户许可只用于特定的用户，并不能在连接时（像并发用户许可那样）动态地转移。
当机器 2 未运行时，active 备用服务器（这里就是机器 1）需要 100 个指定用户许可或注册用户许可。实际上，由于这些许可本身的性质，总是需要 100 个指定用户许可或注册用户许可。当两个服务器都正常运行时，每个服务器各自仍需要 100 个指定用户许可或注册用户许可。
对于在“active 备用”小节中提到的所有高可用性许可方面的考虑，如果您使用 DB2 V8.2 的新 HADR 特性（我在后面会谈到），那么还必须清楚 High Availability Disaster Recovery（HADR）许可方面的考虑。
idle 备用
在 idle 备用 这种配置中，在正常运行期间，高可用性集群中至少有一个服务器上 没有 为用户事务或查询工作负载提供服务的 DB2 数据库。这个服务器上安装有 DB2 服务器软件，可能已经开机，也可能没有开机，但是由于没有执行“有用”的工作，因而说它是闲置的。被归为“无用”的工作（实际上却可能是最有用的工作）包括在故障转移/HA 场景中的一些管理工作，例如使处于前滚暂挂状态的数据库支持日志传送（log shipping），为一个 DB2 数据库作 flash 拷贝，然后在另一个服务器上执行该拷贝的数据库备份，为 HADR 环境提供事务传送支持，等等。如果高可用性集群中某一个服务器出故障，那么集群软件就会将工作负载转移到 idle 备用数据库服务器。
对 idle 备用配置普遍存在的一个误解是，idle 备用机器若专用于恢复操作，那就是对资源的浪费。如此理解这种配置是不对的。实际上，闲置机器不仅可以担任备用角色，还可以有很多其他用途（包括与 DB2 相关和不相关的用途）。例如，您可以在闲置机器（取决于要在那里执行和 DB2 相关的什么工作，其中可能牵涉到许可问题）上创建一个新的 DB2 实例，并使用它作为测试机器，还可以将其他工作负载和功能分摊到它上面来执行。当有故障发生时，又可以推掉这些工作负载，让备用机器以全部资源来处理出故障的服务器上的负载，这样便巧妙地解决了前面讨论 active 备用配置时提到的负载方面的问题。
例如，您可以让 idle 备用机器依照 DB2 日志进行前滚，与此同时，这台机器还可以运行另一个实例中的测试场景（或者与 DB2 无关的测试场景，例如应用程序测试等等）。当有故障发生时，只需 queisce 测试工作负载，并让 DB2 承担出故障的服务器的负载，而不必担心吞吐量的降低。甚至还可以使用来自的 Veritas 快照软件或部分操作和文件系统，例如 AIX JFS2，来创建 HADR 数据库的快照，并打开它们进行读访问，等等。同样，在做出某些决定时需要考虑许可方面的问题，但关键的一点是，idle 不等于置之不用。
客户将备用机器用于各种不同的用途。当考虑对备用机器的使用时，我建议将您的目标和业务需求放在首位。例如，有些客户可能会在一台备用机器上建立一个日志传送环境。同时，他们还希望将这台备用机器用作只读的生产机器 —— 以便将成本分摊到越来越多的资源上（会计师确实喜欢看到这一点）。大部分情况下，这些模型之间是互斥的 —— 也就是说，当您读数据库时，为了使数据库是当前的，就不能依照日志对其进行前滚（如果不是互斥关系，则根据前滚过程保持的速度，两种模型之间有一个折中 —— 就像在逻辑备用服务器中那样）。最终的结果是，备用数据库（就是在出现故障时用于挽救您的工作的机器）为只读操作开放更长的时间，然而同时也增加了出现故障情况下的修复时间（MTTR）：这种配置的设计正是要避免这个问题。我们的建议是，如果您需要突出的可用性特征，那么以此为首要目标来确定环境的成本和规模。 如果可以承受更长的停机时间，那么在决定对备用机器的使用时就有更多的选择。令人高兴的是，不管您需要做什么，DB2 都有很多的选项。
最后，在很多情况下，在 active/idle 环境中为 DB2 颁发许可与其它供应商的 active/active 环境相比（甚至 包括 硬件）更为廉价，并且其表现仍然更出色（您没看错，请相信我，这是真的），这绝不是浮夸。除此以外，从版本 8.2 开始，任何版本的 DB2 for Linux 还包括一个免费的 Tivoli System Automation for Linux 2 节点的许可，该软件能提供快达 10 秒的故障转移场景，而且其复杂性相对而言比较小（复杂性的减少很有意义，因为大多数停机都是因复杂而起）。此外别忘了，对于 所有 DB2 服务器，而不仅仅是 Enterprise 版，都有 HA 许可。
图 3 中展示了一个 idle 备用场景。在这个例子中，当正常运行时，机器 2 用于事务和查询工作负载（在图中标为活动工作），而机器 1 作为机器 2 工作负载的 idle 备用，有时也支持某些附加功能，包括应用程序开发，甚至可以关机。一旦机器 2 出现故障，它的 DB2 工作负载被传递到机器 1。在这个场景中，情况很可能是这样的：如果在出故障之前（任何类型的）任何工作在机器 1 上执行，那么当机器 2 出现故障之后，这些工作就会收回，以便处理新的工作负载（或者，机器 1 最初确定的规模是同时支持它的 DB2 或非 DB2 工作以及机器 2 的工作，否则将出现性能问题）。
在图 3 中，由于从 DB2 的角度看来，正常运行期间只有一台机器是活动的，而另一台在做其他事，所以这种配置被称作 active/idle 配置。（注意，取决于在 idle 备用机器上所执行的工作，可能需要购买附加的 DB2 许可。例如，对于将作为 idle 备用的机器同时用于支持 DB2 应用程序开发环境的开发人员，可以选择购买 DB2 Universal Developer's Edition 许可。）这里要注意的重要概念是，在发生停机之前，机器 1 不做任何（从许可的角度看来）有意义的 DB2 工作，这有助于确定您需要什么类型的高可用性许可。
图 3. 机器 2 的工作负载被转移到 idle 备用服务器，即机器 1
同样，取决于您的可用性需求、工作负载等等，idle 备用可能适合您的环境，也可能不适合；然而，首先不要忘了高可用性环境的目的 —— 减少停机之后的修复时间。
idle 备用机器许可方面的考虑
处理器许可： 对于任何按照 处理器许可模型 颁发许可的 DB2
服务器产品（例如 DB2 Express、DB2 WSUE 或 DB2 ESE），为了获得高可用性，idle 备用服务器上只需要单个处理器的许可。在前面的例子中，假设每台机器在双 CPU 服务器上运行 DB2 WSUE，那么您需要的许可为：（1 台 active 服务器 x 2 个处理器） + 1 台 idle 备用机器上的 1 个处理器 = 3 个处理器。
分区数据库： 对于分区数据库环境中的
idle 备用机器，许可这一术语在 DB2 Version 8.1 中发生了变化。idle 备用机器与 Database Partitioning
Feature（DPF）一起使用，DPF 是 DB2 Enterprise - Extended Edition 在 DB2 Version 7
中提供的一个特性，在这里，idle 备用机器的许可方式与没有分区的服务器的许可方式是一样的。而在 DB2 V8.1 之前，必须对 DB2 EEE
环境中所有的故障转移处理器颁发许可。
例如，如果您有 4 台 8 CPU 的服务器，并在其中 3 台服务器上安装了 DB2
ESE，将它们用作生产型服务器，同时将剩下的一台服务器作为备用服务器（带有 DPF 特性），那么您需要的许可为：（3 台 active 服务器 x 8
个处理器) + 1 台 idle 备用机器上的 1 个处理器 = 25 个处理器（在这个例子中，我们假设您认为一个处理器许可等于一个 DB2 ESE
处理器许可加上每个处理器为 DPF 特性支付的额外费用）。
授权用户： 对于任何按照 授权用户模型 颁发许可的 DB2
服务器产品（这一次，DB2 WSE 是惟一按此方式进行许可的 DB2 服务器），必须为 active 服务器上在正常运行期间（也就是发生故障 之前）访问这台机器的所有授权用户颁发许可，此外还必须为 idle 备用机器上的 25 个用户颁发许可。当出现故障时，出故障的服务器上的授权用户许可可以免费转移到 idle 备用（机器 1）。很简单，active 服务器按照它自己的工作负载环境颁发许可，当发生故障时，它的授权用户许可可以免费转移到 idle 备用机器上。与注册用户和指定用户模型（我将在后面谈到）不同，对于授权用户许可模型，不需要服务器许可。注意，授权用户许可仅用于特定用户，并不能在连接时（像并发用户许可那样）动态地转移。
在 图 2 展示的例子中，如果主 DB2 ESE 服务器处在一个单 CPU 的服务器上，并且有 50 个用户，那么将需要：50 个生产服务器上的授权用户许可 + 25 个 idle 备用上的授权用户许可。当两个服务器都正常运行时，active 服务器只有 50 个授权用户许可，而 idle 备用不能用于执行有意义的工作。记住，对于授权用户模型，不需要考虑服务器许可。
让我们再考虑一个更复杂的例子，假设 active DB2 ESE 服务器处在一台 4 CPU 的服务器上，并且有 50 个用户。在这种情况下，将需要：（（4 CPU x 25 = 100 个授权用户） + 25 个 idle 备用上的授权用户） = 125 个授权用户许可。前一个例子是否让您失去警惕呢？记住，在授权用户模型中，对于每个 acitve 处理器，必须至少有 25 个用户许可（如果实际用户数大于 25，则按照实际用户数）。在这个更为复杂的例子中，由于 active 服务器上有 4 个 CPU，虽然它只有 50 个用户，但是需要 25 x 4 = 100 个授权用户许可。当机器 2 未运行时，active 备用服务器（这里就是机器 1）需要 100 个授权用户许可。在 active/idle 配置中，为了与处理器模型下为单个处理器颁发许可的传统相符，当使用授权用户模型时，也为 idle 备用机器支付等同于一个处理器的许可（最少 25 个授权用户）。当两个服务器都正常运行时，active 服务器只需要 100 个授权用户许可。记住，对于授权用户许可模型，不需要考虑服务器许可。
并发用户： 对于任何按照 并发用户模型 颁发许可的 DB2
服务器产品（例如 DB2 WSE），只需用一个服务器许可为 idle 备用服务器颁发许可，因为在故障转移期间，出故障的服务器上的并发用户许可可以动态地转移到 idle 备用机器上。
在前面的例子中，如果在两台机器上都安装了 DB2 WSE，并为 active 服务器颁发了 50 个并发用户许可，那么您将需要：2 个服务器许可（一个用于生产，一个用于故障转移） + 50 个并发用户许可。
记住，DB2 WSE 是按照每台服务器一个服务器许可加上用户（并发用户或注册用户）许可来颁发许可的。出现故障之后，idle 备用服务器需要 50 个并发用户许可，这是来自机器 2 原有的 50 个并发许可。
注册用户或指定用户： 对于任何按照 指定用户模型（例如 DB2 Express）或 注册用户模型（例如 DB2 WSE）颁发许可的 DB2
服务器产品，只需用一个服务器许可来为 idle 备用服务器颁发许可。（说白一点儿，DB2 Express 指定用户许可和 DB2 WSE 注册用户许可是一回事，但两者都不同于 DB2 ESE 上的授权用户许可）。DB2
注册用户许可和指定用户许可是为特定个体提供的一种权利，使他们可以访问公司中任何为指定用户或注册用户颁发许可的 DB2 服务器。
在前面的例子中，如果有 100 个指定用户和一个 DB2 Express 生产服务器，那么将需要：2 个 DB2 Express 服务器许可 + 100 个指定用户许可。由于指定用户许可可以访问您环境中的多个服务器，所以不需要在各个服务器上区分指定用户。
提示： 在这个环境中，通过将 idle 备用机器作为 active 备用机器使用，可以从注册用户许可或指定用户许可中获得更大的价值，因为它不会影响您的许可成本（这是由于与指定用户或注册用户相关的条款和条件的缘故）。对此的权衡牵涉到出现停机时备用机器上的工作负载，所以必须衡量出这种方法的优缺点。很简单，为注册用户或指定用户颁发了许可的 idle 备用机器可以像在 active/active 配置中一样使用，而不必考虑附加的许可费用。
对于在“idle 备用”小节中提到的所有高可用性许可方面的考虑，如果您使用 DB2 V8.2 的新 HADR 特性（我在后面会谈到），那么还必须清楚 High Availability Disaster Recovery（HADR）许可方面的考虑。
关于 HADR 的高可用性定价
V8.2 引入了一种叫做 High Availability Disaster Recovery（HADR）选项的新的可用性产品。HADR
产品使 DB2 能够从日志缓冲区交付事务，而在此之前的很长一段时间里，DB2
是从日志文件交付事务的。这种增强为一个更丰富的、更有粒度的、齐全的数据丢失预防环境提供了支持，这种环境带有多种扩展选项，例如无需停机便可更新操作系统的能力。HADR
有三个数据丢失预防级别，其中一个级别保证零丢失事务环境。将所有这些包装起来的是一个功能完备的 GUI，这种 GUI 使得 HADR
环境的建立十分便捷。结果令人印象深刻。我们展示了一些数秒内的故障转移场景。下面的 图 4 展示了一个 HADR
的例子：
图 4. HADR 环境中的 DB2
对 HADR 技术细节的讨论超出了本文的范围。请访问 DB2 V8.2 网页，以获得更多信息。
DB2 ESE 附带了 HADR 选项，这个选项没有另外收费，还可以将该选项作为 DB2 Express、DB2 WSE 和 DB2 WSUE
服务器的附带产品；如果您正计划与 ESE 服务器一起使用 HADR，那么只需遵从本文中给出的指南，并跳过此节即可。（此节专用于通过处理器许可模型或授权用户许可模型颁发许可的 DB2 ESE 服务器）。
购买用于 DB2 Express、DB2 WSE 和 WSUE 的 DB2 High Availability Disaster
Recovery 选项的惟一方式是通过一个处理器许可。DB2 服务器上的每个 active 处理器都必须获得 HADR 许可，备用机器获得 HADR
许可的方式应该与用一个处理器许可为备用机器获得 DB2 服务器许可的方式相同（这取决于备用机器是 active 状态，还是 idle 状态）。
如果您使用并发用户、指定用户或注册用户为 DB2 服务器获得许可，那么仍然必须通过服务器上处理器的数量来获得 HADR 选项许可。换句话说，对
DB2 HADR 选项的许可总是基于处理器的数量，而不管 DB2 服务器本身是如何获得许可的。
例如，如果您有一台 DB2 WSE 服务器，服务器有
10 个并发用户，并且是在一个 active/idle 备用集群中使用该服务器，同时该集群在一台 2 CPU 的服务器上带有 DB2
HADR 选项产品，那么您将需要：2 个 DB2 WSE 服务器许可 +
10 个并发用户许可 +（（active 机器上的 2 个 DB2 HADR 选项处理器许可）+ idle 机器上的 1 个 DB2
HADR 选项处理器许可 = 3 个 HADR 处理器许可）。
前一个例子是否让您失去警惕呢？其中可能有些扑朔迷离。我们将为您加以简化。在这个例子中，有 2 台服务器，每台服务器有 2
个处理器（在集群中一共有 4 个处理器）。其中一台机器是 active 机器，做一些有意义的工作。另一台机器是 idle
机器，它一般做一些其他的工作，但是从 DB2 的角度来看，它只是做一些工作来帮助故障恢复等。由于我们有两台服务器，并且选择使用并发用户模型来为
DB2 WSE 颁发许可，所以我们需要 2 个 DB2 WSE 服务器许可。此外，由于 active 机器每次有不超过 10
个的并发用户，因此您将需要 10 个并发用户许可（这里不需要用于 idle
机器的并发用户许可，因为在出现停机情况时，可以动态转移并发用户许可）。最后，由于您要使用 HADR，因此对于 active 服务器，需要有 2 个
HADR 处理器许可，而对于备用服务器，需要有一个 HADR 处理器许可。
参考资料
关于作者  | 
| |
Paul C. Zikopoulos 拥有 BA 和 MBA 学位，是 IBM Database Global Sales Support 小组的获奖作家和演讲者。他有九年以上的 DB2 UDB 经验，还撰写了许多关于 DB2 的杂志文章和书籍。Paul 与人合著了以下书籍：DB2 - The Complete Reference、DB2 Fundamentals Certification for Dummies、DB2 for Dummies、A DBA's Guide to Databases on Linux 和 DB2 Version 8: The Official Guide。Paul 是一位 DB2 认证的高级技术专家（DRDA 和集群/EEE 方面），以及 DB2 认证的解决方案专家（商业智能和数据库管理方面）。您可以通过 paulz_ibm@msn.com 与他联系。 |
对本文的评价
| 
