The business side says the application is slow. In the daily monitoring report, CPU usage looks unremarkable and all the lights are green. Both are right: For a few minutes the CPU ran at full load, and in the daily average the spike disappears.

This session is not about a tool. It's about how measurements turn into a statement you can base decisions on. I deliberately start far away from technology: with my coffee consumption. When do I drink how much? And why is Wednesday, of all days, so expensive? Using this example, I show how aggregation hides patterns, how the choice of metric changes the message, and why it's fine to filter out atypical days, as long as you say why.

Then I apply this to measurements from SQL Server. In the lab, a single load spike shows up as 4, 38 or 77 percent CPU, depending on the resolution. A statement that runs for eight milliseconds can still be the problem if it is executed more than a thousand times with every click. And in my view, the night with the unscheduled index rebuild must not end up in the baseline by accident.

Finally, we look at how numbers become a picture that gets through to the business side without bending the data. Along with that come five questions you should ask any chart before you believe it.

The session is aimed at DBAs who present measurements and at everyone who makes decisions based on such data. After this session, you'll spot what a chart isn't telling you and build your own charts so that they speak for themselves. No code, no formulas.