UPDATE 6 OCT 2011: IMHO, one customer switching is TOO MANY.
Why would an IBM DB2 LUW customer abandon its investment in DB2 and head for the competitors? Lower price? I doubt that. Better features or functionality? Unlikely. I suspect it boils down to performance disappointment and glossy brochures.
UPDATE 6 OCT 2011: During The DB2Night Show™ Episode #59 on Index Design, Best Practices, Myths, Realities, and Magic with special guest Martin Hubel, we asked our studio audience polling and survey questions to ascertain their opinions on why organizations might switch from one database to another. In order of popularity (most likely reason to least), our audience indicated these reasons:
If you missed this show, Martin shared many pearls of wisdom, tips, and techniques. WATCH THE REPLAY
The original premise of this blog presumed that organizations switched databases largely because of performance. As it turns out, performance was only the second most popular response after COST. I now have heightened awareness, although I assert there remains a very tight correlation between Performance and COST. A well tuned database will operate with less CPU and I/O consumption whilst delivering higher performance satisfaction to its user community. If you throw money at hardware to achieve performance, your costs will be much higher than they need to be. It doesn't matter what database your organization operates for its business - databases must be tuned to deliver maximum value (highest performance at the lowest possible costs).
Here's the rub - DB2's Achilles' heel - if you will: DB2 license bundling. IBM includes IBM Optim Performance Manager (affectionately known as OPM) with Advanced Enterprise Server Edition (AESE), Workload Manager Performance Optimization Feature (POF), the Database Partitioning Feature (DPF), Smart Analytics Systems, and more. It seems OPM is pretty hard to avoid unless you are a small enough organization to run DB2 Express. Inasmuch as IBM OPM is freely bundled into so many DB2 licensing packages, it is, for all intents and purposes, virtually a free part of DB2.
It is bad manners in the software industry to not say nice things about your worthy competitors. But IBM OPM isn't a competitor - it is part of DB2 - so we can, and should, have a conversation about it.
You can get a free toy inside a box of Cracker Jacks. Also check the box for cautionary wording to the effect of "choking hazard".
So, inside your box of DB2, you get a "free" performance tool. Terrific. Another free tool to augment "db2pd", "db2top", "db2mon", SQL Snapshots, and all the other "free" stuff out there. There are two important axioms to remember:
UPDATE 6 OCT 2011: Since the original posting of this blog a few weeks ago, no one has contacted me to express their happiness with OPM. To the contrary, discussions in various LinkedIn groups have been poignant. Visit the DB2 UDB DBA LinkedIn Group and see what people are saying.
To the contrary, what we hear is that IBM OPM takes weeks or months to install and implement - that is if you can get it working with or without help from the Germany lab. I'm also told by several sources that the overhead on the monitored database server is extremely high - in the range of 20-30%. Further, IBM OPM users are encouraged to purchase a separate machine for the IBM OPM server - but, no worries, you can get a free limited use license of DB2 ESE for THAT machine.
Well, there's the first three strikes against IBM OPM:
I'm not making this crap up. It's in the IBM OPM documentation. I've verified the analysis flaws with my own testing. And I have a pretty good understanding of why OPM's overhead is so high.
In fairness, as free tools go, even I can find a few things that I like about IBM OPM - if I could get past the first three strikes.
Why does IBM package OPM into the great majority of DB2 license packages?
Your IBM professional will tell you that the bundling is to provide DB2 customers with better value. Really? Is that free toy inside the box really free?
While these direct and indirect opportunity costs are painful, the ultimate cost is the cost of failure.
I know of one large company in the US that was working on rehosting a CICS/COBOL/DB2 z/OS application to the DB2 LUW distributed platform. They spent, they said, about six months working with Germany to get OPM working. Finally, one day last month, they flipped the big switch and cut over to the new distributed DB2 LUW system. And they fell flat on their faces with a system that was too slow and frequently crashed. After being in Sev 1 Crit Sits for 3 days while their business was out of business, the company called DBI and I had a chance to get involved and help. We had their system stabilized and performing better in just a couple of hours.
Why didn't IBM OPM help this customer avoid this catastrophic failure? INCOMPLETE and INACCURATE INFORMATION.
As long as we have this wound opened up, let's rub some more salt into it. Because this new system was too slow and unresponsive, the first thing this organization did was what many companies do - they threw hardware at the problem - they doubled the number of CPU cores from 12 to 24 - incurring, of course, not only hardware costs but also DB2 license costs. The hardware upgrade didn't work.
After I worked with this customer for a few days, response times were markedly improved and CPU utilization dropped to 30-40%. The customer asked IBM for a refund on the hardware upgrade. Once again, we were all reminded that CPUs are like underwear - not returnable. IBM declined to refund the upgrade costs. IBM also declined to refund the customer money it paid (separately) for IBM OPM.
Lesson learned: Tune (with a tool that actually provides results) BEFORE upgrading hardware.
So, why are DB2 LUW customers switching to other databases?
IMHO, because IBM provides a free toy, sorry - tool, called OPM inside the DB2 box. Executives are excited because they just "got a value deal" from IBM. Database Administrators are encouraged to use the free tool. The free tool adds overhead to the DB2 server and fails to reveal true root cause performance problems and tuning opportunities. Performance mediocrity prevails, at best. Applications and Data Warehouses grow, and performance deteriorates. Performance dissatisfaction sets in. People complain. Competitive database sales people show up with glossy brochures promising the moon. A multi-million dollar deal gets inked with (another database vendor) and the migration journey begins. Why? Oh yeah, IBM provided those free tools in the box with DB2 that virtually assured DB2's performance failure.
UPDATE 6 OCT 2011: In fairness, per the earlier update, organizations might switch FROM other databases TO DB2 for a number of reasons with "COST" being the most likely driver. IBM states that over 1,000 customers switched from (another database) to DB2 last year. I haven't been introduced to all 1,000 yet, but DBI has had the opportunity to work with some of the customers that switched. And, yes, we helped tune those migrated databases up! READ THIS PRESS RELEASE.
Think outside the box. The IBM DB2 box, that is.
I wish you many happy, successful days with DB2.
Post from : http://www.dbisoftware.com/blog/db2_performance.php