Usage Scenarios
Introduction
SQL Monitor
ABAP Test Cockpit and Code Inspector in Context of HANA Migration
SQL Performance Tuning Worklist
Usage Scenarios
To record runtime data for the SQL statements executed in your business
processes, switch on the SQL Monitor for a sufficiently long time in your
productive system.
for further analysis. For this purpose, generate so-called SQL snapshots.
Runtime Check Monitor (transaction: SRTCM)
The Runtime Check Monitor allows you to activate certain runtime checks
that complement the corresponding static checks with aspects that can only be
checked during runtime.
In the Quality or Test System, you can perform the following activities:
ABAP Test Cockpit (ATC) or Code Inspector
Static check tools are used in the development system to check the code
during development. The test system contains the consolidated code base and is
therefore suited for regular static code regression check runs. Code Inspector
provides a wide range of checks which cover aspects like functional correctness,
usability, robustness and performance. The Code Inspector checks can be used in
the Code Inspector tool itself or in the new ABAP Test Cockpit. In this
documentation we focus on the performance and DB-related static checks.
In the Development or Correction System, you can perform the following
activities:
SQL Performance Tuning Worklist (transaction SWLT)
system, based on the SQL snapshot that has been exported from the productive
system.
To analyze static code data, you need to select the code inspections or the
corresponding ATC run series that you executed previously in the Code Inspector
or ABAP Test Cockpit tools.
Results from different data sources are matched and combined by their
source position. This enables you to find ABAP SQL code that has potential for
performance improvement in productive processes.
Runtime Check Monitor (transaction: SRTCM)
You have the option to import snapshots into the development system,
based on the runtime check data that has been exported from the productive
system.
ABAP Source Editor
SQL Monitor
In a productive ABAP-based SAP system, a huge number of various SQL requests are
executed by the most diverse business processes. To detect 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.
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 t he analysis to finding systemwide 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:
system?
Which SELECT statements cause the longest runtime?
Which SELECT in the customer code reads the most data?
What does the SQL profile of a report X or transaction Y look like?
You can run the SQL Monitor in a productive system in parallel to productive
use since the performance overhead for the traced business processes is
negligible. (In average <3% overhead for the running processes).
NoteThe data collection of the SQL Monitor is implemented directly in the ABAP
kernel in a highly optimized manner to ensure that live operation of the SAP
system is not disrupted.
You can switch on the SQL Monitor globally for all servers in the system or for
individual servers only.
SQL Monitor traces each and every SQL statement executed in an ABAP
program. This includes OPEN SQL, native SQL, and SQL statements coming from
the ABAP kernel.
NoteTake into account that the runtime SQL data that are recorded in the SQL
Monitor are NOT client-specific - that is independent from the DB tables's client
ID (MANDT).
SQL Monitor collects performance indicators for each traced SQL statement,
including:
o
Number of executions for the SQL statement
o
Execution time (maximum, minimum, average, standard deviation)
o
monitoring results for specific time intervals. For example, you might want to
verify the positive effect of performance-related corrections or of other events
that could have an impact on the system performance. Or, you want to
intentionally omit time intervals with untypical system events, as they could
distort the performance results you want to analyze. Besides that, by using time
series you automatically get a history of your systems performance, which might
be interesting on its own.
Based on the result list of performance data, you are able to derive the
concrete entry point from each business process driving the traced SQL
statement. A request entry point can be an ABAP report, a transaction, an RFC
module, an URL, a batch job, or an update task.
Activating SQL tracing for individual database statements.
You can export your SQL Monitor recordings from the current system to a
local file and then import it into the development system where the corrections
have to be performed.
NoteIn particular, you can avail of the SQL Monitor features when you proceed to
optimize the existing custom ABAP code in the course of database migration to SAP
HANA.
Functional adaptations
the most part, clear, local corrections in program code that do not demand a deep
knowledge of the application.
In the case of SQL performance optimizations, the interaction of various tools
and checks is vital for performing the optimization effectively. Here, the new SQL
Monitor is used, in addition to the new static Code Inspectorperformance checks
and also the SQL Performance Tuning Work List.
Keep in mind that the static performance checks can generate a large number of
messages. However, this is not particularly worrying because these performance
checks are merely of an indicative nature (for example: a nestedSELECT exists).
Only in combination with the relevant performance data can these results from
static checks be used effectively. By combination with the performance data (from
the SQL Monitor) the number of recommended performance corrections is
generally reduced quite considerably.
ABAP Test Cockpit (ATC) - in the case of systems SAP EhP2 and upwards
Figure 1: Selecting the Code Inspector Variant when Using the ATC
Figure 2: Selecting the Code Inspector Variant in the Initial Screen of the Code
Inspector
Further Information
Code Inspector
Quality Checking with the ABAP Test Cockpit
NoteFor native SQL, you have to check whether the SQL code can be run
on SAP HANA and whether it needs to be adapted.
Finding usages of special DDIC function modules that check or return the
existence or technical properties of certain DB indexes.
NoteOn SAP HANA, most DB indexes are not in use and therefore these checks
are generally obsolete.
NoteIn the course of an SAP HANA migration, most pool and cluster tables are
converted into transparent tables of the same name. After this step, access to
these technical pools/clusters that are no longer used does not serve any
purpose.
NoteSince genuine errors are found using these checks, they are of special
importance. An explicit sort of the SQL query must be inserted (ORDER BY clause
or ABAP SORT) for those ABAP code sections that contain them.
NoteWe recommend you to use both checks. The focus of the analysis, however,
should not be on priority 1 and 2 messages of the check "Search problematic
statementw/o ORDER BY". The messages of the partially redundant check
Depooling/Declustering: Search forw/o ORDER BY have a high false-positive rate
and can be processed with lesser urgency.
Tip
For more details on checks, refer to the documentation of the check in question (in
the Code Inspector or the ATC).
FUNCTIONAL_DB_ADDITION
This check variant contains additional checks that are not directly linked with
the SAP HANA migration. However, they can detect - as experience has shown important, potential functional errors and low-performance SQL statements.
Therefore, the checks of this check variant are not mandatory for the SAP
HANA migration, but they are recommended.
This check variant currently includes the following checks:
NoteIn particular for operations that perform a change, like UPDATE and DELETE,
the semantics of this statement should be checked.
Checking SQL operations with the addition FOR ALL ENTRIES IN <itab>,
whereby in the code itself it is not ensured that the internal table < itab> is
always filled.
NoteKeep in mind that in accordance with the ABAP documentation for an
empty internal table <itab> the entire WHERE clause of the SQL operation is
suppressed. This can, in certain circumstances, result in reduced performance
levels.
Related Information
Runtime Checks
The main purpose of the SQL Performance Tuning Worklist is to facilitate the
evaluation of runtime data originating from SQL Monitor in order to identify
promising candidates for performance tuning.
In addition to the SQL Monitor, the SQL Performance Tuning Worklist allows
you to
Combine the SQL monitoring data with findings of local or remote static
findings exist.
Evaluate monitoring data snapshots of the local or a remote AS ABAP
system. You can create snapshots of SQL data directly from the local system or
by specifying the RFC destination.
Import (Upload) the SQL Monitor recordings from a local file that you
the system.
Display a condensed (overview) list of findings that are sorted in accordance
Bjoern Panter
on
Version 3
inShare
When I worked on financial related topics, I had experience to use workload statistic
(ST03N) to get the information about who has been executed what. But there was
always a question from Audit department about how often a certain financial
program with high risk was executed (for example Asset Deprecation, transaction:
AFAB), which I never knew how to answer.
From this year when I joined into my current new team, I started to know Usage and
Procedure Logging (UPL). Honestly saying the first time when I heard this topic, I felt
it must be very technical, and very difficult to be used However, after I get
involved more and more and get the detailed introduction and presentation about
this topic from an internal Bootcamp, I was really surprised on so many benefits you
can get from this functionality and it is so easy to be activated if the right patches
are there. At the same time I was so excited to find the answer for the question
which I was really struggling for a long time. Thats why I would like to promote this
topic to you here.
Get details about the number executed ABAP procedures on a daily base
BW reporting on top
Full integration in the Custom Code Lifecycle Management
Unprecedented granularity level
Proven accuracy in SAP internal productive system in the last 12 months
Integrated in Solution Documentation Assistant and ALM
You can find all important contents regarding UPL (How to activate, system
preconditions, troubleshooting etc) by How To Guide