Performance Tools

SQL Trace

SQL Trace

SQL trace(ST05) provides the developer with the ability to analyse database select statements. Simply execute ST05
to turn on SQL trace, then execute the statement/program you want to analyse. Now turn off SQL trace using ST05
and click on list trace to view the details.

You can also perform traces on other items such as authorisation objects.

Runtime Analysis

*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.

Performance Tuning using Parallel cursor

************************************************************************
* Performance Tuning using parallel cursor
*
* Extracts from program ZFAL2002
************************************************************************


************************************************************************
* START-OF-SELECTION
SELECT *
INTO TABLE I_KEPH FROM KEPH
WHERE KADKY <= SY-DATUM
AND TVERS = '01'
AND KALKA IN ('01','Z1','Z2')
AND BWVAR IN ('Z01','Z02','Z03','Z04','Z07')
AND KKZST = ' '
AND KKZMA = ' '
AND KKZMM = ' '
AND KEART = 'H'
AND PATNR = 0.

* Table must be sorted to ensure all required records are together
SORT I_KEPH BY KALNR KALKA BWVAR KADKY.

* Perform actual processing
Perform get_cost_values.


*----------------------------------------------------------------------*
FORM GET_COST_VALUES.
* Determine start position and then process all records for given key
* from that starting point
* i_keph is sorted on kalnr kalka bwvar kadky.
READ TABLE I_KEPH WITH KEY KALNR = W_KEKO-KALNR
KALKA = W_KEKO-KALKA
BWVAR = W_KEKO-BWVAR
KADKY = W_KEKO-KADKY BINARY SEARCH.
IF SY-SUBRC = 0.
* Loop at itab from first record found (sy-tabix) until record
* no-longer matches your criteria.
LOOP AT I_KEPH FROM SY-TABIX.
IF I_KEPH-KALNR = W_KEKO-KALNR AND I_KEPH-KALKA = W_KEKO-KALKA
AND I_KEPH-BWVAR = W_KEKO-BWVAR AND I_KEPH-KADKY = W_KEKO-KADKY.
* Key match
D_MAT_COST = D_MAT_COST + I_KEPH-KST001.
D_LAB_COST = D_LAB_COST + I_KEPH-KST004.
D_OVER_HEAD = D_OVER_HEAD + I_KEPH-KST010.
D_EXT_PURCH = D_EXT_PURCH + I_KEPH-KST014.
D_MISC_COST = D_MISC_COST + I_KEPH-KST002 + I_KEPH-KST003
+ I_KEPH-KST005 + I_KEPH-KST006 + I_KEPH-KST007
+ I_KEPH-KST008 + I_KEPH-KST009 + I_KEPH-KST011
+ I_KEPH-KST012 + I_KEPH-KST013 + I_KEPH-KST015
+ I_KEPH-KST016 + I_KEPH-KST017 + I_KEPH-KST018
+ I_KEPH-KST019 + I_KEPH-KST020 + I_KEPH-KST021
+ I_KEPH-KST022 + I_KEPH-KST023 + I_KEPH-KST024
+ I_KEPH-KST025 + I_KEPH-KST026 + I_KEPH-KST027
+ I_KEPH-KST028 + I_KEPH-KST029 + I_KEPH-KST030
+ I_KEPH-KST031 + I_KEPH-KST032 + I_KEPH-KST033
+ I_KEPH-KST034 + I_KEPH-KST035 + I_KEPH-KST036
+ I_KEPH-KST037 + I_KEPH-KST038 + I_KEPH-KST039
+ I_KEPH-KST040.
ELSE.
* Key greater - can't be less
EXIT. " Exit loop
ENDIF.
ENDLOOP.
ENDIF.

D_MAT_COST = D_MAT_COST / W_KEKO-LOSGR.
D_LAB_COST = D_LAB_COST / W_KEKO-LOSGR.
D_OVER_HEAD = D_OVER_HEAD / W_KEKO-LOSGR.
D_EXT_PURCH = D_EXT_PURCH / W_KEKO-LOSGR.
D_MISC_COST = D_MISC_COST / W_KEKO-LOSGR.
ENDFORM. " GET_COST_VALUES

Performance tuning using GROUPBY

************************************************************************
* Performance tuning using GROUPBY
*
* Extracts from program ZFAL2002
************************************************************************


************************************************************************
* START-OF-SELECTION

SELECT KALNR KALKA BWVAR MEEHT SUM( MENGE )
INTO TABLE I_CKIS FROM CKIS
WHERE KADKY <= SY-DATUM
AND TVERS = '01'
AND KALKA IN ('01','Z1','Z2')
AND BWVAR IN ('Z01','Z02','Z03','Z04','Z07')
* and kkzst = ' '
AND KKZMA = ' '
AND TYPPS = 'E'
AND ( KSTAR <> 800040 OR KSTAR <> 800050 )
AND ( MEEHT = 'MIN' OR MEEHT = 'H' )
GROUP BY KALNR KALKA BWVAR MEEHT.

* Perform actual processing
Perform get_associated_labour_hours.


*----------------------------------------------------------------------*
FORM GET_ASSOCIATED_LABOUR_HOURS.
* Determine start position and then process single record for given key
* i_ckis is sorted on kalnr kalka bwvar meeht with menge summated.
READ TABLE I_CKIS WITH KEY KALNR = W_KEKO-KALNR
KALKA = W_KEKO-KALKA
BWVAR = W_KEKO-BWVAR
MEEHT = 'H' BINARY SEARCH.
IF SY-SUBRC = 0.
D_LAB_HRS = I_CKIS-MENGE * 60.
ENDIF.

READ TABLE I_CKIS WITH KEY KALNR = W_KEKO-KALNR
KALKA = W_KEKO-KALKA
BWVAR = W_KEKO-BWVAR
MEEHT = 'MINS' BINARY SEARCH.
IF SY-SUBRC = 0.
D_LAB_HRS = D_LAB_HRS + I_CKIS-MENGE.
ENDIF.

D_LAB_HRS = D_LAB_HRS / W_KEKO-LOSGR.
D_LAB_HRS = D_LAB_HRS / 60. "Convert from mins into hours
ENDFORM. " GET_LABOUR_HOURS_ASSOCIATED

ABAP/4 Optimization Techniques

1. ABAP/4 programs can take a very long time to execute, and can make other processes have to wait before executing. Here are some tips to speed up your programs and reduce the load your programs put on the system:
2. Use the GET RUN TIME command to help evaluate performance. It's hard to know whether that optimization technique REALLY helps unless you test it out. Using this tool can help you know what is effective, under what kinds of conditions. The GET RUN TIME has problems under multiple CPUs, so you should use it to test small pieces of your program, rather than the whole program.
3. 
   Generally, try to reduce I/O first, then memory, then CPU activity. I/O operations that read/write to hard disk are always the most expensive operations. Memory, if not controlled, may have to be written to swap space on the hard disk, which therefore increases your I/O read/writes to disk. CPU activity can be reduced by careful program design, and by using commands such as SUM (SQL) and COLLECT (ABAP/4).
4. Avoid 'SELECT *', especially in tables that have a lot of fields. Use SELECT A B C INTO instead, so that fields are only read if they are used. This can make a very big difference.
   Field-groups can be useful for multi-level sorting and displaying. However, they write their data to the system's paging space, rather than to memory (internal tables use memory). For this reason, field-groups are only appropriate for processing large lists (e.g. over 50,000 records). If you have large lists, you should work with the systems administrator to decide the maximum amount of RAM your program should use, and from that, calculate how much space your lists will use. Then you can decide whether to write the data to memory or swap space. See the Fieldgroups ABAP example.
5. Use as many table keys as possible in the WHERE part of your select statements.
   Whenever possible, design the program to access a relatively constant number of records (for instance, if you only access the transactions for one month, then there probably will be a reasonable range, like 1200-1800, for the number of transactions inputted within that month). Then use a SELECT A B C INTO TABLE ITAB statement.
6. Get a good idea of how many records you will be accessing. Log into your productive system, and use SE80 -> Dictionary Objects (press Edit), enter the table name you want to see, and press Display. Go To Utilities -> Table Contents to query the table contents and see the number of records. This is extremely useful in optimizing a program's memory allocation.
7. Try to make the user interface such that the program gradually unfolds more information to the user, rather than giving a huge list of information all at once to the user.
8. Declare your internal tables using OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to be accessing. If the number of records exceeds NUM_RECS, the data will be kept in swap space (not memory).
9. Use SELECT A B C INTO TABLE ITAB whenever possible. This will read all of the records into the itab in one operation, rather than repeated operations that result from a SELECT A B C INTO ITAB... ENDSELECT statement. Make sure that ITAB is declared with OCCURS NUM_RECS, where NUM_RECS is the number of records you expect to access.
10. If the number of records you are reading is constantly growing, you may be able to break it into chunks of relatively constant size. For instance, if you have to read all records from 1991 to present, you can break it into quarters, and read all records one quarter at a time. This will reduce I/O operations. Test extensively with GET RUN TIME when using this method.
11. Know how to use the 'collect' command. It can be very efficient.
12. Use the SELECT SINGLE command whenever possible.
13. Many tables contain totals fields (such as monthly expense totals). Use these avoid wasting resources by calculating a total that has already been calculated and stored.

Workload analysis ( ST03 ) is used to determine system performance

You should check statistics and record trends to get a “feel” for the system’s behavior and
performance. Understanding the system when it is running well helps you determine what
changes may need to be made when it is running poorly.

1. In the Command field, enter transaction ST03 and choose Enter (or from the SAP standard menu, choose Tools -Administration --Monitor - Performance - Workload -ST03-Analysis).
2. Choose Data base server or This application server. (In this example, we chose This
application server, pal101003_SAS_00.)

3. Select a time period to analyze. (In this example, we chose Last minute load.)

4. Enter how many minutes back to analyze, or choose Other selection to specify a date and time period to analyze. In this example, we chose Other selection.

5. Under Time interval to be analyzed is, enter the Date and time range to be analyzed.

6. Choose

7. Check the Current value under Task types (for example, Total).
The task types are:
<>Note : Judgment must be applied when reviewing statistical values. If you just started the R/3
System, the buffers will be empty and many of the statistics will be unfavorable. Once the
buffers are loaded, values can be properly evaluated. In this example, the Av. response time of almost 4 seconds must be evaluated with other
factors in mind.
Note : The R/3 user default for a decimal point is a comma. If your default profile for decimal point, (point or comma) is not appropriately set, the display may be misread. For example, rather than 3,888 ms, it would read 3.888 ms. Quite a difference!

11. Click on any cell in the Response time avg column.

12. Choose .

Analysis of transaction ST03 is covered in BC315 (the Workload Analysis and Tuning class).
We recommend you take this class.

13. The programs and transactions are now sorted in average response time order.

A few standard functional transactions will exceed the one-second guideline. They include,
but are not limited to the following:

Type Transaction 

Create Sales Order VA01 
Change Sales Order VA02 
Display Sales Order VA03 
Create Billing Document VF01 
Create Delivery VL01 
Maintain Master HR data PA30