Execution plans, enough to act

Reading a plan for THE TWO OR THREE THINGS THAT MATTER, without becoming a course on the optimiser. An execution plan is how the database intends to answer a query, and you do not need to understand all of it to act on it. Three things carry almost all the diagnostic value. ONE: FULL TABLE SCANS ON LARGE TABLES. Reading every row of a large table to find a few is the commonest expensive mistake. It is not automatically wrong — scanning a small table is fine, and scanning a large one to return most of it is correct — but a scan of a big table returning three rows is a finding, and it usually means an index is missing or an existing one cannot be used because of how the query is written. TWO: THE ROW ESTIMATES AGAINST WHAT ACTUALLY HAPPENED. This is the highest-value thing in a…

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