ERPClimb logoERPClimb
Login
ABAP · Performance

SAP ABAP Performance Tuning Interview Questions

Performance tuning is almost never asked as a definition question. It arrives as a scenario — a report that used to finish in minutes now runs for hours — and the interviewer is measuring whether you measure. Candidates who start listing optimisations before naming a measurement tool are the ones who get filtered out.

This page collects reviewed ABAP performance and Open SQL interview questions with complete written answers. Between them they cover the analysis path (trace before change), the database side (selective WHERE clauses, index usage, aggregate and join behaviour, buffering), the ABAP side (nested loops, sorted and hashed access to internal tables, reads inside loops), and the S/4HANA-era question of what should be pushed down to the database instead of looped in ABAP.

The answers deliberately keep the order that works in a real interview: what you would measure, what the measurement would tell you, what you would change, and how you would prove the change helped. That last step is the one most candidates skip and most interviewers are listening for.

What interviewers actually probe

Measure first

Expect to be asked which tool you would reach for before touching code. SQL trace and runtime analysis are the two answers that carry weight, and being able to say what each one shows you — statements and their cost versus where the time is spent in the program — matters more than naming them.

Selectivity and indexes

Most slow SQL in ABAP is a selection that cannot use an index or a read placed inside a loop. Interviewers probe whether you reason about which fields are actually restricted, not whether you can recite 'add an index'.

Internal table access

Standard, sorted and hashed tables, binary search on a sorted table, and the cost of nested loops are near-guaranteed questions at 2–6 years of experience, usually as 'this loop is slow — what would you change?'.

Pushdown on HANA

For S/4HANA projects the question becomes where the logic belongs. Aggregation, joins and filtering done by the database instead of by an ABAP loop is the expected direction, along with an honest account of when that is not worth it.

22 questions with full answers

Ordered from foundational to advanced. No sign-in required.

easyPerformance Tuning

1. A report reads 900,000 order rows with SELECT * and then filters and sums them in ABAP. How do you improve it?

I apply the database-first rules: move the filters into the WHERE clause (dates, order types, sales org) so the database returns only relevant rows; replace SELECT * with the few fields needed; and if the report only shows totals, let the database aggregate with SUM … GROUP BY (grouped by currency where amounts are summed). Then the report transfers thousands instead of hundreds of thousands of rows. I verify with ST05 (records, duration) and compare totals with the old version to ensure identical results.
easyPerformance Tuning

2. An MM report occasionally reads nearly all purchase order items and runs for hours. What is the likely cause?

Classic FOR ALL ENTRIES trap: when the driver table is empty (e.g. no headers match the selection on some days), the FAE condition is ignored and the SELECT reads all EKPO rows (limited only by other WHERE conditions). The fix is to check the driver table with IF lt_ekko IS NOT INITIAL before the FAE SELECT. I would also check that the result selects the full key (EBELN, EBELP) — FAE removes duplicate rows based on selected fields — and deduplicate the driver table.
easyPerformance Tuning

3. A slow finance report is blamed on the ALV display. How do you prove where the time really goes?

I measure instead of guessing. STAD for the report's dialog step or job shows the response time split: database time, CPU (ABAP) time, RFC and wait time. If DB time dominates, the ALV isn't the issue — ST05 then shows which SELECTs cost most (executions, records, identical statements, explain plan). If ABAP time dominates, SAT's hit list shows whether time is in data processing (loops, internal table reads) or in ALV preparation. Typically the ALV is a small part; the cost is a SELECT inside a loop or a large read. I document the numbers before and after each change.
mediumPerformance Tuning

4. What is the risk of using FOR ALL ENTRIES with an empty internal table?

If the FOR ALL ENTRIES driver table is empty, the condition based on that table can be ignored and the SELECT may fetch a much larger dataset than expected. Always check the driver table is not initial before the SELECT.
easyPerformance Tuning

5. Why is SELECT inside LOOP considered bad for performance?

SELECT inside LOOP can execute one database call per loop record. If the loop has thousands of entries, it creates thousands of database round-trips. A better design is to collect keys, fetch data once and use internal table lookup.
mediumPerformance Tuning

6. A nested LOOP AT itab1 / LOOP AT itab2 WHERE key = itab1-key is a hotspot. How do you refactor it?

Convert itab2 to a SORTED or HASHED table on the join key and use a single LOOP with READ TABLE ... WITH KEY, or use LOOP AT itab2 INTO ... USING KEY. Complexity drops from O(n*m) to O(n log m) or O(n). If both tables are large and static, materialise the join once into a lookup hashed table; if the join is DB-side, move it to a JOIN or CDS view.
mediumPerformance Tuning

7. A report filtered only by posting date and returned millions of rows slowly. How do you use indexes and WHERE conditions to fix it?

I check SE11 for the table's indexes and ST05 explain for the chosen access path. If posting date isn't a leading field of any index, the database scans; and even with an index, a wide date range isn't selective. I add selective leading fields users actually know — company code, document type, account — to match the primary key or an existing index, make them mandatory on the selection screen, and consider index tables or suitable views for specific access paths. A new secondary index is the last step, only after measurement and considering write costs; on HANA, better filters and fewer columns usually suffice.
mediumPerformance Tuning

8. A month-end job takes three hours and must finish in 30 minutes. How do you run this tuning task?

I define the target and baseline (current runtime, variant, data volume), reproduce with production-like data in QA or measure carefully in production (STAD history, SQL Monitor). I find the top offenders: STAD for DB vs ABAP time, ST05 sorted by duration, SAT hit list. Usually one or two items (SELECT in loop, standard-table lookups, huge reads) cause most of the time. I fix them in order of impact, verify runtime and identical results (row counts, totals, output comparison) after each change, and prevent regression with ATC performance checks and a volume test before go-live.
mediumPerformance Tuning

9. How do you optimise a LOOP AT itab WHERE ... on a large standard table?

A WHERE clause on a STANDARD table is a linear scan. Options: (1) sort the table by the WHERE fields and use LOOP AT ... FROM/TO, (2) define a SORTED secondary key and LOOP ... USING KEY, (3) redesign as HASHED if lookup by unique key, (4) pre-filter into a smaller work table. On HANA, push the filter into the SELECT itself.
mediumPerformance Tuning

10. A sales order enhancement added one MARA SELECT per item, and order saves became slow for large orders. How do you fix it?

This is SELECT inside a loop: one round trip per item. I collect the distinct material numbers of the order's items (SORT + DELETE ADJACENT DUPLICATES), read MARA once with FOR ALL ENTRIES (after checking the key table is not empty) into a hashed table keyed by MATNR, and inside the item loop use READ TABLE … WITH TABLE KEY. Because the exit may be called repeatedly during one save, I also buffer the result for the transaction (e.g. in a global table of the exit's function group) to avoid re-reading. ST05 before/after shows the execution count drop.
mediumPerformance Tuning

11. A large sales report repeatedly searches a standard internal table inside a loop. How do you optimise it?

READ TABLE … WITH KEY on a standard table is a linear search, so inside a loop the cost grows quadratically. If the lookup is by a unique full key, I change the table to HASHED TABLE WITH UNIQUE KEY and use WITH TABLE KEY; for prefix or non-unique access, a SORTED table (LOOP … WHERE on the key prefix is optimised), or sort the standard table once and use BINARY SEARCH. For nested loops over headers and items, a sorted items table or the parallel cursor technique avoids scanning all items per header. I verify with SAT that the internal table time drops.
mediumPerformance Tuning

12. A report loads five million billing rows into ABAP and aggregates them by customer and month. How would you improve it on HANA?

Push the aggregation down: Open SQL with SUM … GROUP BY customer, currency and month (or a CDS view with the aggregation and a calculated period field) so HANA returns a few thousand result rows instead of five million raw rows. A CDS view is reusable for other reports or OData. AMDP is only needed if the logic requires multiple complex set steps not expressible in Open SQL/CDS. Row-wise business logic (messages, BAPIs) stays in ABAP. I measure runtime and memory before and after, and check that authorizations are handled (DCL for CDS).
mediumPerformance Tuning

13. A report selects order headers and then selects items inside the header loop. What alternatives exist, and how do you choose?

The current code is a nested SELECT with one round trip per header. Alternatives: an INNER JOIN of VBAK and VBAP on VBELN with the header filters in WHERE — the database returns all needed rows in one statement; or read headers first and then items with FOR ALL ENTRIES (with empty check and full keys). I choose the JOIN when all data comes from the database and the join is key-based with selective filters; FAE when the driver set is built in ABAP (after complex filtering, from a file or BAPI). Small buffered customizing tables are read separately into hashed tables. I compare both with ST05 when unsure.
mediumPerformance Tuning

14. A memory dump (TSV_TNEW_PAGE_ALLOC_FAILED) occurs in a report processing 3M rows. What do you change?

Stop loading everything into memory. Read in packages with SELECT ... PACKAGE SIZE, process each package, then FREE the driver itab before the next fetch. Move as much filtering/aggregation as possible to CDS/Open SQL so the ABAP side handles a much smaller result. If output goes to a file, stream it (open dataset, write per package) instead of building a giant internal table.
mediumPerformance Tuning

15. What is code push-down and how does it change your ABAP performance mindset on HANA?

Push-down means executing set-based data logic (joins, filters, aggregations, calculations) on HANA rather than looping in ABAP. Shift your mindset from read once, loop in ABAP to shape the data in CDS/AMDP/Open SQL, receive a small result set. This reduces round-trips, leverages column store and parallelism, and keeps ABAP focused on orchestration and business rules.
mediumPerformance Tuning

16. A report takes 30 minutes. How would you start performance analysis?

I would reproduce the issue with realistic input, run ST05 to identify expensive SQL and execution count, run SAT to understand ABAP runtime, check data volume, identify whether DB or ABAP processing is the bottleneck, then optimize the highest-impact area first.
mediumPerformance Tuning

17. Explain buffered vs non-buffered DB tables and when buffering hurts more than it helps.

Buffering keeps table content in the application server buffer. Great for small, mostly-read config tables. It hurts when the table changes often (invalidation storms across servers), when the table is large (memory pressure), or when reads always use non-key access that bypasses the buffer. Check with ST02 and TU02, and disable buffering for volatile master data.
hardPerformance Tuning

18. How would you use parallel processing (aRFC or bgRFC) to shorten a batch run, and what risks do you plan for?

Split the workload by an even key (e.g. company code range) and dispatch chunks via CALL FUNCTION ... STARTING NEW TASK (aRFC) or bgRFC units. Reserve a bounded server group so you do not starve dialog users. Plan for: uneven partitions (long-tail chunk), retry semantics, cross-chunk locks, and result aggregation. Always add a serial fallback path when the RFC destination is down.
hardPerformance Tuning

19. A report runs for 2 hours on production and 5 seconds in DEV. How do you approach tuning?

First reproduce with production-like data volume in QA. Run ST05 (SQL, buffer, RFC, enqueue traces) during a representative execution; look at total DB time vs ABAP time. Use SAT (SE30) for ABAP hotspots. Check execution plan for missing/unused indexes on the top statements, buffer settings, and whether SELECT SINGLE / SELECT ... UP TO 1 ROWS is used properly. Look for SELECT inside LOOP, nested loops without secondary keys, unnecessary sorts, and internal-table copies. Fix top offender first, re-trace to confirm, and add a regression test with production-scale data.
hardPerformance Tuning

20. A nightly job loads more than ten million records into one internal table and fails with a memory dump. How do you redesign it?

I process in packages: SELECT … PACKAGE SIZE (without commits inside) or OPEN CURSOR WITH HOLD with FETCH NEXT CURSOR … PACKAGE SIZE and a database commit per package. Each package is processed and released, so memory stays bounded. For robustness I read in key order and store the last processed key in a status table (or mark records), so the job can restart after failures without duplicates, and log per package in SLG1. If runtime is still too long, I split the key range into parallel jobs or aRFC tasks, making sure they don't lock the same objects.
hardPerformance Tuning

21. A job is fast in DEV/QA but slow in production only during month-end. Where do you start?

Compare data volumes (VBRK/BSEG are much bigger in prod) and the actual execution plan (ST05 + explain), because the DB optimiser can change plans as statistics shift. Check for concurrent long-running jobs in SM50, update statistics if outdated, and consider partitioning or scheduling to a quiet window. If a specific SQL plan flipped, freeze it with a hint after consulting the DB team.
hardPerformance Tuning

22. How would you assess the performance regression of a transport before releasing it to production?

Run ATC in the QA system with the performance-relevant checks enabled; execute the changed report/service under SAT (runtime analysis) with representative data volumes; capture SQL trace (ST05) before and after and diff the statement list. For services, use /IWFND/TRACES and a Postman/loadrunner script that mimics real payloads. Compare wall time, DB time, and memory use, and block the transport if any regression exceeds an agreed threshold.

Practise by experience level

8-12 years4-7 years1-3 years

The questions above are tagged by the experience levels they are normally asked at, so the same page works for a first interview and for a lead-developer round.

SAP ABAP Performance Tuning Interview Questions FAQ

What is the first thing you do when a report is reported as slow?

Reproduce it and measure it. A runtime analysis shows where the program spends its time and an SQL trace shows which statements the database actually executed and how expensive they were. Only after that measurement does it make sense to talk about indexes, buffering or restructuring loops.

Why is a SELECT inside a LOOP considered a problem?

Because it turns one database round trip into as many round trips as the loop has rows, and each of them carries fixed overhead regardless of how small the result is. The standard remedies interviewers expect are reading the required set once into an internal table and then working locally, or letting the database do the join and aggregation in a single statement.

How do you decide between a sorted table and a hashed table?

By the access pattern. A hashed table is for single-record access by full key and gives constant-time reads. A sorted table is for reads by a leading part of the key, for ranges and for processing in key order. A standard table with a linear search is the option to justify, not the default.

What does code pushdown mean in ABAP on HANA?

It means letting the database do set-oriented work — filtering, joining, aggregating, calculating — instead of transporting rows into ABAP and looping over them. In practice that shows up as more expressive Open SQL and CDS-based models, and as removing ABAP loops that only exist to add up or filter what the database could have returned already.

How do you prove a tuning change actually worked?

By comparing the same measurement before and after on comparable data volumes, and by checking that the result set is unchanged. Interviewers value the second half of that answer: a faster program that returns different data is a defect, not an optimisation.

Next practice step

Practise these questions with Interview AITake a mock test

Related SAP interview topics

ERP Climb is an independent educational platform and is not affiliated with SAP SE.