Beruflich Dokumente
Kultur Dokumente
analysis to optimization
Posted by Manfred Hoffmann Jun 5, 2013
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 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.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
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 3 : Avoide many small request and selecting not needed columns
------------------------------------------------------------------------------------------------------------------------------------------------------------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.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
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
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
1. 1. Percentage DB time (ascending) and
2. Percentage Change time (ascending).
You can do this if you apply a filter on both columns using the values given above.
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.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Now choose the object you are interested in. We will analyze a single program, so enter the mandatory data.
You can also check multiple objects, even the contens of a transport request.
Now grab either a pre-defined variant or choose from the list below.
In the first step we will use the four test delivered with 7.40 to identify problematic SELECT statements.
Now run the inspection and take a look at the result list. In our example, SAP Code Inspector has returned two
areas of concern:
In our case the system detects a SELECT * statement, and from the analysis less than 10% of all fields
retreived are used. As this analysis is done by an algorithm, it is always wise to review the analysis and decide
based on a code analysis, wich field should be in the field list.
Let's go on, and jump to the affected lines of code. You can do this directly from the result
After this is reviewd and - if possible - fixed return to the result of the analysis and go to the second finding.
Here we are informed of a nested SELECT.
Let us have a look at the new checks added to SAP Code Inspector with focus on efficient ABAP programming
on SAP HANA.
In two sections SAP has added new checks
1. Section Performance Checks has four new checks
1. 1. Search problematic SELECT * statements
2. Search SELECT .. FOR ALL ENTRIES-clauses to be transformed
3. Search SELECT statement with DELETE statement
4. Search SELECTs in loops across modularization units
What does this mean in detail, and what does the check for me? The inline documentation gives us more
information:
.............................................................................................................................................................
If you have switched on to get detail information, there are the additional messages:
SELECT A SELECT-* statement has been found,
COMP A component of the result of a SELECT-* statement is used.
ALL The complete result of a SELECT-* statement is used by the current statement.
NOEVAL The current state uses the result SELECT-* and has not been evaluated
LEVEL The evaluation has been aborted at the specified procedure.
....................................................................................................................................................................................................
If you have switched on to get detail information, there are the additional messages:
NoMoves Number of moves of the internal table
Effort The effort to correct this problem. It is calculated as follows:
Effort = Effort for each call * number of calls + Effort for one assignment * NoMoves + 10.
Severity The severity of this problem is a measure for the performance loss due to this problem.
It is always 1.
.............................................................................................................................................................
Search for
SELECT .. INTO TABLE tab statements which are followed by a DELETE statement for the result table tab .
The checks delivers the following test result parameters
SEVERITY The severity is always 1
EFFORT The effort is the distance in lines between the
SELECT and the DELETE statement
.......................................................................................................................................................................................................
Performance Check 1.4: Search for SELECTs in loops across modularization units
..............................................................................................................................................................
Robust Programming 2.1: Deepooling/Declustering: Search SELECT for Pool/Cluster-Tables w/o ORDER BY
Search for SELECT and OPEN CURSOR statements for pool or cluster tables where no ORDER BY clause
is specified.
This situation is problematic because the order of the returned database entries changes if the data base table
is modified into a transparent table.
Remark: SELECT SINGLE statement are not analyzed since they are not problematic.
Remark: If the result of the SELECT statement is moved into a sorted internal table, a special message is
raised
Messages of the test can be suppressed via the pseudo comment "#EC CI_NOORDER
.............................................................................................................................................................
Robust Programming 2.2: Search problematic statements for unsorted results of SELECT or OPEN
CURSOR statements
This check searches for the following statements where the internal table is the result of a SELECT statement
without ORDER BY clause. Without ORDER BY clause or other sorting measures the result of the select
statement may be unsorted. So the statements may not work properly.
Check parameters:
Only local calls: With this parameter you can specify if external procedure call should be
analyzed, too.
Local analysis depth: The evaluation process start at the top level procedures of a compilation
unit and follows the calls to other procedures. With this parameter you can specify the maximal
evaluation depth.
Non-local analysis depth: With this parameter you can specify the maximal evaluation depth into
external programs.
------------------------------------------------------------------------------------------------------------------------------------------------------------Coming next
In the next section we will continue with will have a look at Transaction /nT05 (SQL Trace) and how SQL Trace
will help us on our journey to performant ABAP on HANA programming.
Sort the lis by e.g. Time to see the time consuming statements.
Select the one you want to get more information and click on the SELECT statement to see the details of the
WHERE clause.
------------------------------------------------------------------------------------------------------------------------------------------------------------17787 Views Tags: hana, abap, code_inspector, sql_trace, abap4hana, abaponhana, abapforhana,
abapinhana, abap_for_hana, abap_trace
2000002
Heecheol Yeom
Jan 14, 2015 10:05 AM
I should say that this is very helpful blog! Thanks for blogging.
I'm already excited to next blog.
Hyuk Joo Lee
Jan 9, 2015 1:59 AM
Thanks!
Syam Babu
Apr 15, 2014 9:03 PM
Well Written...Thanks.
Trond Stroemme
Sep 24, 2013 1:12 PM
Very thorough and useful. But of course the real gain with HANA is pushing code down to the DB layer avoiding (too much) Open SQL in your ABAP code.
Simon Rotherham
Jun 27, 2013 11:57 PM
A great blog that is not just relevant for ABAP on HANA but also relevant for all ABAP developers in order to
produce efficient code.
Abdul Hakim
Jun 10, 2013 12:17 PM
Useful info. Thanks for sharing with the community.
Aby Jacob
Jun 9, 2013 1:20 PM
Excellent !! Thanks for sharing