Anda di halaman 1dari 13

SQL Performance Monitoring

Usage Scenarios
Introduction
SQL Monitor
ABAP Test Cockpit and Code Inspector in Context of HANA Migration
SQL Performance Tuning Worklist

Usage Scenarios

Figure 1: Interplay of Various Analysis Tools and Utilities

Monitoring and other activities are typically distributed to several systems:


In the Productive System, you can use the following tools to perform these
activities:
SQL Monitor tools (transactions: SQLM and SQLMD)

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.

After approximately 7 days of monitoring, the SQL monitor results enable


you to identify performance hotspots and determine optimization potential on
code level.
You can archive the collected SQL Monitor data in order to have it available

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)

To analyze runtime data, you need to create snapshots in the development

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

Solve the functional issues as detected by static checks or using

the Runtime Check Monitor.


Solve the performance issues as identified in your productive system.

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:

Which SELECT in the customer code is executed most frequently in your

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?

Overview of Features Provided

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

for the SQL statement


Number of database records ( maximum, minimum, average,
standard deviation) that have been retrieved or modified by the SQL
statement

Number of internal sessions in which the SQL statement in question

has been triggered


SQL Monitor provides you with a source code-oriented or, alternatively, a

request-oriented view of the aggregated performance data.


With the time series functionality you have the option to concentrate on SQL

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.

ABAP Test Cockpit and Code Inspector


in Context of HANA Migration
NoteThis topic does not address the common usage of ABAP Test Cockpit (ATC)
and Code Inspector when running static code analysis. In fact, it focuses on the
usage of these tools in the context of HANA migration.
See SAP Note: 1912445
Possible adaptations of and corrections to ABAP custom code can generally be
divided into two main areas:

Functional adaptations

SQL performance optimizations


Analysis of the custom code is supported in both areas through static Code
Inspector checks in order to find the affected ABAP code parts.
In the case of functional adaptations of custom code, the primary goal is to
detect, using checks, ABAP code that relies on specific features of a database and
thus definitely needs to be analyzed and, if necessary, adapted. An example of this
is native SQL usage in ABAP custom code. Such functional adaptations require, for

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.

Executing Static Checks with ATC or Code


Inspector
These two tools are available for executing static checks:

ABAP Test Cockpit (ATC) - in the case of systems SAP EhP2 and upwards

for SAP NetWeaver 7.0 SP 12.


Code Inspector - in the case of older systems (< SAP EhP2 for SAP
NetWeaver 7.0, SP 12), static checks must be performed using the Code
Inspector instead.

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

Recommended Code Inspector Variants


When executing static checks for custom ABAP code, use the following optimized
Code Inspector variants:
Currently, the following checks are included in this check variant:
FUNCTIONAL_DB

Finding Native SQL

NoteFor native SQL, you have to check whether the SQL code can be run
on SAP HANA and whether it needs to be adapted.

Database (DB) hints

NoteMessages on DB hints are to be viewed solely as indications; although DB


hints are declared for specific databases, generally they do not need to be
adapted.

Finding ADBC (ABAP Database Connectivity) Usages

NoteThese usages are to be treated similarly to native SQL.

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.

Finding accesses to technical pools/clusters of a pool/cluster table

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.

Finding non-robust ABAP code that relies on non-ensured/implicit sorting of


certain SQL queries, although noORDER BY clause is used. There are two different
checks available for finding non-robust ABAP code:
o
Search problematic statementw/o ORDER BY
o
Depooling/Declustering: Search forw/o ORDER BY

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:

Checking SQL Operations without a WHERE Clause

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.

Checking settings in DDIC tables for consistency. In particular, this checks

whether table buffer settings have been maintained in a consistent manner


(influence on performance).
PERFORMANCE_DB
We recommend this check variant for performing a static performance check run for
ABAP custom code. The variant contains all the essential static SQL performance
checks.

However, we do not recommend an isolated view of these static performance


checks for the entire custom code because processing the results would be
ineffective. Pure static checks also include ABAP code that is not used at runtime at
all or is not critical for performance.
The essential tool for an overall view of the custom code with regard to performance
optimization is the new SQL Monitor. It returns aggregated performance data from
the productive system for the executed SQL commands. This runtime data of the
SQL Monitor often provides immediate work lists with potential performance
improvements for custom code.
In addition, however, this runtime data can be merged with results of the static
performance checks. This linking of both data sources is performed in the SQL
Performance Tuning Worklist tool. In this way, you get indications or even solution
suggestions from the static performance checks for SQL statements that stand out
negatively in the SQL Monitor.
NoteRemember that the selection of static checks within a check variant can
become obsolete at any time as a result of new findings, and may possibly need to
be amended. The content of the check variants therefore vary between the
supported SAP NetWeaver releases because in each release you may have different
checks / check parameters at your disposal.

Supplementary Runtime Checks


In addition to the static checks, there are supplementary runtime checks that are
executed using the Runtime Check Monitor tool.
The runtime checks thus complement the static checks with aspects that could not
be checked statically (for example, dynamic code) and they show only suspicious
code parts that were also executed at runtime.

Related Information
Runtime Checks

SQL Performance Tuning Worklist


The SQL Performance Tuning Worklist (transaction SWLT) enables you to find ABAP
SQL code that has potential for performance improvement. This tool combines
information from static ABAP code scans that normally run in a test or quality
system with runtime data from the SQL Monitor that typically originates from the
productive system. Based on data records collected by the SQL Monitor, the SQL
Performance Tuning Worklist automatically creates a worklist and allows you to
rank the findings according to specific performance issues and their business
relevance.

Overview of Features Provided

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

performance checks that refer to the executed SQL statements.


Restrict the result list to statements for which static performance check

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

previously exported from the productive system.


Evaluate data from Code Coverage if no SQL Monitor data is available in

the system.
Display a condensed (overview) list of findings that are sorted in accordance

with the selected performance indicators.


Display views with results from static checks and with SQL runtime data.
Navigate to and directly change the affected ABAP source code.

NoteContrary to the SQL Monitor, the SQL Performance Tuning


Worklist always aggregates the monitoring records by source code position.
(However, for each aggregated record you can check the underlying SQL monitoring
records in the detail view of the worklist.)

Getting started with Usage and Procedure Logging (UPL)


created by Shuge Guo on May 8, 2014 3:53 PM, last modified by
Jun 30, 2014 6:00 PM

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.

UPL What is it? What is the difference to ST03N workload


statistic?
UPL is a new functionality available in any ABAP based system based on the core
functionality of SAP Coverage Analyzer. Compared with workload statistic (ST03N),
the UPL result will be more accurate because it is able to detect also submitted
programs or dynamic calls, can detect the usage of any ABAP based unit down to
subroutines and will give you the transparency about used modifications, user exits,
classes and also single method executions. Furthermore workload statistic (ST03N)
only counts dialog steps but not the number of execution, but the UPL can count the
number of executed ABAP procedures on a daily base.

UPL What are benefits of UPL

No measurable performance impact neither CPU nor runtime


Supports all ABAP based systems
Catch also any dynamically called ABAP routines
Supports all ABAP procedure types down to subroutines

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

UPL _How it work


The UPL data will be collected every day and saved in an own encrypted data persistency layer
on the managed system. Within a predefined period a housekeeping job will purge the outdated
UPL data after 14(default) days. If activated from a Solution Manager system, the data will be
extracted and collected in an UPL cube on the BW of the Solution Manager for an unlimited
history and aggregated weeks and months to support different queries.

UPL_ Learning Materials

You can find all important contents regarding UPL (How to activate, system
preconditions, troubleshooting etc) by How To Guide

Anda mungkin juga menyukai