Documente Academic
Documente Profesional
Documente Cultură
A. MOTIVATION
The endless variety of business scenarios make many different demands on the
performance and scalability of standard software in general. There are quality standards
that define criteria that guarantee good performance and scalability of components,
scenarios and processes.
Custom code is a central part the business functionality. The question now is how customers
can smoothly migrate in the first step and optimize their code for SAP HANA in the second
step.
When you plan to migrate to SAP HANA, the amount of custom code in your system will
have an impact on total cost, time and the quality. Let’s look at the potential impact of
custom code, and discuss how to tune custom code to perform optimal on SAP HANA.
So questions are:
In the following exercises you will familiarize yourself with how to:
The migration of customer’s ABAP code to SAP HANA can be divided into two broad
categories:
There are tools available in the ABAP environment that can provide valuable help, in
particular to analyze code for functional correctness and performance.
The ABAP Code Inspector can perform a whole range of static performance checks. The
existing rules and guidelines checked by Code Inspector are as valid for SAP HANA as they
are for other databases. With SAP NetWeaver 7.40, several additional checks were added
generally be divided into two main areas:
These check variant contains checks that are regarded as mandatory for the analysis of
ABAP custom code as part of an SAP HANA migration.
The ABAP Test Cockpit (ATC) was introduced as a holistic quality assurance tool. The ABAP
Test Cockpit integrates the ABAP Code Inspector (SCI), including the configuration of check
variants. The ATC offers more, in particular flexibly scheduling check runs, distribution of
results and in general support for quality management processes.
The checks performed by the ABAP Test Cockpit can be configured. Standard configuration
is that it reuses the ABAP Code Inspector DEFAULT variant. The check variant used may have
to be adjusted, e.g. FUNCTIONAL_DB and PERFORMANCE_DB to make sure all checks
relevant for SAP HANA are performed.
Explanation Screenshot
b) Insert
TEST_A4H_TRAINING_SQ
LM and press OK
Explanation Screenshot
b) Under ABAP
Development select ABAP
Test Cockpit, choose
Global Code
Inspector check
variant,
insert the global check variant
FUNCTIONAL_DB and press
OK
Explanation Screenshot
b) Under ABAP
Development select ABAP
Test Cockpit, choose
Global Code
Inspector check
variant,
insert the global check variant
PERFORMANCE_DB and
press OK
Explanation Screenshot
d) Choose PERFORMANCE_DB to
see the Problematic
Statements found for this
Code Inspector variant
Explanation Screenshot
navigate to the source code
of this problematic statement
7) Possible solution
a) In order to make more stable
and more readable it is best
practice to embrace SELECT
… FOR ALL ENTRIES with
an explicit test for content by
using an IF statement
Summary
· ABAP Test Cockpit (ATC) is the new standard tool for static ABAP code checks
· In general existing ABAP code runs on SAP HANA as before. Only DB specific ABAP
code must be analyzed
· New static Code Inspector Checks and Runtime Checks are available which help to
find the code which must be analyzed
· ATC can be used now to prepare the custom ABAP code for HANA and to improve
the general quality of the code
In addition, please keep in mind, that there are five "Golden SQL Rules", which helps to
improve the performance of your ABAP programs. Two of them have higher priority, if you
are working with SAP HANA:
SQL Monitor
Static performance checks mainly provide performance hints and recommendations. Static
checks cannot predict the performance benefit of a recommended correction. Therefore,
static checks are not sufficient as a single source for performance optimizations.
We need to add runtime data from the productive system to find the relevant code. In a
productive ABAP-based SAP system a huge number of various SQL requests are executed by
the most diverse business processes. To detect the performance hotspots and also identify
potential for optimization in the SQL profile, you require specialized SQL Monitoring Tools
and utilities running in a live ABAP system.
* Not covered: Code generated at runtime, * Find the performance hotspots with the
dynamic code, too complex code SQL Monitor
The SQL Monitor allows you to monitor all SQL statements and operations that are
executed by running ABAP applications. The collected SQL Monitor data provides you with
aggregated performance indicators (number of executions, execution time, number of
effected rows, and so on) for all executed database operations.
In contrast to the standard Performance Trace tool (transaction ST05), the SQL Monitor
enables you to monitor the SQL activity system wide and over longer period of time. In
addition, you can expand the scope of the analysis to finding system-wide hotspots. The
reference to the ABAP context is always retained, except for mere DB monitoring. For each
SQL trace record, the entry point of the respective request (transaction code, submitted
report, RFC function module, and so on) and the affected ABAP source code position is
stored as well. This provides the first connection from the SQL statement to the affected
business process.
You can use the collected SQL performance data to answer questions such as these:
· Which database operation (SELECT, INSERT, UPDATE, DELETE) in the customer code
is executed most frequently in your system?
· Which database operation statements cause the longest runtime?
· Which database operation in the customer code reads the most data?
· What does the SQL profile of a report X or transaction Y look like?
In this exercise you learn how to find performance issues grouped into different categories:
· Many executions
o Which SQL-statement is executed most often?
§ View results are aggregated over all Request Entry Points while using
Aggregation " By Source Code Position " and ordered by Total
Number of DB Execution
o How could the code be improved?
· Slow statement
o Find the SQLM record of a SELECT statement with largest value of DB
Maximum Execution Time (hint: since ordering results by DB Maximum
execution time cannot be preselected on the selection screen, leave Maximal
Number of Records empty to make sure the record is not excluded).
o How can this large value be explained?
Explanation Screenshot
2. Select Snapshot
a) Select Display
Snapshots
b) Choose Display
Snapshot
Explanation Screenshot
Explanation Screenshot
Which are the Top Business Processes taking the most time on the database system?
Explanation Screenshot
3. Result: Top Business Processes
· ZR_A4H_BUSINESS_CA
SE_B (Batch Job)
· ZA4H_BC2
(Transaction)
· ZR_A4H_BUSINESS_CA
SE_A (ABAP-Program)
Explanation Screenshot
Which statements, reports, transactions or batch jobs are the top candidates and responsible for the
large time consumption?
Explanation Screenshot
4. Navigate to the source code
6. Solution
Select–Statement can be
transformed using a field list
Many executions
Explanation Screenshot
Which SQL statement is executed most often?
2. Display Results
a) First entry is showing the
highest number of
statements executed
Explanation Screenshot
Method
get_open_amount_4_inv
c is being called by another
method get_open_amount
in a LOOP
5. Solution
Simply use an inner join to get
rid of the nested function calls
within the SELECT …
ENDSELET statement.
Explanation Screenshot
Find the statements that fetch and/or modify the largest number of database
records?
2. Display Result
Explanation Screenshot
5. Solution:
Slow Statement
Explanation Screenshot
Find SELECT statement with largest value of DB Maximum Execution Time
1. Go back to the SQL
Monitor: Data Display
selection screen and Choose
Aggregation By Source
Code Position and
Total DB Execution
Time in the Order By area
and press Execute
Explanation Screenshot
The explanation here is that two concurrent reports where updating the same table!
Summary
· SQL Monitor collects performance data for each and every SQL executed in an ABAP
application
· SQL Monitor can run in a productive system without disturbing business processes
(performance overhead <3%)
· SQL Monitor allows to link the monitored SQL to the driving business process
· SQL Monitor can be used in the “old” productive system before doing the HANA
migration
· SQL Monitor availability is starting with NW 700 (see appendix for details)
The Runtime Check Monitor allows you to execute a limited range of runtime checks. In
each specific check, you can collect runtime-relevant information during program execution.
You can use these specific runtime checks to perform a final, remaining cleanup of the ABAP
code – for example, following the corresponding static code checks.
The Runtime Check Monitor provides the following runtime checks:
Explanation Screenshot
1. Start transaction
SRTCM (Runtime
Check Monitor)by
using shortcut Alt-
F8, insert SRTCM and
press Enter
· Empty table in
FOR_ALL_ENTRIES
clause
· Missing ORDER BY
or SORT after
SELECT
To display already
collected data either
directly use transaction
SRTCMD or press
Display Results
Explanation Screenshot
The consequence of an
empty for all entries
table is a full table scan
on the database!
6. Navigate to the ABAP
Source Code
Fragment by simply
clicking on the include
name
Explanation Screenshot
8. Solution:
9. Navigate back to
Runtime Check
Monitor.
Explanation Screenshot
11. Navigate to the ABAP
Source Code
Fragment by simply
clicking on the include
name
13. Solution:
F. KEY TAKEAWAYS
· In general existing ABAP code runs on SAP HANA as before. Only DB specific ABAP
code must be analyzed
· ABAP Test Cockpit can be used to find and adapt DB specific ABAP custom code
easily
· In general the well known golden Open SQL rules are still valid on SAP HANA - only
some priorities have shifted
· For effective SQL tuning and to find HANA potential in existing ABAP code new
monitoring tools like the SQL Monitor are available
· The preparation of your custom code can start before the migration to SAP HANA