There’s Money Hidden in your Database!
When thinking about helping to keep costs down for my customers, software costs - whether for new licenses or for ongoing maintenance - are always a major initiative. As Julian Stuhler wrote in his introductory article on the topic this month, software costs account for 21% of global IT spending.
I am often in situations where spending a little time evaluating requirements can result in big savings. This article will point you to some of the methods I use to help my clients control or reduce their DB2 licensing costs. But please – don’t tell your IBM Sales Rep!
Most of us are aware that IBM sells different editions of DB2 for Linux, UNIX and Windows, from the free DB2 Express-C up to Advanced Enterprise Server Edition. Each edition has different limits, both on software functionality and allowable hardware resources.
However, over the past few years, IBM has consistently increased the limits for each edition of DB2. If you have not been paying attention to these changes, looking at the current limits may give you the opportunity to use a “smaller” edition without having to change any of your hardware.
It’s important to keep these changes in mind – just a few years ago you may have needed to use DB2 Workgroup Server Edition to support your database, but the new higher limits would allow you to use DB2 Express – or even DB2 Express-C – today!
Choose Your Hardware Carefully
I have worked in organizations that like to consolidate hardware (leveraging LPARs or virtualization) – moving toward the mainframe model where you have fewer large servers. While this does provide cost savings, it can also end up costing more.
One of the least known facts about IBM’s Processor Value Unit (PVU) pricing is that PVU values depend not just on the particular model of CPU, but also on the physical configuration of the server. You might think that a CPU core is a CPU core, but IBM actually offers different PVU values for the same CPU!
Given that the number of cores per CPU socket has continued to increase, this little-known-fact can allow you to save a significant amount of money if you are careful about the hardware that you choose. For example, with a Power 770 server, DB2 is licensed at 120 PVU per CPU core; the smaller Power 750 is listed at 100 PVU per core, and a Power 740 requires only 70 PVU per core.
A Power 740 server can be configured with a maximum of 16 cores, and this will eventually limit your growth. However, you can support a very, very large DB2 database with 16 cores, and you’ll be using only 1,120 PVU of DB2 licenses. When you compare this to the cost of running a 16-core LPAR on a Power 770 (1,920 PVU, or 71% higher cost), the ability to grow a single LPAR beyond 16 cores often becomes significantly less attractive.
These hardware-specific prices are not limited to IBM POWER servers; there are similar options for Intel and SPARC-based servers as well. IBM publishes a document with current PVU licensing details for all CPU types.
Don’t Pay for What You Don’t Need
Paying only for what you need, when you need it, is an absolutely brilliant way to help reduce costs. There are two options here for doing this with DB2: Sub-capacity licensing and cloud computing.
Customers often will size their hardware environment to be capable of supporting the absolute maximum load that they expect to see. However, if your workload varies on a weekly, monthly (month-end processing) or even yearly (“Black Friday”) basis, you can take advantage of sub-capacity licensing.
With a sub-capacity licensing agreement and hardware that allows you to adjust the amount of CPU and memory available to an LPAR dynamically, you can reduce your DB2 licensing costs during the “low” periods, and increase capacity only during the high periods. To do this, you must run an agent on your server that monitors resource utilization, but the cost savings can be significant.
Another option you have to reduce costs is to leverage the cloud. IBM has always given you the option to “bring your own” DB2 licenses to virtual servers running in the cloud. However, you also have the ability to use IBM-provided virtual machine images that include DB2 licenses. These virtual machine images have a marginally higher operational cost per hour than the same machine without the DB2 license, but this gives you the flexibility of only having to pay for DB2 while the instance is actually in use.
This is a fantastic option for QA or performance validation environments that do not have a 24x7 availability requirement.
Consider Alternate Licensing Metrics
The most common licensing metrics available for DB2 are based on hardware (PVU) or users (AUSI). However, IBM offers one additional licensing metric for customers running analytic workloads: Terabyte pricing.
With Terabyte pricing, IBM offers you the ability to license DB2 software based on how much data your database contains. IBM counts only raw data in your database – not indexes, MQTs, temporary tables, etc – and the metric is calculated only after compression is applied.
As with all software licensing, there are some restrictions and gotchas with Terabyte licensing. One of the biggest caveats is that it is licensed per database, which means that if you have a small staging database or other small application databases on the same server(s) as your large analytic database , you will pay for 1 Terabyte of DB2 for each and every database, regardless of how small the database is.
However, for customers who have CPU-intensive analytic workloads (or those who have “too much” CPU), migrating to terabyte pricing may be able to save you a significant amount of money. One of my customers calculated that it would cost them less money to purchase new Terabyte licenses for one of their data marts than to pay the next year’s software maintenance on their existing Advanced Enterprise Server Edition PVU licenses.
There are many ways of optimizing how you run your DB2 environment. Reading licensing terms may not be terribly exciting, but if you understand how licensing terms change and spend a little time evaluating your current (and future needs), you may be able to find some of that money, hidden within your database.
The limit of 16 cores in a single machine isn’t even really a limit anymore. With pureScale, you can continue to grow your database’s capacity on additional servers (at 70 PVU/core).↩