Entering content frameOverview documentation Buffering Locate the document in its SAP Library structure

The system ensures that data transfer between the R/3 System and the database system is as efficient as possible. To do this, it uses the following techniques:

When you analyze trace records, you should also examine the system's buffering mechanisms.

Table Buffering

Tables can be either partially or fully buffered (refer to Structure link Buffering Database Tables). This means that an OPEN SQL statement only accesses the database if the results of the statement are not already in the buffer. Consequently, the SQL Trace does not contain a command or command sequence for every OPEN SQL statement. On the other hand, every SQL statement in the trace file has been sent to the database and executed.

Database Request Buffering

To minimize the number of time-consuming PREPARE operations, each work process on the application server has a buffer of SQL statements that it has already prepared. The default buffer size is 250 statements.

Whenever an OPEN SQL statement appears in a program, the work process checks whether it already exists in the "statement cache". If it does, the statement is executed immediately; that is, there is no further PREPARE operation, and the statement is executed using a REOPEN (for SELECT) or a REEXEC (for INSERT, UPDATE, or DELETE).

If the statement does not exist in the buffer, it must be prepared for the subsequent OPEN or EXEC operation. The buffer administration uses a LRU (least recently used) algorithm to delete those statements, whenever necessary, that are only seldom used. Frequently-used statements normally only need to be prepared once.

Application servers buffer DECLARE, PREPARE, OPEN, and EXEC statements in the cursor cache of their work processes. Once the system has opened a cursor for a DECLARE statement, it can carry on reusing it in the same work process.

Leaving content frame