What breaks: four performance investigations that went wrong

MEMORY ADDED to a system waiting on disk, AN INDEX ADDED to a table nobody queried that way, A KILL THAT ROLLED BACK FOR TWO HOURS, and A FIX THAT WORKED BECAUSE SOMETHING ELSE WAS RESTARTED AT THE SAME TIME. THE MEMORY ADDED TO A SYSTEM WAITING ON DISK IS LESSON 3 IGNORED. The system was slow, memory is the default suspicion, and a window and a purchase later nothing improved — because the sessions were waiting on I/O and had memory to spare throughout. The measurement was available before the money was spent, and the cost is not only the hardware: everybody now believes performance work does not help. THE INDEX ADDED TO A TABLE NOBODY QUERIED THAT WAY IS THE ONE THAT DOES ONGOING DAMAGE. It was proposed from reading a query rather than from measuring what runs, so it is never used — and every insert and…

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