The beta of Version 10 of DB2 for z/OS is being made available to selected customers from March 12th 2010, and while there is no official word on General Availability dates yet I think it’s safe to assume that if all goes well with the beta, DB2 10 will be fully released sometime during the next…
Hello and welcome to my new monthly column, focusing on DB2 and
IBM Information Management. Despite the apparent maturity of the core DB2
database engine, the world of IBM Information Management is still developing at
an astounding rate and I’m looking forward to sharing some news and insights
with you each month.
For this first column, I thought we’d take a look at IBM’s
recent announcement of Version 10 of DB2 for z/OS. On February 9th, after
many months of anticipation and “technology preview” presentations at various
conferences, IBM finally announced the start of the beta process for the
product that went under the not-so-secret codename of “DB2 X”. The beta is being
made available to selected customers from March 12th 2010, and
while there is no official word on General Availability dates yet I think it’s
safe to assume that if all goes well with the beta DB2 10 will be fully released
sometime during the next 12 months or so.
As always, this new release of DB2 contains a large number of
enhancements and new facilities, and I’ll be covering some of the major ones in
future columns. However, before we get into that, I want to concentrate on two
specific aspects of DB2 10, which are pretty unusual as far as recent releases
are concerned, skip migration and performance regression.
Skip Migration
Traditionally, IBM has only supported migration to a new release
of DB2 from the release immediately preceding it (you could only migrate to V8
from a V7 subsystem, for example). Up until now, the only exception to this
rule was DB2 for z/OS Version 7, which supported direct migration from both V5
and V6. There were good reasons for IBM to offer this facility in 2001 when V7
became generally available, as “Y2K fever” had prevented many V5 customers from
being able to migrate to V6 according to their usual timescales. Skip migration
was a great way of helping those customers to catch up and climb back onto the
upgrade bandwagon, but it wasn’t without its downsides: it required IBM to
expend significant effort to develop and support, and left customers with twice
the number of pre-requisites to manage and new function to
absorb. Whenever the subject of skip migration came up in conversation
since then, several of my IBM friends were heard to mutter dark oaths, with
phrases such as “over my dead body” and “never again” being quite common.
Well, never say never. DB2 10 for z/OS will support skip
migration from V8 as well as from V9, and for very similar reasons to those
that convinced IBM to support the jump from V5 to V7 way back in 2001. Despite
DB2 9 containing some very attractive new functions and being Generally
Available for nearly 3 years now, the recent global economic downturn has
seriously impacted IT budgets and many customers still find themselves running
DB2 V8 (or even earlier releases).
So….does that mean that everyone on V8 today should wait and go
directly to DB2 10? No! As I already mentioned, skip migrations have
significant downsides in terms of increased complexity and risk, and don’t save
nearly as much time or money as you may think (you can expect a V8 to V10
migration to save somewhere around 20-25% when compared to separate V8 to V9
and V9 to V10 migrations). If you’re on V8 today, the chances are that you’re
missing out on some pretty significant business benefits that DB2 9 for z/OS
could provide, including some modest CPU savings for most workloads (more on
this below). Given that most customers won’t be looking to move to DB2 10 for
another 18-24 months at the very earliest, there’s a good case to be made for
established V8 sites to think about moving to DB2 9 now.
So….who is the skip migration actually going to benefit? If
you’re brave or unlucky enough to be running on V7 (unsupported for well over a
year now) you’ll hopefully be planning an upgrade to V8 very soon. V8 is a big
pill to swallow, and will probably keep you busy for the next 6-12 months while
you roll it out across your various environments. Once you’ve done that, you’re
going to be nicely placed to take advantage of the skip migration and go
directly to DB2 10. Likewise, if you’ve only just completed your V7 to V8
migration project and are unlikely to get management approval for another
migration to DB2 9 so soon after the last one, you may want to consider staying
with V8 for now and migrating directly to DB2 10 during the next 18-24 months.
I’ve tried to summarise this decision making process in the flowchart below.
Whichever path you take, make sure you’re getting some good
advice on the pros and cons, and go in to the migration project with your eyes
open. Don’t underestimate the effort involved in a skip migration, or the
“culture shock” for developers and support staff asked to take on two releases
worth of new function in a single, large, indigestible lump.
Justifying the Upgrade
OK, once you’ve decided how you’re going to get to DB2 10 for
z/OS, how do you go about justifying the upgrade? This is a huge issue for most
big DB2 shops, especially under the current economic conditions where clear,
short-term business benefit must be demonstrated before any major
infrastructure upgrade. There’s plenty of interesting new function in DB2 10
which may assist with building that case, but even leaving that aside there’s
an even better and more immediate benefit. DB2 10 promises significant CPU
reductions for most OLTP, query and batch workloads, with initial testing
showing savings of 5-10% out of the box with no application changes, when
compared to Version 9. Those figures could be doubled once applications are
changed to exploit the new function (as always, your mileage may vary!).
As most DB2 for z/OS customers are on some sort of usage-based
charging, lower overall CPU costs directly translate into lower monthly fees
for the DB2 licence; an immediate, quantifiable business benefit. Of course,
less CPU will also usually result in lower elapsed times and better response
time for your users, but that’s often much more difficult to quantify.
To understand how important this will be to most DB2 customers,
we need to take a look at some recent history. Most releases of DB2 in the past
have kept performance regression very low, with customers typically taking a CPU
hit of less than 5% out of the box (and all or some of that could usually be
clawed back later through implementing new function). Version 8 of DB2 for z/OS
was somewhat more painful for most customers, with the inefficiencies
associated with the move to 64-bit addressing typically increasing overall CPU
usage by 5-10% and sometimes even more. That CPU increase made it even more
difficult than usual for many infrastructure managers to put together a convincing
business case for upgrading to V8, especially as many sites began to consider
the upgrade just as the current financial crisis began and IT budgets were
squeezed. Although Version 9 has since redressed the balance somewhat with
modest CPU savings for many customers, it’s clear that IBM was determined to
provide a compelling cost case for moving to Version 10 in addition to some intriguing
new function.
Of course, returning to the subject of skip migration for a
moment, those customers that do decide to make the leap directly from Version 8
to Version 10 may see even bigger potential savings, as they will benefit from
the cumulative CPU reduction of both V9 and V10 in one hit.
I’ll return to the subject of DB2 for z/OS Version 10 in a
future column, as there’s plenty more to discuss regarding the new features and
functions in that release. See you next month.
