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. Because of this, CPU improvements were one of the major design goals for DB2 10. Many savings are available “out of the box” with no application or database changes required. There are even more available with some DBA/developer effort!
What CPU reductions can you expect for transactions, queries, and batch?
- CPU reductions of 5-10% for traditional workloads
- Up to additional 10% CPU savings using new functions
- CPU reductions of up to 20% for new workloads
- For static SQL, REBIND typically required