Part 1: Introduction
This document describes relevant steps to maximize the effect of ABAP performance tuning of custom coding for an SAP System running on HANA DB.
We will focus on tools and guidelines delivered by SAP.
We will start with a procedure how to find candidates (reports, transactions) that show a significant potential for performance improvements optimizing ABAP coding.
In each section of this document we will discuss different aspects of the optimization starting with the identification of potential candidates and ending with tips and tricks from real live projects.
The sections are
- The golden rules – Five performance guidelines for ABAP database operations
- How to find candidates – Use ST03N
- The toolbox – Code Inspector and ABAP Trace
- Optimizing ABAP code – Use FOR ALL ENTRIES and JOINs
- Tips and tricks – Some hints based on our experience
- Code pushdown – Stored procedures and HANA Artifacts
Each of the section can be read individually, but to get most out of this document it is recommended to read them in sequence.
-----------------------------
Outlook
In the following section we will discuss the classical programming paradigms and their meaning for programming on SAP HANA.
-----------------------------
Part 2: The Golden Rules
There are five performance guidelines for ABAP database operations. Despite all changes in the Database technology that come with SAP HANA, these classic programming paradigms remain valid.
With this in mind, we will put one Key message on top of this chapter
- All classical performance recommendations are still valid
as general guidelines - On SAP HANA some of the recommendations have a higher
performance and some of the classical design pattern are of least importance
Let us have a look at the rules and their meaning as a rule of thumb
What does this mean for our ABAP code? We will know look at each rule what what they mean in the context of SAP HANA
Rule 1 : Keep the result set small
Rule 2 : Minimize amount of transferred data
Rule 3 : Avoide many small request and selecting not needed columns
Rule 4 : Define and use appropriate secondary indexes
Rule 5 : Keep unnecessary load away from the database
-----------------------------
Outlook
In the next section will will use Transaction ST03N (Workload Analysis) to analyse the workload on our system and to identify reports and transactions, that can benefit from code canges and gain performance from SAP HANA.
-----------------------------
Part 3: How to find candidates for optimization
There are several ways to identify reports and transactions that will benefit from code rework.
- Look at reports and transactions that are named by users
- Review the EWA report
- Follow the procedure described below
We will now describe how to use Transaction ST03N to identify reports and transactions that will potentially benefit from SAP HANA.
3.1 ST03N - Workload Analysis
With our approach we will gain most from SAP HANA if we focus on ABAP programs with high DB load. The tool of choice is transaction ST03N (Workload Analysis).
How to proceed? In the following we will show brief step-by-step procedure
Step 1:
Call transaction ST03N
Switch to Expert mode first.
In the Workload tree choose Total
Servers and select the last full month.
In the Analysis Views choose the Transaction Profile folder and choose Standard
Step 2:
Go to tab “All Data” and download the list to Excel.
You can now manipulate the data, e.g. apply filter and hide or delete not columns you are not interested in.
If you remove columns from the list, it is recommended to keep the following ones:
Step 3:
Now we can check where the runtime comes from.
Create two new colums in your Excel to calculate percentage of DB time and
percentage of change time. Use this formula
To reduce the number of lines in the result add a filter on Trans/Rep. and apply a textfilter with the restriction to all names in customer namespace. This will
limit your selection to all transaction and reports that can be changed by a programmer without the need to modify SAP standard code.
SAP will take care of its own code and provide changes with patches and notes. Certain scenarios will benefit from SAP Standard Accelerators on HANA (Side Car, e.g. CO/PA Accelerator).
Sort the list by
- Percentage DB time (ascending) and
- Percentage Change time (ascending).
Reports will benefit from HANA if DB time is mainly caused by
- sequential reads ( -> column Total Seq. Read time (s) or T Seq.Read Time ) and the
- time for changes is rather low ( -> column Total Time for Logical DB Changes (s) or T Changes ).
To identify these reports restrict the result list to reports/transactions with
- DB time high ( >70% ) and
- change time low ( <= 1% )
You can do this if you apply a filter on both columns using the values given above.
Finally, the result table should look like this
In our example above we have marked these lines that fulfil our requirement on DB time and Change time in yellow.
Now you have created a list of candidates for code optimization. In the next sessions we will have a more detailed look on ABAP programs using SAP tools to identify areas with potential, the possible code changes and the result of these changes.
-----------------------------
Coming next
In the next section we will have a look at some tools from SAP that will help us with the analysis of our ABAP code. With this information we can later do changes and also analyze pros and cons of our approach.
-----------------------------