http://www.ibm.com/developerworks/data/library/techarticle/dm-0611zikopoulos2/?S_TACT=105AGX52&S_CMP=DWCHINA
DB2 and IBM's Processor Value Unit pricing
Summary: In the third quarter of 2006, IBM® Software Group (SWG) announced a replacement for their processor-based pricing methodology and introduced the Processor Value Unit (PVU) concept as a way to determine the processing capacity of a server. Prior to this announcement, customers added up the number of DB2 processing cores they planned to deploy 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® servers (herein referred to as just DB2) using the PVU metric and includes a number of helpful everyday examples.
Date: 29 Oct 2009 (Published 10 Sep 2006)
Level: Introductory
Activity: 9487 views
Comments: 0 (Add comments) <!-- Rating_Area_Begin --><!-- Ensure that div id is based on input id and ends with -widget -->
Average rating (based on 31 votes)
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 server, 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, followed by POWER6). Today, these chips are available with the POWER (formerly known as System i and System p) server family 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 a server motherboard's package). An example of a multi-core processor (in this case it's 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 single core processor to a dual-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 processor cores for different application operations.
Today, my feeling is that most applications still aren't written to fully utilize cores from a optimization perspective; however, all applications definately take advantage of the excess processing capacity and this is definately changing. 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.
In the case of the first generation POWER dual-core chips, each core was faster than their single-core predecessors; 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/package on the motherboard that now had two traditional processing cores 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 vendors followed suit by releasing dual-core processors of their own such as Sun, Intel, and AMD; since then, we've seen a plethora of multi-core chips (quad-core, hexa-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. For example, a 32/64/128 benchmark report means that the result was attained on a server with 32 dual core processors with some sort of hyperthreading enabled (32 sockets * 2 cores per socket * 2 threads per core = 128 threads).
In an effort to promote clear comparisons, 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 8 DB2 processors. However, when x86 dual-core chips were first introduced from Intel and AMD, they didn't double (or more than double as was the case with their IBM POWER counterparts) the performance of the server. While these new dual core commodity processors provided some performance improvements by placing two cores on a chip, these architectures just didn't yield 2+ times speedup of their single-core counterparts. On a personal note, my own non-validated or regulated research showed the speedup for these first generation x86 dual core processors to be around 30% (give or take); certainly not double as was the case with the POWER-based processors. After dual core processors were first introduced, the now obsolete dual core processors yielded better results than their initial demonstrated performance.
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 greater performance. As a result, the market seemed to conclude 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, this too changed, or will change, over time.)
Because of these core discrepancies, 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 the original x86 dual core processors didn't give the same performance as the original dual core POWER processors, 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). Of course, since the dual core POWER processors more than doubled the performance of their single core counterparts when they were first introduced, you had to buy two processor licenses per socket: one per core.
Note: When Intel introduced hyperthreading which tricked software into thinking there were two processors for each single-core processor by pausing and inter-weaving scheduled worker threads, the yield was around a 30% performance benefit; IBM never charged for these virtual processors because they didn't produce twice the performance. As of DB2 9.7, you still don't license for hyperthreading with x86 chipsets or simultaneous multithreading (SMT) with POWER chipsets, and so on.
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 of database applications (this guidance came from Sun themselves) - though subsequent generations of this chipset have some-what improved on this oringal positioning. In contrast, these original processors were focussed on 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 and attempts to normalize these 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 software group (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 (unless you are using one of the new licensing methods introduced for DB2 Express and DB2 Workgroup servers in DB2 9.7 or the Authorized User license - more on those in a bit). 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 can 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 entire physical server, you simply license the PVU rating of the server.) For example, let's assume you want to license your DB2 software using the PVU model and your server was rated at 400 PVUs; if you installed DB2 in 8 VMWare sessions each configured to use 100 PVUs, you would only license 400 PVUs of DB2, not 800 PVUs. There are some exceptions to this rule depending on the DB2 licensing metric you use. For example, if you licensed DB2 Express with the new SERVER license (which was introduced in DB2 9.7) in these 8 VMWare sessions, you would have to buy 8 DB2 Express SERVER licenses.
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 virtualized session by the per-DB2 PVU price for the edition or Feature Pack you want to license.
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 the industry's most popular processing cores to PVUs are as shown in Figure 3.
Figure 3. Table of Processor Value Units (PVU) per core
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 organized by the per core PVU ratings for each vendor and their respective 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 8i and the IBM Cell/B.E. single core processors). If you look at the Intel Xeon x86 multi core processor, you can see that you can buy this processor architecture in a dual core, quad, core, or hexa core format. If a single socket was occupied by a dual core verion of this processor, it would be rated at 100 PVUs (2 cores x 50 PVUs). If you plugged in the quad-core version of this processor into a server, it would be rated at 200 PVUs (4 cores x 50 PVUs). Finally, if you plugged in the latest hexa-core version into a server, that socket would be rated at 300 PVUs (6 cores x 50 PVUs). You can also see that a System z10 processor (used to run Linux on a System z server) 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 socket). Let's assume your server has 2 dual-core AMD processors; in this case, you woud be required to buy 200 PVUs of your DB2 software: (2 sockets x (50 PVUs x 2 cores)) = 200 PVUs. Now let's assume in this example you were using the faster performing dual-core POWER6 processor which 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 sockets x (120 PVUs x 2 cores)) = 480 PVUs.
Note: Some POWER servers use POWER6 processors that are rated at 80 PVUs. Specifically, the POWER p520 and JS12, JS22, JS23, and JS43 server models use specially-rated POWER6 processors each rated at 80 PVUs per core. All other servers using POWER6 processors than those listed online where the most up to date version of this table resides 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 with a PVU license, 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. The DB2 9.7 release introduced the FTL and SERVER metric for DB2 Express 9.7 (more on that in a bit) which allows you to bypass the PVU rating of the server; however, you need to be aware of trade-offs that surround this model. Likewise, the DB2 9.7 release introduces a new SOCKET metric for DB2 Workgroup servers which allows you to install DB2 on servers larger than the 480 PVU restrictions since it ignores the PVU count of a server and licenses the software at the socket level (more on that in a bit too). For example, in DB2 9.7 using a DB2 Workgroup SOCKET license, you can actually install this DB2 product on a server rated as high as 960 PVUs by the servers available at the time this article was written.
Ignoring some of the new licensing options introduced in DB2 9.7 (for the purposes of illustrating the PVU license - the point of this article), you can see that you can install DB2 Workgroup using a PVU license 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 table.
Note: This is a sample for illustrative purposes only. Please visit the referenced Web site for actual values and calculations.
Table 1. Quickly finding details on your server using the IBM guide to identifying your processor family
| Server Model Number | Processor Vendor/Brand | Processor Type | Processor Model Number* | PVUs per Core** |
|---|---|---|---|---|
| 3105 | AMD Opteron/Athlon | SC/DC | All existing | 100/50 |
| 3200 | Intel Xeon | DC/QC | 3000 to 3499 | 50 |
| 3200 M2 | Intel Xeon | DC/QC | 3000 to 3499 | 50 |
| 3250 | Intel Pentium / Xeon | SC/DC | All existing | 100/50 |
| 3250 M2 | Intel Xeon | DC/QC | 3000 to 3499 | 50 |
| 3350 | Intel Xeon | DC/QC | 3000 to 3499 | 50 |
| 3400 | Intel Xeon | DC/QC | 5000 to 5499 | 50 |
| 3400 M2 | Intel Xeon | DC/QC | 5500 to 5599 | 70 |
| 3450 | Intel Xeon | DC/QC | 5000 to 5499 | 50 |
| 3455 | AMD Opteron | DC/QC | All existing | 50 |
| 3500 | Intel Xeon | DC/QC | 5000 to 5499 | 50 |
| 5500 to 5599 | 70 |
To further assist you in determining the number of PVUs your server may be rated at, 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 4. 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 5. An example of sub-capacity licensing a DB2 server
The server in Figure 5 is an IBM POWER6 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 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) but you just need to license it for 120 PVUs in this example.
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 1/2 processor here would be rounded up to a full processor license). This is a good example of a potential benefit of the PVU paradigm. As you can imagine, as the number of cores per chip continues to increase with quad-core, octi-core, and so on, sub-capacity pricing could have become more disadvantageous for clients without this kind of model.
Note: There are other specifics with respect to the edition and licene you choose when it comes to licensing DB2 editions in a virtualized environemnt. Please refer to my other licensing and packaging articles for all the details.
Since other licensing options beyond the PVU option were referencd in this article, I felt it would be beneficial to give you a very quick introduction to the different licensing options available with the different DB2 editions as of DB2 9.7. Quite simply, the best way to ensure you understand what PVUs, are and subsequently understand PVU pricing, is with a little background on DB2 pricing in general.
Note: In this section, the term server represents either the physical server where the DB2 software is running, or an IBM price-supported virtualization session (such as VMWare, LPAR, and so on) unless otherwise noted.
Essentially, DB2 provides the following licensing methodologies:
- A per server approach used by the FTL or SERVER pricing model
The FTL or SERVER licenses are only available with DB2 Express and were just introduced in the DB2 9.7 release. It's outside the scope of this article to delve into the details of these licenses (since this article's purpose is to explain the PVU license); however, it's suffice to say that these licenses are counted per server. For example, if you had a 4 socket quad core server that was rated at 800 PVUs, you would just buy a single FTL or SERVER license for the physical sever. (Note however that the FTL and SERVER licenses throttles the compute resource used by DB2 to 4 cores and 4 GB of RAM.The FTL license gives you fixed term usage rights for the DB2 Expres software, while the SERVER license gives you perpetual rights to the software. Finally, an FTL or SERVER license supports an unlimited number of users accessing the DB2 software.
The FTL and SERVER licenses are well suited for business partners and small-medium businesses (SMBs) because it is very simple to price. In some cases this license can be very advantageous, and in other cases it can be more costly than other licensing options. For example, even in a high availability environment with a warm or cold standby, you still purchase an FTL or SERVER license 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.7 servers in a high availability environment" by Paul Zikopoulos.
- A per server socket approach used by the SOCKET pricing model
A SOCKET license is only available with DB2 Workgroup and was just introduced in the DB2 9.7 release. It's outside the scope of this article to delve into the details of this license (since this article's purpose is to explain the PVU license); however, it's suffice to say that this license is counted per socket on the server. For example, if you had a 4 socket Intel-based quad core server that was rated at 800 PVUs, you would buy 4 DB2 Workgroup SOCKET licenses. A SOCKET license supports an unlimited number of users accessing the DB2 software. Finally, no matter how many cores resides on a socket, DB2 will throttle usage to a maximum 16 cores based on the server's enumeration as defind in the BIOS. For example, if you had a 4 socket hexa core server, then DB2 would only schedule work on 16 of the available 24 cores. Your BIOS would determine if it would schedule work on 4 cores of each socket, or fully saturate the 1st and 2nd sockets with work and schedule work on just the remaining 4 cores of the 3rd socket - leaving 1/3 of the 3rd socket and all of the 4th socket completely unutilized.The SOCKET license is well suited for those clients that require the highest performance posible for a mid-market focussed solution. In some cases this license can be very advantageous, and in other cases it can be more limiting than other licensing options. Read Which distributed edition of DB2 9.7 is right for you? by Paul Zikopoulos for more information.
- A per user approach, called the Authorized User (AU) 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, AU pricing is available for all DB2 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 AUs. DB2 Enterprise servers need to be licensed for a minimum 25 AUs 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 AU licenses (400 PVUs/100 PVUs = 4 * 25= 100 AUs). Even if you only had 25 users in your environment, you would still need to buy 100 AU licenses since you have to minimally license DB2 Enterprise with 25 AU licenses per 100 PVUs when you use this license. If your environment had 125 users, in this example, you would need to procure 125 AU licenses since it is greater than the 25 per 100 PVUs minimum.
- A capacity 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 capacity pricing) is a pricing metric where the total PVU rating of the underlying server is derived and multiplied by the DB2 per-PVU 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 PVU pricing is that as new employees are hired, each new employee doesn't 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.
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 distributed edition of DB2 9.7 is right for you?" by Paul Zikopoulos.
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 since over time, new processors will be differentiated based on relative performance
- Enables sub-capacity licensing at the processor core
- Continues to deliver software price performance improvements
- Makes licenses more transferable across distributed systems since PVUs can be moved around to different database servers that run on different core architectures
- Provides clarity to middleware licensing.
The PVU model might be 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.
<!-- CMA ID: 180822 --><!-- Site ID: 1 --><!-- XSLT stylesheet used to transform this file: dw-document-html-6.0.xsl -->Learn
- "Compare the distributed DB2 9.7 servers" (developerWorks, Sep 2009): Compare the DB2 for Linux, UNIX, and Windows editions in a side-by-side comparison table.
- "Which DB2 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.7 is right for you?" (developerWorks, Sep 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.7.
- Now you can use DB2 for free. Download DB2 Express-C 9.7, 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
- developerWorks blogs: Get involved in the developerWorks community.
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 15 years of experience with DB2. Paul has written more than 300 magazine articles and 13 books on DB2 including, DB2 9.7: A Tour of Cost-Slashing New Features, 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..
6948
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
