ABAPAdvanced
Performance Tuning
Master ABAP performance tuning with SQL optimization, ST05, SAT, SQL Monitor, internal table strategy, buffering, package processing and real production debugging.
Overview
Master ABAP performance tuning with SQL optimization, ST05, SAT, SQL Monitor, internal table strategy, buffering, package processing and real production debugging.
Lessons in this topic
- Performance Part 1: Measuring with ST05, SAT and STADMeasure before tuning: STAD to see where the time goes (DB, CPU, wait, RFC), ST05 SQL trace (statements, executions, records, identical selects, execution plan), SAT runtime analysis (hit list, call hierarchy), and ST12 as a combined tool — with a repeatable measuring routine.
- Performance Part 2: The Database-First RuleApply the database-first rule: read only needed rows and columns, use full keys and indexes, avoid repeated identical reads, aggregate in the database, use buffering where appropriate, and understand why database round trips dominate most ABAP runtimes.
- Performance Part 3: Tuning in Real Projects — Measure, Fix, VerifyRun performance work like a project: define targets, reproduce with production-like volumes, find the top offenders with STAD/ST05/SAT, fix the biggest item first, verify with numbers, protect with ATC/SCI performance checks and SQL Monitor, and communicate results.
- Performance Part 4: SELECT Inside LOOP — The Classic Performance KillerRecognise and fix SELECT inside LOOP: why thousands of single reads are slow, how it appears in ST05, rewriting with one set-based read (FOR ALL ENTRIES or JOIN) plus a sorted/hashed lookup table, handling SELECT SINGLE in loops, and hidden cases inside function modules and methods called per row.
- Performance Part 5: FOR ALL ENTRIES — Correct Use and Hidden RisksUse FOR ALL ENTRIES correctly: the empty driver table trap (reads the whole table), automatic duplicate removal (and why you must select full keys), sorting and deleting duplicates in the driver table, package sizes, large driver tables, and when a JOIN or range is better.
- Performance Part 6: Internal Tables — Standard, Sorted and HashedChoose the right internal table type for performance: linear search on standard tables, binary search and sorted tables, hashed tables for key lookups, secondary keys, nested loops with WHERE on sorted tables, parallel cursor technique, and memory aspects.
- Performance Part 7: JOIN vs FOR ALL ENTRIES vs Nested SELECTCompare data retrieval patterns: nested SELECT (worst), FOR ALL ENTRIES (driver from ABAP), INNER and LEFT OUTER JOINs (database does the work), when each fits, join conditions on keys, number of joined tables, buffered tables in joins, and views/CDS for reuse.
- Performance Part 8: HANA Pushdown with Open SQL, CDS and AMDPMove data-intensive logic to SAP HANA: code-to-data principle, aggregations and joins in Open SQL, CDS views for reusable models with calculations and associations, AMDP for procedural SQLScript, when pushdown helps and when it doesn't, and keeping classic ABAP readable.
- Performance Part 9: Package Processing for Large Data VolumesProcess millions of records safely: SELECT … PACKAGE SIZE with ENDSELECT, OPEN CURSOR WITH HOLD / FETCH NEXT CURSOR, committing between packages, restartability, memory limits, and parallel processing with background jobs or aRFC for very large runs.
- Performance Part 10: Indexes, Selectivity and WHERE ConditionsUnderstand how indexes serve WHERE conditions: primary key and secondary indexes (SE11), field order and leading fields, selectivity, conditions that prevent index use (NOT, <>, leading wildcards, functions), client field, checking the execution plan in ST05, HANA specifics, and when (not) to create a new index.
Interview questions covered
- How would you use parallel processing (aRFC or bgRFC) to shorten a batch run, and what risks do you plan for?
- What is the risk of using FOR ALL ENTRIES with an empty internal table?
- Why is SELECT inside LOOP considered bad for performance?
- A nested LOOP AT itab1 / LOOP AT itab2 WHERE key = itab1-key is a hotspot. How do you refactor it?
- A report runs for 2 hours on production and 5 seconds in DEV. How do you approach tuning?
- How do you decide between JOIN, FOR ALL ENTRIES and CDS for performance?
- You need to reduce end-to-end latency of a Fiori OData list from 8s to under 2s. Walk through your plan.
- What is ABAP performance tuning?
- A report reads 900,000 order rows with SELECT * and then filters and sums them in ABAP. How do you improve it?
- A nightly job loads more than ten million records into one internal table and fails with a memory dump. How do you redesign it?
- An MM report occasionally reads nearly all purchase order items and runs for hours. What is the likely cause?
- A report filtered only by posting date and returned millions of rows slowly. How do you use indexes and WHERE conditions to fix it?
- A month-end job takes three hours and must finish in 30 minutes. How do you run this tuning task?
- How do you optimise a LOOP AT itab WHERE ... on a large standard table?
- A job is fast in DEV/QA but slow in production only during month-end. Where do you start?
- A sales order enhancement added one MARA SELECT per item, and order saves became slow for large orders. How do you fix it?
- A large sales report repeatedly searches a standard internal table inside a loop. How do you optimise it?
- A report loads five million billing rows into ABAP and aggregates them by customer and month. How would you improve it on HANA?
- A slow finance report is blamed on the ALV display. How do you prove where the time really goes?
- A report selects order headers and then selects items inside the header loop. What alternatives exist, and how do you choose?