1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 1/14

Getting Started Newsletters Store

Products Services & Support About SCN Downloads

Industries Training & Education Partnership Developer Center

Lines of Business University Alliances Events & Webinars Innovation

Log On Join UsHi, Guest Search the Community

Activity Communications Actions

Browse

ABAP for SAP HANA

0 Tweet

Part 1: Introduction  This document describes relevant steps to maximize the effect of ABAP performance tuning of custom coding for anSAP 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 forperformance improvements optimizing ABAP coding.  In each section of this document we will discuss different aspects of the optimization starting with the identification ofpotential 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 insequence.       Outlook In the following section we will discuss the classical programming paradigms and their meaning for programming onSAP HANA.   

Part 2: The Golden Rules There are five performance guidelines for ABAP database operations. Despite all changes in the Database technologythat 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 validas general guidelines

On SAP HANA some of the recommendations have a higherperformance 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 

ABAP on HANA  from analysis to optimizationPosted by Manfred Hoffmann in ABAP for SAP HANA on 05Jun2013 16:11:20

Share 10 4Like

1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 2/14

  What does this mean for our ABAP code? We will know look at each rule what what they mean in the context of SAPHANA

 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

1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 3/14

  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 toidentify reports and transactions, that can benefit from code canges and gain performance from SAP HANA.

  

1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 4/14

     

Part 3: How to find reports, programs and transactionsoptimization 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 benefitfrom 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 ofchoice is transaction ST03N (Workload Analysis).How to proceed? In the following we will show brief stepbystep procedure Step 1:

Call transaction ST03N

Switch to Expert mode first.

In the Workload tree choose TotalServers 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 interestedin.

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 andpercentage of change time. Use this formula

1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 5/14

       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 incustomer namespace. This willlimit your selection to all transaction and reports that can be changed by a programmer without the need tomodify SAP standard code. 

SAP will take care of its own code and provide changes with patches and notes. Certain scenarios will benefitfrom SAP Standard Accelerators on HANA (Side Car, e.g. CO/PA Accelerator). Sort the list by

 

1.  Percentage DB time (ascending) and

2.  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 thetime 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 inyellow. Now you have created a list of candidates for code optimization. In the next sessions we will have a moredetailed look on ABAP programs using SAP tools to identify areas with potential, the possible code changes andthe 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 ourABAP code. With this information we can later do changes and also analyze pros and cons of our approach.

    

Part 4: Analyze and optimize ABAP Code  static codeanalysis 4.1 SAP Code Inspector SAP code Inspector is a tool designed to perform static code checks. For shure it will not find everything, but you willsee it is a fine tool to find and eleminate common mistakes, that are hidden in your code. It is especially useful if youstart working on code that was designed and written years ago and there is a need to find areas for improvementwithout spending time for a detailed analysis. How does it work? We will guide you through the tool without going to all facts and features and will concentrate us onthe checks that will help us on our journey towards performant ABAP code running on SAP HANA.  

1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 6/14

Now start SAP Code Inspector and create a new inspection.

 Enter transaction code SCI (or /nSCI) and this will lead you to the initial screen

            We will run a new Inspection, soenter a name and proceed.

    

      

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

                              Let's have a brieflook at the test wehave flagged Searchproblematic

SELECT* statement> This test will find statements selecting all fields. This can be replaced with a field listSearch SELECT . . . FOR ALL ENTRIESclauses to be transformed> Go further and find out, if this can be replaced using a (LEFT OUTER) JOINSearch SELECT statement with DELETE statement> Try to avoid deleting single lines (within a loo), transfor this to an array operationSearch SELECTs in loops across modularization units> This will help you to find nested SELECTs hidden in modularization unigs, e.g. in FORMs or ROUTINEs  Now run the inspection and take a look at the result list. In our example, SAP Code Inspector has returned two areas ofconcern:             

1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 7/14

   

Select a line and double click on it to see the details      

Again choose one of the messages to see the details       

In our case the system detects a SELECT * statement, and from the analysis less than 10% of all fields retreived areused. As this analysis is done by an algorithm, it is always wise to review the analysis and decide based on a codeanalysis, 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 weare informed of a nested SELECT.

           Let us have a look at the newchecks added to SAP CodeInspector with focus onefficient ABAP programmingon SAP HANA.

In two sections SAP hasadded new checks

1. Section PerformanceChecks has four new checks

1.  Search problematic SELECT* statements

2.  Search SELECT .. FOR ALL ENTRIESclauses to be transformed

3.  Search SELECT statement with DELETE statement

4.  Search SELECTs in loops across modularization units

   2. Section Robust Programming has two new checks

1.  Search problematic SELECT * statements

2.  Search problematic statements for unsorted results of SELECT or OPEN CURSOR statements

   What does this mean in detail, and what does the check for me? The inline documentation gives us more information:  .............................................................................................................................................................  

1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 8/14

 Performance Check 1.1: Search problematic SELECT * statementsSearch for

SELECT * FROM dbtab statements which should be transformed into SELECT comp1 comp2 ...FROM dbtab.

This check searches for SELECT * FROM dbtab statements where less than a specified percentage of thefields are effectively used. The default value for the percentage is 20 percent. If less than 20 percent of thefields are used it is more adequate to select only the used fields.If single subroutines are specified by the check set, only the coding in these routines is checked.Check parameters:

Minimum table size category: with this parameter you can restrict the search on SELECTstatementsthat access database tables with a size category that is equal or larger than the parameter. The sizecategory is maintained in the technical settings of a database table in the ABAP dictionary (SE11).Minimum number of table fields: with this parameter you can restrict the search on SELECTstatements that access database tables with equal or more columns than the parameter.Only search for these tables: here it is possible to restrict the search to accesses to the selectedtables.Percentage of fields: Percentage of used table fields to be considered as "few"Evaluation level: The evaluation process start at the top level procedures of a compilation unit andfollows the calls to other procedures. With this parameter you can specify the maximal evaluationdepth.Exclude buffered tables: Normally accesses to buffered tables are analyzed as well. With thisparameter you can exclude it.Not to be transformed selects: Display also information about SELECTstatements which should notbe transformed.

Display detail information: If you switch on this parameter you get very detailed information about theaccess to the result of the select* statements and the evaluation process. EFFORTParameters

EFFORT for one assignmentEFFORT for one column access

   The check delivers the following result messages:   

FEW SELECTStatement can be transformed, because less than the specified percentage of fields isused.MANY SELECTStatement should not be transformed, because more than the specified percentage offields is used.EXISTS SELECTStatement can be transformed very easily, because it is used just for an existencecheck. The work area or any of its components are not used.UNCLEAR The situation for the select statement is unclear because of one of two reasons:

The result of the SELECTstatement cannot be analyzed further on

The evaluation was aborted because the evaluation level has been exceeded.

   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 evaluatedLEVEL The evaluation has been aborted at the specified procedure.

   The checks delivers the following test result parameters   

SEVERITY The severity is the number of columns of the data base table which are read but not used

EFFORT The effort is computed via the following formula:

 ....................................................................................................................................................................................................  Performance Check 1.2: Search SELECT .. FOR ALL ENTRIESclauses to betransformed

Search for 

SELECT ... FOR ALL ENTRIES statements which can be joined with other SELECT statementsThis check searches for SELECT ... FOR ALL ENTRIES where the input for the for all entries table is theresult of another SELECT statement. In this case the two statements can be joined into one statement with

1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 9/14

an improved performance.The two SELECT statements can be in different subroutines.If single subroutines are specified by the check set, only the coding in these routines is analyzed.Buffered tables, except those with single record buffering, are excluded from the analysis. In this case twoSELECTstatements are more adequateGeneral parameters: 

Minimum table size category: with this parameter you can restrict the search on SELECTstatementsthat access database tables with a size category that is equal or larger than the parameter. The sizecategory is maintained in the technical settings of a database table in the ABAP dictionary (SE11).Only search for these tables: here it is possible to restrict the search to accesses to the selectedtables.

Effort parameters:Effort for one assignment: with this parameter you can determine the effort for an assignment of theinternal table that was filled by the select statement to another table.

Effort for each call: with this parameter you can determine the effort of a call between the select andthe select for all entries.

 The check delivers the following result messages:

TRANSFORM The SELECTFORALL statement can be joined with another SELECTstatement. Theposition of the second statement is mentioned in the message text.LEVEL The evaluation has been aborted at the current procedure, because the maximum evaluationlevel has been reached

 If you have switched on to get detail information, there are the additional messages:

NoMoves Number of moves of the internal tableEffort 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.

 .............................................................................................................................................................  Performance Check 1.3: Search SELECT statement with DELETE statement  

Search for 

SELECT .. INTO TABLE tab statements which are followed by a DELETE statement for theresult table tab .

 The checks delivers the following test result parameters

SEVERITY The severity is always 1EFFORT The effort is the distance in lines between theSELECT and the DELETE statement

...................................................................................................................................................................................................................................... Performance Check 1.4: Search for SELECTs in loops across modularization units  Find database operations in nested loops across modularization units

This check searches for database operations that are nested inside any kind of loop (e.g. LOOPloop, DOloop, ...). If in the loop there is a call to a modularization unit (PERFORM, CALL FUNCTION, CALLMETHOD), then this call is tracked and it will be analyzed, whether there is a database operation in the calledunit. This way, several levels of the callstack are analyzed (for runtime reasons, there is an upper limit forthe callstack depth).What you can do:If a database operation is executed inside a loop for several entries of the internal table that is processed,please check whether it is possible to read or write the needed database lines with one database statementinstead. For example, it could be possible to replace the SELECT inside the LOOP with a SELECT ...FROM dbtab FOR ALL ENTRIES IN itab.

 General Parameters:

Minimum table size category: with this parameter you can restrict the search on those databaseoperations that access database tables with a size category that is equal or larger than the parameter.The size category is maintained in the technical settings of a database table in the ABAP dictionary(SE11).Callstack depth for analysis: this value determines how many levels of the callstack will beanalyzed below the loop statement. The default value is 3, the maximum value is 10.Exclude buffered tables: here it is possible to exclude accesses to buffered tablesAnalyze only local procedures: here it is possible to restrict the evaluation to local procedures,which saves evaluation time

1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 10/14

Analyze reading db operations: analyze reading database operations inside a loop, i.e. SELECT,OPEN CURSOR, FETCH, CLOSE, and the obsolete ones READ TABLE dbtab and LOOP AT dbtab.Analyze writing db operations: analyze writing database operations inside a loop, i.e. DELETE,INSERT, UPDATE, and MODIFYAnalyze EXEC SQL statements: analyze exec sql statements inside a loop

Effort Parameters (determine the effort to correct a problematic statement)Effort for db op in loop: with this parameter you determine the effort to remove a loop surroundinga database statement. The default value is 10.

Effort for each call: with this parameter you determine the effort to remove a loop surrounding aprocedure call that contains a database statement. The default value is 20.

  The check delivers the following result messages:  DBREAD_LOC A reading database operation was found inside a local loop.DBREAD A reading database operation was found inside a non local loopDBWRT_LOC A writing database operation was found inside a local loop.DBWRITE A writing database operation was found inside a non local loopEXEC_LOC An exec sql operation was found inside a local loop.EXEC An exec sql operation was found inside a non local loop

  If you have switched on to get detail information, there are the additional messages:  

Table Name Name of the database table concernedNr Loops Number of loops around the database operationNr Calls Number of procedure calls around the database operationEffort The effort to correct this problem. It is calculated as follows:Effort = Effort for db op in loop +  Effort for each call * number of calls

Severity The severity of this problem is a measure for the performance loss due to this problem.It is calculated: Severity = number of loops

 .............................................................................................................................................................. Robust Programming 2.1: Deepooling/Declustering: Search SELECT for Pool/ClusterTables 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 basetable 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 israised Messages of the test can be suppressed via the pseudo comment "#EC CI_NOORDER 

 ............................................................................................................................................................. Robust Programming 2.2: Search problematic statements for unsorted results ofSELECT or OPEN CURSOR statements 

This check searches for the following statements where the internal table is the result of a SELECTstatement without ORDER BY clause. Without ORDER BY clause or other sorting measures the result of theselect 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 unitand follows the calls to other procedures. With this parameter you can specify the maximal evaluationdepth.Nonlocal analysis depth: With this parameter you can specify the maximal evaluation depth intoexternal programs.

 The problematic statements are:

1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 11/14

What you can do:There are two (three) possibilities:1.  Add an ORDER BY clause to the select statement

2.  Add a SORT statement for the internal table

3.  If no problem exists add the specified pseudo comment

Remark: The SELECT statement and the critical statement can be in different subroutines.............................................................................................................................................................. If you want to learn more about SAP Code Inspector follow these links http://wiki.sdn.sap.com/wiki/display/ABAP/Code+Inspector http://www.sap.com/australia/campaign/esnewsletterq4/code_inspector.epx   Coming next In the next section we will continue with will have a look at Transaction /nT05 (SQL Trace) and how SQLTrace will help us on our journey to performant ABAP on HANA programming.

  

 

Part 5: DB Performance Analysis with SQL Trace If you experience slow transaction step is mainly caused by one or more long running SQL statements. To get to theroot cause of this problem, do an SQL trace of the process step.

For this start ST05 Aattention: The trace is only performed for the instance you are currently logged on, so checkTransaction SM51/SM51 before you start). Call Transaction /nST05 and activate the SQL trace via the ‘Activate Tracewith Filter’. In case you have to trace another user and not your own, add this information to this popup.

Remark: You should always use filter criteria, to (a) keep the number of collected data low and (b) avoidunneccessary load on the system. And always Deactivate Trace after you have finished collecting the required data.

 

1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 12/14

If the configuration is done, execute the long running statement.

As soon as you have performed the trace, switch of the tracing (Deactivate Trace) and go to Display Trace.Choose your trace file and display the summarized list. 

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

Click on the ‘Explain’ button to see the execution plan of the statement as it is executed by the DB. You can see, if andwhich index/indices have been used

In our example no index was choosen and a full table scan was done.

1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 13/14

Average User Rating

(10 ratings)

0 Tweet

No take appropriate actions and find out, what can be done to optimize this statement.

  Coming next In the next section we will continue with will have a look at Transaction /nSAT (ABAP Trace) and how ABAP Trace willhelp us on our journey to performant ABAP on HANA programming.

  

17130 ViewsTopics: abap Tags: hana, code_inspector, sql_trace, abap4hana, abaponhana, abapforhana, abapinhana, abap_for_hana,

abap_trace

Share 10 4Like

13 Comments

Like (0)

Aby Jacob 09Jun2013 13:20

Excellent !!   Thanks for sharing

Like (0)

Abdul Hakim 10Jun2013 12:17

Useful info. Thanks for sharing with the community.

Like (0)

Simon Rotherham 27Jun2013 23:57

A great blog that is not just relevant for ABAP on HANA but also relevant for all ABAP developers inorder to produce efficient code.

Like (0)

Trond Stroemme 24Sep2013 13:12

Very thorough and useful. But of course the real gain with HANA is pushing code down to the DBlayer  avoiding (too much) Open SQL in your ABAP code.

Like (0)

Syam Babu 15Apr2014 21:03

Well Written...Thanks.

Like (0)

Hyuk Joo Lee 09Jan2015 01:59

Thanks! 

Like (0)

Heecheol Yeom 14Jan2015 10:09

I should say that this is very helpful blog! Thanks for blogging. I'm already excited to next blog.

Riaz Ghouse 09Dec2015 07:24

Very Helpful and clear

1/24/2016 ABAP on HANA  from analysis to optimization | SCN

http://scn.sap.com/community/abap/hana/blog/2013/06/05/abaponhanafromanalysistooptimization 14/14

Follow SCNSite Index Contact Us SAP Help PortalPrivacy Terms of Use Legal Disclosure Copyright

Like (0)

Like (0)

Raghuveer Saireddy 21Dec2015 13:03

Very well explained, Point to Point.. very well written :)

Like (0)

Ramesh Natarajan 22Dec2015 04:58

Each and every points are well explained.

Like (0)

Thomas Fiedler 22Dec2015 09:12

Hi Manfred,we recommend to use the SQL monitor (transaction SQLM) to detect performance issues andoptimization potential in your code. 

Optimizing Custom ABAP Code for SAP HANA – The New ABAP SQL Monitor.pdf In the meanwhile there is also an Eclipse based tooling for SQLM findings:

3 Simple Steps to Identify Performance Hotspots in ABAP Custom Code Give it a try. Regards,Thomas.

Like (0)

Markus Zoeller 20Jan2016 08:58

Hi All, is there a good recommendation or approach that describes the analysis to identify potentialyunnecessary "SecondaryIndices" when moving from classic DB (e.g. ORACLE) to HANA DB. Thanks and RegardsMarkus 

Like (0)

Lars Breddemann 20Jan2016 13:52 (in response to Markus Zoeller)

The question is not so much whether there are potentially unnecessary sec. indexes, butrather: of all the sec. indexes in the system, which ones could potentially be useful? Since the indexing options, strategies and reasons for Oracle are fundamentally differentthan for SAP HANA, the recommendation is: get rid of all secondary indexes (especiallythose one more than one column) and review the performance of your application on SAPHANA. You might want to check SAP notes 2160391 FAQ: SAP HANA Indexes2000002 FAQ: SAP HANA SQL Optimization for further reading on this.