Professional Documents
Culture Documents
S4 HANA
By
Muralikrishna Dabbugudi
Agenda
•1 What is HANA and how do we differentiate with other
databases?
•2 Path for HANA Migration
•3 Let’s see ABAP Code in HANA
•4 Tools for facts-based code migration planning
•5 Best Practice & Recommendations for code migration to HANA
•6 S/4 HANA and ABAP Code
•7 What are the Available tools and Options
•8 Q&A
What is HANA and how is it different from other databases?
SAP HANA is an in-memory database and application platform, which is for many
operations 10-1000x faster than a regular database like Oracle on the same hardware
SAP HANA database is different by design. It stores all data in-memory, in columnar format
and compressed. Everything is calculated on-demand, on the fly, in main memory. HANA is
the solutions to all the problems of columnar databases, like concurrency (HANA uses
MVCC) and row-level insert and update performance (HANA uses various mechanisms like a
delta store).
3. SAP HANA only supports Unicode installations, So code has to be Unicode enabled.
5 Golden Rules for Database Programming
Most of the functional check have been introduced in NetWeaver release 7.02 SP14 and above,
Some of the check have lot of False positives as the tool does Static code analysis. So this data has
to be combined with runtime statistics to get the correct list of Adaptions for Migration.
Usage scenarios for ABAP Test Cockpit/Code inspector
SQL monitor (transaction SQLM)
Default setting is to switch
off the SQL monitor after 7
days, but one should aim
for a month covering the
month end if possible year
end runtime data.
Available statistics
Collected data is aggregated by
• Number of executions
• Process type (e.g. transaction, report ,RFC module, HTTP request)
• Entry point (e. g. transaction VA01) • Execution time (maximum, minimum, average,
• ABAP source code location of the statement (i.e. program, include, line) standard deviation)
• Database table names (e.g. MARA). • Fetched/changed rows (maximum, minimum,
The data quality decreases whenever processes are modified. average, standard deviation)
• Number of internal sessions that triggered the
respective SQL statement
Usage scenario for SQL Monitor
Usage scenario for SQL Monitor
SQL Performance Tuning Worklist (transaction code SWLT)
SQL Performance Tuning Worklist is a tool for combining the result of a code analysis with
relevant runtime data coming from a productive system. This combination of data makes it
easy to generate a ranked work list for SQL performance tuning by analyzing and filtering
the data set
Why SQL Performance Tuning Worklist ?
SQL Worklist effectively combines runtime and static time analysis of abap code in a single
report for a complete analysis.
We can set:
• Object set filter: we can select the object set (e.g. limit to Z*, Y*, etc.) for limiting the
number of the retrieved check results / SQL monitor data.
• Runtime data: SQL monitor data snapshot can be imported via RFC or a local file into
SWLT
• [Optional] Coverage Analyzer: If no SQL monitor data is available, you can use code
coverage data (obtained e.g. via the Usage and Procedure Logging; UPL) from a
remote system to get at least the number of executions on the level of
modularization units. In particular, this allows ruling out coding which is never
invoked at all.
• Code analysis: we can Choose a Code Inspector or ATC result by providing the Code
Inspector inspection or the ATC run series. SWLT will always choose the latest version of
the available results.
Usage Scenarios for SQL Performance Tuning Worklist
HANA Migration process model
Planning phase
Check list for planning code migration:
1. Check whether all installed components (including e.g. SAP or partner Add-Ons are supported on SAP HANA). Please consult SAP Notes 1812713
(NetWeaver), 1760306 (ERP), 1855666 (3rd party) for compatibility information. As SAP HANA supports only Unicode installations, a Unicode
Conversion might be a part of the transitioning project
2. Install and configure the SQL Monitor tool in all relevant systems.
3. Run SQL Monitor in productive system(s) to collect SQL runtime data. Usually a timeframe of 1-4 weeks is recommended. Capture the
data as a snapshot.
6. Correlate the SQL Monitor results with ATC check results in the Performance Tuning Worklist
a. Pre-Analyze the SQL Monitor results (plausibility checks)
b. Import the SQL Monitor snapshot and ATC result data into the SWLT
c. Rank the findings by different criteria and select candidates.
Muralikrishna Dabbugudi
Sr. SAP Solution Architect