Performance tuning about select

hi experts:
   in one case : select ** ** ** into table tab
                            from **
                             for all entries in t_tab
                             where ** = t_tab-**
                                 and *** in ('1','2').
   second case: select ** ** ** into table tab
                            from **
                             for all entries in t_tab
                             where ** = t_tab-**
                                 and ' *** = '1' or ***= '2' '.
thirs case : select ** ** ** into table tab
                            from **
                             for all entries in t_tab
                             where ** = t_tab-**
                                 and *** between '1' and '2'.
last case : select ** ** ** into table tab
                            from **
                             for all entries in t_tab
                             where ** = t_tab-**.
              delete tab where *** > 2.
which case is the best??
Message was edited by:
        chen xinrong

Hi,
Based on your requirement you can mention the where condition.
If u want the records which have that filed values both 1 and 2 then u should give
= 1 and
= 2.
If u want either 1 or 2 then
= 1 or
= 2.
If u don't want both 1 and 2 value records then
Delette t_tab where ******* = 1 and
= 2.
your using the forall entries os you should chekc the table t_tab have the data or not. Otherwise performance will go down.Better to not use 'NO' operator in select statement.
Hope this helps you, reply for queries, Shall post you the updates.
Regards.
Kumar. .

Similar Messages

Performance tuning of select with inner join

Hi experts,
I need to improve the performanve in these two big selects, could you give me some tips, please?Thanks!
SELECT AWBELN BPOSNR ARFBSK AWFDAT ALIFRE AKNUMV
         BZZ_TKNUM BKOWRR BZZ_VSART BZZ_DTABF
         CTKNUM CVSART C~TDLNR
         CDTABF CSHTYP C~SDABW
         DTPNUM DVBELN
         EERDAT EVSTEL EKUNNR EANZPK EBTGEW EGEWEI
         E~LFDAT
     INTO CORRESPONDING FIELDS OF TABLE GT_AGENCY
        FROM WBRK AS A
          INNER JOIN WBRP AS B
             ON AWBELN = BWBELN AND
                B~KOWRR EQ ''
          INNER JOIN VTTK AS C
             ON BZZ_TKNUM = CTKNUM
          INNER JOIN VTTP AS D
             ON CTKNUM = DTKNUM
          INNER JOIN LIKP AS E
             ON DVBELN = EVBELN
          WHERE A~WBELN IN SO_WBELN AND
                A~RFBSK IN SO_RFBSK AND
                A~WFDAT IN SO_WFDAT AND
                A~LIFRE IN SO_TDLNR AND
                B~ZZ_VSART IN SO_VSART AND
                B~ZZ_DTABF IN SO_DTABF AND
                C~VSART IN SO_VSART AND
                D~TKNUM IN SO_REBEL AND
                D~VBELN IN SO_VBELN AND
                E~ERDAT IN SO_ERDAT AND
                E~VSTEL IN SO_VSTEL AND
                E~KUNNR IN SO_KUNNR.
SORT GT_AGENCY BY TDLNR VSTEL TKNUM TPNUM VBELN.
DELETE ADJACENT DUPLICATES FROM GT_AGENCY
COMPARING TDLNR VSTEL TKNUM TPNUM VBELN.
IF NOT GT_AGENCY[] IS INITIAL.
    SELECT VFKPTDLNR VFKPFKNUM VFKPFKPOS VFKPKNUMV          VFSIKPOSN VFKPREBEL VFSIVBELN vfsivbtyp
      INTO corresponding fields of TABLE GT_SHIPCOST
      FROM VFKP
      JOIN VFSI ON VFSIKNUMV = VFKPKNUMV
      WHERE VFKP~TDLNR IN SO_TDLNR
         AND VFKP~FKNUM IN SO_FKNUM
         AND VFKP~FKPOS IN SO_FKPOS
         AND VFKP~STBER IN SO_STBER
       AND VFKP~FKPTY IN SO_FKPTY
       AND ( VFSI~VBTYP = 'J'(S01) OR
             VFSI~VBTYP = 'T'(S03) or
             vfsi~vbtyp = 'a' ).
ENDIF.
Thanks a lot!
Patricia

Hi
1) Dont use nested seelct statement
2) If possible use for all entries in addition
3) In the where addition make sure you give all the primary key
4) Use Index for the selection criteria.
5) You can also use inner joins
6) You can try to put the data from the first select statement into an Itab and then in order to select the data from the second table use for all entries in.
7) Use the runtime analysis SE30 and SQL Trace (ST05) to identify the performance and also to identify where the load is heavy, so that you can change the code accordingly
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/5d0db4c9-0e01-0010-b68f-9b1408d5f234
1. Use Inner Joins
2. INTO TABLE
3. No nested loop
4. FOR ALL ENTRIES
5. Use as much of the key as possible
5. try to use primary or secondary keys in where condition. When using key fields, start with first key field.
6. Select only the fields you need for display/processing - avoid select *
Reward if useful
regards
Anji

Performance tuning SELECTs: Can I force a TRUE db read every time?

Good day everyone!
I've been programming in ABAP for almost 6 years now, and I'd like to begin learning more about performance tuning with respect to database performance.
More specifically, I'm testing some things in a particular SELECT in a report program we have that is timing out in the foreground because of the SELECT. When I first run the program, the SELECT goes against the database, as we all know. Subsequent runs, however, use the buffered data, so the response is a lot quicker and doesn't really reflect that first, initial database read.
Am I correct in assuming that I should be testing my various approaches and collecting performance runtimes against that initial, "true" database read? If that's the case, is there any way I can force the system to actually read the database instead of the buffered data? For those experienced with this kind of performance analysis and tuning, what's the best approach for someone very new to this area such as myself?
Thank you,
Dave

Hi Dave and Rob,
Just my two cents (and yes, I know this is already answered, but..).
I think you might be confusing 2 things: one is SAP buffering, and another one is caching at other levels (database, operating system, etc).
From what I understood Rob was talking mainly about SAP buffering. In that context it is true that if there is a first execution that loads the buffers (for example, some not so small fully buffered tables) then that is an atypical execution, and should be discarded. In real life you will never have execution times like those, except maybe on the very first execution on a monday morning.
Another thing is database caching. If you execute a report twice with exactly the same parameters then you might not be actually making physical reads in the second execution. This second execution will be very fast, but that will not be simulating real life: no user wants a report to be fast the second time you execute it with exactly the same parameters.
To avoid this in Oracle you can empty the so-called SGA, but that is not so useful and it will probably not get you closer to what happens in the real life.
So what to do? In doubt, measure it several times, with different parameters, and probably exclude the extreme values.
Regards,
Rui Dantas

VAL_FIELD selection to determine RSDRI or MDX query: performance tuning

according to on of the HTG I am working on performance tuning. one of the tip is to try to query base members by using BAS(xxx) in the expension pane of BPC report.
I did so and found an interesting issue in one of the COPA report.
with income statement, when I choose one node gross_profit, saying BAS(GROSS_PROFIT), it generates RSDRI query as I can see in UJSTAT. when I choose its parent, BAS(DIRECT_INCOME), it generates MDX query!
I checked DIRECT_INCOME has three members, GROSS_PROFIT, SGA, REV_OTHER. , none of them has any formulars.
in stead of calling BAS(DIRECT_INCOME), I called BAS(GROSS_PROFIT),BAS(SGA),BAS(REV_OTHER), I got RSDRI query again.
so in smmary,
BAS(PARENT) =>MDX query.
BAS(CHILD1)=>RSDRI query.
BAS(CHILD2)=>RSDRI query.
BAS(CHILD3)=>RSDRI query.
BAS(CHILD1),BAS(CHILD2),BAS(CHILD3)=>RSDRI query
I know VAL_FIELD is SAP reserved name for BPC dimensions. my question is why BAS(PARENT) =>MDX query.?
interestingly I can repeat this behavior in my system. my intention is to always get RSDRI query,
George

Ok - it turns out that Crystal Reports disregards BEx Query variables when put in the Default Values section of the filter selection.
I had mine there and even though CR prompted me for the variables AND the SQL statement it generated had an INCLUDE statement with hose variables I could see by my result set that it still returned everything in the cube as if there was no restriction on Plant for instance.
I should have paid more attention to the Info message I got in the BEx Query Designed. It specifically states that the "Variable located in Default Values will be ignored in the MDX Access".
After moving the variables to the Characteristic Restrictions my report worked as expected. The slow response time is still an issue but at least it's not compounded by trying to retrieve all records in the cube while I'm expecting less than 2k.
Hope this helps someone else

Query About performance tuning

Hi Guru's
May be this question is stupid one, but i think this is the forum where every user get details of all there questions.
I want to start learning Performance tuning but not know the path from where to start can anyone suggest me the same.
Thanks in advance

Hi,
performance tuning is a huge area. It involves following skills:
1. Understanding how Oracle stores data (physical structure of tables and indexes) and how it reads and writes it.
2. Understanding how Oracle processes and executes queries
3. Ability to read execution plans (not just scan them for 'red flags')
4. Familiarity is most common wait events, knowing and understanding Oracle Wait Interface and its limitations
5. Ability to understand AWR and ASH data and its limitations
6. Understanding Oracle optimizer and it's inputs, knowing basic formulas for cardinality and selectivity, cardinality feedback tuning
7. Abilty to read trace files (first of all extended SQL trace, 10046, and CBO trace, 10053)
8. Understanding concurrency and read consistency and work Oracle does to maintain them.
This is probably not a complete list. Of course you won't be able to learn everything at once. You can start by reading:
1. The official Oracle Performance Tuning Guide
2. T. Kyte's books on Oracle architecture
3. Milsap's and Holt's book "Optimizing Oracle Performance"
4. J. Lewis "Cost based fundamentals"
Best regards,
Nikolay

Looking for book about performance tuning 11g database

Hi,
I am looking for books about performance tuning oracle 11g. The documents from OTN 2 days 11g performance tuning and performance tuning guide are not really study material.
Has someone idea?
greeting,
Max

Hi,
http://astore.amazon.com/oraclebooks-20/detail/1590599683 {Part IV Database Tuning }
Greetings,
Sim

Performance tuning help

hello friends,
i am supposed to use ST05 and SE30 to do performance tuning,and also perform cost estimation,
can some plz help me understand, i am not that good at reading large paragraphs, so plz donot give me links to help.sap
thank you.

Hi
Se30 is the runtime analysis
Here it will give you detailed graph about your program .
abap time,database time application time ..
st05 is sql trace where it will give you individual select stmnts in your program
and also proper index is being used or not.
Other performance tips
check any select stmnts inside the loop and replace with read statement
use binary search in read stmnts
use proper index in where condition in select stmnt.
if you want to execute st05..go st05..trace on-execute ur program--come to st05..trace off and --list trace...
you get summary details of select queires and it will be pink or other color.
Thanks

Performance Tuning Question

Greetings,
I did a few searches for any topics related to this and
haven't found anything relevant - if I'm missing something obvious
I apologize.
We are doing some performance tuning of a CFMX 7.0.2 system
running on Solaris. Of the many things we're doing one is to run
truss on the cfmx processes to find out what in fact it's doing.
The following is an excerpt from one of the truss outputs:
stat64("/opt/coldfusionmx7/runtime/../lib/macromedia/jdbc/sqlserver/SQLServerURLParser.cla ss\0",
0x254FB860, 0x254FB9BC) = -1 Err#2
stat64("/opt/coldfusionmx7/runtime/../gateway/lib/macromedia/jdbc/oracle/OracleURLParser.c lass\0",
0x254FB860, 0x254FB9BC) = -1 Err#2
Err #2 means "File not found" in essence
These lines show up quite a bit in the output - and we're
curious as to why it's trying to find those particular classes at
all and why in those locations - there are other entries where it
looks like it's going through a series of paths that it knows about
trying to find these entries. As we use Oracle as our database what
could be the reason it's looking for SQLServer? Finally does anyone
know of a way to stop the attempt to find these classes and save
the system processing time to give us back those cycles for real
work?
Regards,
Scott

Please try:
Create View View3
As
SELECT a.Col1, a.Col2
From dbo.TableA A
WHERE NOT Exists (SELECT 1 From dbo.TableB B With(NoLock) WHERE A.Col1 = B.Col1)
UNION
SELECT Col1, Col2 From dbo.TableB
Also, please make sure that INDEXes on Col1 on both tables are NOT fragmented and your STATISTICS are also up tp date.
Best Wishes, Arbi; Please vote if you find this posting was helpful or Mark it as answered.

Performance Tuning Tips

Dear All,
In our project we are facing lot of problems with the Performance, users are compaining about the poor performance of the few reports and all, we are in the process of fine tuning the reports by following the all methods/suggestions provided by SAP ( like removing the select queries from Loops, For all entries , Binary serach etc )
But still I want to know from you people what can we check from BASIS percpective ( all the settings ) and also ABAP percpective to improve the performance.
And also I have one more query that what is " Table Statistics " , what is the use of this ...
Please give ur valueble suggestions to us in improving the performance .
Thanks in Advance !

Hi
Ways of Performance Tuning
1. Selection Criteria
2. Select Statements
 Select Queries
 SQL Interface
 Aggregate Functions
 For all Entries
Select Over more than one Internal table
Selection Criteria
1. Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement.
2. Select with selection list.
Points # 1/2
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
 SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
 SBOOK_WA-CONNID = '0400'.
Select Statements Select Queries
1. Avoid nested selects
2. Select all the records in a single shot using into table clause of select statement rather than to use Append statements.
3. When a base table has multiple indices, the where clause should be in the order of the index, either a primary or a secondary index.
4. For testing existence , use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit.
5. Use Select Single if all primary key fields are supplied in the Where condition .
Point # 1
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
 WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
 FROM EKKO AS P INNER JOIN EKAN AS F
 ON PEBELN = FEBELN.
Note: A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. One should therefore use nested SELECT loops only if the selection in the outer loop contains very few lines or the outer loop is a SELECT SINGLE statement.
Point # 2
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
 SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list and puts the data in one shot using into table
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
 SBOOK_WA-CONNID = '0400'.
Point # 3
To choose an index, the optimizer checks the field names specified in the where clause and then uses an index that has the same order of the fields . In certain scenarios, it is advisable to check whether a new index can speed up the performance of a program. This will come handy in programs that access data from the finance tables.
Point # 4
SELECT * FROM SBOOK INTO SBOOK_WA
UP TO 1 ROWS
WHERE CARRID = 'LH'.
ENDSELECT.
The above code is more optimized as compared to the code mentioned below for testing existence of a record.
SELECT * FROM SBOOK INTO SBOOK_WA
 WHERE CARRID = 'LH'.
EXIT.
ENDSELECT.
Point # 5
If all primary key fields are supplied in the Where condition you can even use Select Single.
Select Single requires one communication with the database system, whereas Select-Endselect needs two.
Select Statements contd.. SQL Interface
1. Use column updates instead of single-row updates
to update your database tables.
2. For all frequently used Select statements, try to use an index.
3. Using buffered tables improves the performance considerably.
Point # 1
SELECT * FROM SFLIGHT INTO SFLIGHT_WA.
SFLIGHT_WA-SEATSOCC =
 SFLIGHT_WA-SEATSOCC - 1.
UPDATE SFLIGHT FROM SFLIGHT_WA.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
UPDATE SFLIGHT
 SET SEATSOCC = SEATSOCC - 1.
Point # 2
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE CARRID = 'LH'
 AND CONNID = '0400'.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE MANDT IN ( SELECT MANDT FROM T000 )
 AND CARRID = 'LH'
 AND CONNID = '0400'.
ENDSELECT.
Point # 3
Bypassing the buffer increases the network considerably
SELECT SINGLE * FROM T100 INTO T100_WA
BYPASSING BUFFER
WHERE SPRSL = 'D'
 AND ARBGB = '00'
 AND MSGNR = '999'.
The above mentioned code can be more optimized by using the following code
SELECT SINGLE * FROM T100 INTO T100_WA
WHERE SPRSL = 'D'
 AND ARBGB = '00'
 AND MSGNR = '999'.
Select Statements contd Aggregate Functions
 If you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself.
Some of the Aggregate functions allowed in SAP are MAX, MIN, AVG, SUM, COUNT, COUNT( * )
Consider the following extract.
 Maxno = 0.
 Select * from zflight where airln = LF and cntry = IN.
 Check zflight-fligh > maxno.
 Maxno = zflight-fligh.
 Endselect.
The above mentioned code can be much more optimized by using the following code.
Select max( fligh ) from zflight into maxno where airln = LF and cntry = IN.
Select Statements contdFor All Entries
 The for all entries creates a where clause, where all the entries in the driver table are combined with OR. If the number of entries in the driver table is larger than rsdb/max_blocking_factor, several similar SQL statements are executed to limit the length of the WHERE clause.
 The plus
 Large amount of data
 Mixing processing and reading of data
 Fast internal reprocessing of data
 Fast
 The Minus
 Difficult to program/understand
 Memory could be critical (use FREE or PACKAGE size)
Points to be must considered FOR ALL ENTRIES Check that data is present in the driver table
 Sorting the driver table
 Removing duplicates from the driver table
Consider the following piece of extract
Loop at int_cntry.
 Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
Endloop.
The above mentioned can be more optimized by using the following code.
Sort int_cntry by cntry.
Delete adjacent duplicates from int_cntry.
If NOT int_cntry[] is INITIAL.
 Select * from zfligh appending table int_fligh
 For all entries in int_cntry
 Where cntry = int_cntry-cntry.
Endif.
Select Statements contd Select Over more than one Internal table
1. Its better to use a views instead of nested Select statements.
2. To read data from several logically connected tables use a join instead of nested Select statements. Joins are preferred only if all the primary key are available in WHERE clause for the tables that are joined. If the primary keys are not provided in join the Joining of tables itself takes time.
3. Instead of using nested Select loops it is often better to use subqueries.
Point # 1
SELECT * FROM DD01L INTO DD01L_WA
WHERE DOMNAME LIKE 'CHAR%'
 AND AS4LOCAL = 'A'.
SELECT SINGLE * FROM DD01T INTO DD01T_WA
 WHERE DOMNAME = DD01L_WA-DOMNAME
 AND AS4LOCAL = 'A'
 AND AS4VERS = DD01L_WA-AS4VERS
 AND DDLANGUAGE = SY-LANGU.
ENDSELECT.
The above code can be more optimized by extracting all the data from view DD01V_WA
SELECT * FROM DD01V INTO DD01V_WA
WHERE DOMNAME LIKE 'CHAR%'
 AND DDLANGUAGE = SY-LANGU.
ENDSELECT
Point # 2
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
 WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
 FROM EKKO AS P INNER JOIN EKAN AS F
 ON PEBELN = FEBELN.
Point # 3
SELECT * FROM SPFLI
INTO TABLE T_SPFLI
WHERE CITYFROM = 'FRANKFURT'
 AND CITYTO = 'NEW YORK'.
SELECT * FROM SFLIGHT AS F
 INTO SFLIGHT_WA
 FOR ALL ENTRIES IN T_SPFLI
 WHERE SEATSOCC < F~SEATSMAX
 AND CARRID = T_SPFLI-CARRID
 AND CONNID = T_SPFLI-CONNID
 AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
The above mentioned code can be even more optimized by using subqueries instead of for all entries.
SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA
 WHERE SEATSOCC < F~SEATSMAX
 AND EXISTS ( SELECT * FROM SPFLI
 WHERE CARRID = F~CARRID
 AND CONNID = F~CONNID
 AND CITYFROM = 'FRANKFURT'
 AND CITYTO = 'NEW YORK' )
 AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
Internal Tables
1. Table operations should be done using explicit work areas rather than via header lines.
2. Always try to use binary search instead of linear search. But dont forget to sort your internal table before that.
3. A dynamic key access is slower than a static one, since the key specification must be evaluated at runtime.
4. A binary search using secondary index takes considerably less time.
5. LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified condition internally.
6. Modifying selected components using MODIFY itab TRANSPORTING f1 f2.. accelerates the task of updating a line of an internal table.
Point # 2
READ TABLE ITAB INTO WA WITH KEY K = 'X BINARY SEARCH.
IS MUCH FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY K = 'X'.
If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ).
Point # 3
READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.
Point # 5
LOOP AT ITAB INTO WA WHERE K = 'X'.
ENDLOOP.
The above code is much faster than using
LOOP AT ITAB INTO WA.
CHECK WA-K = 'X'.
ENDLOOP.
Point # 6
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1 TRANSPORTING DATE.
The above code is more optimized as compared to
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1.
7. Accessing the table entries directly in a "LOOP ... ASSIGNING ..." accelerates the task of updating a set of lines of an internal table considerably
8. If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.
9. "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to LOOP-APPEND-ENDLOOP.
10. DELETE ADJACENT DUPLICATES accelerates the task of deleting duplicate entries considerably as compared to READ-LOOP-DELETE-ENDLOOP.
11. "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to DO -DELETE-ENDDO.
Point # 7
Modifying selected components only makes the program faster as compared to Modifying all lines completely.
e.g,
LOOP AT ITAB ASSIGNING <WA>.
I = SY-TABIX MOD 2.
IF I = 0.
 <WA>-FLAG = 'X'.
ENDIF.
ENDLOOP.
The above code works faster as compared to
LOOP AT ITAB INTO WA.
I = SY-TABIX MOD 2.
IF I = 0.
 WA-FLAG = 'X'.
 MODIFY ITAB FROM WA.
ENDIF.
ENDLOOP.
Point # 8
LOOP AT ITAB1 INTO WA1.
READ TABLE ITAB2 INTO WA2 WITH KEY K = WA1-K BINARY SEARCH.
IF SY-SUBRC = 0.
 ADD: WA1-VAL1 TO WA2-VAL1,
 WA1-VAL2 TO WA2-VAL2.
 MODIFY ITAB2 FROM WA2 INDEX SY-TABIX TRANSPORTING VAL1 VAL2.
ELSE.
 INSERT WA1 INTO ITAB2 INDEX SY-TABIX.
ENDIF.
ENDLOOP.
The above code uses BINARY SEARCH for collect semantics. READ BINARY runs in O( log2(n) ) time. The above piece of code can be more optimized by
LOOP AT ITAB1 INTO WA.
COLLECT WA INTO ITAB2.
ENDLOOP.
SORT ITAB2 BY K.
COLLECT, however, uses a hash algorithm and is therefore independent
of the number of entries (i.e. O(1)) .
Point # 9
APPEND LINES OF ITAB1 TO ITAB2.
This is more optimized as compared to
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
Point # 10
DELETE ADJACENT DUPLICATES FROM ITAB COMPARING K.
This is much more optimized as compared to
READ TABLE ITAB INDEX 1 INTO PREV_LINE.
LOOP AT ITAB FROM 2 INTO WA.
IF WA = PREV_LINE.
 DELETE ITAB.
ELSE.
 PREV_LINE = WA.
ENDIF.
ENDLOOP.
Point # 11
DELETE ITAB FROM 450 TO 550.
This is much more optimized as compared to
DO 101 TIMES.
DELETE ITAB INDEX 450.
ENDDO.
12. Copying internal tables by using ITAB2[ ] = ITAB1[ ] as compared to LOOP-APPEND-ENDLOOP.
13. Specify the sort key as restrictively as possible to run the program faster.
Point # 12
ITAB2[] = ITAB1[].
This is much more optimized as compared to
REFRESH ITAB2.
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
Point # 13SORT ITAB BY K. makes the program runs faster as compared to SORT ITAB.
Internal Tables contd
Hashed and Sorted tables
1. For single read access hashed tables are more optimized as compared to sorted tables.
2. For partial sequential access sorted tables are more optimized as compared to hashed tables
Hashed And Sorted Tables
Point # 1
Consider the following example where HTAB is a hashed table and STAB is a sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE HTAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
This runs faster for single read access as compared to the following same code for sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE STAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
Point # 2
Similarly for Partial Sequential access the STAB runs faster as compared to HTAB
LOOP AT STAB INTO WA WHERE K = SUBKEY.
ENDLOOP.
This runs faster as compared to
LOOP AT HTAB INTO WA WHERE K = SUBKEY.
ENDLOOP.
Reward if usefull

Planning to start the performance tuning but....

Friends,
Database OS: RHEL AS 3.0
Database: Oracle Release 9.2.0.4.0
Number of Tables: 503
TableSpace size - 1.8GB out of 3GB
Max.Records in a Table - 1 Million and its increasing..
Our DB Optimizer mode is - CHOOSE (is it RBO?)
We are not using enterprise manager and not installed any tuning scripts like statspack etc....
Currently we are taking user managed backup without any problem so we are continuing the same from 2004 onwards.
Now we want want to tune our database.(We have never tuned our database)
We would like to change our optimizer from RBO to CBO.
Can anybody tell me the first step for the performance tuning?
Please dont suggest me oracle doc im already studying.....its taking time....
In the mean time......
Step 1: Can i Analyze the table or dbms_stat package?
We have not at all used the analyze or dbms_stat. So can i start with any of the above or do u have any other suggestions for the 1st step?
Thanks

our manager feels that if we tune our db the performance will be more than compared to the current one.you have a mystique manager then, ask him what kind of "feelings" does he have about my database ;) there is no place for feelings in this game, this is life cycle to be successful ; testing->reporting->analyzing->take nedded actions->re-testing->reporting->analyzing..
so while you are surely reading the documentation;
Oracle9i Database Performance Planning Release 2 (9.2)
http://download.oracle.com/docs/cd/B10501_01/server.920/a96532/toc.htm
Oracle9i Database Performance Tuning Guide and Reference Release 2 (9.2)
http://download.oracle.com/docs/cd/B10501_01/server.920/a96533/toc.htm
first thing you have to do is to setup an appropriate test environment with same os-oracle releases, parameters;
-- some of them to check
SELECT NAME, VALUE
FROM v$system_parameter a
WHERE a.NAME IN
       ('compatible', 'optimizer_features_enable',
        'optimizer_mode', 'pga_aggregate_target', 'workarea_size_policy',
        'db_file_multiblock_read_count', .. )and of course schema set and data amount. Then you run your application on load and take statspack snapshots and do the same after collecting statistics;
-- customize for your configuration, schema level object statistics
exec dbms_stats.gather_schema_stats( ownname =>'YOUR_SCHEMA', degree=>16, options=>'GATHER AUTO', estimate_percent=>dbms_stats.auto_sample_size, cascade=>TRUE, method_opt=>'FOR ALL COLUMNS SIZE AUTO', granularity=>'ALL');
-- check your system stats, with sys account
SELECT pname, pval1 FROM sys.aux_stats$ WHERE sname = 'SYSSTATS_MAIN';after you have the base report and the report after change compare the top 5 waits, the top queries which have dramatic logical I/O changes etc. At this point you go into session based tuning in order to understand why a specific query performs worser with CBO compared to RBO. You need to be able to create and read execution plans and i/o statistics at least. Here are some quick introductions;
http://www.bhatipoglu.com/entry/17/oracle-performance-analysis-tracing-and-performance-evaluation
http://psoug.org/reference/explain_plan.html
http://coskan.wordpress.com/2007/03/04/viewing-explain-plan/
and last words again goes to your manager; how does he "feel" about a 10gR2 migration? With Grid Control, AWR, ADDM and ASH performance tuning evolved a lot. Important note here, after 10g RBO is dead(unsupported).
Best Regards,
H.Tonguç YILMAZ
http://tonguc.yilmaz.googlepages.com/
Message was edited by:
TongucY

Performance Tuning - Suggestions

Hi,
I have an ABAP (Interactive List) Program times out in PRD very often. The ABAP run time is about 99%. The DB time is less than 1%. All the select statements has the table index in place. Actually it isprocessing all the Production Orders (Released but not Confirmed/Closed). Please let me know if you have any suggestion.
Appreciate Your Help.
Thanks,
Kannan.

Hi
1) Dont use nested select statements
2) If possible use for all entries in addition
3) In the where addition make sure you give all the primary key
4) Use Index for the selection criteria.
5) You can also use inner joins
6) You can try to put the data from the first select statement into an Itab and then in order to select the data from the second table use for all entries in.
7) Use the runtime analysis SE30 and SQL Trace (ST05) to identify the performance and also to identify where the load is heavy, so that you can change the code accordingly
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/5d0db4c9-0e01-0010-b68f-9b1408d5f234
ABAP performance depends upon various factors and in devicded in three parts:
1. Database
2. ABAP
3. System
Run Any program using SE30 (performance analys) to improve performance refer to tips and trics section of SE30, Always remember that ABAP perfirmance is improved when there is least load on Database.
u can get an interactive grap in SE30 regarding this with a file.
also if u find runtime of parts of codes then use :
Switch on RTA Dynamically within ABAP Code
*To turn runtim analysis on within ABAP code insert the following code
SET RUN TIME ANALYZER ON.
*To turn runtim analysis off within ABAP code insert the following code
SET RUN TIME ANALYZER OFF.
Always check the driver internal tables is not empty, while using FOR ALL ENTRIES
Avoid for all entries in JOINS
Try to avoid joins and use FOR ALL ENTRIES.
Try to restrict the joins to 1 level only ie only for tables
Avoid using Select *.
Avoid having multiple Selects from the same table in the same object.
Try to minimize the number of variables to save memory.
The sequence of fields in 'where clause' must be as per primary/secondary index ( if any)
Avoid creation of index as far as possible
Avoid operators like <>, > , < & like % in where clause conditions
Avoid select/select single statements in loops.
Try to use 'binary search' in READ internal table. Ensure table is sorted before using BINARY SEARCH.
Avoid using aggregate functions (SUM, MAX etc) in selects ( GROUP BY , HAVING,)
Avoid using ORDER BY in selects
Avoid Nested Selects
Avoid Nested Loops of Internal Tables
Try to use FIELD SYMBOLS.
Try to avoid into Corresponding Fields of
Avoid using Select Distinct, Use DELETE ADJACENT
Check the following Links
Re: performance tuning
Re: Performance tuning of program
http://www.sapgenie.com/abap/performance.htm
http://www.thespot4sap.com/Articles/SAPABAPPerformanceTuning_PerformanceAnalysisTools.asp
check the below link
http://www.sap-img.com/abap/performance-tuning-for-data-selection-statement.htm
See the following link if it's any help:
http://www.thespot4sap.com/Articles/SAPABAPPerformanceTuning_PerformanceAnalysisTools.asp
Check also http://service.sap.com/performance
and
books like
http://www.sap-press.com/product.cfm?account=&product=H951
http://www.sap-press.com/product.cfm?account=&product=H973
http://www.sap-img.com/abap/more-than-100-abap-interview-faqs.htm
http://www.thespot4sap.com/Articles/SAPABAPPerformanceTuning_PerformanceAnalysisTools.asp
Performance tuning for Data Selection Statement
http://www.sap-img.com/abap/performance-tuning-for-data-selection-statement.htm
Debugger
http://help.sap.com/saphelp_47x200/helpdata/en/c6/617ca9e68c11d2b2ab080009b43351/content.htm
http://www.cba.nau.edu/haney-j/CIS497/Assignments/Debugging.doc
http://help.sap.com/saphelp_erp2005/helpdata/en/b3/d322540c3beb4ba53795784eebb680/frameset.htm
Run Time Analyser
http://help.sap.com/saphelp_47x200/helpdata/en/c6/617cafe68c11d2b2ab080009b43351/content.htm
SQL trace
http://help.sap.com/saphelp_47x200/helpdata/en/d1/801f7c454211d189710000e8322d00/content.htm
CATT - Computer Aided Testing Too
http://help.sap.com/saphelp_47x200/helpdata/en/b3/410b37233f7c6fe10000009b38f936/frameset.htm
Test Workbench
http://help.sap.com/saphelp_47x200/helpdata/en/a8/157235d0fa8742e10000009b38f889/frameset.htm
Coverage Analyser
http://help.sap.com/saphelp_47x200/helpdata/en/c7/af9a79061a11d4b3d4080009b43351/content.htm
Runtime Monitor
http://help.sap.com/saphelp_47x200/helpdata/en/b5/fa121cc15911d5993d00508b6b8b11/content.htm
Memory Inspector
http://help.sap.com/saphelp_47x200/helpdata/en/a2/e5fc84cc87964cb2c29f584152d74e/content.htm
ECATT - Extended Computer Aided testing tool.
http://help.sap.com/saphelp_47x200/helpdata/en/20/e81c3b84e65e7be10000000a11402f/frameset.htm
Just refer to these links...
performance
Performance
Performance Guide
performance issues...
Performance Tuning
Performance issues
performance tuning
performance tuning
You can go to the transaction SE30 to have the runtime analysis of your program.Also try the transaction SCI , which is SAP Code Inspector.
1 Always check the driver internal tables is not empty, while using FOR ALL ENTRIES
2 Avoid for all entries in JOINS
3 Try to avoid joins and use FOR ALL ENTRIES.
4 Try to restrict the joins to 1 level only ie only for 2 tables
5 Avoid using Select *.
6 Avoid having multiple Selects from the same table in the same object.
7 Try to minimize the number of variables to save memory.
8 The sequence of fields in 'where clause' must be as per primary/secondary index ( if any)
9 Avoid creation of index as far as possible
10 Avoid operators like <>, > , < & like % in where clause conditions
11 Avoid select/select single statements in loops.
12 Try to use 'binary search' in READ internal table. Ensure table is sorted before using BINARY SEARCH.
13 Avoid using aggregate functions (SUM, MAX etc) in selects ( GROUP BY , HAVING,)
14 Avoid using ORDER BY in selects
15 Avoid Nested Selects
16 Avoid Nested Loops of Internal Tables
17 Try to use FIELD SYMBOLS.
18 Try to avoid into Corresponding Fields of
19 Avoid using Select Distinct, Use DELETE ADJACENT.
Regards
Anji

Can anyone send tutor for performance tuning?

can anyone send tutor for performance tuning?I like to chk my coding.

1. Unused/Dead code
Avoid leaving unused code in the program. Either comment out or delete the unused situation. Use program --> check --> extended program to check for the variables, which are not used statically.
2. Subroutine Usage
For good modularization, the decision of whether or not to execute a subroutine should be made before the subroutine is called. For example:
This is better:
IF f1 NE 0.
PERFORM sub1.
ENDIF.
FORM sub1.
ENDFORM.
Than this:
PERFORM sub1.
FORM sub1.
IF f1 NE 0.
ENDIF.
ENDFORM.
3. Usage of IF statements
When coding IF tests, nest the testing conditions so that the outer conditions are those which are most likely to fail. For logical expressions with AND , place the mostly likely false first and for the OR, place the mostly likely true first.
Example - nested IF's:
IF (least likely to be true).
 IF (less likely to be true).
 IF (most likely to be true).
 ENDIF.
 ENDIF.
 ENDIF.
Example - IF...ELSEIF...ENDIF :
IF (most likely to be true).
ELSEIF (less likely to be true).
ELSEIF (least likely to be true).
ENDIF.
Example - AND:
 IF (least likely to be true) AND
 (most likely to be true).
 ENDIF.
Example - OR:
 IF (most likely to be true) OR
 (least likely to be true).
4. CASE vs. nested Ifs
When testing fields "equal to" something, one can use either the nested IF or the CASE statement. The CASE is better for two reasons. It is easier to read and after about five nested IFs the performance of the CASE is more efficient.
5. MOVE statements
When records a and b have the exact same structure, it is more efficient to MOVE a TO b than to MOVE-CORRESPONDING a TO b.
MOVE BSEG TO *BSEG.
is better than
MOVE-CORRESPONDING BSEG TO *BSEG.
6. SELECT and SELECT SINGLE
When using the SELECT statement, study the key and always provide as much of the left-most part of the key as possible. If the entire key can be qualified, code a SELECT SINGLE not just a SELECT. If you are only interested in the first row or there is only one row to be returned, using SELECT SINGLE can increase performance by up to three times.
7. Small internal tables vs. complete internal tables
In general it is better to minimize the number of fields declared in an internal table. While it may be convenient to declare an internal table using the LIKE command, in most cases, programs will not use all fields in the SAP standard table.
For example:
Instead of this:
data: t_mara like mara occurs 0 with header line.
Use this:
data: begin of t_mara occurs 0,
 matnr like mara-matnr,
 end of t_mara.
8. Row-level processing and SELECT SINGLE
Similar to the processing of a SELECT-ENDSELECT loop, when calling multiple SELECT-SINGLE commands on a non-buffered table (check Data Dictionary -> Technical Info), you should do the following to improve performance:
o Use the SELECT into <itab> to buffer the necessary rows in an internal table, then
o sort the rows by the key fields, then
o use a READ TABLE WITH KEY ... BINARY SEARCH in place of the SELECT SINGLE command. Note that this only make sense when the table you are buffering is not too large (this decision must be made on a case by case basis).
9. READing single records of internal tables
When reading a single record in an internal table, the READ TABLE WITH KEY is not a direct READ. This means that if the data is not sorted according to the key, the system must sequentially read the table. Therefore, you should:
o SORT the table
o use READ TABLE WITH KEY BINARY SEARCH for better performance.
10. SORTing internal tables
When SORTing internal tables, specify the fields to SORTed.
SORT ITAB BY FLD1 FLD2.
is more efficient than
SORT ITAB.
11. Number of entries in an internal table
To find out how many entries are in an internal table use DESCRIBE.
DESCRIBE TABLE ITAB LINES CNTLNS.
is more efficient than
LOOP AT ITAB.
CNTLNS = CNTLNS + 1.
ENDLOOP.
12. Performance diagnosis
To diagnose performance problems, it is recommended to use the SAP transaction SE30, ABAP/4 Runtime Analysis. The utility allows statistical analysis of transactions and programs.
13. Nested SELECTs versus table views
Since releASE 4.0, OPEN SQL allows both inner and outer table joins. A nested SELECT loop may be used to accomplish the same concept. However, the performance of nested SELECT loops is very poor in comparison to a join. Hence, to improve performance by a factor of 25x and reduce network load, you should either create a view in the data dictionary then use this view to select data, or code the select using a join.
14. If nested SELECTs must be used
As mentioned previously, performance can be dramatically improved by using views instead of nested SELECTs, however, if this is not possible, then the following example of using an internal table in a nested SELECT can also improve performance by a factor of 5x:
Use this:
form select_good.
data: t_vbak like vbak occurs 0 with header line.
data: t_vbap like vbap occurs 0 with header line.
select * from vbak into table t_vbak up to 200 rows.
select * from vbap
 for all entries in t_vbak
 where vbeln = t_vbak-vbeln.
endselect.
endform.
Instead of this:
form select_bad.
select * from vbak up to 200 rows.
select * from vbap where vbeln = vbak-vbeln.
endselect.
endselect.
endform.
Although using "SELECT...FOR ALL ENTRIES IN..." is generally very fast, you should be aware of the three pitfalls of using it:
Firstly, SAP automatically removes any duplicates from the rest of the retrieved records. Therefore, if you wish to ensure that no qualifying records are discarded, the field list of the inner SELECT must be designed to ensure the retrieved records will contain no duplicates (normally, this would mean including in the list of retrieved fields all of those fields that comprise that table's primary key).
Secondly, if you were able to code "SELECT ... FROM <database table> FOR ALL ENTRIES IN TABLE <itab>" and the internal table <itab> is empty, then all rows from <database table> will be retrieved.
Thirdly, if the internal table supplying the selection criteria (i.e. internal table <itab> in the example "...FOR ALL ENTRIES IN TABLE <itab> ") contains a large number of entries, performance degradation may occur.
15. SELECT * versus SELECTing individual fields
In general, use a SELECT statement specifying a list of fields instead of a SELECT * to reduce network traffic and improve performance. For tables with only a few fields the improvements may be minor, but many SAP tables contain more than 50 fields when the program needs only a few. In the latter case, the performace gains can be substantial. For example:
Use:
select vbeln auart vbtyp from table vbak
into (vbak-vbeln, vbak-auart, vbak-vbtyp)
where ...
Instead of using:
select * from vbak where ...
16. Avoid unnecessary statements
There are a few cases where one command is better than two. For example:
Use:
append <tab_wa> to <tab>.
Instead of:
<tab> = <tab_wa>.
append <tab> (modify <tab>).
And also, use:
if not <tab>[] is initial.
Instead of:
describe table <tab> lines <line_counter>.
if <line_counter> > 0.
17. Copying or appending internal tables
Use this:
<tab2>[] = <tab1>[]. (if <tab2> is empty)
Instead of this:
loop at <tab1>.
append <tab1> to <tab2>.
endloop.
However, if <tab2> is not empty and should not be overwritten, then use:
append lines of <tab1> [from index1] [to index2] to <tab2>.
P.S : Please reward if you find this useful..

Performance tuning of this code.

Hello Friends,
Following is the piece of Code.. can some one please help me to optimise the code.
I want to do performance tuning on the same.
Any inputs on this would be valuable to me .
Thanking you all in anticipation.
<< Unformatted code removed >>
Edited by: Jitesh Pamnani on Apr 7, 2009 10:09 AM
Edited by: Jitesh Pamnani on Apr 7, 2009 10:09 AM
Edited by: Rob Burbank on Apr 7, 2009 11:05 AM

please read,
SQL trace:
/people/siegfried.boes/blog/2007/09/05/the-sql-trace-st05-150-quick-and-easy
for the first part, without SQL Trace it does not make much sense, to check your select statements.
I guess that one or several are slow. But there are too many.
Second part, use sorted tables or binary search!!!!!
Your coding is highly nonlinear, not only quadratic but even cubic!!!!
Read here for table types and runtimes
Measurements on internal tables: Reads and Loops:
/people/siegfried.boes/blog/2007/09/12/runtimes-of-reads-and-loops-on-internal-tables
Read here about nonlinearity:
Nonlinearity: The problem and background
/people/siegfried.boes/blog/2007/02/12/performance-problems-caused-by-nonlinear-coding
Read here for measuring:
SE30
/people/siegfried.boes/blog/2007/11/13/the-abap-runtime-trace-se30--quick-and-easy
Z_SE30_COMPARE
/people/siegfried.boes/blog/2008/01/15/a-tool-to-compare-runtime-measurements-zse30compare
Nonlinearity Check
/people/siegfried.boes/blog/2008/01/24/nonlinearity-check-using-the-zse30compare
If you do ot all I assume that your coding can becomes faster by factors 10 ... 100 or even more.
Siegfried

Regarding Indexes and performance tuning.

Hi Everyone,
I need some elaborate explanation about indexes and performance tuning.
1. How do you find out whether the select query which I write is utilizing the indexes .
2. Is it true that the sequence in which the indexes are defined in se11
for eg: MANDT
KNUMH
KOPOS
your select query should also have the same sequence in the where clause else the indexes are not utilized well .
3. Is there any precautions/ special method to write select queries for proper utilization of indexes.
Thanks to all reading and answering in advance.
Rgds,
Anu.

Hi
You will find like this
If your select like this
select matnr mtart from mara into<itab>
where matnr = <>..
Go to table and see mara ..if matnr is checked as primary key,then you are using primary index.
Check secondary index tab and see if any fields,if those fields you are using in select then you are using secondary index.
2.Not sequence,check how many fields are checked tick as primary key,all thsoe are index.
3.Always try to use proper primary index in select statment and avoid nested select statements.
Thanks

Report running for long time & performance tuning

Hi All,
(1). WebI report is running for long time.so what are the steps i need to check for it ?
(2). Can you tell me about performance tuning in BO ?
please help me.....
Thanks
Kumar

(1). WebI report is running for long time.so what are the steps i need to check for it ?
The first step is to see if the problem lies in the query on the data source or in webi itself. Depending on the data source there are different ways to extract the query and try to run it against the database. Which source does your report uses?
(2). Can you tell me about performance tuning in BO ?
I would recommend to start by reading the administrator's guide. There is a section about how to improve performance.
Regards,
Stratos

Performance tuning about select

Similar Messages

Maybe you are looking for