ARTICLE
Open SQL - SAP Buffering
When accessing a database table using Open SQL ,
SAP buffering is usually active if it is
defined for the database table in question. The definition of a database
table in ABAP Dictionary determines whether and how it is buffered.
There are three buffering types:
Individual record buffering or partial
buffering of individual records
Generic buffering of specific areas
Complete buffering of the whole table
With the exception of the statements listed below, read Open SQL
statements access the buffer. Modifying Open SQL statements that
make modifications using work areas access
the buffer of the current application server directly and invalidate the
entries affected in the buffer of the other application server.
Modifications using UPDATE ... SET ... WHERE
... or DELETE ... WHERE ...
invalidate the entries affected in the buffers of all the application
servers. The invalidation of the entries on the other application
servers does not happen directly and uses a buffer synchronization that
is called periodically. The time interval can be set using the
profile parameter
rdisp/bufreftime and has a default
value of two minutes. An access to an invalidated entry of a buffer
reloads the entry from the database.
You can use the addition BYPASSING BUFFER
of the SELECT statement to switch off access to the buffer
explicitly. As well as specifying the BYPASSING BUFFER
explicitly, SAP buffering is also avoided implicitly by some variants of
Open SQL statements since the corresponding operations can only
be carried out in the database and not in the SAP buffer. The following
Open SQL statements avoid SAP buffering implicitly and access the
database table directly:
SELECT with the addition FOR
UPDATE .
SELECT with the addition
DISTINCT ,
SELECT with aggregate expressions .
Open SQL statement with the addition
CLIENT SPECIFIED when the client ID is not specified in a
WHERE condition.
SELECT with JOIN expressions.
SELECT , if the WHERE condition
compares a column with another column
from a database table specified after FROM .
Access to a table with individual record buffering without specifying
(in the WHERE condition) all the equality
conditions joined by AND for all the key fields of the primary
key.
Access to a generically buffered area without complete specification of
equality conditions joined by AND in a WHERE
condition.
Open SQL statements with IS [NOT]
NULL in the additions WHERE and HAVING .
Use of a subquery in a WHERE
condition.
SELECT with FOR ALL ENTRIES
in the following cases:
Access to a table with single record buffering.
Access to a table with generic buffering if the requirement to specify
the generic area exactly (as specified above) is violated. The condition
after FOR ALL ENTRIES cannot produce an OR relationship
between multiple generic areas.
SELECT with the addition GROUP BY
,
SELECT with the addition ORDER BY
, if individual columns are specified as the sort key, and these
columns are not a left-aligned subset of the primary key in the correct
order.
After the invalidation of an entry in the buffer using a modifying
statement, the next five read accesses that should have accessed the
entry avoid the buffer of the current application server by default. The
next read access to the changed entry reloads it into the buffer and
removes the invalidation. The number of read accesses that avoid the
buffer before the reload is specified in the
profile parameter
zcsa/sync_reload_c .
Note
The avoidance of the SAP buffer using the additions above should be
noted for access to buffered data for performance reasons. To explicitly
avoid the SAP buffer in the SELECT statement you should always
use the BYPASSING BUFFER addition and not rely on the implicit
behaviour of the additions above.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved