on 06-28-2011 10:25 AM
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,
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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,
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,
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
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
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
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,
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
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,
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
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
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,.
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
User | Count |
---|---|
90 | |
10 | |
10 | |
10 | |
7 | |
7 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.