Measure before you tune

The one habit that separates this from guesswork. What to measure, and WHY THE FIRST THING EVERYBODY SUSPECTS IS ALMOST NEVER IT. Performance work divides cleanly into two activities: measuring, and guessing with confidence. The second is far commoner and it produces changes that are defensible, expensive, and unrelated to the problem. THE FIRST THING EVERYBODY SUSPECTS IS RESOURCE: NOT ENOUGH MEMORY, NOT ENOUGH CPU, NOT ENOUGH HARDWARE. It is almost never that. An EBS system that was fast last month and is slow today is running on the same hardware, so unless something measurable changed in the load, the resource is not the variable. WHAT IT USUALLY IS: ONE STATEMENT WHOSE PLAN CHANGED — Lesson 8 — ONE SESSION BLOCKING OTHERS, OR ONE JOB DOING FAR MORE WORK THAN ANYBODY REALISED. All three are specific, findable, and invisible to any conversation about capacity. SO MEASURE WHERE THE TIME GOES…

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