8/28/2014 Performance Guidelines for ABAP Development on ...

| SCN
http://scn.sap.com/community/abap/hana/blog/2013/03/24/performance-guidelines-for-abap-development-on-the-sap-hana-database 1/4
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 Us Hi, Guest Search the Community
Activity Communications Actions
Browse
ABAP for SAP HANA
Previous
post
Next
post
Tweet
2
If you are an experienced ABAP Developer, then you most likely know the classical performance guidelines for using
Open SQL (if not, then you should look them up immediately).

One of the frequently asked questions we receive is:
What changes in the context of SAP HANA regarding these guidelines?

Let us first reconsider the existing guidelines. In a nutshell, they are usually summarized in the 5 golden rules:

Icon Rule Details / Examples

Keep the result sets
small
Do not retrieve rows from the database and discard them on the
application server using CHECK or EXIT, e.g. in SELECT loops
Make the WHERE clause as specific as possible
Minimize amount of
transferred data
Use SELECT with a field list instead of SELECT * in order to transfer
just the columns you really need
Use aggregate functions (COUNT, MIN, MAX, SUM, AVG) instead of
transferring all the rows to the application server
Minimize the
number of data
transfers
Use JOINs and / or sub-queries instead of nested SELECT loops
Use SELECT FOR ALL ENTRIES instead of lots of SELECTs or
SELECT SINGLEs
Use array variants of INSERT, UPDATE, MODIFY, and DELETE
Minimize the search
overhead
Define and use appropriate secondary indexes
Keep load away
from the database
Avoid reading data redundantly
Use table buffering (if possible) and do not bypass it
Sort Data in Your ABAP Programs

Well, the short answer regarding the question above is
All existing (standard and custom) ABAP code runs on SAP HANA without modifications
All the existing guidelines are still valid for SAP HANA as general recommendation


However, the priorities of some rules are changing, i.e. some aspects are less important due to the nature of the In-
Memory Column Store but there are also certain patterns of non-optimal coding with higher impact on SAP HANA.
Furthermore, there are completely new opportunities for performance tuning on SAP HANA which were not possible
in the past, e.g. by pushing complex operations to the database.

In this blog series, Hermann Gahm and myself will drill into more details of the slightly adapted performance
recommendations, and give some background information. In addition, we try to give some guidance for several
frequently asked questions.

The planned structure of this blog series is as follows:
Performance Guidelines for ABAP Development on the SAP HANA Database (this post)
Performance Guidelines for ABAP Development on
the SAP HANA Database
Posted by Eric Westenberger in ABAP for SAP HANA on Mar 24, 2013 5:46:33 PM
Share 1
8/28/2014 Performance Guidelines for ABAP Development on ... | SCN
http://scn.sap.com/community/abap/hana/blog/2013/03/24/performance-guidelines-for-abap-development-on-the-sap-hana-database 2/4
Average User Rating
(15 ratings)
Tweet
2
Details and background information on adapted guidelines (to come)
Frequently Asked Questions for ABAP Development on SAP HANA (to come)


The following recommendations are derived from measurements and experiences based on SAP Business Suite
using SAP NetWeaver AS ABAP 7.4 running on SAP HANA SPS5. They will be added to the standard ABAP 7.4
documentation and also supported in standard tools such as the ABAP code inspector.

Guideline Additions in the context of SAP HANA
As on all database systems, there is a performance overhead associated with every database
access for connection handling, SQL parsing, execution plan determination, etc.

The following existing guidelines should be prioritized higher on SAP HANA:
For modifying operations (INSERT, UPDATE, DELETE) using array operations should be
preferred to single operations when changing many data records
Nested SELECT loops should be avoided or replaced if possible by
Changing the nested single SELECT statement to an appropriate SQL construct (e.g.
FOR ALL ENTRIES, JOIN, sub-query, etc.)
Avoiding repeated access to the same data via SQL
Using the ABAP table buffer (see existing guidelines for the ABAP table buffer)
In most cases, SAP HANA does not require secondary indices for good search performance.
To reduce main memory consumption, and to improve insert performance all existing non-
unique secondary database indices on columnar tables are removed during migration or do not
get created during installation for all AS ABAP systems from SAP NetWeaver 7.4 onwards.

For some use cases secondary indexes can still be beneficial. This is especially true for highly
selective queries on non-primary key fields. These queries can be significantly improved by
indexes on single fields which are most selective. SAP Note 1794297 describes the procedure
to find and create these indexes.
The guideline is renamed to "Keep load away from the database, but push data-intensive
calculations to the database where applicable"

On SAP HANA, it is beneficial to move data-intensive calculations into the database.
Nevertheless, it is not recommended to execute the same operations redundantly, e.g. in
different user contexts or different dialog steps of the same user. Meaningful buffering of results
on the application server should be applied.

The following recommendation should be considered in this light on SAP HANA

Sorting data:In general, the recommendations for sorting remain as before, i.e. if the database
does not use the same index for sorting as for selection, then it may be in some situations
more efficient to sort in the application server in particular if all data to be sorted has to be
fetched from the application server anyway. However, if the sorting is part of determining the
result set (e.g. select top n customers by revenue) or the sorting is part of a larger calculation
logic (e.g. within a procedure), it should be done in SAP HANA.

As outlined above, the next post contains some more technical background information for the reasoning behind
these recommendations, and some answers to frequently asked questions.
9915 Views Topics: perf ormance, abap Tags: hana, guidelines
Share 1
12 Comments
P. van Os Mar 25, 2013 3:58 PM
Hi Eric,

According to note 1662726 the performance of a select statement with a FOR ALL ENTRIES (FAE)
clause could be poor. The note described to use a DB Hint.

However, one of the two prerequisites is that the select statement must not be a join statement.

What do you recommend in case of a FAE in combination with a JOIN?
8/28/2014 Performance Guidelines for ABAP Development on ... | SCN
http://scn.sap.com/community/abap/hana/blog/2013/03/24/performance-guidelines-for-abap-development-on-the-sap-hana-database 3/4
Like (0)
Is a database view the only option?

Regards,
Patrick
Like (1)
Hermann Gahm Mar 31, 2013 6:25 PM (in response to P. van Os)
Hi Patrick,

the note can be beneficial in some cases.

Regarding the FAE with the join there is no hint necessary / available. A join / view (avoiding
the FAE) can (but does not have to) be beneficial. I would recommend to try different
variants. It also depends on the version of HANA that you have in use since FAE processing
in HANA might be different.

Kind regards,

Hermann
Like (0)
Abdul Hakim Apr 5, 2013 1:34 PM
Nice blog. Looking forward to future blog series in this topic.

Thanks
Abdul Hakim
Like (1)
Suhas Saha Apr 26, 2013 11:08 AM
Looking forward to the next blog in the series. A lil' bit of ABAP code won't harm anyone

BR,
Suhas
Like (1)
Hermann Gahm May 18, 2013 7:56 PM (in response to Suhas Saha)
Hi,

next posts will contain some ABAP.
Hope i will find some time to start them.

Kind regards,
Hermann
Like (0)
Camille Bommart Oct 9, 2013 2:53 PM
Hello Hermann

I have some basic questions on SAP HANA perfomance with ABAP.

If we migrate to a SAP HANA database on ECC, will our custom programs be more performant even
if we don't optimize them for HANA?
Same questions for the BW extractors and for some extraction programs generated by the
Informatica tool?
Globally, what can we expect in terms of performance increase on programs that are not
reviewed/optimized after migration to SAP HANA for ECC?

Thank you
Richard
Like (1)
Hermann Gahm Oct 9, 2013 3:23 PM (in response to Camille Bommart)
Hi,

that depens on the SQL statements. Some will be faster, some will not change
and some might be slower.
Have a look at these documents for tools that can help you
in finding the SQLS that might need some adaptions.

http://scn.sap.com/docs/DOC-46714
http://scn.sap.com/docs/DOC-47444

Kind regards,

Hermann
8/28/2014 Performance Guidelines for ABAP Development on ... | SCN
http://scn.sap.com/community/abap/hana/blog/2013/03/24/performance-guidelines-for-abap-development-on-the-sap-hana-database 4/4
Follow SCN
Site Index Contact Us SAP Help Portal
Privacy Terms of Use Legal Disclosure Copyright
Like (0)
Camille Bommart Oct 9, 2013 4:03 PM (in response to Hermann Gahm)
Thank you very much
Like (0)
Venkatesan Parasuraman Nov 6, 2013 9:08 PM
Thank you very much, this is helpful
Like (0)
Peter Inotai Nov 21, 2013 11:04 AM
Hi Eric,
Very great summary!
Is there any change regarding fully buffered tables (eg customizing tables)?
Or everything stays the same (except that it's also in memory in DB side)?
Thanks,
Peter
Like (1)
Hermann Gahm Nov 25, 2013 10:14 AM (in response to Peter Inotai)
Hi Peter,

regarding buffered tables there is no change for the golden rules. We continue to use them
like we did in the past. Local application server memory access (buffered table in-memory
of the local application server) is still faster than remote memory access of the table in-
memory of the databse server. With SAP Netweaver 7.4 there is a new table buffer based
on internal tables that allows to have secondary indexes in the table buffer. With that we
have even more buffering options.

Kind regards,

Hermann
Like (0)
Peter Inotai Nov 25, 2013 12:54 PM (in response to Hermann Gahm)
Hi Hermann,
Thanks a lot for this clarification.
Peter