We are planning a migration of ABAP-based SAP system to SAP HANA and want to prepare our ABAP custom code for this.
The migration of the ABAP custom code for SAP HANA can be split into two main areas:
- Functional modifications of the custom code
- SQL performance optimization of the custom code
For the first point, "Functional modifications of the custom code", the main task is to locate ABAP code that potentially relies on specific properties of the predecessor data base and that might need to be modified. One example of this is the use of native SQL in ABAP custom code.
For the second point, new tools are available for effective optimization: The new ABAP SQL monitor, static Code Inspector performance checks, and the SQL Performance Tuning Worklist.
In both areas, the analysis of the custom code is supported by static Code Inspector checks to efficiently find the ABAP source code sections to be analyzed.
This SAP describes in particular which static Code Inspector checks and Code Inspector check variants are currently recommended for this.
Solution
Functional adjustment of the ABAP custom code for the SAP HANA migration
Implement the program corrections in SAP 1935918 in your system. The SAP contains Code Inspector check variants that contain the currently recommended functional checks and their parameterization. You can use these new check variants in the ABAP Test Cockpit or Code Inspector check runs for your custom code.
It is important to add that, as a result of new information, this check selection might become obsolete or need to be supplemented. The content of the check variants can differ in the various supported SAP NetWeaver because different checks and check parameters are available in each .
Important: It only makes sense to use the check variants if the referenced checks are also available and correct in the system.
For this reason, SAP 1935918 lists the checks contained in each SAP NetWeaver and information about how to obtain the various checks in each .
For example, the check from SAP 1875529 must be imported for SAP NetWeaver 740 Support Package 2. (The SAP and transport are available for SAP NetWeaver 740 SP2 and must be requested by means of a customer message.)
Before using the new check variants, check that they are complete and consistent.
The new check variants are available for the following SAP NetWeaver s (new checks are also available with these s - for more information about the availability of the individual checks, see the SCN document cited above):
SAP NetWeaver 7.02 as of SAP_BASIS SP14
SAP NetWeaver 7.31 as of SAP_BASIS SP09
SAP NetWeaver 7.40 as of SAP_BASIS SP02
The two new global Code Inspector check variants delivered with SAP 1935918 are:
FUNCTIONAL_DB
FUNCTIONAL_DB_ADDITION
Check variant FUNCTIONAL_DB
This check variant contains checks that are regarded as mandatory for the analysis of ABAP custom code as part of an SAP HANA migration.
Currently, these are:
- Location of native SQL and database (DB) hints (messages on DB hints should be regarded as information only, as DB hints are declared on a database-specific basis and usually do not need to be adapted).
- For native SQL you must check whether the SQL code can also run on SAP HANA or whether it should be adjusted.
- Location of ADBC (ABAP Database Connectivity) usages (should be treated in a similar way to native SQL).
- Location of usages of special ABAP Dictionary function modules that check/provide the existence or technical properties of certain database indexes. On SAP Hana, most of the database indexes are not in use, and these checks are therefore usually obsolete.
- Location of accesses to technical (!) pools/clusters of a pooled/cluster table. As part of an SAP HANA migration, most pooled and cluster tables are converted to transparent tables of the same name. After this step, access to these technical pools/clusters that are no longer used does not make sense.
- Location of non-robust ABAP code that relies on a non-guaranteed/implicit sorting of certain SQL queries, even though no ORDER BY clause is used.
- For these incorrect ABAP source code sections, an explicit sorting of the SQL query must be inserted (ORDER BY clause or ABAP SORT).
There are two checks for the last point (which has a particular importance in the analysis):
"Search problematic statement…w/o ORDER BY"
"Depooling/Declustering: Search for…w/o ORDER BY"
You are advised to use both checks. However, the focus of the analysis should be on the priority 1 and 2 messages of the check "Search problematic statement…w/o ORDER BY". The messages of the partially redundant check "Depooling/Declustering: Search for…w/o ORDER BY" have a high false positive rate and the processing of these is less urgent.
For details on the checks, see the documentation for the check in question (in the Code Inspector) and the technical background in the following SAP :
1785057 - Recommendations for migrating suite systems to SAP HANA
Check variant FUNCTIONAL_DB_ADDITION
This check variant contains additional checks that are not directly linked with the SAP HANA migration but experience has shown that they can locate potential functional errors and SQL statements with poor performance. Thus the checks in this check variant are not mandatory for the SAP HANA migration, but they are recommended.
This check variant currently contains the following checks:
- SQL operation without WHERE clause. The semantics of this statement should be checked for changing operations, in particular.
- SQL operation with the supplement FOR ALL ENTRIES IN <itab>, where the code does not ensure that the internal table <itab> is always filled. (For an empty internal table <itab> the complete WHERE clause of the SQL operation disappears, according to the ABAP documentation.)
- Check ABAP Dictionary table settings for consistency. In particular, this checks whether table buffer settings have been maintained consistently (performance).
Notice: Supplementary runtime checks
In addition to the static checks, there are supplementary runtime checks for the following two cases:
- SQL operation with the supplement FOR ALL ENTRIES IN <itab>, where the code does not ensure that the internal table <itab> is always filled.
- Location of non-robust ABAP code that relies on a non-guaranteed/implicit sorting of certain SQL queries, even though no ORDER BY clause is used.
At program runtime, these runtime checks check certain aspects of the aforementioned pattern.
For example, each time a SELECT ... FOR ALL ENTRIES IN <itab> is executed, the system writes a log entry if the internal table <itab> was empty.
These runtime checks therefore supplement the static checks by checking aspects that could not be checked statically (for example dynamic code) and reveal merely suspicious code sections that were also actually executed.
During an SAP HANA migration, you are advised to activate these runtime checks in the final test phase and after going live in the production (SAP HANA) system.
These runtime checks are available as of NW 740 SP5. An advance delivery is also provided for NW 740 SP2, SP3, and SP4.
All information on these runtime checks, in particular the technical requirements, is provided in SAP 1931870.
SQL performance optimization of the customer code
The most important new tool for an overall analysis of the custom code with regard to performance optimization is the new SQL monitor.
This provides performance data aggregated from the production system (including before migration) for all executed SQL commands.
This runtime data from the SQL monitor often provides direct worklists with potential performance improvements for custom code. (Analysis strategies are provided in the SQL monitor SCN document "Optimizing Custom ABAP Code for SAP HANA – The New ABAP SQL Monitor.pdf" scn.sap.com/docs/DOC-47444.)
However, this runtime data can also be combined with the results of the static performance checks. This linking of the two data sources is carried out in the new tool "SQL Performance Tuning Worklist" (see the aforementioned SCN document for details).
This provides you with information from the static performance checks or even solution proposals for SQL commands that are shown up as problematic in the SQL monitor. For the static performance check run, the check variant PERFORMANCE_DB is recommended. This contains all the main static SQL performance checks.
An isolated analysis of the results of these static performance checks is NOT recommended for the entire custom code because this would be inefficient to process. (The analysis can include code that might not be used at all or is not performance-critical.)