SAP Performance

ST03 (workload analysis) shows where time is spent, response time broken into database, CPU, wait and other components, by transaction and time period. It is the starting point for performance work: it tells you what is slow and why, rather than guessing.

• Buffers (ST02): ensure program and table buffers are well-sized to avoid database hits.
• Database (ST04, ST05 SQL trace): find and fix expensive SQL and missing indexes.
• Work processes (SM50/SM66): right mix and enough of each type.
• Custom code: the frequent culprit, SELECTs in loops and the like.

One area not on most lists and frequently the answer: locking. A long-running job holding a lock makes every user waiting on it appear slow, and the symptom is indistinguishable from a capacity problem until you look at SM12. Checking locks early is cheap and it resolves a surprising share of "the system is slow" reports outright.

The single most useful skill here is breaking a response time into its parts, because each part points somewhere different.

Wait time is the request sitting in the queue before a work process picked it up. High wait time means there are not enough work processes, or they are all occupied by something long running. It is not a database problem, and tuning the database will not help.

Database time is the request waiting for data. High database time means an expensive statement, a missing index, or a table that has grown beyond what the access path assumed.

CPU time is the application server doing work. High CPU with low database time usually means processing in ABAP that should have happened in the database.

Roll and load time covers context switching and program loading, and unusual values here point at buffer problems rather than at the program.

Lock time is waiting for something another user holds.

The diagnostic value is that the split tells you which specialist the problem belongs to before anybody has argued about it. A slow transaction with high wait time is a capacity conversation; the same transaction with high database time is a completely different one.

Baseline with ST03, drill to the worst offenders, use SQL trace (ST05) or ABAP runtime analysis (SAT) to find the cause, fix one thing, re-measure. Most big wins come from fixing bad custom SQL and right-sizing buffers/database.

The order matters because each step narrows the next. Start with ST03 to find where time is spent across the whole system rather than starting from the complaint. Take the worst transactions by total time, not by average, because something run ten thousand times a day at two seconds costs more than something run once at a minute. Then trace one execution with ST12 or SAT to see where inside it the time goes. Only then look at the statement in the database monitor.

Working the other way, starting from a statement somebody noticed, produces optimisation of things that were not costing anything.

An hour on a system with real load, and it is the core skill of the discipline.

1. Open ST03 for last week and sort the transaction profile by total response time.
2. Take the top entry and read its split: wait, database, CPU.
3. If database dominates, open ST04 or the equivalent and find the expensive statements for that program.
4. Read the execution plan. A full scan on a large table with a selective where clause is a missing index; a selective plan with high volume is a design question.
5. If CPU dominates, trace it with ST12 and look for loops doing work the database could do in one statement.
6. If wait dominates, look at SM50 during a busy period and count what the processes are actually doing.

On HANA, many traditional bottlenecks vanish, but performance work shifts to pushing logic to the database and avoiding row-by-row processing. The measure-first principle still rules.

What changes specifically: aggregation and selectivity stop being expensive, so reports that were slow because they summed millions of rows become fast without being touched. What does not change is code that selects rows into the application server and loops over them, which is now the dominant pattern in anything still slow. On HANA, a performance problem in custom code is usually a pushdown problem. See HANA administration for the database side.

Performance work has a hierarchy of return, and knowing it stops effort going where it will not help.

Custom code is nearly always first. It was written for a data volume that has since grown, and a single badly written select inside a loop can dominate a system's database time. Fixing one program often outperforms every parameter change available.

Missing or wrong indexes come next, and they are cheap to add and easy to over-apply. Every index costs on write, so adding one per slow query eventually slows the updates.

Buffering matters where small configuration tables are read constantly. A table that should be buffered and is not produces enormous read counts for trivial data.

Work process configuration is capacity rather than tuning: enough dialogue processes for the users, enough background processes for the jobs, and separation so a long job cannot occupy everything.

Housekeeping is the one people forget. Tables that grow forever slow down everything that reads them, and archiving is a performance activity as much as a storage one.

Hardware is last, and it is where the conversation usually starts. Adding capacity to an inefficient system buys time and not a fix.

Most performance work is reactive, and the systems that stay fast are the ones somebody watches when nothing is wrong.

A weekly baseline. Run ST03 weekly and record the top transactions by total response time and the average dialogue response. Two months of that turns "it feels slower" into a number and a date.

Growth. Table sizes and database growth per month. A table growing faster than its neighbours is either a business change or a job that stopped clearing it.

Job runtimes. A nightly job creeping from two hours to five is the earliest warning of a volume problem, and it is visible months before users notice anything.

After every release. Compare the baseline before and after. New custom code arrives with each release, and the fastest way to find the expensive piece is to see what changed in the profile.

None of this takes long once it is routine, and it converts performance from an emergency into maintenance.

• Tuning without measuring (ST03 first).
• Ignoring expensive custom SQL.
• Under-sized buffers hammering the database.

• Tuning the thing somebody complained about. It is rarely the thing costing the most, and ST03 will say so.
• Adding an index without checking existing ones. Every index costs on write, and several overlapping ones are worse than one designed.
• Changing several parameters at once. Nothing is learned about which one helped. See RFC administration for a common source of hidden waiting.

• Optimising a report run once a month. Total time is the measure, not duration, and a two second transaction run ten thousand times a day costs far more than a slow monthly job.

Reading a monitor is the start, and diagnosing a real slowdown from the workload profile down to the statement is the part you do in the course.

The discipline that matters most is measuring before changing. ST03 first, always, because the thing somebody complained about is rarely the thing costing the most.