ABAP SQL Monitor

Implementation Guide and Best Practices

 www.sap.com

TABLE OF CONTENTS
ABAP SQL Monitor - What is it and why do I need it? ................................................................................. 3
When is it available and what are the technical requirements? ................................................................. 5
In which system shall I use the SQL Monitor? ............................................................................................. 5
SQL Monitor will run in production What is the performance overhead and average data volume? . 5
How long should the SQL Monitor be activated? ........................................................................................ 6
What are the steps to switch on the SQL Monitor in my production system? ......................................... 7
How do I use the data of the SQL Monitor? .................................................................................................. 9
Which data is displayed in SQL Monitor and how can I read it? .............................................................. 13
What is the best strategy to analyze SQL Monitor data? .......................................................................... 15
What are the steps to switch off the SQL Monitor and to purge all the data collected? ....................... 16
APPENDIX ...................................................................................................................................................... 17
Data volume consumption for releases before NW 740 SP8 .................................................................... 17
Data volume consumption using Time Series in NW 740 SP8 and higher releases .............................. 17

2016 SAP AG or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any

form or for any purpose without the express permission of SAP AG.
The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain

proprietary software components of other software vendors. National product
specifications may vary.

These materials are provided by SAP AG and its affiliated companies (SAP
Group) for informational purposes only, without representation or warranty of
any kind, and SAP Group shall not be liable for errors or omissions with
respect to the materials. The only warranties for SAP Group products and
services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be
construed as constituting an additional warranty.

SAP and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in
Germany and other countries.

Please see
http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark
for additional trademark information and notices.
ABAP SQL MONITOR

ABAP SQL Monitor - What is it and why do I need it?

Before you migrate an existing productive Business Suite to Business Suite on SAP HANA or S/4HANA custom ABAP
code needs to be adapted. This comprises corrections to avoid functional regressions (e.g. DB dependent code) as well
as performance optimizations on ABAP code that runs inefficiently as it does not apply to the classic performance
guidelines for Open SQL1 and thus prevents HANA from utilizing its strengths.

Detailed documentation on the overall process of custom code adaptions can be found here:

Thomas Fiedlers blog on ABAP custom code adaption for SAP HANA The efficient way:
http://scn.sap.com/community/s4hana/blog/2016/04/22/abap-custom-code-adaption-for-sap-hana-the-efficient-way

Considerations for Custom ABAP Code when Migrating to SAP HANA Best Practices and
Recommendations
http://go.sap.com/documents/2013/09/702792e8-527c-0010-82c7-eda71af511fa.html

The focus of this document is the performance optimization of SQL statements in custom code. In particular we
concentrate on how to find the most relevant SQL statements in the most relevant business processes to reduce
correction effort to a minimum.

If we want to find the most relevant SQL statements, we need to:

Monitor the (production) system

Identify the business processes with significant DB execution times
Identify the most time consuming SQL statements
Link SQL statement findings to relevant business processes

In essence, we need a tool, which monitors the performance of ALL ABAP SQL executions in a (production) system and
links the results back to the driving business processes.

For analyzing SQL statements there are already a number of tools, e.g.:

SQL Trace (ST05) and ABAP Runtime Analysis (SAT)

Statistics (STAD) and Workload Analysis (ST03)

Although SQL Trace and ABAP Runtime Analysis deliver detailed performance information about SQL statements and
are able to trace dedicated requests that can be linked to business processes, they are not designed to monitor a
system over a longer period of time. Statistics (STAD) and Workload Analysis (ST03), on the other side, are able to
monitor complete systems, but they do not deliver detailed performance information about SQL statements.

The ABAP SQL Monitor fills these gaps. It is able to monitor a complete system for a longer period of time while also
delivering detailed performance information about SQL statements that can be linked to business processes.

Using the SQL Monitor can answer questions such as:

Which of my business processes have the highest total SQL execution time - and are responsible for the main
load on the database?
What are the productive SQL profiles of my main business processes and which SQL statements are
involved?
Which SQL statements have the highest execution time and which business processes are affected by these
(slow) SQL statements?

1Please refer to Eric Westenbergers blog on Performance Guidelines for ABAP Development on the SAP HANA Database:
https://blogs.sap.com/2013/03/24/performance-guidelines-for-abap-development-on-the-sap-hana-database

3
ABAP SQL MONITOR

Which of my business processes run a huge number of SQL statements or work with a lot of data?
Which are the most often executed SQL statements in my custom code?

The ABAP SQL Monitor is designed for monitoring SQL statements with a minimum of overhead. It delivers detailed
statistic information about SQL statements and requests. In detail the ABAP SQL Monitor performs the following tasks:

Traces each and every SQL statement coming from an ABAP program - this includes OPEN SQL, CDS, ADBC,
native SQL, AMDP and SQL statements executed natively from inside the ABAP kernel
Aggregates and supplies statistic information for SQL statements with the same
o DB table name(s)
o SQL Statement location in ABAP (program, include, line)
o Request type and request name (e.g. transaction VA01)
Can be switched on for all or dedicated servers of an ABAP system
Can run in a production system during productive use, since the performance overhead is negligible (the data
collection is highly optimized by using kernel functionality, which buffers and pre-aggregates the
performance data in different memory layers before storing it asynchronously on the database)
Collects performance data for each traced SQL statement including:
o Number of executions
o Statistics on execution time (maximum, minimum, average, standard deviation)
o Statistics on fetched/changed rows
Collects performance data for all requests
o Number of requests
o Total request execution time (NW 7.40 SP5)
o Total DB execution time therein
Identifies the request entry point of each business process driving the traced SQL statement; the entry point
can be a transaction, report, RFC module or URL
Allows displaying the performance data aggregated by business process (request) or ABAP code location
Allows downloading SQL Monitor data in order to import it in a development system, where the code
corrections can be done
Show monitoring data in Time Series of arbitrary time periods, with automatic aggregation to larger time
periods as you go further back in time (NW 7.40 SP8)

The following screenshot shows an example for the SQL data display of SQL Monitor without aggregation and ranked
by executions.

4
ABAP SQL MONITOR

When is it available and what are the technical requirements?

SQL Monitor is available as a standard delivery of NW (SAP_BASIS software component) and via the ST-PI add-on.
The standard NW SQL Monitor is recommended for the relatively new NW releases like 702, 703/731, 740 and higher.
The ST-PI add-on variant has been added to serve older NW releases (but not older than NW release 700).

SQL Monitor
Supported NW Release Kernel version
variant
For NW releases < 740:
NW NW 702, NW 703/731, NW 740, and higher
use at least kernel 721
NW 700, NW 701, NW 702, NW 703/731, NW 710, NW 711, NW For NW releases < 740:
ST-PI add on
720, NW 730, NW 740 use at least kernel 721

Please refer to OSS note 1885926 for all details about availability and necessary preparation steps.

The following SQL Monitor description focuses on the feature set shipped with NW 740 SP3 or via the ST-PI add-on
(2008_1_700 SP8).
New features have been added in later SPs of 740, e.g. Time Series with NW 740 SP8. References to features
introduced in SPs later than NW 740 SP3 are marked in the text.

In which system shall I use the SQL Monitor?

The SQL Monitor can run in any ABAP system which fulfills the technical requirements, but since its task is to collect
realistic SQL performance data, it is normally used in a production system or in a test system, where "realistic" tests
are running.

SQL Monitor will run in production What is the performance overhead and average data volume?

The SQL Monitor data collection is highly optimized to ensure that it can run in parallel to production. In order to
ensure a minimum overhead, the SQL Monitor uses an efficient three level aggregation technique, which can be
roughly described as follows:

1. Aggregation at the level of the currently running internal session

When a SELECT statement is executed for a request (e.g. transaction VA01), then the SQL Monitor kernel
functionality stores the measured performance data in the local memory of this internal session. Once the
same SELECT statement at the same source position is executed again in this session, then the measured
data is aggregated into the same data record of the internal session.
2. Aggregation into shared memory of the application server
When an internal session is rolled out or closed, then the collected data is transferred and aggregated into
the shared memory of the server. A swap file is used, when the shared memory area for storing the SQL
Monitor is exhausted.
3. Aggregation into the database
The shared memory data is transferred to the database asynchronously by a batch job.

Aggregation at level 1 and 2 use fast memory access. Thus, storing the data for a single SQL statement during runtime
is in nearly all cases more than one order of magnitude faster than the execution time of the statement itself.
Similarly, transferring the internal session data to the shared memory is more than one order of magnitude faster than
the complete roll-out procedure of an internal session. Finally, well separated from the running business processes,
SQL Monitor batch jobs collect periodically the data from shared memory to the dedicated SQL Monitor database
tables.

5
ABAP SQL MONITOR

As a result the SQL Monitor performance overhead for the running requests of an application server is very low (lower
than 3 %.). The SQL Monitor has already been active in several large production systems (SAP in-house and customer
systems) without any noticeable performance impact on the running business processes.

The SQL Monitor aggregates data. The aggregation keys are roughly speaking the SQL statement (and here in
particular the source position in the ABAP program and the table name) and the request name. Thus, after a while, in
every system a kind of final saturation is reached, where nearly no additional records are added, but the existing
records are being updated with respect to their statistical data (e.g. Number of Executions or Execution Mean
Time). The amount of aggregated data the SQL Monitor finally collects depends on the diversity of requests and the
number of different SQL statements executed in a particular system. It increases with the number of SQL statement
executions in different programs and with the number of different requests, which trigger them.
First experience shows that after one day (24h) you see between 25.000 and 500.000 SQL Monitor records. The
number of SQL Monitor records then quickly reaches saturation, when all SQL statements and all requests2 have at
least been executed once. Finally, youre going to see between 100.000 and about 1-2 million SQL Monitor records
after 1-2 weeks, depending on your system. This translates to additional space requirements on the database of
between 100 MB and approx. 1-2 GB. A detailed calculation can be found in the appendix.

How long should the SQL Monitor be activated?

As the amount of data aggregated by the SQL Monitor reaches a state of saturation, there is in principle no need to
switch it off after a certain period of time. However, you should be clear on the data you want to analyze. If you, for
example, want to optimize requests of your normal production and let the SQL Monitor additionally run through the
monthly close phase, the aggregated data of your normal production requests may get blurred, which can have some
negative impact on the final analysis. Thus, it is recommended to limit the activation of SQL Monitor to the business
phase you are interested in. Once the relevant business phase has ended, the SQL Monitor should be switched off and
the data should be saved to a snapshot file, which can then be used for further analysis and code optimization in the
relevant development system.

From NW release 740 SP8 on Time Series are available and are the default. This means you can monitor results with
the granularity of 15 minutes to 24 hours (default is 1 hour). A retention time specifies after which time the results
should be aggregated to full days (default is 10 days) and finally another retention time can be specified, after which
the Time Series data will be automatically deleted (default is 365 days). This allows the SQL Monitor remain active in
your system for an arbitrary time, even across different business phases. When analyzing the data, you simply pick the
relevant time span. Needless to say, the Time Series feature results in additional memory consumption on your
database.

We recommend to start on other database systems than SAP HANA with Time Series settings:

1h as time period (default)

Aggregate Time Series older than 10 days to full days (default)
Delete data older than 90 days (default is 365 days)

These recommendations lead in medium sized systems to approx. 6-7 GB and for large systems to 13 GB additional
space needed on the database (details can be found in the appendix). When using SAP HANA, you can leave the
default settings (delete data older than 365 days rather than 90 days), which then leads to similar database space
requirements due to the efficient built-in SAP HANA data compression.

So in most cases the SQL Monitor should be able to run without any problems using the default settings. For special
cases however, the SQL Monitor resource consumption can be managed as follows:

2 A special problem for the aggregation of HTTP requests arise from the fact that some URL strings may contain request specific pattern, like
request identification via GUIDs. Taking these URLs as is would prevent the SQL Monitor from efficient request aggregation. Therefore the SQL
Monitor detects request specific pattern in URL strings and replaces them by uniform pattern (refer to note 1920319 for all the details).

6
ABAP SQL MONITOR

Record Limit
A record limit is set, when activating the SQL Monitor. Once this limit is reached, the SQL Monitor is deactivated. The
default value for the record limit is 2.000.000. Experience show that even in larger systems this record limit is not
reached.
If however you actually experience a SQL Monitor switch off due to the default record limit, you may double the
record limit in a first step, re-activate the SQL Monitor and then monitor how the number of records increase over
time. Use the SQL Monitor Log for this purpose.

Deactivation Date
When activating the SQL Monitor, a deactivation date needs to be specified. This eliminates the need for you to switch
off the SQL Monitor manually. It is recommended to set the deactivation date to the date, which you anticipate will
correspond with the end of all business processes of interest. When using Time Series in NW release 740 SP8 you may
specify a longer activation time period. It is possible to change the activation expiry date at any point in time using SQL
Monitor->Maintain Deactivation Schedule.

Emergency Switch
Should the activation of the SQL Monitor compromise the functionality of the application server, then there is a SQL
Monitor main switch. In such a case you can use profile parameter abap/sqlm/main_switch (to be changed in the
application server profile or along with transaction RZ11) to switch SQL Monitor functionality off. However, as of
today (and as far as we know) the SQL Monitor main switch has never been required, neither in-house at SAP nor at
customer side.

What are the steps to switch on the SQL Monitor in my production system?

In the following table you find a step by step description on how to implement and switch on the SQL Monitor in your
production system:

SQLM
Variant
Step Description
/
Release
OSS note 1885926 describes all the details about the kernel version you need, which
additional OSS notes have to be applied and how to get the NW SP or ST-PI add-on (if you
need it)
Software
Deployment
OSS note 1972328 summarizes all available corrections and improvements for the SQL
Monitor for all releases. Check which kernel patch level you should be using in your
release and which notes are applicable.
Apply selective privileges for those users who administrate the SQL Monitor and those
who only display SQL Monitor data.
Attach
For standard authorization object for trace tools (ST05 etc...) S_ADMI_FCD add new
Authorizations
authorization values:
to SQL Monitor NW
SQMA: administrate SQL Monitor: switch on/off etc...
users
SQMD: display SQLM Data

Add authorization for transaction code SQLM (administrate SQL Monitor).

Add authorization for transaction code SQLMD (display SQL Monitor data).
Apply selective privileges for those users who administrate the SQL Monitor and those
Attach
who only display SQL Monitor data.
Authorizations
ST-PI
to SQL Monitor
For standard authorization object for trace tools (ST05 etc...) S_ADMI_FCD add existing
users
authorization values:

7
ABAP SQL MONITOR

ST0M(authorization to change trace switches) for administrate SQL Monitor

ST0R(authorization to analyze traces) for display SQLM Data

Add authorization for transaction code /SDF/ZQLM (administrate SQL Monitor)

Add authorization for transaction code /SDF/ZQLMD (display SQL Monitor data)
Run transaction SQLM (ST-PI: /SDF/ZQLM)
Standard is to switch on SQL Monitor on all servers to collect all running SQL statements in
the system:
Choose: SQL Monitor->Activate->all servers
If you want to switch on the SQL Monitor only on dedicated servers, then choose
SQL Monitor->Activate->Selected servers and select the servers in the provided server
list. You can use the same functionality to change the server activation at any time.
Switch on SQL
Monitor and
NW / In both scenarios you are prompted for the SQL Monitor activation expiry date - meaning
define
ST-PI when the SQL Monitor shall be switched off automatically. It is recommended to set the
activation
deactivation date to any date, which you anticipate will correspond with the end of all
expiry
business processes of interest.
When using Time Series in NW release 740 SP8 you may specify a longer activation time
period.
After activation you can change the activation expiry date at any point in time using
SQL Monitor->Maintain Deactivation Schedule.

Use the default value for the record limit of 2.000.000.

Run transaction SQLM (ST-PI: /SDF/ZQLM) and choose SQL Monitor -> Server State ->
Check Server State.
A server list with information about the actual SQL Monitor activation state and whether
the actual state matches the expected state is shown.
Verify server
NW /
activation
ST-PI
status

If there is an inconsistency then you can try to correct this either using SQL Monitor ->
Server State -> Ensure Server State or you deactivate and activate SQL Monitor again.
Verify in the Job overview (SM37) that the job RTM_PERIODIC_JOB is running periodically
(once an hour).
If this job is not scheduled, then run transaction SRTM and choose
Verify/Schedule Only for Runtime Monitor-> Administration -> Settings.
SQL Monitor NW 740 Here you see the job administration for the job RTM_PERIODIC_JOB which should have
jobs SP2 been scheduled automatically when accessing Runtime monitor (SRTM) the first time.
Verify that the SQL Monitor data replication is scheduled:
Check in the job overview if the job RSQLM_UPDATE_DATA is scheduled periodically.
If this job is not scheduled, then follow the instructions of OSS note 1859369.
No action necessary.
The following jobs are scheduled/verified automatically, when SQL Monitor is switched
on:
NW 702,
NW 731,
RTM_PERIODIC_JOB
Verify/Schedule NW 740
Runs periodically once an hour.
SQL Monitor SP3 and
Basic job, collects data from shared memory and stores it in DB tables.
jobs higher
SQLM_UPDATE_DATA/SCHEDULE (ST-PI: /SDF/ZQLM_UPDATE_DATA/SCHEDULE)
Runs periodically once an hour and replicates data to SQL Monitor tables.
ST-PI
SQLM_DEACTIVATE/SCHEDULE (ST-PI: /SDF/ZQLM_DEACTIVATE/SCHEDULE)
Runs at the specified date and time to deactivate the SQL Monitor.

8
ABAP SQL MONITOR

If the job scheduling should fail then an appropriate status information is visible in the SQL
Monitor start screen.

In order to solve this, just deactivate and then reactivate the SQL Monitor. If this does not
help please verify that you are allowed to schedule batch jobs.

How do I use the data of the SQL Monitor?

After activating the SQL Monitor it takes approximately one hour until the first data can be displayed. This delay
occurs due to the periodic nature of the SQL Monitor batch jobs responsible for collecting the data.
The SQL Monitor data can be accessed via transaction SQLMD (/SDF/ZQLMD for ST-PI version) or by pressing the
button "Display data" in SQL Monitor start screen.

The following table contains usage scenarios and how these can be realized using SQL Monitor:

Step Description
Run transaction SQLM or /SDF/ZQLM.
Choose SQL Monitor -> Display Log/History.
Specify a start date for the log display. As a result you will be presented with a chronological list of SQL
Analyze Monitor events like activation/deactivation of SQL Monitor, deletion of SQL Monitor records,
SQL Monitor replication of data done by the periodic jobs etc
Log to
determine In order to analyze the SQLM data you can use this information to determine, when the measurement
when the started or if someone deleted the data in between.
SQL Monitor
has been Additionally, you can display the accruement of SQL Monitor records over time to estimate if an
activated adapted record limit is appropriate.

Finally, you can use the SQL Monitor Log, if you are interested in detailed information pertaining to
the SQL Monitor activity and events, especially warnings and errors.
You normally download SQL Monitor data, when you want to analyze it in another system or if you
intend to switch off the SQL Monitor and delete all the data in order to start from scratch (e.g.
after you have done some correction on SQL statements).
Download
SQL Monitor
To download SQL Monitor data press button "Download Data" in the SQL Monitor start screen.
data
NW 740 SP2 only
Running the report RSQLM_DOWNLOAD_DATA downloads the current SQL Monitor data to a local file.

9
ABAP SQL MONITOR

In the selection screen you can choose what you want to download, for example only customer code
packages (Z*, Y*). If no selection restrictions are defined everything is downloaded.
Additionally you need to specify the local file for the download.
The result is a zip file containing the SQL Monitor data in XML format, which you then can import into
a development system, where you perform your code changes.
Access SQL Run transaction SQLMD or /SDF/ZQLMD or press the button "Display data" in the SQLM or /SDF/ZQLM
Monitor data monitor start screen.
In the SQL Monitor data selection screen limit the packages to your custom code (e.g. Z*, Y*) and
aggregate by source position. Order by total time or executions.

Display the
top n custom
code SQL
statements
of the
system
sorted by
Total Time /
Executions

Display the
top n
requests
with the In the SQL Monitor data selection screen choose aggregation by request and order by Total Time/
highest SQL Executions:
load /
highest SQL
traffic

10
ABAP SQL MONITOR

You can drill down from the top n request list (see scenario "Display the top n requests with the
highest SQL load") or directly limit the display to one request (e.g. transaction VA01).

Display the
SQL profile
of a request

11
ABAP SQL MONITOR

Limit the display to one database table to evaluate which customer ABAP code is accessing the table:

Display the
usage of a
DB table

12
ABAP SQL MONITOR

Which data is displayed in SQL Monitor and how can I read it?

Example screenshot with aggregation = none, sorted by executions and without a filter. All not self-explanatory
columns have a F1 help to provide the necessary information.

Here is a short summary of the most interesting fields and their meanings:

Example
Field Meaning
value
Mean Time[ms] 0,950 ms Average (aggregated) execution time of the SQL statement in milliseconds
Mean Records 0,667 Average number of rows selected or changed by the SQL statement
DB table(s) used during execution of the SQL statement.
For joins or sub queries, the involved database table names are presented as a
Table Names DD02L comma separated list.
For dynamic access, you may find several trace entries with different table names
for the same Open SQL statement.
SELECT SQL Operation kind - here you can distinguish between Read and Write accesses as
SQL Operation
(Open SQL) well as Open and Native SQL.
Number of different internal sessions (roll areas), where this SQL statement has
Int. Sessions 2.954 been executed. For a simple report (request type Submit Report) the number of
internal sessions equals the number of report executions.
Average execution counter of the SQL statement per session. In this example the
Executions/Session 35,987 SQL was executed in average 36 times per internal session.
High execution/session values are often an indication for a select within a loop.

Note: All time values are displayed in milliseconds. All numbers are displayed with 3 decimal places. (Don't overlook
the comma before the last 3 digits - e.g. 2.220,570 ms is ~2.221 milliseconds)

Another example screenshot from NW release 740 SP5 with aggregation by request, sorted by total DB time and
without a filter.

13
ABAP SQL MONITOR

Here is a short summary of the most interesting fields and their meanings:

Field Example value Meaning

Total Records 369.032.400 Total number of fetched/changed rows
Mean Records 4,945
Max Records 100.000 Statistics on fetched/changed rows about mean, maximum, minimum
Min Records 0 values and standard deviation.
Dvtn Records 651,831
Summarized database execution time (for executing this particular
Total DB Time 441.514.573,5 ms
request) in milliseconds
DB Mean Time 5,916
DB Max Time 11.323 Statistics on DB execution time about mean, maximum, minimum
DB Min Time 0,376 values and standard deviation.
DB Dvtn Time 16,223
Total time of all requests of this particular request entry point spent
Total Time 447.770.339,2 ms in the work processes (ABAP execution time plus DB time) in
milliseconds
Ratio of database execution time to total request execution time for
DB Time/Total Time[%] 98,60%
all requests of this particular request entry point
Total number of DB statements executed for all requests of this
Total DB Executions 74.626.760
particular request entry point

14
ABAP SQL MONITOR

What is the best strategy to analyze SQL Monitor data?

In principle, there are 2 main strategies for analysis: request view and system view. The request view shows the
requests dominated by SQL statements and enables you to focus on performance optimizations of the most relevant
business processes. The system view points you to those SQL statements with the biggest performance footprint
system-wide. This enables you to focus on overall system performance optimizations, where in general more than one
request or business process is involved.

Steps Details
Choose aggregation by request - no filter (and no max nr of records limitation!).
Now you have the complete list of requests, which ran SQL statements in your
system!

Rank this list by Total DB time to get the requests with the highest total SQL
execution time.

In NW release 740 SP5 and higher you can additionally check the contribution of the
Total DB Time to overall requests execution time. Rank list by DB Time / Total Time
[%] to focus on those requests, where the Total DB Time dominates the overall
requests execution time.
Step 1: Request View
Rank this list by DB Executions to get the requests, which run most of the SQL
Get an overview of your main
statements.
SQL driven requests
Rank this list by Total DB Records to get the requests with the highest total
fetch/change row count.

Now check the top 10 of these rankings and inspect the SQL profile of all 10 listed
requests (keep in mind the aggregated value of the measurement value you are
interested in, e.g. Total DB Time).
To do so, drill down (link in "Records" column) and rank again by the column of
interest (e.g. Total DB Time).
Analyze the top entries, which contribute most to the total value you found on
request level.
Experience shows that the first top 5 SQL statements in the SQL profile contribute up
to 80% of the measurement value of interest.
Choose aggregation by source position - no filter (and no max nr of records
limitation).
Now you have the complete list of ABAP SQL statements executed in your system.

Step 2: System View Sort by Total DB time or DB Executions.

Get the most often executed Check the min/max/standard deviation values of these top entries to figure out
and most expensive SQL whether e.g. only one SQL execution was extremely slow (due to e.g. DB lock) or
statements (limited to whether almost all executions are slow.
customer code) You can drill down using the "Requests" column to see, which requests are driving
these top SQL statements.
When sorted by Executions and after the drill down into the Requests, focus on
the high values in column "Executions/Session", since these often point to SQL
statements performed in loops.
Choose aggregation by source position -no filter (and no max nr of records limitation).
Now you have the complete list of ABAP SQL statements executed in your system.
Step 3: System View
Get the SQL statements
Sort by Total DB Records.
reading/writing most of the
Check the min/max values for records. If the maximum and minimum is always the
data
same (and equals the total number of lines stored in the DB table) then this might be
a SQL statement without a where clause. If you see a big difference between max and

15
ABAP SQL MONITOR

min value then this might be a SQL statement with an empty FOR ALL ENTRIES table
or empty RANGE tables.
Choose aggregation by request. Filter by Request Type and Request Entry Point
Step 4: Request View
(e.g. transaction VA01).
Analyze dedicated requests
which you want to optimize
Now proceed like described in step 1.

Experience shows that for all analysis steps described here there are low hanging fruits, meaning a quite small
number of SQL statements, which can be easily adapted and will lead to significant improvements of the relevant
business processes as well as the overall database and application server performance.

After importing all the SQL/ABAP corrections, we recommend to start SQL Monitoring from scratch to check, whether
the performance adaptions were beneficial.
When using Time Series with NW 740 SP8 you do not need to turn off the SQL Monitor in order to compare the
performance data of single SQL statements or complete requests before and after your corrections.

What are the steps to switch off the SQL Monitor and to purge all the data collected?

The following table describes how to switch off the SQL Monitor on all servers and delete the SQL Monitor data.

SQLM
Step Variant / Description
Release
Switch
NW / In SQL Monitor (transaction SQLM or /SDF/ZQLM for ST-PI version) use menu
off SQL
ST-PI SQL Monitor -> Deactivate
Monitor
Run transaction SQLM (ST-PI: /SDF/ZQLM) and choose
SQL Monitor -> Server State -> Check Server State.
As a result you will see a server list with information about the current SQL Monitor activation
state and if the actual state matches the expected state.

Verify
server NW /
activation ST-PI
status

If there is an inconsistency then you can try to correct this using

SQL Monitor -> Server State -> Ensure Server State.
Or you directly logon to the inconsistent server and deactivate SQL Monitor for this server
again.
In SQL Monitor (transaction SQLM or /SDF/ZQLM for ST-PI version) use menu
SQL Monitor -> Data-> Delete.
Delete
SQL NW /
Only in NW 740 SP8 or higher:
Monitor ST-PI
When using Time Series you can delete Time Series data older than an arbitrary number of
data
days using menu
SQL Monitor -> Time Series Data -> Delete.

16
ABAP SQL MONITOR

APPENDIX
Data volume consumption for releases before NW 740 SP8

As a rule of thumb, we can estimate the memory consumption per SQL Monitor record used on the database to 1
Kbyte. This translates to approx. 100MB additional space on the database for 100.000 records or 2GB for 2 million
records.

Data volume consumption using Time Series in NW 740 SP8 and higher releases

In NW 740 SP8 the memory consumption of one SQL Monitor record has been reduced significantly. Now the SQL
Monitor uses approx. 200 byte (previously 1Kbyte) for each aggregated record. When using Time Series the number of
overall records consists of

Number of records in all existing non-aggregated Time Series (default: 1h time periods during the last 10
days)
Number of records for full days (default: aggregated after 10 days, deleted after 365 days)
Number of records in the current result set

When using the recommend settings for other database systems than SAP HANA:

1h as time period (default)

Aggregate Time Series older than 10 days to full days (default)
Delete data older than 90 days (default is 365 days)

this results in

240 time slices with duration of 1 hour

80 time slices (aggregated) with duration of 1 day

Experiences in in-house SAP systems as well as in customer systems show for:

Medium sized systems

50.000 records per hour

250.000 records per day (aggregated)
1.000.000 overall records in the current result set

Large systems

100.000 records per hour

500.000 records per day (aggregated)
2.000.000 overall records in the current result set.

This translates to 33 million records in medium sized systems and to 66 million records in large systems.

17
ABAP SQL MONITOR

The resulting database space needed for medium sized systems is thus 6-7 GB for medium sized systems and 13GB for
large systems.

Using SAP HANA with built-in data compression brings the SQL Monitor data down to one quarter (experiences from
SAP in-house systems). Thus with SAP HANA, you can keep the data for 365 days (default settings) with the same
memory consumption as above.

18