Guide to optimize your ABAP Code for SAP HANA
This guide describes how You can optimize Your existing ABAP-Coding for SAP HANA and achieve maximum performance in terms of runtime!
- Understand the major performance killers
- Static Analysis with the SAP Code Inspector (SCI)
- Online SQL Monitoring in the Production System
- Combined evaluation of the diagnostic results
1. Understand the major performance killers
SELECT * FROM <dbtab>
When a SELECT * statement is called, each column of a table is selected as usual. However, under SAP HANA, the problem with the runtime is simply the high compression rate of the data. This is because each column must be decompressed.
For example, if a table with 200 columns and 2 million data records is selected, but only 20% of the columns are used, then significant performance is wasted.
LOOP AT <itab>.
SELECT SINGLE * FROM <dbtab>.
In this case, it is similar to a SELECT *, except that a single record selection is performed within a loop with n iterations.
Therefore the problem is that the database is bothered with n similar selects, which differ only in the restriction. This is also called „Identical Select“ and is absolutely not recommended. With regard to ABAP for SAP HANA, this is particularly performance-intensive, since the SELECT statement is sent n times to the HANA database and each record must therefore be unpacked individually. Here it is still recommended to use the array fetch before the start of the iteration.
READ TABLE <itab> ... BINARY SEARCH.
For the binary search you require a sorted table. If the database query result is sorted, it works as well. Since this is not the default in SAP HANA due to parallelization, your old coding, which depends on a sorted result, will no longer work. Therefore, make sure that you either use a sorted table or explicitly ensure that SAP HANA returns the result sorted.