General Performance Advice for Open SQL

Keep the hit list small

Wherever possible, you should include all selection conditions in the WHERE clause, using AND and checking for equality. Do not select a large dataset and then check it with CHECK. If you want to read the whole table, you do not have to specify a WHERE condition at all.

Transfer small amounts of data

If you only want to transfer a few fields, use SELECT with a structure, not SELECT *. Alternatively, you can use one of the views in the ABAP Dictionary to select data.

Use the aggregate functions rather than selecting data and grouping it yourself. SAP buffering is switched off when you use aggregate functions.

When you UPDATE a database record, you should only update those columns that have been changed.

Use a small number of database accesses

When you INSERT, UPDATE or DELETE, you should use sets of data instead of individual table entries. This ensures that the index only has to be maintained once, which relieves the load on the database.

You should only use nested SELECT loops when the hit list in the outermost level is very small. There are various ways of avoiding nested SELECT loops:

  1. Building a JOIN in the FROM clause
  2. Joins as views defined in the ABAP Dictionary.
  3. SELECT ... FOR ALL ENTRIES

    In the outermost loop, the database table (PACKAGE SIZE) is read section-by-section into an internal table, sorted by its primary key (SORT on the internal table, or read in using ORDER BY PRIMARY KEY). For each data record in the internal table, all associated, dependent records are read into a further internal table (using SELECT ... FOR ALL ENTRIES). This is also sorted. You can then carry on processing using a nested LOOP.
    The advantage of SELECT ... FOR ALL ENTRIES is that it provides good performance regardless of the selectivity of the condition on the outermost table, since, in contrast to the nested SELECT, it works in a data-oriented way in the database, but still only picks out the relevant database entries (different to parallel cursor processing).
    You should use the addition FOR ALL ENTRIES if a JOIN is not possible for syntactical reasons or if the JOIN would result in high redundancy due to the constantly repeated fields from the left table.
  4. Explicit cursor handling (OPEN CURSOR [WITH HOLD]...)

    In this processing type, a separate cursor is opened for each table involved. These are processed in parallel. In order for the system to recognize control breaks, the tables must be sorted (ORDER BY PRIMARY KEY) before being read. You should only use parallel cursor processing when you want to process the outermost table completely or to a large extent, since WHERE conditions for the outermost table cannot be passed on to other tables (in other words, you might read more data than is necessary).
    Caution: RANGES tables
    You should use explicit cursor handling for large quantities of data and logical databases.

Search through small amounts of data

  1. In WHERE conditions, you should use EQ comparisons linked with AND as often as possible. This means that the system can use indexes in the search.
  2. NOT, OR and IN are not supported by indexes unless all of the fields in the SELECT clause and WHERE condition are also contained in the index.

Reduce the database load wherever possible

  1. Saving database in local buffers (see SAP buffering) can save considerable time in client-server environments, as the access time via the network is considerably higher than access time via a locally buffered table.

    The SAP buffering is switched off:
    1. When you use SELECT FOR UPDATE or SELECT DISTINCT in the SELECT clause,
    2. When you use BYPASSING BUFFER in the FROM clause,
    3. When you use JOINs and subqueries (subqueries),
    4. When you use ORDER BY f1 f2 ... in the ORDER-BY clause.
    5. When you use aggregate functions in the SELECT clause.
    6. When you use IS [NOT] NULL in the WHERE condition.

      You cannot process a query in the SAP buffer if the generic key section is not specified in the WHERE condition
  2. Avoid re-reading the same data.
  3. Before you change a table using DELETE, INSERT or UPDATE, you should check whether you need to read entries using SELECT.
  4. If you want to sort data, it is more efficient to read it into the internal table and sort it using SORT than to use the ORDER-BY clause, where the sort is not supported by an index.
  5. Check whether you can delete duplicates using the variant DELETE ADJACENT DUPLICATES FROM itab instead of using SELECT DISTINCT.
  6. You should use logical databases if possible.

Strings in database tables

Data in long strings is stored outside the dataset, which means that it takes longer to access long strings than to access other data types. This applies in particular to set operations, and does not apply for short strings.

Further Help

Notes on Performance