Table Buffers

Created on: Thursday, July 24, 1997

From R/3 Release: 3.0A to: 3.1*
OS Platform: all
DB System: all
Table of Contents
Summary
Introduction
Table Buffering Types
Profile Parameters for Table Buffers
Recommended Settings
Problem Solving
Related Information
Copyright
Summary
This article describes the configuration of table buffers in R/3 and provides pr
ofile parameters and problem analysis.
Introduction
Reading data from R/3 buffers (in 0.2 to 6 ms) can be up to 100 times faster tha
n reading it from the database which may involve a physical file I/O from the da
tabase files (requiring 8 to 600 ms). R/3 buffers are located in shared memory s
o they can be accessed by all work processes belonging to the instance. Each ins
tance contains one of each of the following types of R/3 buffers:

Program buffer for ABAP loads
Presentation buffer for screens
CUA buffer for menu objects
Nametab buffer for ABAP dictionary information
Number range buffer for number ranges to be assigned to application objects
Calendar buffer for active definitions of calendars and holidays
Table buffers for buffered tables

In a productive system, R/3 buffers should contain data which is frequently read
but seldom changed. When changing buffer data, the problem of reading data whic
h is not up-to-date can occur if the R/3 System consists of more than one instan
ce (see fig. 1). To avoid this problem, and notify other instances about changes
to buffered data on a particular instance, the relevant data is marked as inval
id in those other instances.
Buffers can be invalidated in different ways, depending on the type of buffer. F
or table buffers invalidation is carried out asynchronously in the following ste
ps:
1. When a buffered table is updated (through inserts, or deletes) on a part
icular instance, the data is changed:
o on the database
o on the table buffer for the particular instance (see fig. 1).

2. Once the data has been changed, information about the changed data is in
serted into the table DDLOG, provided that the profile parameter rdisp/bufrefmod
e is set to sendon, exeauto (see fig. 1).
Note: Setting sendoff instead of sendon deactivates the mechanism that inserts i
nformation about changes to buffered data into table DDLOG.



Fig. 1. Illustrating Steps 1 and 2 of table buffer invalidation.

3. If the parameter exeauto is set, all instances read the table DDLOG at s
pecific intervals defined by the profile parameter rdisp/bufreftime. Reading DDL
OG enables each instance containing table buffer data which is not up-to-date, t
o mark this data as invalid.
Note: Setting exeoff instead of exeauto deactivates the mechanism that reads inf
ormation about not up-to-date buffered data from table DDLOG.

4. Once the contents of a table buffer marked as invalid are accessed, the
valid data is read from the database.
Tip: Between buffer refreshes (between two reads of the table DDLOG), users may
read data from the buffers that is not up-to-date. To avoid out-of-date reads, b
uffer only tables which are rarely changed.
[ Back to Top ]
Table Buffering Types
In Technical setting for a table in the ABAP dictionary, you can set whether and
how a table should be buffered. There are three buffering types (see fig. 2):
Resident buffering With the first read access, all records of the table are
loaded into the buffer.
Generic buffering With the first read access to one or more records of a g
eneric area, all records of the generic area are loaded into the buffer. A gener
ic area corresponds to all the records of a table that match a generic key. To b
uild the generic key, specify the Number of key fields to be taken from the prim
ary key. If you choose n key fields, the system takes the first n fields from th
e primary key.
Partial buffering When first accessing a single record, that record alone
is loaded into the buffer.


Fig.2. Buffering types (shaded areas are an example of table areas which can be
buffered in each type of buffering)
Tip: When writing programs which access buffered tables, it is important to know
which SQL statements use the buffers and which bypass the buffers. For a detail
ed list of such statements, see OSS Note 47239 Behavior of table buffers.
Table buffers reside in two separate shared memory areas on each instance as fol
lows:

Single record for partially buffered tables
Generic key for resident and generic buffered tables

Partial buffers consist of frames of fixed size (4KB). One record cannot exceed
one frame. Thus, only tables with records smaller than 4KB can be buffered parti
ally. The generic key buffer has the same structure as the single record buffer
before R/3 Release 3.0. Even a very small table occupies at least one frame of 4
KB. As of Release 3.0, memory management within the generic key buffer is more e
fficient:
Memory is divided into blocks of 256 Bytes
Blocks related to a single table are usually contiguous
Tip: Table buffers do not only contain existing records, but also information ab
out records not found in the directory of the buffer. Buffering of many "empty"
records could lead to an exhausted directory of the buffer although there is eno
ugh free space for the data.
[ Back to Top ]
Profile Parameters for Table Buffers
To configure table buffers, use the relevant profile parameters listed below:

Profile Parameter Function
rtbb/buffer_length Size of single record table buffer in KB
rtbb/max_tables Maximal number of buffered tables
ipc/shm_psize_33 Location of the partial buffer. Standard is 0 ( = not in
a pool)
zcsa/table_buffer_area Size of generic key table buffer in bytes
zcsa/db_max_buftab Maximal number of buffered objects
ipc/shm_psize_19 Location of the generic/resident buffer.
Standard is10 ( = in pool 10)
rdisp/bufrefmode Synchronization mode (sendon or sendoff, exeauto or exeo
ff). Standard is sendon, exeauto. Other combinations are for special purposes.
rdisp/bufreftime Time between two synchronizations in seconds
ipc/shm_psize_46 Location of the buffer synchronization table.
[ Back to Top ]
Recommended Settings
The following recommended settings for table buffers are the result of the exper
ience of software developers and consultants. Three categories of recommended se
ttings are distinguished according to the modules on the instance to be configur
ed:

Category 1 The instance has one of the modules FI, AM, CO, or HR.
Category 2 The instance has two of the modules FI, AM, CO, or HR.
Category 3 The instance has any other combination of modules.

Profile Parameter Category 1 Category 2 Category 3
rtbb/buffer_length 10 000 15 000 20 000
rtbb/max_tables 200 300 400
zcsa/table_buffer_area 20 000 000 30 000 000 40 000 000
zcsa/db_max_buftab 2000 3000 4000

Improve performance on HP/HPPA and IBM/RS6000, by grouping shared memories toget
her as shared memory pools to reduce the number of shared memories. Configuratio
n must take into account that the maximum size of a shared memory segment is lim
ited by the operating system. For example, on AIX the maximum size is 256MB.
See the following OSS Notes and therein referenced Notes:
OSS Note 5076 Shared Pool Space Exhausted; SHM Problems Under AIX
OSS Note 37537 Performance increase by Shared Memory Pools
[ Back to Top ]
Problem Solving
Poorly configured table buffers or unbuffered tables can cause performance probl
ems. In the following, the most critical problems are described:
Table buffer exhausted
Table not buffered
Table too large for buffering
Inefficient SQL statements
Table Buffer Exhausted
To correct the size of table buffers, proceed as follows:
1. From the main menu choose Tools ? Administration ? Monitoring ? Performa
nce ? Setup/Buffers ? Buffers. (Alternative: transaction code ST02.)
2. Check whether the displayed values for Generic key and Single record ful
fill the conditions:
o Free space > 20%
o Free directory > 20%
Tip: If the table buffers are too small, all required data cannot be stored in t
he buffers.
Instead, buffered tables are displaced. The Buffer State displayed in the table
call statistics (transaction code ST10) is either absent or displaced.

3. If free space and free directory conditions are not fulfilled (or a lot
of tables are displaced), adapt the profile parameters to the recommended values
.
4. If the profile parameters already fulfill the recommendations, contact t
he SAP Hotline.
Table Not Buffered
To deal with unbuffered tables, proceed as follows:
1. From the main menu choose Tools ? Administration ? Monitoring ? Performa
nce ? Setup/Buffers ? Buffers. (Alternative: transaction code ST02.)
2. Choose Detail analysis menu and within the group Tables choose Call stat
istics. (Alternative: transaction code ST10.)
3. List the not buffered tables since the startup of all servers
4. Sort the list with respect to the columns ABAP/4 Processor Requests Tota
l and ABAP/4 Processor Requests Changes to find out which tables for buffering a
re often accessed, but never or only rarely changed.
Tip: Guidelines for table buffering:
Do not buffer a table of the SAP name range without consulting SAP.
Do not buffer a table that is changed more than once per day.
Do not buffer a table that is only rarely accessed.
Do not buffer a table that is larger than 1 MB.
Exception: tables of between 1 and 5 MB if they are not changed.
Adapt the size of the table buffers if necessary.
Table Too Large For Buffering.
Since R/3 Release 3.0, table buffers displace buffered objects when there is not
enough free space for new objects to be loaded. This displacement is critical f
or performance when the size of the table to be buffered is larger than the size
of the buffer. In that case, tables have to be reloaded into the buffer again a
nd again.
A table is too large for buffering if:
The buffer history shows a lot of database accesses, although the size of the bu
ffer meets the recommendations (transaction code ST02).
Many tables have buffering status absent or displaced (transaction code ST10).
Within table call statistics (transaction code ST10), a bufferable table shows h
igh database activity (list sorted by DB activity Rows affected).
If a table is to large for buffering, you can either:
Switch off the buffering
Buffer smaller generic areas of the table.
Inefficient SQL statements.
To analyze inefficient SQL statements, use the SQL trace. The SQL trace chronolo
gically lists all database requests through the database interface. The informat
ion displayed helps you to tune the accesses for non-buffered tables. This can i
mprove application performance considerably. To obtain an SQL trace:
1. Execute the program you intend to trace, to ensure that that program's b
ufferable database requests are buffered.
When you execute the program again, with the SQL trace running, the trace measur
es only the database accesses of non-buffered tables.
2. To run the SQL Trace, from the menu choose System ? Utilities ? SQL trac
e. (Alternative: transaction code ST05.) Choose Trace on and, when required, ent
er the name of the user whose database activities you want to trace.
3. The user whose name is entered should now execute the transaction or pro
gram and carry out all the activities you want to measure.
4. To stop the SQL trace, return to the main SQL Trace screen (transaction
code ST05) and choose Trace off.
Since the amount of data written is high, optimize system performance by switchi
ng off the trace as soon as you finish recording your application.
5. To display a trace file, on the main SQL Trace screen (transaction code
ST05) choose List trace and, when required, enter user name, start date and star
t time of the trace you require.
To use the displayed information effectively, you need precise knowledge of the
RDBMS and of the R/3 System.
Tip: See also:
R/3s Extended Help, choosing Basis Components ? ABAP/4 Development Workbench ? AB
AP/4 Workbench Tools ? SQL Trace Tool.
The R/3 Knowledge Products CD System Monitoring, choosing Specific Problem ? SQL
Trace.
[ Back to Top ]
Related Information
See also:
OSS Note 3501 Status of a Table in the Buffer
OSS Note 36283 Information on Buffers and Synchronization
OSS Note 47239 Behavior of Table Buffers
OSS Note 71364 Collective note: Monitoring: ST04, DB02, ST10, ST03
The R/3 Knowledge Products CD System Monitoring
________________________________________
SAP TechNet Knowledge Base Article
Topic: System Monitoring
Subtopic: Tuning Performance
Keywords: R/3 buffers, table buffer, buffer synchronization, bufrefmode, b
ufreftime, DDLOG, resident buffering, generic buffering, partial buffering, buff
er status, table statistics

SAP Home Page: http://www.sap.com