When it is the application, not the database

A slow report that is slow BECAUSE OF WHAT IT WAS ASKED TO DO. Recognising it, and HANDING IT TO THE RIGHT PERSON WITH EVIDENCE. Not every performance problem has a technical fix, and recognising the ones that do not is what stops weeks being spent on them. THE SHAPE IS A REPORT THAT IS SLOW BECAUSE IT IS DOING AN ENORMOUS AMOUNT OF LEGITIMATE WORK. Run with no date range, across every organisation, over five years of history. The plan is optimal, the statistics are current, the indexes are right — and it is reading forty million rows because that is what it was asked for. THE TELL IS THAT THE MEASUREMENTS COME BACK CLEAN. No plan problem, no waits worth naming, no blocking — just a large amount of work, efficiently done. When Lesson 7's estimates match reality and the plan is sensible, the query is not the…

In this module: Module 11 · Performance: finding the actual problem

1. 1Measure before you tuneFree preview
2. 2"The system is slow": turning that into a question
3. 3Where time actually goes
4. 4AWR and ASH, used properly
5. 5A baseline is what makes a report meaningful
6. 6Finding the expensive SQL
7. 7Execution plans, enough to act
8. 8Statistics: the commonest real cause
9. 9Locking and blocking
10. 10When it is the application, not the database
11. 11What breaks: four performance investigations that went wrong
12. 12Lab briefing · Diagnose three slow systems