Maximizing SAP ABAP Performance

Maximizing SAP ABAP Performance

Maximizing SAP ABAP Performance from PeterHBrown

Read More

Code Inspector

Code Inspector

Features
The Code Inspector is a tool for checking static ABAP coding and DDIC objects (i.e. generally all objects of the Object Repository) under
aspects of functional correctness, performance, security, reliability, and statistical information.
It helps developers to adhere to programming standards and guidelines by creating messages on less-than-optimal coding. The Code
Inspector offers various possibilities to define object sets and to combine multiple single checks in so-called "check variants". These
functions, and the tool's parallel processing framework, make the Code Inspector a flexible and effective development assistant.
The Code Inspector can be used in various scenarios with different types of checks, thus providing insights into the code quality from
various angles.
Usage scenarios
1. Single object checks from the Development Workbench
You can check a single object with the Code Inspector from the ABAP Editor (transaction SE38), the Function Builder
(transaction SE37), the Class Builder (transaction SE24), or the ABAP Data Dictionary (transaction SE11). To do this, choose
<object> > Check > Code Inspector from the menu, w here <object> can be a program, function module, class, or table. The
respective single objects are then checked with a default check variant.
2. Checks on transport objects from the Transport Organizer
You can invoke the Code Inspector from w thin the Transport Organizer (transaction SE09) to check objects in a transport
request. To do this, choose Request/Task > Complete Check > Objects (Syntax Check).
3. Checks on sets of objects from transaction SCI
The Code Inspector (transaction SCI) itself enables you to create a wide range of object sets using standard selections via
package, software and application component, source system, transport layer, responsible, object type, object name and so on.
In addition, special object collectors are available that allow you to read objects from a file, for example.
An object set can be combined with a check variant to a so-called "inspection" that can be executed in a single process or in
parallel. For a more details see Code Inspector User Manual
Types of checks and check variants
Below is a short extract of the types of checks and functions that are offered by Code Inspector. New checks can be implemented if
required, see for example Code Inspector - How to create a new check.
ABAP Test Cockpit
Syntax
Syntax check; extended program check
Performance
Analysis of WHERE clauses for SELECT, UPDATE and DELETE; SELECT statements that bypass the table buffer; Low performance
operations on internal tables ; table attributes check
Security
Usage of critical statements; dynamic and cross-client database accesses; use of ADBC-interface
Robustness
Check of SY-SUBRC handling; suspect conversions; activation check for DDIC objects
Programming Conventions
Naming conventions
Search Functions
Search of ABAP tokens; search ABAP statement patterns; search for ABAP statements with regular expressions
Metrics and Statistics
Program complexity test; statement statistics
You can combine any of these single checks into so-called "check variants", for example to check for the adherence to given
programming guidelines.
Best Practices
Developers can use the Code Inspector to support their everyday work. For example, the search functions or metric checks of the tool
can be a great help w hen restructuring the code.
The Code Inspector allow s developers to define which objects are to be checked and which quality aspect of the code is to be
inspected (e.g. performance, security).
It is also possible to define global check variants as general programming guidelines, to ensure standardized programming within a
development community. Check variants can prescribe for example naming conventions or other rules. The global check variants
'DEFAULT' and 'TRANSPORT' inspect objects in the development workbench and in transport requests, respectively. These check

Code Inspector's Performance Checks
Analysis of the WHERE clause for SELECT, UPDATE and
DELETE
SELECT statements that bypass the table buffer
Low performance operations on internal tables
Table attributes check
3/4/2014 Code Inspector - ABAP Development - SCN Wiki
http://wiki.scn.sap.com/wiki/display/ABAP/Code+Inspector 2/2
'DEFAULT' and 'TRANSPORT' inspect objects in the development w orkbench and in transport requests, respectively. These check
variants contain SAP-defined settings, but can be modified as needed.
Another global check variant delivered w ith every SAP system is 'PERFORMANCE_CHECKLIST' w hich helps to detect less-than-optimal
coding w ith regard to application performance.
Related tools
ABAP Test Cockpit (ATC) : ABAP check toolset w hich allow s running static checks and unit tests for your ABAP development
objects
Syntax checks: standard syntax check is integrated into the ABAP editor. Extended syntax check (transaction SLIN)
Dynamic performance checks: performance trace (transaction ST05 ) for SQL (database access) / SAP enqueue / RFC trace
analysis, ABAP runtime trace (transaction SAT or ABAP profiler) for application code
Performance in a system landscape: global performance analysis (transaction ST30)

Read More

Performance Tuning

Performance TuningIntroduction•Purpose
•Use
•Challenges

   Performance Tuning is nothing but optimizing theperformance of your program through various   techniques thus increasing the productivity of the user.

Purpose

    In this world of SAP programming, ABAP is the universal language . Often due to the pressure of schedules and deliveries, the main focus of making a efficient program takes a back seat. An efficient program is one which delivers the required output to the user in a finite time as per the complexity of the program, rather than hearing the comment “I put the program to run , have my lunch and come back to check the results”

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.

Note: It is suggestible to make at least on field mandatory                             in Selection-Screen as mandatory fields restrict the data selection and hence increasing the performance.

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

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 P~F1 P~F2 F~F3 F~F4 INTO TABLE ITAB

    FROM EKKO AS P INNER JOIN EKAN AS F

      ON P~EBELN = F~EBELN.

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. 

Read More

Performance Tuning using Parallel Cursor

Performance Tuning using Parallel Cursor

Nested Loops – This is one of the fear factors for all the ABAP developers as this consumes lot of program execution time. If the number of entries in the internal tables is huge, then the situation would be too worse. The solution for this is to use parallel cursor method whenever there is a need for Nested Loop.

Program using Normal Nested Loop:

REPORT  ZNORMAL_NESTEDLOOP.

TABLES:
  likp,
  lips.

Data:
  t_likp  type table of likp,
  t_lips  type TABLE OF lips.

data:
  W_RUNTIME1 TYPE I,
  W_RUNTIME2 TYPE I.

START-OF-SELECTION.
select *
  from likp
  into table t_likp.

select *
  from lips
  into table t_lips.

get RUN TIME FIELD w_runtime1.

loop at t_likp into likp.
  loop at t_lips into lips where vbeln eq likp-vbeln.
  endloop.
endloop.

get RUN TIME FIELD w_runtime2.

w_runtime2 = w_runtime2 - w_runtime1.

write w_runtime2.

Nested Loop using Parallel Cursor:

REPORT  zparallel_cursor2.

TABLES:
  likp,
  lips.

DATA:
  t_likp  TYPE TABLE OF likp,
  t_lips  TYPE TABLE OF lips.

DATA:
  w_runtime1 TYPE i,
  w_runtime2 TYPE i,
  w_index LIKE sy-index.

START-OF-SELECTION.
  SELECT *
    FROM likp
    INTO TABLE t_likp.

  SELECT *
    FROM lips
    INTO TABLE t_lips.

  GET RUN TIME FIELD w_runtime1.
  SORT t_likp BY vbeln.
  SORT t_lips BY vbeln.

  LOOP AT t_likp INTO likp.

    LOOP AT t_lips INTO lips FROM w_index.
      IF likp-vbeln NE lips-vbeln.
        w_index = sy-tabix.
        EXIT.
      ENDIF.
    ENDLOOP.
  ENDLOOP.

  GET RUN TIME FIELD w_runtime2.

  w_runtime2 = w_runtime2 - w_runtime1.

  WRITE w_runtime2.

Analysis report: Runtime in microseconds: 

Iteration No	Normal Nested Loop	Using Parallel Cursor
1	34,796,147	63,829
2	38,534,583	56,894
3	34,103,426	50,510

Read More

ABAP/4 Tuning Checklist

ABAP4 Tuning Checklist

General Considerations:

1. Is the program YEAR 2000 compliant ?

check date logic and make sure there are not any 2 digit year fields

2. Is the program US ready ?

taking into consideration the US volumes, w ill the program ever finish? Can data be selected for just the US - selection parameters at company code level, plant, purch org,

sales div, etc...

SQL SELECT statements:

3. Is the program using SELECT * statements ?

Convert them to SELECT column1 column2 or use projection view s

4. Are CHECK statements for table fields embedded in a SELECT ... ENDSELECT loop, or in a LOOP AT ... ENDLOOP ?

Incorporate the CHECK statements into WHERE clause of the SELECT statement, or the LOOP AT statement

5. Do SELECTS on non-key fields use an appropriate DB index or is table buffered ?

Create an index for the table in the data dictionary or buffer tables if they are read only or read mostly

6. Is the program using nested SELECTs to retrieve data ?

Convert nested selects to database view s, DB joins (4.0) or SELECT xxx FOR ALL ENTRIES IN ITAB Nested open select tatements are usually bad, and unless the amount of data is

enormous, these types of reads should be avoided. They are usually used as they are the safest w ay to program - you w ill never have any memory issues. The technical explanation as to w hy this is

bad follow s - feel free to tune out for the remainder of the paragraph. Open selects read just one record from the database at a time. Each time you do this, the app server and database server need to

communicate. The packet size of this communication is typically much larger than the size of the record, so most of the packet is w aisted w ith this type of read. When system load is heavy, this can slow

performance. Combine this w ith the overhead of accessing the database many times vs just once.

7. Are there SELECTs w ithout WHERE condition against files that grow constantly (BKPF/BSEG,MKPF/MSEG,VBAK/VBAP...) ?

Program design is w rong - back to draw ing board

8. Are SELECT accesses to master data files buffered (no duplicate accesses w ith the same key) ?

Buffer accesses to master data files by storing the data in an internal table and filling the table w ith READ TABLE...BINARY SEARCH method

9. Is the program using SELECT ...APPEND ITAB ...ENDSELECT techniques to fill internal tables ?

Change processing to read the data immediately into an internal table (SELECT VBELN AUART ... INTO TABLE IVBAK...)

10. Is the program using SELECT ORDER BY statements ?

Data should be read into an internal table first and then sorted, unless there is an appropriate index on the order by fields

11. Is the programming doing calculations/summations that can be done on the database via SUM, AVG, MIN or MAX functions of the SELECT statement?

use the calculation capabilities of the database via SELECT SUM...

12. Do any SELECT statements contain fully-qualified keys (all keys are specified to match a single value in the WHERE clause) but not the keyw ord SINGLE?

the syntax checker w on't catch this & neither does the database optimizer! such an "incorrect" statement can take 5x longer

13. Are there any SELECT or LOOP AT structures that are only attempting to retrieve the first match on a generic key lookup?

use the EXIT statement, or UP TO 1 ROWS option in the case of SELECT, to break the loop & avoid unnecessary iterations

14. Do UPDATE/INSERT/DELETE statements occur inside loops?

save all accumulated changes in an internal table and then use the SQL array statements to perform the updates: INSERT <tab> FROM TABLE <itab>.

15. Are only a few fields being changed by an UPDATE statement?

use the SET <field> = <value> clause of the UPDATE statement rather than updating the entire record

16. Is the program inserting/updating or deleting data in dialog mode (not via an update function module) ?

Make sure that the program issues COMMIT WORK statements w hen one or more logical units of w ork (LUWS) have been processed.

17. Are internal tables processed using READ TABLE itab WITH KEY ... BINARY SEARCH technique ?

Change table accesses to use BINARY SEARCH method. Note that this is ONLY possible if the table is sorted by the access key! Add a SORT if not already there.

18. Is a semi-sequential scan of a large, sorted internal table being performed by a LOOP AT ... WHERE, or LOOP AT ... w ith CHECK statements to continue/terminate the

loop ?

Use a READ TABLE w ith BINARY SEARCH to retrieve first record in the sequence matching the lookup keys, then LOOP AT ... FROM SY- TABIX + 1 until one of the key field values

changes; this w ay you get only the records you need, rather than reading up to the starting point

19. Is a condensed, summary internal table being built by READ TABLE... BINARY SEARCH and then sum, INSERT or APPEND?

Use the COLLECT statement, and SORT the result after the table is complete

20. Is a COLLECT statement being used simply to avoid duplicate entries in an all-character fields - no numeric fields: types I, P or F - internal table ?

Use the READ TABLE ... WITH KEY ... BINARY SEARCH w ith an INSERT ... INDEX SY-TABIX to build the table

21. Are internal tables being SORTed w ithout any field qualifiers?

Specify the actual fields to be used: SORT <tab> BY <fld1> <fld2> ... The few er fields, the better!

22. Are internal tables being copied or compared record-by-record?

Use the "[]" option to refer to the entire table in one line of code:

- TAB2[] = TAB1[] - copy TAB1 to TAB2

- IF TAB1[] EQ TAB2[] - compare TAB1 to TAB2

String Processing:

23. Are strings being built up/broken dow n manually w ith code fragments?

use the new CONCATENATE/SPLIT statements, w ith the SEPARATED BY SPACE option of CONCATENATE if desired

24. Are the older, obsolete string handling functions for finding string length, or centering/right-justifying strings being called?

use the new er "strlen( )", "WRITE...TO...CENTERED", "WRITE...TO...RIGHT-JUSTIFIED" statements

25. Are field strings (records) being set to a special character, other than SPACE, via a CLEAR and then a TRANSLATE instruction?

use the new CLEAR <record> WITH <char> statement (esp. useful w ith standard SAP batch input generation programs to set the "no value for this

field" indicator, w hich has a default symbol of "/")

Miscellaneous:

26. Is an internal table filled w ith a massive amount of data (approx. 5000 to 10000 records or more, depending on record length), sorted and processed?

- instead, use the FIELD-GROUPS declaration, and the INSERT, EXTRACT, SORT and LOOP instructions to define, create, sort and process such large volumes of data more efficiently

27. Is a logical database-driven program taking too long to select data?

- convert the program to specific SELECT statements, w ith more appropriate index usage and a minimized sequence of nested SELECTs; don't forget to remove the 'Logical database'

name/application from the program's attributes

28. Is a MOVE-CORRESPONDING statement used w hen it's not needed?

- if moving a complete record w ith same structure, just use the simple assignment statement: XVBAP = VBAP or MOVE VBAP TO XVBAP

and if moving only a handful of fields, use specific assignments

29. Are there no OBLIGATORY specifications on the key PARAMETERS and/or SELECT-OPTIONS declarations?

- enforce user entry of key fields, thus limiting database accesses to some degree. To read everything, how ever, the user could still enter "1" -"99999999..." (see next item though), but at

least they start to think about w hat they really need to see.

30. Are SELECT-OPTIONS fully open to the most complex searches even w hen they need not be?

- Use the keyw ords NO-EXTENSION and/or NO INTERVALS of the SELECT-OPTIONS declaration, if possible, to limit the number of ranges to only 1 (NO-EXTENSION), or

limit the entry to single values only (NO INTERVALS) if that's all that is really needed for the application, so that the SELECT statement's "IN" operation is less complex

31. Producing information messages about "long run-times" can also be beneficial in reducing run-times

-the user w ill think tw ice and hopefully re-starts the program w ith a smaller range; or in extreme situations, an error message preventing generic input or complete range input on a key field

32. In especially difficult cases, w here no amount of specific statement re- w riting, indexing, or buffering increases performance enough, consider re- structuring the

main SELECT sequence, if possible, to reduce the total number of records to a manageable size.

- this technique is only possible w ith certain table sequences that are related via both forw ard and backw ard pointing foreign key relationships, and then only makes sense w hen reversing

the logic w ill definitely reduce the total read accesses, and does not require a complete program re-w rite of all related routines, etc.var domainName = 'https://w iki.sdn.sap.com/w iki'; var entityId = '35836';

var spaceKey = 'Snippets'new Ajax.Autocompleter('labelName', 'labelsAutocompleteList', '35836',

Read More

ABAP Performance Standards

ABAP Performance Standards

By Tejaswini

Following are the performance standards need to be following in writing ABAP programs:

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

Read More