 | Level: Introductory Paul Zikopoulos (paulz_ibm@msn.com), Program Director - DB2 Evangelism, IBM
Deb Jenson (dejenson@us.ibm.com), Product Manager, IBM Japan, Software Group
30 Nov 2006
Updated 10 Feb 2009 In the third quarter of 2006, IBM software group (SWG) announced a replacement for their processor-based pricing and introduced the Processor Value Unit (PVU) concept as a way to determine the processor rating of a
server. Prior to this announcement, customers simply added up the number of processing cores they planned to deploy DB2® on, and multiplied by the price. However, the introduction of multi-core processors, and the rate at which this market is changing, led to confusion and had both clients and vendors asking "What is a processor"? This article describes how to license DB2 for Linux®, UNIX®, and Windows® (DB2) using the new PVU metric and includes a number of helpful everyday examples.
Introduction
The best way to ensure you understand what PVUs are and subsequently understand PVU pricing is to have a little background on DB2 pricing in general. Essentially, DB2 provides two licensing methodologies:
-
A user approach, called the Authorized User model
The authorized-user model, as its name would suggest, requires you to count the number of users that will be using DB2 and multiply that number by a per-user price to determine your license costs. This pricing model is especially attractive to companies that have few users in relation to having large databases or for environments that implement application software such as SAP which is also licensed in this manner, and more. In DB2, authorized-user pricing is available for the DB2 Express, DB2 Workgroup, and DB2 Enterprise editions, as well as the development focused Database Enterprise Developer Edition (DEDE).
With the exception of DEDE, all the DB2 editions come with a minimum number of authorized users that you must license to use this model. DB2 Express and DB2 Workgroup require you to minimally license 5 authorized users. DB2 Enterprise servers need to be licensed for a minimum 25 authorized users for every 100 PVUs for the server upon which this edition is installed. For example, if you installed DB2 Enterprise on a server rated for 400 PVUs, you would need to buy at least 100 authorized user licenses (400 PVUs/100 PVUs = 4 * 25= 100 authorized
users). Even if you only had 25 users in your environment, you would still need to buy 100 authorized user licenses since you have to minimally license DB2 Enterprise with 25 authorized user licenses per 100 PVUs when you use this license. If your environment had 125 users, in this example, you would need to procure 125 authorized user licenses since it is greater than the 25 per 100 PVUs minimum.
-
A processor approach, based on the processing power rating of the underlying server or virtualization session, called the PVU Processor model
The PVU processor model (also known as per processor pricing) is a pricing metric where each processor running the DB2 software is counted and multiplied by the DB2 per-processor price to determine the eventual license costs. This model is attractive to companies that have large numbers of users in relation to database size as well as environments where end users are not easily counted (like a Web-based application), because this licensing paradigm removes the need to mainfest or "know" your users (from a licensing perspective). Another attractive feature with per-processor pricing is as new employees are hired, each new employee does not require a license entitlement. This leads to a reduction in license administration costs because you don't have to maintain a manifest of your
users.
One exception to the previous DB2 edition pricing models is with DB2 Express-C FTL; generally considered a package of DB2. DB2 Express-C, of course, is free. FTL (stands for Fixed Term License) is a one year support and feature contract. DB2 Express-C FTL servers are priced per server, no matter what the PVU rating of the underlying server is. In fact, even in a high availability environment with a warm or cold standby, you still purchase the per server FTL contract for each server. You can learn more about how to license any DB2 edition or package in a high availability environment by reading
"Licensing distributed DB2 9.5 servers in a high availability environment" by Paul Zikopoulos.
This article focuses solely on the PVU processor model and how PVUs change the way you
calculate your license costs. For complete details on the features, licensing restrictions, and extensibility options available with the distributed editions of the DB2 family, refer to "Which DB2 9 edition is right for you?." by Paul Zikopoulos.
How we got here...
Prior to the introduction of dual-core chips, there wasn't much question what a processor was since all processors were single-core processors. This made processor-based licensing simple to understand and manage: if you had a four processor system, then you needed four software license entitlements.
In October 2000, IBM introduced a new line of highly scalable dual-core microprocessors with their POWER processor (the POWER4 series was the first generation of dual-core processors released by IBM, this generation was replaced by POWER5, and has since been replaced with POWER6). Today, these chips are available with the POWER (formerly known as System i and System p) servers from IBM. These POWER chips changed the technology landscape by implementing two cores (the ability to have two separate circuitry units executing compute instructions) on a single silicon chip (something that plugs into your computer's motherboard). An example of a dual-core processor is shown below:
Figure 1. A dual-core processor
The following figure compares a single core processor to a dual core processor:
Figure 2. A comparison of a dual-core processor to a single core processor
The advantage of dual-core chips is that they can be used to drive performance and reduce power requirements as well as the heat generated by higher and higher clock speeds of their single-core counterparts. Dual-core chips are denser as well, which means their physical requirements are more along the lines of their single-core cousins since they share the same form factor. Dual-core chips would also appear to be more environmentally friendly in that they consume less electricity and have lower heating, ventilation, and air conditioning (HVAC) requirements. Finally, the proximity of cached memory can yield performance advantages too and more and more software companies are looking to specifically write their applications to leverage different cores on a processor for different operations. Today, my feeling is that most applications aren't written to fully utilize cores from a optimization perspective; however, all applications definately take advantage of the excess processing capacity. One good example of true core exploitation is the IBM Data Power appliance which has specific cores that are optimized for specific functions such as XML parsing and validation. These functions exclusively run on specific cores.
Each core on the first generation POWER dual-core chips were faster than their single-core predecessors in the previous generation; by putting two of these faster cores on the same chip, customers saw their performance improve more than two times for these new "processors" (the physical chip that plugged into the socket on the motherboard that now had two traditional processors on it as opposed to one). At this point, IBM Software Group (IBM SWG) determined that a processor should be defined as a core (so a dual-core processor meant two processors from a licensing perspective) since users were getting the full benefit of both cores on the chip. Soon after, other hardware vendors followed suit by releasing dual-core processors, like Sun, Intel, and AMD; soon after that we've seen a plethora of multi-core chips (quad-core, hex-core- octi-core, and so on) each designed for various characteristics: price performance, electrical consumption, performance, and so on.
Some hardware vendors reference the pieces of silicon that plug into the motherboard as a processor no matter how many cores are on it. You can see the marketing advantage here. One vendor may refer to a server with eight processing cores as an eight-way server while another would call it a four-way (since it has four dual-core processors, each processor with two processing cores). Various benchmarking organizations have adopted policies to limit this type of confusion and have implemented rules with respect to the reporting of server capacity such that you typically see benchmark results now reported as Processors/Cores/Threads (P/C/T); for example, a 32/64/128 benchmark report means that the result was run on a server with 32 dual core processors with some sort of hyperthreading enabled (2 threads per core). The Standard Performance Evaluation Corporation (SPEC) mandates that all results be reported in cores and the Transaction Performance Processing Council (TPC) also mandates the reporting of Processors/Cores/Threads in their disclosure reports. This is something to keep in mind when comparing the performance of servers and so on; ensure you're comparing cores to cores and I recommend you ask for the specific number of cores on the machine or reports that conform to the SPEC mandate to ensure accurate comparisons between any vendors.
In the past, to license IBM software running on a dual-core chip, customers counted the number of cores, and multiplied by the per-processor price. If a customer had what was traditionally known as a "four-way" dual-core server (4 sockets each with 2 cores = 8 cores), they were required to license eight processors of DB2. However, when x86 dual-core chips were introduced from Intel and AMD, they didn't double (or more than double) the performance, as was the case with their POWER counterparts. While Intel and AMD provided performance improvements by placing two cores on a chip, these architectures just didn't yield 2+ times the speedup of their single-core counterparts; our own research showed the speedup for these first generation x86 dual core servers to be around 30% (give or take); certainly not double as was the case with the POWER-based processors. Now mix this with the evolution of the processor market where certain processors are architected to be more energy efficent than pure performance play cores, and you can see how scrambled the simplistic per core pricing becomes. In some cases, you could pay more and not get more performance, and in other cases pay more and get proportionally greafter performance.
As a result, the market has concluded that not all multi-core chips are created equal and therefore
shouldn't be licensed the same way. For example, the x86 quad-core first generation processors that hit the market soon after the dual core craze didn't double the performance of their precedessors (at first, a single quad core processor could not outperform two dual core processors; however, there is the definite and expected potential for them to be
faster.)
Because of this core disparity, IBM announced a policy in 2005 that started to accrue the value a core provides to the software (for example, speedup) as a key ingredient to the price of the software. For example, since x86 dual core processors didn't give the same performance as a dual core POWER processor, when licensing x86 dual-core chips, you were effectively required to buy one-half of a license for each processor core (essentially one processor license per
socket).
Note: When Intel introduced hyperthreading which tricked software into thinking there were two processors for each single-core processor by pausing and inter-weaving schedule threads of work, the performance yield was around 30%; IBM never charged for these virtual processors because they didn't produce twice the performance.
To further complicate the procurement of IT solutions at this point was the fact that most software vendors were charging for each core and most hardware vendors were charging for the chip (since they can't sell half a chip), leading to even greater confusion in the marketplace.
If it hadn't become confusing enough, in the middle of 2006 (before the concept of PVU was announced) the multi-core marketplace became even more complex when Sun introduced their quad-core, hexa-core, and octi-core processors that shipped with their first generation T1000/T2000 "Niagara" servers. These processors were not really engineered for straight out performance (though future generations of them have some-what addressed this issue) rather energy efficiencies in relation to performance. The point is that today's marketplace is characterized by different kinds of multi-core processors that have different characteristics: some provide double the performance, some provide massive energy savings, some try to compromise between the two, some are engineered for laptops, and more. Indeed, the evolution of the processing core foreshadowed the need for something new.
As we look into the future and see more multi-core processors from different vendors with different performance characteristics and value propositions, it seemed that there had to be a way to normalize these discrepancies. After all, it wouldn't seem fair to buy two licenses for a dual-core processor if it only yielded a 30% performance improvement. At the same time, it wouldn't seem fair to pay for only one license with a dual-core processor that yields a 200% (or more) performance improvement. The PVU methodology is used to standardize the value derived from a varying array of processor architectures to normalize the benefits and equate that to the software you are running to come up with a fair charge metric.
So now what? The Processor Value Unit (PVU)
In the third quarter of 2006, IBM SWG announced a replacement for processor core-based pricing and introduced the concept of PVU pricing. Since this announcement, you now interpret license limits for distributed DB2 servers, and procure entitlements using this new PVU metric. For example, today, when you want to license your DB2 server for unlimited users you arrive at the final DB2 price by aggregating the total amout of PVUs on the server (often referred to as the server's PVU rating) where the DB2 software is running and multiplying that by the per PVU price of the DB2 edition (and/or Feature Pack) that you are running. Since as of February 10th, 2009, all DB2 servers support sub-capacity licensing, you use the PVU rating of a virtualization session to arrive at the DB2 license costs of that session. (By the way, in the event that the total number of virtual PVUs exceed the total PVU rating of the underlying server, you simply license the PVU rating of the server.) For example, if you had a 400 PVU server and deployed 8 VMWare sessions each configured to use 100 PVUs, you license 400 PVUs of DB2, not 800 PVUs. The exception to this rule is DB2 Express-C FTL where you purchase an FTL feature and support contract for each installation, so you would need 8 DB2 Express-C FTL licenses in this example.
A PVU is simply a unit of measure used to differentiate processing cores from the various hardware vendors. IBM now maintains the
PVU Licensing for Distributed Software table which maps today's available processors to the number of PVUs associated with a single respective processing core. This table is continually updated as manufacturers go to market with different chip architectures. In fact, IBM SWG works so closely with these chip vendors that they are well aware of the performance benefits of many of the new processors before the market itself. You can determine the total PVU rating for your server or virtualization session by adding up the PVUs attributed to each core using this table. Once you've determined the number of PVUs, multiply the total amount of PVUs for your server or virtualization session by the per-DB2 PVU price for the edition or Feature Pack you want to license.
A PVU Licensing Example
To understand how traditional processor pricing equates to PVU pricing, it's best to compare and contrast the two models. As of the date this article was last updated, conversion rates for processing cores to PVUs are as follows:
Figure 3. PVU Licensing for Distributed Software
table
Note: This table is provided for your convenience and to facilitate a working example; for the most update to date PVU conversion rates, refer to the previous table online.
You can see this table is pretty much organized by decreasing per core PVU ratings for each vendor and their processor architecture. Simply locate the brand of your processor, the respective number of cores on the processor, and arrive at the PVU rating for each core using the PVUs per Processor Core column.
For example, using this table you can see that almost any single core processor from any vendor requires 100 PVUs (the exceptions are the IBM PowerXCell and Cell/B.E. single core processors). If you look at the Intel Xeon x86 quad core processor, you realize that any socket occupied by this processor requires 200 PVUs (4 x 50 PVUs). You can also see that a System z10 processor (used to run Linux on System z) is rated at 120 PVUs per core for the Integrated Facility for Linux (IFL) engine it runs.
So how do we explicitly figure out how many PVUs of a DB2 edition or Feature Pack we have to buy? From this table we can determine that a single dual-core AMD Opteron processor requires 100 PVUs (50 PVUs per core x 2 cores = 100 PVUs per processor). Let's assume your server has 2 dual-core AMD processors; you are required to buy 200 PVUs of your DB2 software: (2 processors x (50 PVUs x 2 cores)) = 200 PVUs. In contrast, the faster performing dual-core POWER6 processor yields far more performance than an AMD-based dual-core processor. If you have a POWER server with 2 dual core POWER6 processors, you are required to purchase 480 PVUs of DB2: (2 processors x (120 PVUs x 2 cores)) = 480 PVUs.
Note: POWER 6 processors - as illustrated in the PVU table referenced above - can be rated at a 80 PVUs depending on the server where they run. Specifically, POWER p520 and JS12 models, along with IBM BladeCenter JS12/JS22 servers, count each POWER6 core as 80 PVUs. All other servers using POWER6 processors than those listed here (and updated online in the table) are rated at 120 PVUs.
PVUs are used for licensing restrictions as well. This means that if a DB2 edition is limited to 200 PVUs, like DB2 Express, then from the table referenced above, you can deduce that you could install the DB2 Express code on any server that does not exceed a 200 PVU rating. In May 2008, IBM changed the PVU limit for DB2 Workgroup from 400 PVUs to 480 PVUs to accommodate 4-core POWER6 servers running this edition of DB2. As you can see, you can install DB2 Workgroup on:
- A server with four dual-core x86 AMD-based Opteron chips
- A server with a single quad-core x86 AMD-based Opteron chips
- A server with two dual-core POWER6 chips
- A server with a two quad-core POWER5 5 QCM chips
- A server with a four UltraSparcT1 quad-core chip
- and more...look at the table!
If you need some help identifying what kind of cores are in what server, IBM publishes a guide to help you identify the processor family correlated to your server. For example, if you have an IBM System x server, you can quickly find out the type of processing core used with this server, how many cores occupy each socket, and the PVU rating per core as shown in the following figure:
Figure 4. Quickly finding details on your server using the IBM guide to identifying your processor family
To further assist you in determining the number of PVUs your server may aggregate to, you can use the IBM Processor Value Unit Calculator to determine the overall PVU rating of your server using a useful wizard. An example of this tool is shown below:
Figure 5. An example of using the IBM Value Unit Calculator
With all of the power available in today's processor cores, clients increasingly want to partition their systems such that an application is limited to only a subset of the total processing power of a system. As of February 10th, 2009, sub-capacity pricing is supported for all DB2 servers (there are some potential requirements you need to follow that correlate to your server's operating system to enable this kind of licensing). In this situation, you are required to license the PVU rating of the partition where the DB2 software runs.
Consider the following:
Figure 6. An example of sub-capacity licensing a DB2 server
The server in Figure 6 is an IBM POWER server with a total of four processing cores (it has two dual-cores chips). If you wanted to run WebSphere Application Server on three of those cores, and DB2 Enterprise on the one remaining core, you could license DB2 Enterprise for the number of PVUs for that single-core (in this case 120 PVUs) using the POWER virtualization technologies. Under the traditional full capacity licensing model, you would be required to have 480 PVUs of DB2 (since each POWER6 core is rated at 120 PVUs).
Assume for a moment that Figure 6 illustated an AMD-based dual-core machine. In this case, you will be required to buy only 50 PVUs because DB2 is only running on a single-core. In the previous licensing model, you would have been required to purchase a full processor, because you always round a fraction up when licensing (the .5 processor here would be rounded up to a full processor license). This is a good example of a potential benefit of the new PVU paradigm. As you can imagine, as the number of cores per chip continues to increase with quad-core, then octi-core, and so on, sub-capacity pricing could have become more disadvantageous for clients.
Wrapping it up...
To summarize, DB2 PVU pricing provides the following benefits:
- Creates a simple and fair licensing structure
- Avoids fractional licensing for multi-core chips
- Avoids charging too much for multi-core chips
- Provides flexibility and granularity
- Enables sub-capacity licensing at the processor core
- Positions for the future
- Continues to deliver software price performance improvements
- Makes licenses more transferable across distributed systems since PVUs can be moved around to different data servers that run on different core architectures
- Provides clarity to middleware licensing
- Over time, new processors will be differentiated based on relative performance
The new PVU model is a change in the way you do things, and to be honest, no one really likes a change. In due time, it'll become old hat, and as different processing cores offering various benefits are brought to the marketplace, you'll be able to leverage them in a fair and consumable manner.
Resources Learn
-
"Compare the distributed DB2 9.5 servers" (developerWorks, Feb 2009): Compare the DB2 for Linux, UNIX, and Windows editions in a side-by-side comparison table.
-
"Which DB2 9.5 client connectivity option is right for you?" (developerWorks, Apr 2008): Learn the details of all the various client connectivity options.
-
"Which distributed edition of DB2 9.5 is right for
you?" (developerWorks, Feb 2009): Get the details on what makes each edition of DB2 for Linux, UNIX, and Windows unique.
-
Visit the developerWorks resource page for DB2 for Linux, UNIX, and Windows to read articles and tutorials and connect to other resources to expand your DB2 skills.
-
Learn about DB2 Express-C, the no-charge version of DB2 Express Edition for the community.
-
developerWorks Information Management: Learn more about IBM Information Management products. You'll find technical documentation, how-to articles, education, downloads, product information, and more.
Get products and technologies
-
Download a free trial version of DB2 Enterprise 9.
-
Now you can use DB2 for free. Download DB2 Express-C, a no-charge version of DB2 Express Edition for the community that offers the same core data features as DB2 Express Edition and provides a solid base to build and deploy applications.
Discuss
About the authors | 
| | Paul C. Zikopoulos, BA, MBA, is the Program Director for the DB2 Evangelist team at IBM. He is an award-winning writer and speaker with more than 14 years of experience with DB2. Paul has written more than 230 magazine articles and 11 books on DB2 including, Information on Demand: Introduction to DB2 9.5 New Features, DB2 9 Database Administration Certification Guide and Reference (6th Edition), DB2 9: New Features, Information on Demand: Introduction to DB2 9 New Features, Off to the Races with Apache Derby, DB2 Version 8: The Official Guide,
DB2: The Complete Reference, DB2 Fundamentals Certification for Dummies, DB2 for Dummies, and A DBA's Guide to Databases on Linux. Paul is a DB2 Certified Advanced Technical Expert (DRDA and Clusters) and a DB2 Certified Solutions Expert (BI and DBA). In his spare time, he enjoys all sorts of sporting activities, including running with his dog Chachi, avoiding punches in his MMA training, and trying to figure out the world according to Chloë – his daughter. You can reach him at paulz_ibm@msn.com. |
| 
| | Deb Jenson joined IBM in 2004 to drive strategic marketing for the DB2 data server. As Product Manager for DB2, she is responsible for market strategies that drive incremental growth and increase market awareness for the DB2 data server. Deb has over 12 years experience in the commercial software industry with extensive experience developing database products and driving market execution strategies that drive growth. Deb joined IBM from Quest Software and prior to Quest, held various positions at Platinum Technology focused on the database management product family. Deb can be reached at: dejenson@us.ibm.com..
|
Rate this page
| |
