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 its 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 Im looking forward to sharing some news and insights with you each month.
For this first column, I thought wed take a look at IBMs 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 its 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 Ill 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.
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 wasnt 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 dont 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 youre on V8 today, the chances are that youre 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 wont be looking to move to DB2 10 for another 18-24 months at the very earliest, theres 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 youre brave or unlucky enough to be running on V7 (unsupported for well over a year now) youll 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 youve done that, youre going to be nicely placed to take advantage of the skip migration and go directly to DB2 10. Likewise, if youve 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. Ive tried to summarise this decision making process in the flowchart below.
Whichever path you take, make sure youre getting some good advice on the pros and cons, and go in to the migration project with your eyes open. Dont 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 youve decided how youre 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. Theres plenty of interesting new function in DB2 10 which may assist with building that case, but even leaving that aside theres 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 thats 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, its 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.
Ill return to the subject of DB2 for z/OS Version 10 in a future column, as theres plenty more to discuss regarding the new features and functions in that release. See you next month.