The cry heard around the DB2 world of late has been, “How much CPU is DB2 Version 8 going to use?” Whether you call it CPU consumption, regression, or simply usage, this seems to be a big question on everyone’s mind. For some, it’s merely curiosity; they’re moving forward regardless. However, they’d like to be prepared should something increase so they can adequately plan for it. Others, however, have questions that must be answered before they’ll start their V8 upgrade. Still others aren’t even considering an upgrade to V8 until they’re comfortable they won’t be affected by any CPU increase.

This article addresses concerns that DB2’s CPU utilization will be horrible. Please note that the opinions expressed here are mine only and not necessarily those of IBM, its affiliates, or employees.

When you completed previous version upgrades, you always faced the possibility of some kind of CPU increase. With each version, DB2 is adding functionality, improving features, and increasing the amount of code that comprises DB2, all of which have the potential of increasing the amount of CPU it uses. This is the price of progress and V8 is no exception.

Consider what you’re getting in V8:

  • A ton of new SQL
  • Lots of new access paths
  • A bunch of stuff that makes DB2 easier to work with.

The catalog has been converted to Unicode and now uses long names. V8 has considerably more code than V7, and it’s now taking advantage of 64-bit processing, which, by itself, can make things more exciting. Sometimes, 64-bit instructions may take a little more time to run than their 31-bit counterparts; words are longer, registers are longer, control blocks are larger (some as much as twice as large), and some old 24- and 31-bit stuff needs to be expanded to 64- bit before it can be used.

So, if you’re thinking CPU could increase, you’re probably right. The problem lies in the amount of increase you think you might see. Those estimates are all over the board and based on a variety of information, some of which is misunderstood and some just plain ignored.

It’s fascinating that CPU is such a focal point in V8 upgrade discussions because CPU was rarely a significant discussion point in past upgrades. We (IBM, DB2 consultants, users) created most of this controversy for ourselves. Sometimes, we can be just a little too helpful. In the past, we’d discuss CPU on a feature-by-feature basis. However, in V8, we knew there could be some increases because of the reasons previously listed, so we tried to forewarn people with a little too much information.

So, this article carefully looks at what you might expect to see in V8. You might see some CPU regression. That’s a given. So what actions will you take if you do see those CPU numbers increase more than expected? There are two answers here: one for Compatibility Mode (CM) and one for New Function Mode (NFM). Let’s look at CM first.

Compatibility Mode

The first action you can take to reduce the amount of CPU consumed in V8 CM is to start rebinding your plans and packages. Some access paths you may get in V8 could use less CPU. If you don’t rebind anything, you’ll pay the price for V8 without reaping any of the benefits. If you have a tool such as Path Checker that tells you if you’ll improve your access path by doing a rebind, you can reduce the number of total rebinds you may have to do and limit those to just the rebinds that will benefit you. Rebind is your first defense to increasing CPU cost, so take advantage of it.

3 Pages