Sapnote_155413 - Analysis of Slow SQL Statements

7/28/2019 Sapnote_155413 - Analysis of Slow SQL Statements

http://slidepdf.com/reader/full/sapnote155413-analysis-of-slow-sql-statements 1/6

SAP Note 460268 - Could not find stored procedure

Note 155413 - Analysis of slow SQL statementsHeader

Version / Date 4 / 2002-07-29

Priority Recommendations/additional info

Category Help for error analysis

Primary Component BC-DB-MSS Microsoft SQL Server

Secondary Components

Summary

Symptom

An ABAP report can be slow for various reasons. If the report needs a lot of time on the database, you should examine this more precisely

using the R/3 SQL Trace.

This note provides an overview for analyzing slow SQL statements for the Microsoft SQL Server. Refer to the online documentation or the

specialized literature for the precise use of the R/3 transactions.

The cause for the long runtime of a ABAP report is often quite simple and it can be found with the help of this note. If this is not possible, you

should call in a consultant. The consultant needs the following information for the analysis.

Other terms

SQL trace, ST05, SQL Server 7.0, SQL Server 2000, explain SQL, density

Reason and Prerequisites

Both the R/3 and the SQL server achieve their best performance a few hours after starting. This is due to the fact, that frequently required data

is buffered. The buffers need some time before they are optimally filled. For this reason, an ABAP often runs significantly faster during the

second execution.

A hanging situation suddenly makes the entire R/3 system run slow. The analysis of a hanging situation is described in Note 155402. In contrast

to this, this note describes the analysis of individual reports which are always slow.

Solution

For the analysis of a slow ABAP report, start an R/3 SQL trace (Transaction ST05). A Transaction ST05 trace shows the Native SQL

Statements (SQL Server T-SQL) that R/3 sends to the database. The Native SQL Statements do not necessarily need to be identical with the

Open SQL statements of the ABAP.The ST05 traces are stored on the application server as a file. Old ST05 traces are automatically overwritten. You should therefore keep the

ST05 trace as small as possible and analyze it immediately. All relevant information should be saved manually in a file because the ST05 trace

may no longer be available the next day.

I. Required information

The following information has to be saved as a text file:

• ST05 trace

Logon using two different R/3 users (A and B) on the same application server. This should be the application server, on which the updates

occur (DIA and UPD work process).

As users A, activate user B's SQL trace (Transaction ST05).

Execute the slow transaction as user B.

Deactivate the SQL trace as user A (Transaction ST05)

Display the SQL trace of user B (Transaction ST05).

An ST05 trace is illustrated in the example below.

• Explain SQL

The output of the ST05 trace contains the runtime of the individual SQL statements in microseconds (1.0E-6 sec). SQL statements with longer




Summary

runtimes are displayed red.

Select the slowest SQL statement and press the "Explain SQL" pushbutton.

The execution plan for this SQL statement appears. The execution plan shows the indices, which the SQL Server would use at the

present time to execute the SQL statement. This execution plan may change as soon as the contents of the database changes or an automatic

statistics update is executed.

An "Explain SQL" is illustrated in the example below.

• ABAP report

In the ABAP report you can see the original Open SQL statement, that generates the native SQL statement (visible in Transaction STO5).

Select the slowest SQL statement in the ST05 trace and press the button "ABAP display".

Save the displayed section from the ABAP report.

In addition, make a note of the report's name.

• Statistics

An SQL statement is often very slow because no suitable index exists or is used by the query optimizer. You therefore need the statistics of all

tables involved in the slow SQL statement for analysis:

Start the Transaction DB02 and press the button "Detail analysis".

A list of all statistics is displayed after entering the table name.

Select the required statistics and press the button "Show statistics".

II. Causes for slow SQL statements

As soon as you have collected all information described above, you can examine the cause for a slow SQL statement:

• Statistics are too old

The query optimizer of the SQL server generates the execution plan of a SQL statement. During this generation the decision is made, whether

and which indices of a table are used for the respective SQL statement. The query optimizer needs statistics from tables and their fields to

make this decision. Up-to-date statistics are a requirement for an efficient database. SQL Server updates the statistics automatically. For this

the following database options of the <SAPSID> database must be set:

Auto create statistics

Auto update statistics

• A missing or inappropriate index

The query optimizer makes the decision when creating the execution plan which indices are to be used. The density of an index is decisive for

this decision. The smaller the density the better the index is.

See the examples below

• For All Entries Parameter

The Open SQL statement "Select for all entries" must be transformed into several Native SQL statements prior to the execution. The kind of

transformation can be influenced by means of R/3 profile parameters. These profile parameters have a considerable influence on

performance.




Summary

See Note 77013

• A re-used execution plan

SAP R/3 uses Stored Procedures (SP's) for accessing the SQL Server. The SQL Server generates the execution plan during the first call of

the SP. All additional calls use the same execution plan until the SP is re-compiled (caused, for example, by an automatic statistics update).

This improves the overall performance of the R/3 System. However, in rare cases this can result in very long-running SQL statements.

See Note 159171

• Result set is too large

An ABAP programmer should always select only the data that is really required. Unfortunately, the following methods are frequently used:

Reading a complete database table in an internal ABAP table. Selecting the desired data records f ron the internal ABAP

table

Reading the complete data record (SELECT *) instead of the data actually required (SELECT F1, F2, .. FROM)

This causes performance problems!

III. Examples

The following example shows the index statistics of the table COEJ. You should pay attention to the following sections:

• The date of the last statistics update is in the section "Updated" (Mar 30 1999). If the data of the table changed heavily since this

date, an unfavorable execution plan may be generated.

• The density is in the section "All density" for every usable combination of fields. The smaller the density the more useful the index is.

• The histogram of the first index field is in the section "Steps". The other fields of the index have no histogram. If SQL Server needs a

further histogram, it automatically creates column statistics. A column statistic has the name _WA_Sys_* and is set up precise like an index

statistic.

In R/3, an index normally consists of several fields. The index can only be used for a selection if the first field of the index occurs in the where-

clause of the SQL command. If the first two, three, four ... fields occur in the WHERE-Clause the density gets better and better. The chances

increases that the index is actually used by the SQL Server.

Statistics for INDEX 'COEJ~0'.

Updated Rows Rows Sampled Steps Density

==================== =========== ============ =========== ============

Mar 30 1999 3:57AM 123213 123213 300 0.0

All density Columns

=============================

1.0 MANDT

0.33333334 MANDT, KOKRS

1.9432569E-4 MANDT, KOKRS, BELNR

8.1160269E-6 MANDT, KOKRS, BELNR, BUZEI

8.1160269E-6 MANDT, KOKRS, BELNR, BUZEI, PERBL

Steps

=====

800

800

800

...

Statistics for INDEX 'COEJ~1'.

Updated Rows Rows Sampled Steps Density

==================== =========== ============ =========== ============

Mar 30 1999 3:57AM 123213 123213 300 0.0

All density Columns

=================================




Summary

1.0 MANDT

1.0 MANDT, LEDNR

1.447178E-3 MANDT, LEDNR, OBJNR

5.9701491E-4 MANDT, LEDNR, OBJNR, GJAHR

4.3047784E-4 MANDT, LEDNR, OBJNR, GJAHR, WRTTP

4.0064103E-4 MANDT, LEDNR, OBJNR, GJAHR, WRTTP, VERSN

4.331817E-5 MANDT, LEDNR, OBJNR, GJAHR, WRTTP, VERSN, KSTAR

4.2879808E-5 MANDT, LEDNR, OBJNR, GJAHR, WRTTP, VERSN, KSTAR, H

4.2879808E-5 MANDT, LEDNR, OBJNR, GJAHR, WRTTP, VERSN, KSTAR, H

...

Steps

=====

800

800

800

...

Example A

KOKRS, BELNR and BUZEI are selected via the f ields in the report ZZCOEJA. The f ield MANDT is supplemented automatically by ABAP. The

density for these four fields is 8.1E-6 (see the index statistics of COEJ~0). This way the primary index COEJ~0 fits optimally.ABAP:

----------------------------------------------------------------------

1 report zzcoeja.

2 data tmp like coej occurs 100 with header line.

3 select * from coej into table tmp

4 where belnr = '0000004711'

5 and buzei = '001'

6 and kokrs = '1000'.

7 loop at tmp.

8 write: / tmp-kokrs, tmp-belnr, tmp-buzei, tmp-perbl.

9 endloop.

ST05:

----------------------------------------------------------------------

Duration Object Oper Rec RC Statement

14.536 COEJ OPEN 0 SELECT WHERE "MANDT" = @P000 AND5.304 COEJ FETCH 1 0

282 COEJ FETCH 0 0

Explain SQL:

----------------------------------------------------------------------

SELECT

Clustered Index Seek(OBJECT:([IDS].[dbo].[COEJ].[COEJ~0]),

SEEK:([COEJ].[MANDT]=[@1] AND [COEJ].[KOKRS]=[@4] AND

[COEJ].[BELNR]=[@2] AND [COEJ].[BUZEI]=[@3]) ORDERED)

BUZEI and MANDT are selected via the fields in the report ZZCOEJB. Both fields are indeed contained in the primary index COEJ~0, however,

only MANDT can be used for a selection with the help of this index (because KOKRS and BELNR are not contained in the where-clause).

ABAP:

----------------------------------------------------------------------1 report zzcoejb.



4 where buzei = '001'.

5 write: / sy-dbcnt.

ST05:

----------------------------------------------------------------------


987.437 COEJ OPEN 0 SELECT WHERE "MANDT" = @P000 AND




Summary

6.775 COEJ FETCH 7 0



...

Explain SQL:

----------------------------------------------------------------------

SELECT

Clustered Index Seek(OBJECT:([IDS].[dbo].[COEJ].[COEJ~0]),

SEEK:([COEJ].[MANDT]='800'),

WHERE:([COEJ].[BUZEI]='001') ORDERED)

This explain has the form:

• Index Seek( OBJECT(..), SEEK(..), WHERE(..) )

All data records which correspond to the SEEK(..) condition are accessed here. Additional WHERE(..) conditions are only checked after reading

the data record. Almost all data records are for client 800. Therefore the Explain corresponds to a full table scan.

Example B

In the report ZZCOEJC, the SQL Server uses the suitable secondary index COEJ~1. The SELECT only needs a few milliseconds and fetches

only one data record.

ABAP:

---------------------------------------------------------------------

1 report zzcoejc.



4 where objnr = 'KL100000000041005000'

5 and lednr = '00'.


ST05:

---------------------------------------------------------------------



5.387 COEJ FET 1 0281 COEJ FETC 0 0

Explain SQL:

----------------------------------------------------------------------

SELECT

Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([IDS].[dbo].[COEJ]) W

Index Seek(OBJECT:([IDS].[dbo].[COEJ].[COEJ~1]), SEEK:([COEJ].

[MANDT]='800' AND [COEJ].[LEDNR]='00' AND [COEJ].[OBJNR]=

'KL100000000041005000') ORDERED)

In the report ZZCOEJD, the SQL Server also uses the secondary index. However, in contrast to report ZZCOEJC, this time it takes a few

seconds because over 2000 data records are read. The example shows that you must also pay attention to the number of selected data records

in addition to the duration of an SQL command.

ABAP:

---------------------------------------------------------------------

1 report zzcoejd.

2 * slow select using secundary index 1, 2604 row selected



5 where objnr = 'KL100000000010001510'

6 and lednr = '00'.


ST05:

---------------------------------------------------------------------




Summary






...

Explain SQL:

---------------------------------------------------------------------

SELECT

Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([IDS].[dbo].[COEJ]) W

Index Seek(OBJECT:([IDS].[dbo].[COEJ].[COEJ~1]), SEEK:([COEJ].

[MANDT]='800' AND [COEJ].[LEDNR]='00' AND [COEJ].[OBJNR]=

'KL100000000010001510') ORDERED)

Related Notes

1558087 SQL Server Statistics Maintenance

489690 CC INFO: Copying large production clients

208919 CC-INFO: Performance as of Release 4.6

159171 Recompilation of Stored Procedures

77013 Resolution of 'select for all entries'

67205 CC-INFO: Copying large and productive clients

http://www.stechno.net/sap-notes.html?view=sapnote&id=1558087












Documents

Sapnote_155413 - Analysis of Slow SQL Statements