Success Stories



Cards & Letters

Tell Me More

White Papers

Amazing but true...

One site in New York reduced CPU busy rate from 99% to 39% in less than one week.

"This application was notorious for poor performance. Now the machine is bored."

Mr. Confidentiality
A Company in NY

It's the Little Things!

Have you ever been bitten by an elephant?

Have you ever been bitten by a mosquito?

There you go! It's the little things in life that bite you!

And you know what? Since we started this DB2 performance tools business a few years ago, do you know what we often hear from our customers?

It's the little (unexpected) SQL statements that bite them

  • In the State of Illinois, a team of six Database Administrators worked on a new, high volume, OLTP application for two years. They carefully explained and scrutinized every SQL statement. With their machine running a steady 100% CPU busy, they called us. In 10 minutes (includes installation time), SQL-GUY found a single SQL statement that was consuming 33% of all the CPU resources.

    select max(somedate) from table where key1 = value;

    When DB2 Explained, the optimizer's estimated cost was barely double digits with estimated cardinality of 3. This simple statement never caught anyone's attention during performance analysis and implementation testing...

    ... but it consumed 33% of all CPU time ...
    (sorts, big and small, are expensive)

    After making an index change, this customer was able to reclaim that 33% CPU time... it was like getting a free CPU on an SMP 4-way machine... and transaction throughput rates climbed accordingly.

  • In the State of Florida, one company's e-Commerce web site slowed to an unacceptable crawl. CPU was a steady 100% busy. The application team had recently added some functionality improvements. Everything looked great and performed well in the test environment.
    We put Wise-GUY and SQL-GUY to work, and, in a matter of a few minutes, we identified the culprit SQL statement:

    select * from sometable where int_key_col = value order by char_col4;

    DB2 Explain indicated the optimizer's cost was virtually "free" for this statement that was estimated to retrieve just 8 of 350 total rows in the table... all buffered, no physical I/O, just a little 8 row composite sort (10,000 times per minute)...

    ... but it consumed almost 70% of all CPU time ...

    After adding a clustering index, reorg, and runstats, the high CPU cost of that simple SQL statement was abated and e-Business performance returned to "exceptional".

We love stories with happy endings, and we hope we can help you create and maintain success stories in your shop.
Your business deserves the best. Please contact sales for more information.

Simple. Easy. Fun. Informative. Valuable.
"At last, I can see what is going on."
-A DBA in Massachusetts

Home | Contact Us | Support | Top 10 Tips | Customer Feedback | Careers | Downloads
Live! Monitor Our Database!   |   Live! Monitor Our Tables!
White Papers and Other Resources

Copyright © 2003 Database-Guys. All rights reserved. Privacy and Legal details.