A baseline is what makes a report meaningful

Without a NORMAL to compare against, EVERY NUMBER LOOKS ALARMING. Taking one WHILE THE SYSTEM IS HEALTHY. This is the cheapest lesson in the module and the one most often skipped, because taking a baseline is work you do when nothing is wrong. A HEALTHY EBS SYSTEM PRODUCES NUMBERS THAT LOOK BAD IN ISOLATION. Millions of buffer gets, waits measured in hours, statements consuming enormous elapsed time. Every one of those is what a busy system doing its job looks like — and shown a report during an incident, a person with no comparison will find something alarming, because there is always something. SO THE BASELINE IS WHAT CONVERTS A NUMBER INTO EVIDENCE. Forty percent of database time on one statement means nothing until you know it was four percent last month. WHAT TO CAPTURE IS A SMALL SET AND IT SHOULD BE PERIODIC. An AWR from a normal busy…

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