Lesson 5 of 5
Prioritizing
9 min
Listen to this lesson
Contoso's first ATC run after conversion produced thousands of performance findings across the custom code. Kenji's team has room for perhaps a few dozen tuning items before go-live. Fixing findings in the order ATC lists them would spend that time on code that runs once a quarter. This lesson is about choosing: using usage and runtime data to tune what matters.
The principle: cost times frequency
A statement that takes 2 milliseconds and runs ten million times a day costs more than one that takes 30 seconds and runs once a month. What matters is total cost (time per execution times executions) and business impact (who waits, and what deadline is at risk). Runtime data usually follows a steep curve: a small number of statements account for most of the database time. Find them first.
Usage data you can use
| Source | What it tells you | Contoso use |
|---|---|---|
| SQL Monitor (SQLM) in production | Executions, total and average time, records read per statement, with source position and entry point | Top statements by total database time after go-live |
| SQL performance tuning worklist (SWLT) | ATC findings ranked by runtime data | Which of the thousands of findings actually run |
| Custom code usage data (for example from the ABAP call monitor) | Which custom objects are used at all, and how often | Retire unused code instead of tuning it |
| Job logs and batch chain timings | Runtime against the overnight window | Protect the nightly chain and month-end |
| Key user feedback with times and apps | Where people wait | Maria's list of slow steps in order-to-cash |
Inputs for a tuning backlog. Combine system data with business deadlines and user pain.
Before go-live, production SQL Monitor data from the new system does not exist yet. Use what you have: ECC usage and job statistics from EP1 tell you which custom code runs often and which jobs are time-critical, and SQL Monitor runs in CMQ during regression cycles show the expensive statements under test load. After go-live, switch to production data and re-rank.
- CollectSQL Monitor in production or CMQ regression; ECC usage and job statistics before go-live
- RankBy total time, then by business deadline and user impact
- Join with findingsUse the tuning worklist to see which hot spots have known anti-patterns
- Fix the top itemsPushdown and anti-pattern fixes with unit tests and performance criteria
- Re-measure and re-rankConfirm the gain, then move to the next items
Avoiding wasted effort
- Do not tune dead code. If usage data shows nobody runs a report, retire it.
- Do not micro-optimize ABAP when the database dominates; check the trace split between ABAP and database time first.
- Do not fix findings in bulk without tests. Every change can alter results; tuning without regression evidence trades a performance risk for a correctness risk.
- Stop when the criterion is met. Further gains on a job that already fits its window rarely beat the next item on the list.
What would you do?
Kenji has capacity for five tuning items before the dress rehearsal. Candidates: (1) a month-end report that takes 25 minutes and runs once a month with no deadline issue; (2) a read in order save that takes 4 ms and runs 600,000 times a month; (3) the fleet rebate run, which threatens the overnight window; (4) 300 ATC findings in a package no one has run since 2019; (5) the open deposits report, used all day and taking 9 seconds. Which choice best fits the principles?
- Prioritize by total cost (time times executions) and business impact, not by finding count.
- A few statements usually account for most database time; find them with SQL Monitor.
- Use ECC usage and CMQ regression data before go-live; production SQL Monitor data after.
- Retire dead code, check ABAP versus database time, and back every fix with tests.
Check your understanding · not graded
Lesson check
1. Which statement usually deserves tuning first?
2. What should happen to custom code that usage data shows is never run?
3. Before go-live, which data can help rank tuning work?
4. A trace shows 90% of a report's time in ABAP, 10% in the database. What should Kenji tune first?