Skip to Content
Technical Articles
Author's profile photo Ankit Rastogi

AMDP Statement performance trace

1.    Objective

The objective of this blog is to explain step-by-step process to trace AMDP method to analyze the performance and pin-point any performance bottlenecks.

2.    Requirement

Requirement is to analyze performance of any AMDP method which gives us a fair idea about its execution times across it’s modularization units such as subsequent AMDP method calls within any AMDP method. The developer would like to leverage AMDP statement trace utility to address this requirement.

3.    Understanding limitation in regular performance traces

3.1 Transaction SAT

SAT transaction gives us performance snapshot across processing blocks in given transaction or report program. This transaction provides the execution time of any given method, any given subroutine or any function module etc. along with its percentage with respect to total. With new code push down techniques now more and more code is being pushed to database layer, we are seeing increase in AMDP methods. However, SAT transaction gives us idea that AMDP method is taking how much time, but it is displayed as single row in SAT analysis snapshot mentioning as database procedure (DB: Exec).

The limitation arises when AMDP method is not so much straight forward. What if AMDP method itself has thousands of lines of code with multiple AMDP methods call with in an AMDP method. See below screenshot.

One can see here one AMDP method CL_FR_DAYS_CALCULATION=CALC_FR_DAYS_PLAN takes majority time approx. 28% of total (5.2 secs) in it’s processing. When we see this AMDP method, we find that it has around 1500 lines of code with multiple AMDP method calls from with in. So it becomes difficult to pin point the bottleneck in performance by seeing SAT results.

3.2   Transaction ST05

Transaction ST05 is also powerful tool to analyze performance. It provides various traces such as SQL Trace, Buffer Trace, RFC Trace etc to trace and analyze the results. In case of AMDP methods, SQL trace provides results similar to SAT Transaction. It provides one line of result that this database procedure is taking how much of the time. But what is causing that much time is not clear by looking at the result. See below screenshot.

One can see here ST05 trace also provides high level view on AMDP method performance. It tells us that around 5.3 sec is execution time of our AMDP method, but it does not provide any further information on what caused this execution time.

4.    Steps to trace AMDP method

The following steps explain step by step process for AMDP method trace:

4.1      Run Transaction AMDP_UTILS

This transaction provides list of AMDP utilities present in our system.

4.2     RS_AMDP_STMT_TRACE Report

Double click on the line having RS_AMDP_STMT_TRACE report name and following screen appears.

Here we see self-explanatory buttons similar to transaction ST05 where one can switch on and switch off AMDP statement trace.

Click on button ‘Activate Trace’ and then run your transaction.

Once your transaction is complete, click on button ‘Deactivate trace’ and then button ‘Display Trace Entries’ to display the trace result.

5.    Understanding AMDP trace with an example

In our current example, we have seen that the method CL_FR_DAYS_CALCULATION=>CALC_FR_DAYS_PLAN takes 5.2 secs. Let’s trace it with AMDP_UTILS transaction and try to identify its performance bottlenecks.

Step 5.1: Activate the AMDP trace for current user

Run transaction AMDP_UTILS and then choose statement RS_AMDP_STMT_TRACE.

Click on button ‘Activate Trace’.

Confirmation message is displayed that trace is switched on for current user.

Step 5.2:

Now run your transaction and once your transaction is finished click on ‘Deactivate Trace’ button.

Step 5.3:

Now click on ‘Display Trace Entries’ button.

Following screen appears.

It list down all the AMDP method calls within your transaction and also displays execution time against each AMDP method. Once can see here our AMDP method CL_FR_DAYS_CALCULATION=>CALC_FR_DAYS_PLAN_AMDP takes 5.4 secs

Scroll to the right

We see a column ‘Display’. We can click on this button against any particular AMDP and it will display details about each processing block with in AMDP method.

Step 5.4:

Click display button in front of AMDP method CL_FR_DAYS_CALCULATION=>CALC_FR_DAYS_PLAN_AMDP

Following screen appears.

We can see from here that out of 5.4 secs, 3.35 secs were spent while executing one underlying AMDP CL_FR_DAYS_CALCULATION=>CALC_OUTB_QTY_EXTEN. Rest other AMDP’s are executing at fairly normal level.

Step 5.5:

As we now know the performance pain point, we can focus our analysis in this AMDP only. After analyzing this AMDP CL_FR_DAYS_CALCULATION=>CALC_OUTB_QTY_EXTEN, it was found that we have put SELECT DISTINCT unnecessarily in one of it’s select query. This SELECT DISTINCT was causing underlying select query to run slow.

Once we removed this SELECT DISTINCT, the performance is greatly improved. We can see the stats after this change.

AMDP Trace after the code change:

SAT Trace after the code change:

Once can see the improvement in the performance.

Earlier same AMDP method was taking approx. 5.4 secs (28% of total), now after code changes, it takes only 0.3 secs to execute less than 2% of total execution time.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Badal Bhasin
      Badal Bhasin

      Very informative blog..Very well explained!!

      Author's profile photo Jonathan Bourne
      Jonathan Bourne

      The AMDP trace tool is not yet available in S/4 1610.

      Author's profile photo Ankit Rastogi
      Ankit Rastogi
      Blog Post Author

      It is available in 1709



      Author's profile photo Vijayakumar Mukunthan
      Vijayakumar Mukunthan

      Hi Ankit

      The blog is very clearly explained step by step execution and new learning to me. Keep it up. Good job.

      Thanks and Regards


      Author's profile photo Gaurav Sharan
      Gaurav Sharan

      Thanks for sharing.. Very Informative.

      Author's profile photo Venkata Sreekar Krothapalli
      Venkata Sreekar Krothapalli

      Thanks for the detailed steps.

      We are on SAP BW 750, SP 08 and don't have the the transaction: AMDP_UTILS or some of the other programs you've mentioned in this blog. What's the minimum system requirement to perform the various AMDP traces you've outlined in your blog ?

      Author's profile photo Dominik Kacprzak
      Dominik Kacprzak

      It is AMDP_UTIL not AMDP_UTILs

      Author's profile photo Dominik Kacprzak
      Dominik Kacprzak

      My list of available reports is much shorter. There is not trace.

      Do I need to implement some notes with missing reports?

      All I get:


      Author's profile photo Mandar Athavale
      Mandar Athavale

      Hello Dominok,

      Same here, did you find answer to your question ?

      We can see below options in this Tcode.



      Author's profile photo Lakshminarasimhan Narasimhamurthy
      Lakshminarasimhan Narasimhamurthy

      Nice document, I was able to trace the AMDP method in the SAP BW system using the AMDP_UTILS. But was when i executed the BW transformation(program) the trace was not recorded!! it was only getting recorded when i manually executing the AMDP script from the SE24 !

      Author's profile photo Benjamin Schweizer
      Benjamin Schweizer

      Really great summary. Thanks.

      However, I'm facing the issue that I want to trace my AMDP logic within my planning function (BW/4 HANA system). The trace from RS_AMDP_STMT_TRACE is not logging that.

      It doesn't matter whether I execute this planning function from any frontend (SAC, AfO) or via the transaction RSPLAN.

      Am I missing any settings or do I need to prepare something else in order for this to work?

      I just want to analyse the performance of my AMDP logic to see whether I can make some adjustments to it. Thank you in advance