cancel
Showing results for 
Search instead for 
Did you mean: 

SD reports are running slow

former_member182034
Active Contributor
0 Kudos

hi All,

here SD users are getting slow system when they execute that tcode which get data from VB?? tables. So, ABAPER is saying me that i have to create indexes against field VBFA-VBELV. When i check the indexes against VBFA then the result is:

MANDT	MANDT	CLNT	3	0	Client
VBELV	VBELN_VON	CHAR	10	0	Preceding sales and distribution document
POSNV	POSNR_VON	NUMC	6	0	Preceding item of an SD document
VBELN	VBELN_NACH	CHAR	10	0	Subsequent sales and distribution document
POSNN	POSNR_NACH	NUMC	6	0	Subsequent item of an SD document
VBTYP_N	VBTYP_N	CHAR	1	0	Document category of subsequent document
RFMNG	RFMNG	QUAN	15	3	Referenced quantity in base unit of measure
MEINS	MEINS	UNIT	3	0	Base Unit of Measure
RFWRT	RFWRT	CURR	15	2	Reference value
WAERS	WAERS_V	CUKY	5	0	Statistics currency

when i check the indexex against VBFA then result is:

Index Name	Extension Index	Status	Last Changed By	Date	Switch	Switch Position
M01	X	New	SAP	7/3/2006	ISM_MPS_BASIS	off

this field VBFA-VBELV is already a primary index.

now please tell me if i create the index against VBFA-VBELV then speed will be fast or not.

if you required more information then please tell me

Regards,

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi majamil,

try to find out the SQL_ID and SQL text of the bad performing SQL statement. E.g. by checking transaction ST04 -> Wait Event Analysis -> Session Monitor. Then get the execution plan of the query and post it to this thread. With this information we can decide what to do with it and whether an additional index might help.

Regards,

Mark

former_member182034
Active Contributor
0 Kudos

hi Mark,

there are showing many SQL Statement in Session Monitor while number of user are accessing VBFA table with different tcodes. but I want to get the sql statement against VA02. how can i get relevant sql statement. or i just find that statement which is having VBFA table.

Regards,

Former Member
0 Kudos

Maybe your ABAPer can help, for example by showing you the relevant ABAP which contains the SQL statement.

If not, then call the Oracle SQL Tuning Advisor:

sqlplus "/ as sysdba"
@?/rdbms/admin/sqltrpt.sql

If your SD transaction is executed frequently and shows a bad performance, then it should be listed among the most expensive SQL statements from the cursor cache or AWR data.

former_member182034
Active Contributor
0 Kudos

Dear Mark,

now every tx is taking too much time special those tcode which are getting data from VBXX tables . Please check the Workload Overveiw in ST03.

Task Type Name	Number of Dialog Steps	Average response Time/Dialog Step (ms)	Avg. Processing Time	Average CPU Time (ms)	Ø DB Time (ms)	Ø Time/DB Procedure Call (ms)	Average Wait Time per Dialog Step (ms)	Average Roll In Time (ms)	Average Roll Wait Time (ms)	Average Load and Generation Time (ms)	Average Lock Time per Dialog Step (ms)	Average RFC Interface Time (ms)	Average Frontend Network Time (ms)	Average GUI Time per Dialog Step (ms)	Number of Roundtrips	Requested Data (KB)	Number of Sequential Reads	Total Sequential Read Time (s)	Average Sequential Read Time (ms)	Number of Direct Reads	Total Time for Direct Reads (s)	Average Time for Direct Reads (ms)	Number of Logical Database Changes	Total Time for Logical DB Changes (s)	Average Time for Logical DB Changes (ms)	Number of Logical Database Calls	Average Time per Log. Database Call (ms)	No.  of Physical Database Read Accesses	Number of Modified Database Records	# Records Read from Single Record Buffer	Total Roll-In Time (s)	Total Roll Wait Time (s)	Total roll-out time (s)	Number of Roll In Operations	Number of Roll-Out Operations	Average Roll-In Time per Roll-In (ms)	Average Roll-Out Time (ms)	% CPU Time	% Database Time	% DB Proc. Time	% Wait Time	% Roll-In Time	% roll wait time	% Load/Gen. Time
DIALOG	241856	1583.0	219.7	124.2	1086.9	0.0	176.3	0.6	91.7	7.4	0.4	3.1	217.6	102.6	428826	126819992	42420350	250967	5.9	40951594	9094	0.2	412103	2822	6.8	83784047	3.1	29906629	561446	20587851	143	22178	106	452911	455050	0.3	0.2	7.8	68.7	0.0	11.1	0.0	5.8	0.5
RFC	9697	582.6	325.0	36.7	103.9	0.0	114.5	0.3	35.7	3.1	0.0	11.8	10.2	31.5	2049	917322	216461	785	3.6	220469	87	0.4	32745	136	4.2	469675	2.1	200017	32916	92432	3	346	1	7997	7999	0.4	0.2	6.3	17.8	0.0	19.7	0.1	6.1	0.5
UPDATE	9169	757.0	24.4	28.1	719.7	0.0	1.7	0.0	0.0	11.0	0.3	0.0	0.0	0.0	0	2688880	607461	702	1.2	579043	201	0.3	295774	5695	19.3	1482278	4.5	196492	672686	428007	0	0	0	0	0	0.0	0.0	3.7	95.1	0.0	0.2	0.0	0.0	1.4
UPDATE2	7163	157.6	12.1	12.6	131.9	0.0	11.0	0.0	0.0	2.6	0.0	0.0	0.0	0.0	0	774125	365691	102	0.3	199570	100	0.5	290240	742	2.6	855501	1.1	67617	505598	164856	0	0	0	0	0	0.0	0.0	8.0	83.7	0.0	7.0	0.0	0.0	1.6
BACKGROUND	6866	491.1	171.4	37.7	198.5	0.0	73.1	0.1	0.0	46.4	1.6	102.7	0.0	0.0	0	1966693	421664	904	2.1	293634	242	0.8	52567	218	4.1	767865	1.8	418051	51834	106773	0	0	0	2911	3015	0.1	0.1	7.7	40.4	0.0	14.9	0.0	0.0	9.4
AUTOTH	5057	80.9	1.5	0.7	1.6	0.0	77.7	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0	348	0	0	0.0	4148	7	1.8	2074	1	0.3	6222	1.3	2074	2074	0	0	0	0	0	0	0.0	0.0	0.9	2.0	0.0	96.1	0.0	0.0	0.0
SPOOL	4324	538.8	518.0	7.2	19.7	0.0	0.1	0.1	0.0	0.9	0.0	0.0	0.0	434.0	4301	176165	29286	9	0.3	165525	28	0.2	29120	48	1.7	223931	0.4	74227	27411	14245	0	0	0	3352	3352	0.1	0.1	1.3	3.7	0.0	0.0	0.0	0.0	0.2
DEL. THCALL	3623	114.4	7.6	0.1	1.0	0.0	105.8	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0	118	0	0	0.0	1474	3	2.0	737	1	1.1	2211	1.7	737	704	0	0	0	0	0	0	0.0	0.0	0.1	0.9	0.0	92.5	0.0	0.0	0.0
HTTP	2878	133.0	15.7	1.2	2.7	0.0	113.4	0.0	0.0	1.2	0.0	0.0	0.0	0.0	0	17529	66388	5	0.1	29036	2	0.1	0	0	0.0	95424	0.1	468	0	20223	0	0	0	0	0	0.0	0.0	0.9	2.0	0.0	85.3	0.0	0.0	0.9
BUFFER SYNC	1539	161.7	5.7	0.2	5.8	0.0	150.1	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0	16	1440	9	5.9	194	0	1.9	97	0	0.3	1731	5.2	10602	97	0	0	0	0	0	0	0.0	0.0	0.1	3.6	0.0	92.9	0.0	0.0	0.0
DDLOG CLEANUP	1530	200.4	5.9	0.1	42.5	0.0	152.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0	15	0	0	0.0	288	61	210.9	92	4	46.2	380	171.1	144	90	0	0	0	0	0	0	0.0	0.0	0.0	21.2	0.0	75.8	0.0	0.0	0.0
AUTOABAP	668	1747.6	601.6	265.4	964.2	0.0	113.3	1.7	0.0	64.2	2.4	0.0	0.0	0.0	0	875761	152987	490	3.2	175934	146	0.8	4324	8	1.9	333245	1.9	69616	4326	147434	1	0	1	14065	14065	0.1	0.1	15.2	55.2	0.0	6.5	0.1	0.0	3.7
RPCTH	20	6274.5	3871.7	73.5	2401.4	0.0	0.0	0.0	0.0	1.3	0.0	0.0	0.0	0.0	0	31210	1192	16	13.5	2588	26	10.0	88	6	69.1	3868	12.4	2166	8	24	0	0	0	0	0	0.0	0.0	1.2	38.3	0.0	0.0	0.0	0.0	0.0
OTHER	7	3874.3	220.1	11.1	5.1	0.0	3040.4	0.6	607.3	0.7	0.0	0.0	3495.1	0.0	0	42	11	0	0.1	21	0	1.6	0	0	0.0	32	1.1	7	0	13	0	4	0	7	7	0.6	0.3	0.3	0.1	0.0	78.5	0.0	15.7	0.0

if you required more info then please tell me and guide me to sort out the issue.

Regards,

former_member182034
Active Contributor
0 Kudos

SQL*Plus: Release 10.2.0.4.0 - Production on Thu Jun 30 21:28:24 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> @E:\oracle\PRD\102\RDBMS\ADMIN\sqltrpt.sql

15 Most expensive SQL in the cursor cache
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SQL_ID           ELAPSED SQL_TEXT_FRAGMENT
------------- ---------- -------------------------------------------------------

5g5bt1vnj07cb  18,069.54 SELECT /*+ FIRST_ROWS (1)  */ "VBELV" FROM "VBFA" WHERE

cc66p9qk304w7  17,174.34 SELECT T_01 . "FKIMG" , T_01 . "BRTWR" , T_00 . "FKART"

8tu62pr56jvpg   9,577.37 SELECT "MATNR" , "ARBPL" , "STAT" FROM "VIQMELST" WHERE

3h7npwfaa1ywx   6,051.33 SELECT "VBELN" , "VKORG" , "KUNNR" , "ERDAT" FROM "VBAK

4mvqyrcxbfyw0   5,842.11 SELECT /*+ FIRST_ROWS (1)  */ "ERFME" , SUM( "ERFMG" )
7k7yb9pvdcd6q   5,492.74 SELECT SUM( "KWMENG" ) FROM "VBAP" WHERE "MANDT" = :A0
3pp5t5d6n8ws7   5,442.17 SELECT * FROM "EKBE" WHERE "MANDT" = :A0 AND "EBELN" =
agsss4791n1nr   4,605.19 SELECT "MANDT" , "BUKRS" , "HKONT" , "AUGDT" , "AUGBL"
9y1g9p15fmtja   4,092.96 INSERT INTO "TST03" VALUES( :A0 , :A1 , :A2 , :A3 , :A4

bgdzvk36rb29p   3,648.18 SELECT /*+ FIRST_ROWS (1)  */ * FROM "BSAD" WHERE "MAND

dajfu53gf8wd6   3,642.63 SELECT T_00 . "MANDT" , T_00 . "BUKRS" , T_00 . "KUNNR"


SQL_ID           ELAPSED SQL_TEXT_FRAGMENT
------------- ---------- -------------------------------------------------------

7btr9qzszwan9   3,394.04 SELECT * FROM "VBFA" WHERE "MANDT" = :A0 AND "VBELV" =
4z4tvxrmpgd2x   3,304.01 SELECT "ADRNR" , "ADRNR_ILOA" , "ARBPL" , "ARBPLWERK" ,

1mz5jdc7ngd4u   3,223.30 SELECT /*+ FIRST_ROWS (1)  */ * FROM "VBAP" WHERE "MAND

bk9b65z6k4ktx   2,806.50 SELECT T_02 . "MATNR" , T_00 . "BUDAT" , SUM( T_01 . "M


15 Most expensive SQL in the workload repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SQL_ID           ELAPSED
------------- ----------
SQL_TEXT_FRAGMENT
--------------------------------------------------------------------------------

5g5bt1vnj07cb  96,054.08
SELECT /*+ FIRST_ROWS (1)  */ "VBELV" FROM "VBFA" WHERE

8tu62pr56jvpg  70,497.35
SELECT "MATNR" , "ARBPL" , "STAT" FROM "VIQMELST" WHERE

cc66p9qk304w7  53,295.31
SELECT T_01 . "FKIMG" , T_01 . "BRTWR" , T_00 . "FKART"


SQL_ID           ELAPSED
------------- ----------
SQL_TEXT_FRAGMENT
--------------------------------------------------------------------------------

7pusy4xtaqy1v  38,192.22
SELECT "MATNR" , "BWART" FROM "RESB" WHERE "MANDT" = :A

3h7npwfaa1ywx  34,958.06
SELECT "VBELN" , "VKORG" , "KUNNR" , "ERDAT" FROM "VBAK

7k7yb9pvdcd6q  32,628.97
SELECT SUM( "KWMENG" ) FROM "VBAP" WHERE "MANDT" = :A0


SQL_ID           ELAPSED
------------- ----------
SQL_TEXT_FRAGMENT
--------------------------------------------------------------------------------

28zu0sgkdr7a1  30,272.09
SELECT /*+ FIRST_ROWS (1)  */ "INACT" FROM "JEST" WHERE

4mvqyrcxbfyw0  27,905.70
SELECT /*+ FIRST_ROWS (1)  */ "ERFME" , SUM( "ERFMG" )

bgdzvk36rb29p  23,726.21
SELECT /*+ FIRST_ROWS (1)  */ * FROM "BSAD" WHERE "MAND


SQL_ID           ELAPSED
------------- ----------
SQL_TEXT_FRAGMENT
--------------------------------------------------------------------------------

frptzdfxtpmrc  22,508.19
SELECT "MANDT" , "BUKRS" , "KUNNR" , "UMSKS" , "UMSKZ"

1p6dxyb7cuatn  20,849.43
SELECT /*+ FIRST_ROWS (1)  */ * FROM "MVKE" WHERE "MAND

5ynun06y6z5g0  20,677.10
SELECT * FROM "JEST" WHERE "MANDT" = :A0 AND "OBJNR" IN


SQL_ID           ELAPSED
------------- ----------
SQL_TEXT_FRAGMENT
--------------------------------------------------------------------------------

3pp5t5d6n8ws7  16,182.37
SELECT * FROM "EKBE" WHERE "MANDT" = :A0 AND "EBELN" =

4kh7mcyhbq84r  16,019.42
SELECT /*+ FIRST_ROWS (1)  */ "PERNR" FROM "KNVP" WHERE

9uas0gh6ga0ym  15,748.93
SELECT /*+ FIRST_ROWS (1)  */ * FROM "MCHB" WHERE "MAND


Specify the Sql id
~~~~~~~~~~~~~~~~~~
Enter value for sqlid:Specify the Sql id
~~~~~~~~~~~~~~~~~~
Enter value for sqlid: prd

Sql Id specified: prd

Tune the sql
~~~~~~~~~~~~
ERROR: statement is not in the cursor cache or the workload repository.
Execute the statement and try again

Regards,

Former Member
0 Kudos

Hi majamil,

the SQL statement with ID 5g5bt1vnj07cb is the top SQL statment (according to total processing time) both with the current cursor cache and the whole of the AWR data. And it is selecting column VBELV from table VBFA. So: Bingo! I believe we have identified the crucial statement.

Can you please run sqltrpt.sql once more and enter 5g5bt1vnj07cb as the SQL_ID? Let's see what the SQL Tuning Advisor says about this statement.

Regards,

Mark

former_member182034
Active Contributor
0 Kudos

hi Mark,

thanks for putting light on SQL Tunning Advisor,

the result of you query is following:


SQL*Plus: Release 10.2.0.4.0 - Production on Mon Jul 4 16:39:38 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> @E:\oracle\PRD\102\RDBMS\ADMIN\sqltrpt.sql

15 Most expensive SQL in the cursor cache
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SQL_ID           ELAPSED SQL_TEXT_FRAGMENT
------------- ---------- -------------------------------------------------------

8tu62pr56jvpg   7,957.23 SELECT "MATNR" , "ARBPL" , "STAT" FROM "VIQMELST" WHERE

3h7npwfaa1ywx   5,274.72 SELECT "VBELN" , "VKORG" , "KUNNR" , "ERDAT" FROM "VBAK

1p6dxyb7cuatn   3,896.13 SELECT /*+ FIRST_ROWS (1)  */ * FROM "MVKE" WHERE "MAND

7pusy4xtaqy1v   3,526.53 SELECT "MATNR" , "BWART" FROM "RESB" WHERE "MANDT" = :A

5ynun06y6z5g0   3,453.73 SELECT * FROM "JEST" WHERE "MANDT" = :A0 AND "OBJNR" IN

bgdzvk36rb29p   2,844.02 SELECT /*+ FIRST_ROWS (1)  */ * FROM "BSAD" WHERE "MAND

7k7yb9pvdcd6q   2,386.18 SELECT SUM( "KWMENG" ) FROM "VBAP" WHERE "MANDT" = :A0
5d94k4rwt3u3y   1,559.90 SELECT DISTINCT T_00 . "VBELN" FROM "VBFA" T_00 WHERE T

3a24f5pd6acmk   1,527.26 SELECT * FROM "EKBZ" WHERE "MANDT" = :A0 AND "EBELN" =
34gy2jzvyc65t   1,436.75 SELECT "HKONT" , "DMBTR" FROM "BSIS" WHERE "MANDT" = :A

9u40n6bma8t62   1,405.76 SELECT T_00 . "MENGE" , T_00 . "BWART" FROM "MSEG" T_00


SQL_ID           ELAPSED SQL_TEXT_FRAGMENT
------------- ---------- -------------------------------------------------------

9uas0gh6ga0ym   1,388.64 SELECT /*+ FIRST_ROWS (1)  */ * FROM "MCHB" WHERE "MAND

0qk61uqwz0tyb   1,386.57 SELECT "VBELN" , "ERDAT" , "VBTYP" , "AUART" , "VKORG"
89mf23wgsyqdy   1,359.67 SELECT DISTINCT T_00 . "VBELN" FROM "VBFA" T_00 WHERE T

c014m3g3q885z   1,223.60 SELECT /*+ FIRST_ROWS (1)  */ * FROM "NRIV" WHERE "CLIE


15 Most expensive SQL in the workload repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SQL_ID           ELAPSED
------------- ----------
SQL_TEXT_FRAGMENT
--------------------------------------------------------------------------------

5g5bt1vnj07cb ##########
SELECT /*+ FIRST_ROWS (1)  */ "VBELV" FROM "VBFA" WHERE

8tu62pr56jvpg  70,466.51
SELECT "MATNR" , "ARBPL" , "STAT" FROM "VIQMELST" WHERE

cc66p9qk304w7  67,136.48
SELECT T_01 . "FKIMG" , T_01 . "BRTWR" , T_00 . "FKART"


SQL_ID           ELAPSED
------------- ----------
SQL_TEXT_FRAGMENT
--------------------------------------------------------------------------------

7pusy4xtaqy1v  37,706.60
SELECT "MATNR" , "BWART" FROM "RESB" WHERE "MANDT" = :A

3h7npwfaa1ywx  32,855.42
SELECT "VBELN" , "VKORG" , "KUNNR" , "ERDAT" FROM "VBAK

28zu0sgkdr7a1  27,434.87
SELECT /*+ FIRST_ROWS (1)  */ "INACT" FROM "JEST" WHERE


SQL_ID           ELAPSED
------------- ----------
SQL_TEXT_FRAGMENT
--------------------------------------------------------------------------------

7k7yb9pvdcd6q  25,760.96
SELECT SUM( "KWMENG" ) FROM "VBAP" WHERE "MANDT" = :A0

bgdzvk36rb29p  25,674.19
SELECT /*+ FIRST_ROWS (1)  */ * FROM "BSAD" WHERE "MAND

4mvqyrcxbfyw0  25,497.31
SELECT /*+ FIRST_ROWS (1)  */ "ERFME" , SUM( "ERFMG" )


SQL_ID           ELAPSED
------------- ----------
SQL_TEXT_FRAGMENT
--------------------------------------------------------------------------------

5ynun06y6z5g0  22,339.86
SELECT * FROM "JEST" WHERE "MANDT" = :A0 AND "OBJNR" IN

1p6dxyb7cuatn  19,655.83
SELECT /*+ FIRST_ROWS (1)  */ * FROM "MVKE" WHERE "MAND

4kh7mcyhbq84r  16,047.70
SELECT /*+ FIRST_ROWS (1)  */ "PERNR" FROM "KNVP" WHERE


SQL_ID           ELAPSED
------------- ----------
SQL_TEXT_FRAGMENT
--------------------------------------------------------------------------------

9uas0gh6ga0ym  15,315.56
SELECT /*+ FIRST_ROWS (1)  */ * FROM "MCHB" WHERE "MAND

frptzdfxtpmrc  14,710.75
SELECT "MANDT" , "BUKRS" , "KUNNR" , "UMSKS" , "UMSKZ"

agsss4791n1nr  14,144.84
SELECT "MANDT" , "BUKRS" , "HKONT" , "AUGDT" , "AUGBL"


Specify the Sql id
~~~~~~~~~~~~~~~~~~
Enter value for sqlid: 5g5bt1vnj07cb

Sql Id specified: 5g5bt1vnj07cb

Tune the sql
~~~~~~~~~~~~
ERROR: statement is not in the cursor cache or the workload repository.
Execute the statement and try again

Regards,

majamil

Former Member
0 Kudos

Hi majamil,

yes this is annoying. It also happened often to me that the SQL code wasn't available any more. Maybe that was due to the weekend and the public holiday on Monday. As the script suggests, you can run the SQL tuning advisor once more to see whether the SQL statment was executed again in the meantime. Since it is showing up so high among the top SQL statements, chances are quite high that it will be available now.

Is your AWR retention time still set to 7 days (the Oracle 10g default value)? You can check that via quering view DBA_HIST_WR_CONTROL. Then consider raising that to some longer period like e.g. 31 days. Extending the retention period is also recommended by SAP. All you need is some more space for tablespace SYSAUX, but the in case of performance problems the AWR data is really useful.

Regards,

Mark

former_member182034
Active Contributor
0 Kudos

hi Mark,

Sorry for Delay,

Dear, again, I executed Tune Adviser and result is:


SQL*Plus: Release 10.2.0.4.0 - Production on Thu Jul 21 16:22:31 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> @E:\oracle\PRD\102\RDBMS\ADMIN\sqltrpt.sql

15 Most expensive SQL in the cursor cache
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SQL_ID           ELAPSED SQL_TEXT_FRAGMENT
------------- ---------- -------------------------------------------------------

8tu62pr56jvpg  11,662.87 SELECT "MATNR" , "ARBPL" , "STAT" FROM "VIQMELST" WHERE

28zu0sgkdr7a1  10,883.70 SELECT /*+ FIRST_ROWS (1)  */ "INACT" FROM "JEST" WHERE

1p6dxyb7cuatn  10,034.91 SELECT /*+ FIRST_ROWS (1)  */ * FROM "MVKE" WHERE "MAND



15 Most expensive SQL in the workload repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SQL_ID           ELAPSED
------------- ----------
SQL_TEXT_FRAGMENT
--------------------------------------------------------------------------------

8tu62pr56jvpg  37,315.79
SELECT "MATNR" , "ARBPL" , "STAT" FROM "VIQMELST" WHERE

7pusy4xtaqy1v  27,145.76
SELECT "MATNR" , "BWART" FROM "RESB" WHERE "MANDT" = :A



Specify the Sql id
~~~~~~~~~~~~~~~~~~
Enter value for sqlid: 8tu62pr56jvpg

Sql Id specified: 8tu62pr56jvpg

Tune the sql
~~~~~~~~~~~~

GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name                  : TASK_28213
Tuning Task Owner                 : SYS
Scope                             : COMPREHENSIVE
Time Limit(seconds)               : 1800
Completion Status                 : COMPLETED
Started at                        : 07/21/2011 16:24:46
Completed at                      : 07/21/2011 16:25:26
Number of SQL Profile Findings    : 1

----------------------------
Schema Name: SAPSR3

SQL ID     : 8tu62pr56jvpg
SQL Text   : SELECT "MATNR" , "ARBPL" , "STAT" FROM "VIQMELST" WHERE "MANDT"
             = :A0 AND "ERDAT" BETWEEN :A1 AND :A2 AND "STAT" <> :A3 AND (
             "QMART" = :A4 OR "QMART" = :A5 ) AND "MATNR" <> :A6

-------------------------------------------
FINDINGS SECTION (1 finding)
-------------------------------------------

1- SQL Profile Finding (see explain plans section below)
--------------------------------------------------------
  A potentially better execution plan was found for this statement.


  Recommendation (estimated benefit<=10%)
  ---------------------------------------
  - Consider accepting the recommended SQL profile.
    execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_28213',
            replace => TRUE);

-------------------------------------
EXPLAIN PLANS SECTION
---------------------------------------
1- Original With Adjusted Cost
------------------------------
Plan hash value: 2447980984


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

-----------
| Id  | Operation                        | Name   | Rows  | Bytes | Cost (%CPU)|

 Time     |
---------------------

-----------
|   0 | SELECT STATEMENT                 |        |   103 | 15244 |  3340   (1)|

 00:00:18 |
|*  1 |  FILTER                          |        |       |       |            |

          |
|*  2 |   TABLE ACCESS BY INDEX ROWID    | JEST   |     1 |    29 |     9   (0)|

 00:00:01 |

|   3 |    NESTED LOOPS                  |        |   103 | 15244 |  3340   (1)|

 00:00:18 |
|   4 |     NESTED LOOPS                 |        |   100 | 11900 |  2439   (1)|

 00:00:13 |
|   5 |      NESTED LOOPS                |        |   100 | 10200 |  2338   (1)|

 00:00:13 |
|*  6 |       TABLE ACCESS FULL          | QMEL   |   100 |  7200 |  2139   (1)|

 00:00:12 |
|   7 |       TABLE ACCESS BY INDEX ROWID| QMIH   |     1 |    30 |     2   (0)|

 00:00:01 |
|*  8 |        INDEX UNIQUE SCAN         | QMIH~0 |     1 |       |     1   (0)|

 00:00:01 |
|*  9 |      INDEX UNIQUE SCAN           | ILOA~0 |     1 |    17 |     1   (0)|


 00:00:01 |
|  10 |     INLIST ITERATOR              |        |       |       |            |

          |
|* 11 |      INDEX UNIQUE SCAN           | JEST~0 |     1 |       |     8   (0)|

 00:00:01 |
--------------------------------------------------------------------------------

-----------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(:A1<=:A2)
   2 - filter("T1"."INACT"=' ')

   6 - filter("T2"."ERDAT">=:A1 AND "T2"."ERDAT"<=:A2 AND ("T2"."QMART"=:A4 OR
              "T2"."QMART"=:A5) AND "T2"."MATNR"<>:A6 AND "T2"."MANDT"=:A0)
   8 - access("T3"."MANDT"=:A0 AND "T3"."QMNUM"="T2"."QMNUM")
   9 - access("T4"."MANDT"=:A0 AND "T4"."ILOAN"="T3"."ILOAN")
  11 - access("T1"."MANDT"=:A0 AND "T1"."OBJNR"="T2"."OBJNR" AND
              ("T1"."STAT"='I0068' OR "T1"."STAT"='I0069' OR "T1"."STAT"='I0070'

 OR
              "T1"."STAT"='I0072' OR "T1"."STAT"='I0076' OR "T1"."STAT"='I0167')

)
       filter("T1"."STAT"<>:A3)

2- Original With Adjusted Cost
------------------------------

Plan hash value: 2819618961

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

-----------
| Id  | Operation                        | Name   | Rows  | Bytes | Cost (%CPU)|

 Time     |
--------------------------------------------------------------------------------

-----------
|   0 | SELECT STATEMENT                 |        |   103 | 15244 |  3340   (1)|

 00:00:18 |
|*  1 |  FILTER                          |        |       |       |            |

          |
|*  2 |   TABLE ACCESS BY INDEX ROWID    | JEST   |     1 |    29 |     9   (0)|


 00:00:01 |
|   3 |    NESTED LOOPS                  |        |   103 | 15244 |  3340   (1)|

 00:00:18 |
|   4 |     NESTED LOOPS                 |        |   100 | 11900 |  2439   (1)|

 00:00:13 |
|   5 |      NESTED LOOPS                |        |   100 | 10200 |  2338   (1)|

 00:00:13 |
|*  6 |       TABLE ACCESS FULL          | QMEL   |   100 |  7200 |  2139   (1)|

 00:00:12 |
|   7 |       TABLE ACCESS BY INDEX ROWID| QMIH   |     1 |    30 |     2   (0)|

 00:00:01 |
|*  8 |        INDEX UNIQUE SCAN         | QMIH~0 |     1 |       |     1   (0)|

 00:00:01 |

|*  9 |      INDEX UNIQUE SCAN           | ILOA~0 |     1 |    17 |     1   (0)|

 00:00:01 |
|  10 |     INLIST ITERATOR              |        |       |       |            |

          |
|* 11 |      INDEX UNIQUE SCAN           | JEST~0 |     1 |       |     8   (0)|

 00:00:01 |
--------------------------------------------------------------------------------

-----------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(:A1<=:A2)

   2 - filter("T1"."INACT"=' ')
   6 - filter("T2"."ERDAT">=:A1 AND "T2"."ERDAT"<=:A2 AND ("T2"."QMART"=:A4 OR
              "T2"."QMART"=:A5) AND "T2"."MATNR"<>:A6 AND "T2"."MANDT"=:A0)
   8 - access("T3"."MANDT"=:A0 AND "T3"."QMNUM"="T2"."QMNUM")
   9 - access("T4"."MANDT"=:A0 AND "T4"."ILOAN"="T3"."ILOAN")
  11 - access("T1"."MANDT"=:A0 AND "T1"."OBJNR"="T2"."OBJNR" AND
              ("T1"."STAT"='I0068' OR "T1"."STAT"='I0069' OR "T1"."STAT"='I0070'

 OR
              "T1"."STAT"='I0072' OR "T1"."STAT"='I0076' OR "T1"."STAT"='I0167')

)
       filter("T1"."STAT"<>:A3)

3- Using SQL Profile

--------------------
Plan hash value: 2819618961

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

-----------
| Id  | Operation                        | Name   | Rows  | Bytes | Cost (%CPU)|

 Time     |
--------------------------------------------------------------------------------

-----------
|   0 | SELECT STATEMENT                 |        |   103 | 15244 |  3340   (1)|

 00:00:18 |
|*  1 |  FILTER                          |        |       |       |            |

          |

|*  2 |   TABLE ACCESS BY INDEX ROWID    | JEST   |     1 |    29 |     9   (0)|

 00:00:01 |
|   3 |    NESTED LOOPS                  |        |   103 | 15244 |  3340   (1)|

 00:00:18 |
|   4 |     NESTED LOOPS                 |        |   100 | 11900 |  2439   (1)|

 00:00:13 |
|   5 |      NESTED LOOPS                |        |   100 | 10200 |  2338   (1)|

 00:00:13 |
|*  6 |       TABLE ACCESS FULL          | QMEL   |   100 |  7200 |  2139   (1)|

 00:00:12 |
|   7 |       TABLE ACCESS BY INDEX ROWID| QMIH   |     1 |    30 |     2   (0)|

 00:00:01 |
|*  8 |        INDEX UNIQUE SCAN         | QMIH~0 |     1 |       |     1   (0)|


 00:00:01 |
|*  9 |      INDEX UNIQUE SCAN           | ILOA~0 |     1 |    17 |     1   (0)|

 00:00:01 |
|  10 |     INLIST ITERATOR              |        |       |       |            |

          |
|* 11 |      INDEX UNIQUE SCAN           | JEST~0 |     1 |       |     8   (0)|

 00:00:01 |
--------------------------------------------------------------------------------

-----------

Predicate Information (identified by operation id):
---------------------------------------------------


   1 - filter(:A1<=:A2)
   2 - filter("T1"."INACT"=' ')
   6 - filter("T2"."ERDAT">=:A1 AND "T2"."ERDAT"<=:A2 AND ("T2"."QMART"=:A4 OR
              "T2"."QMART"=:A5) AND "T2"."MATNR"<>:A6 AND "T2"."MANDT"=:A0)
   8 - access("T3"."MANDT"=:A0 AND "T3"."QMNUM"="T2"."QMNUM")
   9 - access("T4"."MANDT"=:A0 AND "T4"."ILOAN"="T3"."ILOAN")
  11 - access("T1"."MANDT"=:A0 AND "T1"."OBJNR"="T2"."OBJNR" AND
              ("T1"."STAT"='I0068' OR "T1"."STAT"='I0069' OR "T1"."STAT"='I0070'

 OR
              "T1"."STAT"='I0072' OR "T1"."STAT"='I0076' OR "T1"."STAT"='I0167')

Regards,

Former Member
0 Kudos

Hello majamil,

the output is difficult to read, but interesstingly the SQL Tuning Advisor shows always the same execution plan:

- Original With Adjusted Cost

- Using SQL Profile

So the SQL Tuning Advisor is no help here, I believe the execution plan is fine and cannot be improved. Anyway I don't think SQL statement 8tu62pr56jvpg is relevant for your SD transactions. It would be more interessting to see the SQL Tuning Advisor running against SQL ID 5g5bt1vnj07cb.

Regards,

Mark

former_member182034
Active Contributor
0 Kudos

hi Mark,

now i got your point mean I have to trace the VBELV from table VBFA (not Oracle Expert)

today i am tracing the VBELV from table VBFA but it did not see in SQL Tune Advisor. anyways.. i got VBELN against VBFA.

please check....

Specify the Sql id
~~~~~~~~~~~~~~~~~~
Enter value for sqlid: bcxcr58na9gz0

Sql Id specified: bcxcr58na9gz0

Tune the sql
~~~~~~~~~~~~

GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name                  : TASK_28245
Tuning Task Owner                 : SYS
Scope                             : COMPREHENSIVE
Time Limit(seconds)               : 1800
Completion Status                 : COMPLETED
Started at                        : 07/22/2011 16:53:28
Completed at                      : 07/22/2011 16:53:32
Number of SQL Profile Findings    : 1
Number of Index Findings          : 1

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

Schema Name: SAPSR3
SQL ID     : bcxcr58na9gz0
SQL Text   : SELECT DISTINCT T_00 . "VBELN" FROM "VBFA" T_00 WHERE T_00 .
             "MANDT" = :A0 AND T_00 . "VBELV" = :A1 AND T_00 . "VBTYP_N" =
             :A2 AND T_00 . "POSNV" IN ( :A3 , :A4 , :A5 ) AND T_00 . "VBELN"
             NOT IN ( SELECT T_100 . "SFAKN" FROM "VBRK" T_100 WHERE T_100 .
             "MANDT" = :A6 AND T_100 . "SFAKN" <> :A7 )

-------------------------------------------------------------------------------
FINDINGS SECTION (2 findings)
-------------------------------------------------------------------------------

1- SQL Profile Finding (see explain plans section below)

--------------------------------------------------------
  A potentially better execution plan was found for this statement.

  Recommendation (estimated benefit: 97.65%)
  ------------------------------------------
  - Consider accepting the recommended SQL profile.
    execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_28245',
            replace => TRUE);

2- Index Finding (see explain plans section below)
--------------------------------------------------
  The execution plan of this statement can be improved by creating one or more
  indices.


  Recommendation (estimated benefit: 99.54%)
  ------------------------------------------
  - Consider running the Access Advisor to improve the physical schema design
    or creating the recommended index.
    create index SAPSR3.IDX$$_6E550001 on SAPSR3.VBRK("SFAKN");

  Rationale
  ---------
    Creating the recommended indices significantly improves the execution plan
    of this statement. However, it might be preferable to run "Access Advisor"
    using a representative SQL workload as opposed to a single statement. This
    will allow to get comprehensive index recommendations which takes into

    account index maintenance overhead and additional space consumption.

-------------------------------------------------------------------------------
EXPLAIN PLANS SECTION
-------------------------------------------------------------------------------

1- Original With Adjusted Cost
------------------------------
Plan hash value: 1180966534

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

--------
| Id  | Operation                     | Name   | Rows  | Bytes | Cost (%CPU)| Ti


me     |
--------------------------------------------------------------------------------

--------
|   0 | SELECT STATEMENT              |        |     1 |    42 | 65740   (1)| 00

:05:43 |
|   1 |  HASH UNIQUE                  |        |     1 |    42 | 65740   (1)| 00

:05:43 |
|   2 |   NESTED LOOPS ANTI           |        |     1 |    42 | 65739   (1)| 00

:05:43 |
|*  3 |    INDEX RANGE SCAN           | VBFA~0 |     1 |    35 |     4   (0)| 00

:00:01 |
|*  4 |    TABLE ACCESS BY INDEX ROWID| VBRK   |   169K|  1156K| 65735   (1)| 00

:05:43 |

|*  5 |     INDEX RANGE SCAN          | VBRK~0 |   170K|       |  1119   (1)| 00

:00:06 |
--------------------------------------------------------------------------------

--------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("T_00"."MANDT"=:A0 AND "T_00"."VBELV"=:A1 AND
              "T_00"."VBTYP_N"=:A2)
       filter("T_00"."VBTYP_N"=:A2 AND ("T_00"."POSNV"=:A3 OR
              "T_00"."POSNV"=:A4 OR "T_00"."POSNV"=:A5))
   4 - filter("T_100"."SFAKN"<>:A7 AND "T_00"."VBELN"="T_100"."SFAKN")

   5 - access("T_100"."MANDT"=:A6)

2- Original With Adjusted Cost
------------------------------
Plan hash value: 1972805714

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

--------
| Id  | Operation                     | Name   | Rows  | Bytes | Cost (%CPU)| Ti

me     |
--------------------------------------------------------------------------------

--------
|   0 | SELECT STATEMENT              |        |     1 |    42 | 65740   (1)| 00


:05:43 |
|   1 |  HASH UNIQUE                  |        |     1 |    42 | 65740   (1)| 00

:05:43 |
|   2 |   NESTED LOOPS ANTI           |        |     1 |    42 | 65739   (1)| 00

:05:43 |
|*  3 |    INDEX RANGE SCAN           | VBFA~0 |     1 |    35 |     4   (0)| 00

:00:01 |
|*  4 |    TABLE ACCESS BY INDEX ROWID| VBRK   |   169K|  1156K| 65735   (1)| 00

:05:43 |
|*  5 |     INDEX RANGE SCAN          | VBRK~0 |   170K|       |  1119   (1)| 00

:00:06 |
--------------------------------------------------------------------------------

--------


Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("T_00"."MANDT"=:A0 AND "T_00"."VBELV"=:A1 AND
              "T_00"."VBTYP_N"=:A2)
       filter("T_00"."VBTYP_N"=:A2 AND ("T_00"."POSNV"=:A3 OR
              "T_00"."POSNV"=:A4 OR "T_00"."POSNV"=:A5))
   4 - filter("T_100"."SFAKN"<>:A7 AND "T_00"."VBELN"="T_100"."SFAKN")
   5 - access("T_100"."MANDT"=:A6)

3- Using SQL Profile
--------------------

Plan hash value: 4075274406

------------------------------------------------------------------------------
| Id  | Operation           | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |        |     1 |    42 |  1543   (2)| 00:00:09 |
|   1 |  HASH UNIQUE        |        |     1 |    42 |  1543   (2)| 00:00:09 |
|*  2 |   HASH JOIN ANTI    |        |     1 |    42 |  1542   (2)| 00:00:09 |
|*  3 |    INDEX RANGE SCAN | VBFA~0 |     1 |    35 |     4   (0)| 00:00:01 |
|*  4 |    TABLE ACCESS FULL| VBRK   |   169K|  1157K|  1536   (2)| 00:00:09 |
------------------------------------------------------------------------------

Predicate Information (identified by operation id):

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

   2 - access("T_00"."VBELN"="T_100"."SFAKN")
   3 - access("T_00"."MANDT"=:A0 AND "T_00"."VBELV"=:A1 AND
              "T_00"."VBTYP_N"=:A2)
       filter("T_00"."VBTYP_N"=:A2 AND ("T_00"."POSNV"=:A3 OR
              "T_00"."POSNV"=:A4 OR "T_00"."POSNV"=:A5))
   4 - filter("T_100"."SFAKN"<>:A7 AND "T_100"."MANDT"=:A6)

4- Using New Indices
--------------------
Plan hash value: 2387750198


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

----------------
| Id  | Operation                     | Name           | Rows  | Bytes | Cost (%

CPU)| Time     |
--------------------------------------------------------------------------------

----------------
|   0 | SELECT STATEMENT              |                |     1 |    42 |     7
(15)| 00:00:01 |
|   1 |  HASH UNIQUE                  |                |     1 |    42 |     7
(15)| 00:00:01 |
|   2 |   NESTED LOOPS ANTI           |                |     1 |    42 |     6
 (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN           | VBFA~0         |     1 |    35 |     4

 (0)| 00:00:01 |
|*  4 |    TABLE ACCESS BY INDEX ROWID| VBRK           |   169K|  1156K|     2
 (0)| 00:00:01 |
|*  5 |     INDEX RANGE SCAN          | IDX$$_6E550001 |     1 |       |     1
 (0)| 00:00:01 |
--------------------------------------------------------------------------------

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

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("T_00"."MANDT"=:A0 AND "T_00"."VBELV"=:A1 AND "T_00"."VBTYP_N"=:A2

)

       filter("T_00"."VBTYP_N"=:A2 AND ("T_00"."POSNV"=:A3 OR "T_00"."POSNV"=:A4

 OR
              "T_00"."POSNV"=:A5))
   4 - filter("T_100"."MANDT"=:A6)
   5 - access("T_00"."VBELN"="T_100"."SFAKN")
       filter("T_100"."SFAKN"<>:A7)

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

i send you relevant after traceout.

Regards,

Former Member
0 Kudos

Hello majamil,

please check the formatting via looking at the Preview first before posting. Essential information from the execution plans is lost with the current formatting (or lack thereof)!

If you accept the proposed SQL Profile then the execution time of the critical SQL statement should decline from 343 seconds to 9 seconds. So I suggest to give it a try:

execute dbms_sqltune.accept_sql_profile(task_name => 'TASK_28245', replace => TRUE);

Then check your SD transaction whether this fixed the issue at hand or whether your SD users have yet another performance problem.

Regards,

Mark

Former Member
0 Kudos

To also add some information in addition to Mark's suggestions. Is the SQL statement that is have the problem this one?

SELECT DISTINCT T_00 . "VBELN" FROM "VBFA" T_00

WHERE

T_00 . "MANDT" = :A0

AND T_00 . "VBELV" = :A1

AND T_00 . "VBTYP_N" = :A2

AND T_00 . "POSNV" IN ( :A3 , :A4 , :A5 )

AND T_00 . "VBELN" NOT IN

( SELECT T_100 . "SFAKN" FROM "VBRK" T_100 WHERE T_100 . "MANDT" = :A6 AND T_100 . "SFAKN"= :A7 )

A couple of things:

1) If you have an SAP transaction running long, you can use SAP transaction ST12 to trace the transactions which will give you an SE30 (runtime analysis) and an ST05 (SQL Trace) see SAP 755977. Especially if you have a reproducible troubled transaction in SAP.

Use SM51 to logon to the app server the user is logged onto, go to ST12 -> Enter a description in the "Comment" field of the trace -> Put in the USERNAME of the user having the problem in "Username", hit START TRACE. After the transaction is completed hit "END Trace". Then down at EVALUATE (at the bottom) the ABAP button will down the runtime analysis and will quickly identify if the problem is in the ABAP or DB. If it is ABAP then the function or program with the most time should jump out at you. If it is in the DB, then we click on on the PERFORMANCE TRACES to see ALL the SQL statements. If there are thousands of SQL statements, then just click on TOP LEFT MENU option "Trace List" and then go to "Summarize Trace by SQL Summary". This will summarize the SQL statements and show which SQL statement is taking the MOST time. Play around with ST12 and you will get better at the tracing.

Also if you have authorizations to run the transaction, then in ST12 you can click on "Current Mode", enter the transaction/program, then click "Execute/Start Trace". Once the transaction is completed then "Green Arrow" back to the St12 screen. Wait for SAP to gather the analysis and then click on the "ABAP Trace" or "Performance Traces" at the bottom as before.

2) Now if the ABAP trace shows you have long runtimes in the ABAP programs/functions then you show this to the developers and they can debug why. If you see long runtimes in the DB and especially on certain SQL statements, then you need to look into SQL tuning. This could mean

a) Oracle needs to pick a better execution plan

b) We need a better SQL statement (if this is custom code)

c) We may need a better index for this query.

Now with all this said (very long I know), "if" your problem SQL statement is the one above, what I "think" I saw was the query is doing a FULL TABLESCAN on VBRK, which is why Mark needs to see the formating (TABLE ACCESS FULL| VBRK). If this is true and VBRK has a large number of records, then it takes Oracle a while to read all the records in VBRK. Again, this is "if" I see the correct SQL statement. Another option would be to find the SQL statement and do an explain in SAP either from the ST12 or ST05 screen.

Sorry it's so long but tuning is rarely a short answer

Good luck,

Mike Kennedy

former_member182034
Active Contributor
0 Kudos

hi Mark,

Last question which i want to ask about below SQL Statement.

I execute SQL Tune Advisor and result is:

15 Most expensive SQL in the cursor cache
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

7k7yb9pvdcd6q     551.01 SELECT SUM( "KWMENG" ) FROM "VBAP" WHERE "MANDT" = :A0

15 Most expensive SQL in the workload repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7k7yb9pvdcd6q  19,438.24
SELECT SUM( "KWMENG" ) FROM "VBAP" WHERE "MANDT" = :A0

 Recommendation (estimated benefit: 99.67%)
 ------------------------------------------
 - Consider running the Access Advisor to improve the physical schema design
   or creating the recommended index.
  create index SAPSR3.IDX$$_6FB70001 on SAPSR3.VBAP("VGBEL","MANDT");

now i have to create above index (VGBEL) against VBAP table mean i just execute

SQL> create index SAPSR3.IDX$$_6FB70001 on SAPSR3.VBAP("VGBEL","MANDT");

or i have to use SE11 to create this index.

Regards,.

Former Member
0 Kudos

Hello majamil,

you have to use transaction SE11 to create additional indexes for SAP systems. The Oracle SQL Tuning Advisor doesn't know of SAP, so it simply suggests to create an index on certain columns. Only create additional indexes if you have an urgent need, i.e. if this slow SQL statement is really causing your business significant problems. Remember that all INSERT/UPDATE/DELETE statements on table VBAP will be slowed down due to the additional index.

Regards,

Mark

Answers (0)