ERPClimb logoERPClimb

SAP ABAP Performance Tuning Interview Questions

Performance Tuning comes up in SAP ABAP interviews because it is one of the few areas where an interviewer can tell, in two questions, whether you have worked with the process or only read about it.

Master ABAP performance tuning with SQL optimization, ST05, SAT, SQL Monitor, internal table strategy, buffering, package processing and real production debugging.

This page carries 12 reviewed SAP ABAP performance tuning interview questions, each with a complete written answer and no sign-in required. The set breaks down into 1 foundational, 7 mid-level and 4 advanced questions, so you can start at the top for a first interview or skip ahead to the scenario-based items for a senior round.

The fastest way to use this page is to read the question, answer it yourself, and only then read the answer. The gap between your version and the written one is your actual revision list for performance tuning.

Read the full guide: SAP ABAP Performance Tuning Interview Questions

12 Performance Tuning questions with answers

mediumPerformance Tuning

1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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.

Related lesson

HANA Pushdown with Open SQL, CDS and AMDP

Related topics

Internal TablesOpen SQLABAP CoreEnhancementsDebuggingOOP ABAPIDocUser ExitsWorkflowBAdISmartForms

Next practice step

Practice with Interview AITake a mock test