Running Out of Gas

Don't miss out on the most obvious clues by not paying attention to your database's "gas gauge."

---

It takes a license to fly a private plane, and it takes a lot of determination to get that license: physical examinations, lessons, tests, both written tests of knowledge and exacting evaluations of flying skill. You only become a pilot after considerable expenditure of time, money and energy. And in spite of all that - and the fact that the pilot might be flying a plane purchased with his own hard-earned money, and a plane that carries those he loves the most, one of the leading causes of private airplane accidents is what is called “fuel starvation.”1

In other words, the engines ran out of gas. It causes private plane crashes twice a week on average.²

Twice a week.

Sometimes it’s caused by a bad gauge. Sometimes it’s caused by a bad fuel pump. And sometimes - way too often - it’s caused by pilot error. The pilot wasn’t paying attention, or was paying attention and thought he could make it. Except he didn’t.

A friend knew a pilot who made just such a miscalculation. He tried to make it with the fuel he had and didn’t make it, costing his own life and the lives of two other people in the plane with him.

He was a good pilot - but he failed to pay attention to the most obvious thing: planes can’t keep flying without gas.

Whether it’s football, or airplanes, or databases, or anything else, there are certain fundamentals that must be right.

DBI Software is in the database business. Our patented, award-winning software ensures that many of the world’s top companies run IBM DB2 LUW databases at peak efficiency. It’s a high stakes business - full of powerful machines, run by expensive, sophisticated programs, overseen by highly-intelligent people, all in the service of companies that employ multiplied millions of people. They all know that if the database is slow, the company won’t grow.

But when a database is slow, it comes down to one thing: it doesn’t have the right indexing design. Some indexes will be harmful and not helpful, while in other instances they might be missing altogether. Even if your servers have terabytes of memory and solid state disks, your CPUs will run out of gas if the index design does not properly support the workload.  Just like everyone has different fingerprints, every organization’s implementation of a database is unique. Coke’s database is different from Costco’s.

So if you find yourself in a situation where your IBM DB2 database is slow, ask your IT executives these questions:

1. Are you running IBM’s freely bundled performance management tools like OPM or DSM? If so, know that they are likely making your problems worse with overhead or by obfuscating root-cause problems.
2. Are the same people who installed the poorly-performing database the ones who are leading the charge to fix it? If so, know that the same ones who got you in this mess are unlikely to get you out of it without spending a lot more money.
3. Has your team taken DBI’s free 15-Second Challenge? If not, then this is the place to start. We fix your database problems in an afternoon, and for a fraction of the price of non-returnable CPUs, memory, and licenses. Guaranteed.