Here is the documentation
1.1 SQL Performance Tuning
Worklist
1.1.1 Purpose
The SQL Performance Tuning Worklist tool (transaction /SWLT)
enables you to find ABAP SQL code that has potential for performance
improvement in productive business processes. This tool combines new ABAP code
scans (ABAP Test Cockpit or Code Inspector /SCI) with monitoring and
analysis utilities (SQL Monitor and Coverage Analyzer), and automatically
creates a condensed worklist. The resulting findings allow you to rank the
worklist according to specific performance issues and your business relevance.
enables you to find ABAP SQL code that has potential for performance
improvement in productive business processes. This tool combines new ABAP code
scans (ABAP Test Cockpit or Code Inspector /SCI) with monitoring and
analysis utilities (SQL Monitor and Coverage Analyzer), and automatically
creates a condensed worklist. The resulting findings allow you to rank the
worklist according to specific performance issues and your business relevance.
Prior to analyzing static checks, appropriate ABAP test cockpit
runs must be performed in the case of systems SAP EhP2 and upwards for SAP
NetWeaver 7.0 SP 12, and their results must be replicated into the relevant
system. In the case of older systems (< SAP EhP2 for SAP NetWeaver 7.0, SP
12), static checks must be performed with the Code Inspector instead.
runs must be performed in the case of systems SAP EhP2 and upwards for SAP
NetWeaver 7.0 SP 12, and their results must be replicated into the relevant
system. In the case of older systems (< SAP EhP2 for SAP NetWeaver 7.0, SP
12), static checks must be performed with the Code Inspector instead.
Recommendation
For the execution of static checks (ABAP Test Cockpit or Code
Inspector) we recommend using the pre-defined Code Inspector variant PERFORMANCE_DB.
Inspector) we recommend using the pre-defined Code Inspector variant PERFORMANCE_DB.
Moreover, in case you are only interested in static check results
for SQL statements that have been recorded by the SQL Monitor, we advise you to
use the Code Inspector object collector CL_CI_COLLECTOR_SQLM_SNAPSHOT("Objects of
SQLM-Snapshot"). This object collector allows restricting the inspection's
object set to objects that are contained in a previously recorded SQL Monitor /SQLMsnapshot which helps to optimize the performance and memory consumption of
the used scan and analysis tools.
for SQL statements that have been recorded by the SQL Monitor, we advise you to
use the Code Inspector object collector CL_CI_COLLECTOR_SQLM_SNAPSHOT("Objects of
SQLM-Snapshot"). This object collector allows restricting the inspection's
object set to objects that are contained in a previously recorded SQL Monitor /SQLMsnapshot which helps to optimize the performance and memory consumption of
the used scan and analysis tools.
1.1.2 Features
Options for Object Selection
You can select development objects that are suitable for analysis
using various criteria. For example, you can limit the objects to a particular
set of packages or a particular object type.
using various criteria. For example, you can limit the objects to a particular
set of packages or a particular object type.
Options for SQL Monitoring
You can either use snapshots that already exist in the system for
SQL monitoring data or, if required, generate new ones.
SQL monitoring data or, if required, generate new ones.
Managing Snapshots of SQL Monitor Data
The snapshot management can be initiated either from the selection
screen of transaction SWLT (via the button "Manage Snapshots") or by
executing the report SWLT_SQLM_CREATE_SNAPSHOT. You can generate new snapshots directly
from the local system or by specifying an RFC destination. Alternatively, you
can also upload a snapshot file previously created with the report RSQLM_DOWNLOAD_DATA. In addition, there is an option to delete snapshots based on
their creation date.
screen of transaction SWLT (via the button "Manage Snapshots") or by
executing the report SWLT_SQLM_CREATE_SNAPSHOT. You can generate new snapshots directly
from the local system or by specifying an RFC destination. Alternatively, you
can also upload a snapshot file previously created with the report RSQLM_DOWNLOAD_DATA. In addition, there is an option to delete snapshots based on
their creation date.
Options for Results Display from Static Checks
You can make adjustments for the
selection and display of results of static checks (ATC or Code Inspector).
selection and display of results of static checks (ATC or Code Inspector).
Compressed Overview Display
In accordance with your selection options, you will get a list of
results (findings) that, in the standard version, are sorted according to the
number of executions or the execution time. From here you already have the
possibility to detect the performance hotspots. From the overview display, you
can double-click the line in question and request the details view for runtime
data and data from the respective static check.
results (findings) that, in the standard version, are sorted according to the
number of executions or the execution time. From here you already have the
possibility to detect the performance hotspots. From the overview display, you
can double-click the line in question and request the details view for runtime
data and data from the respective static check.
Detailed View with SQL Monitoring Data
Using the SQL Monitor Results display function, you can perform a
more advanced breakdown or analysis of the runtime data; in particular, you can
determine the entry point of the processes or DB operations.
more advanced breakdown or analysis of the runtime data; in particular, you can
determine the entry point of the processes or DB operations.
Detailed View with Results from Static Checks
Using another detailed view, you can analyze the findings from the
static check with regard to their relevance for possible code optimization.
Here, the statements on priority, severity, and estimated work effort are of
particular relevance.
static check with regard to their relevance for possible code optimization.
Here, the statements on priority, severity, and estimated work effort are of
particular relevance.
Integration of Code Coverage
If no SQL data is available in the
system, you can evaluate the data from the code coverage.
system, you can evaluate the data from the code coverage.
1.1.3 Activities
The typical procedure for working
with SWLT transaction involves the following steps:
with SWLT transaction involves the following steps:
- 1. Launch transaction SWLT.
- 2. On the Selection Screen, specify the options for the object
selection, the SQL monitoring data, and for displaying the static check
findings. - 3. Choose Execute (F8).
- 4. On the Aggregated Results Overview screen, identify and
analyze the performance hotspots. - 5. On the Aggregated Results Overview screen, double-click
the corresponding table row to open the detailed view. - 6. Analyze the details for the runtime data and the static check
findings.