Buffer setting allowed in table creation technical setting....

[Former Member]

Hi all, can any one give me the detail of Buffer setting allowed in table creation technical setting...., what's the use & difference b/w three of them(buffer not allowed, buffer allowed but switched off, buffer switched on).

what are all the uses of buffer types?.

[Former Member]

HI

The buffering type defines which table records are loaded into the buffer of the application server when a table record is accessed. There are the following buffering types:

<b>Full buffering:</b> All the records of the table are loaded into the buffer when one record of the table is accessed.

With full buffering, either the entire table is in the buffer or the table is not in the buffer at all. All the records of the table are loaded into the buffer when one record of the table is read.

<b>When Should you Use Full Buffering?</b>

When deciding whether a table should be fully buffered, you should take into account the size of the table, the number of read accesses, and the number of write accesses. Tables best suited to full buffering are small, read frequently, and rarely written.

<b>Full buffering is recommended in the following cases:</b>

Tables up to 30 KB in size. If a table is accessed frequently, but all accesses are read accesses, this value can be exceeded. However, you should always pay attention to the buffer utilization.

Larger tables where large numbers of records are frequently accessed. If these mass accesses can be formulated with a very selective WHERE condition using a database index, it could be better to dispense with buffering.

Tables for which accesses to non-existent records are frequently submitted. Since all the table records reside in the buffer, the system can determine directly in the buffer whether or not a record exists.

<b>Generic buffering:</b> When a record of the table is accessed, all the records having this record in the generic key fields (part of the table key that is left-justified, identified by specifying a number of key fields) are loaded into the buffer.

With generic buffering, all the records in the buffer whose generic key fields match this record are loaded when one record of the table is accessed. The generic key is a part of the primary key of the table that is left-justified.

<b>How Should you Define the Generic Key?</b>

In generic buffering, it is crucial to define a suitable generic key.

If the generic key is too small, the buffer will contain a few very large areas. During access, too much data might be loaded in the buffer.

If the generic key is too large, the buffer might contain too many small generic areas. These can reduce buffer performance since there is an administrative entry for every buffered generic area. It is also possible that too many accesses will bypass the buffer and go directly to the database, since they do not fully define the generic key of the table. If there are only a few records in each generic area, it is usually better to fully buffer the table.

Only 64 bytes of the generic key are used. You can specify a longer generic key, but the part of the key exceeding 64 bytes is not used to create the generic areas.

<b>Access to Buffered Data</b>

It only makes sense to generically buffer a table if the table is accessed with fully-specified generic key fields. If a field of the generic key is not assigned a value in a SELECT statement, it is read directly from the database, bypassing the buffer.

If you access a generic area that is not in the buffer with a fully-specified generic key, you will access the database to load the area. If the table does not contain any records in the specified area ("No record found"), this area in the buffer is marked as non-existent. It is not necessary to access the database if this area is needed again.

<b>Single-record buffering:</b> Only the records of a table that are really accessed are loaded into the buffer.

With single-record buffering, only the records that are actually read are loaded into the buffer. Single-record buffering therefore requires less storage space in the buffer than generic and full buffering. The administrative costs in the buffer, however, are greater than for generic or full buffering. Considerably more database accesses are necessary to load the records than for the other buffering types.

<b>When Should you Use Single-Record Buffering?</b>

Single-record buffering should be used particularly for large tables where only a few records are accessed with SELECT SINGLE. The size of the records being accessed should be between 100 and 200 KB.

Full buffering is usually more suitable for smaller tables that are accessed frequently. This is because only one database access is necessary to load such a table with full buffering, whereas several database accesses are necessary for single-record buffering.

<b>Access to Buffered Data</b>

All accesses that are not submitted with SELECT SINGLE go directly to the database, bypassing the buffer. This applies even if the complete key is specified in the SELECT statement.

If you access a record which is not yet buffered with SELECT SINGLE, there is a database access to load the record. This record is marked in the buffer as non-existent if the table does not contain a record with the specified key. This prevents another database access when accessing the table at a later time with the same key.

Regards Rk

Message was edited by:

Rk Pasupuleti

[Former Member]

<b>Buffering not allowed</b> if a table may not be buffered.

<b>Buffering allowed but not activated</b> if buffering is

principally allowed for a table, but at the moment no buffering

should be active. The

buffering type specified in this case is only

a suggestion.

<b>Buffering allowed</b> if the table should be buffered. In this

case a buffering type

must be specified.

<b>buffering types</b>

<b>Single-record buffering</b>

With this kind of buffering, only the records of a table which are

actually accessed are loaded into the buffer.

This kind of buffering requires less storage space in the buffer than

full buffering. However, greater organization is necessary and

considerably more database accesses are necessary for loading.

If an as yet unbuffered record is accessed using SELECT SINGLE, a

database access occurs to load the record. If the table does not contain

a record for the specified key ('no record found'), this record is noted

as nonexistent in the buffer. If a further attempt is made to access

this record using SELECT SINGLE, a renewed database access can be

avoided.

<b> When should single-record buffering be selected?</b>

o For large tables where there are frequent single-record accesses

(using SELECT SINGLE ...). The size of the records being accessed

should be between 100-200 KB.

o For comparatively small tables for which the access range is large,

it is normally advisable to opt for full buffering. Only one

database access is required to load such a table for full buffering,

while single-record buffering calls for a very large number of table

accesses.

<b> Generic buffering</b>

In a read access to a record of a generically buffered table, all the

records whose left-justified part of the key (generic area) corresponds

are loaded into the buffer.

If this type of buffering is selected, the generic area must be defined

by specifying a number n of key fields. The first n key fields of the

table then define the generic key.

The number of key fields to be entered must lie between 1 and the number

of key fields -1. For example, only values between 1 and 5 are permitted

for a table with 6 key fields. The client field is included here.

<b> When should generic buffering be selected?</b>

o A table should be buffered generically if usually only certain areas

of the table are required. The individual generic areas are treated

like independent tables that are fully buffered. Refer also to the

text on complete buffering.

o The generic key area should be selected so that the generic areas

are not too small to prevent too may generic areas being produced.

If there are only a few records for each generic area, it is more

efficient to use full buffering.

o Generic buffering only makes sense if the table is accessed by a

specified generic key. If, when an access takes place, a field of

the generic key is not supplied with a value, the buffer is ignored

and the records are read directly from the database.

o Language-specific tables are an example of good use of generic

buffering (with the language key field as generic key area).

<b>Full buffering</b>

With full buffering, either the complete table or none of the table is

in the buffer. If a read access is made to a record, all records of the

table are transferred to the buffer.

<b> When should you select full buffering?</b>

o For tables up to 30 KB in size. If a table is accessed frequently,

but all accesses are read accesses, this value can be exceeded.

o For larger tables where large numbers of records are frequently

accessed. However, if the application program is able to formulate

an extremely selective WHERE condition using a database index, it

may be advisable to dispense with full buffering.

o For tables with frequent accesses to data not contained in the

table. Since all records are contained in the buffer, a quick

decision can be made as to whether or not the table contains a

record for a specific key.

When considering whether a table should be fully buffered, you should

take three aspects into account: the size of the table, the number of

read accesses, and the number of write accesses. Tables best suited to

full buffering are small, frequently read, and rarely updated.

[Former Member]

Hi ArunKumar,

Go through this info.

Buffering

You must define whether and how a table is buffered in the

technical settings for the table. There are three possibilities

here:

1> Buffering not permitted: Table buffering is not permitted,

for

example because application programs always need the

most

recent data from the table or the table is changed too

frequently.

2> Buffering permitted but not activated: Buffering is

permitted from the business and technical points of view.

Applications which access the table execute correctly with

and without table buffering.

Whether or not table buffering will result in a gain in

performance depends on the table size and access profile

of the table (frequency of the different types of table

access).

Table buffering is deactivated because it is not possible to

know what these values will be in the customer system. If

table buffering would be advantageous for the table size and

access profile of the table, you can activate it in the customer

system at any time.

3> Buffering activated: The table should be buffered. In this

case you must specify a buffering type.

Buffering types:

1> Single-Record buffering

With single-record buffering, only the records that are actually

read are loaded into the buffer. Single-record buffering therefore

requires less storage space in the buffer than generic and full

buffering. The administrative costs in the buffer, however, are

greater than for generic or full buffering. Considerably more

database accesses are necessary to load the records than for

the other buffering types.

When Should you Use Single-Record Buffering?

Single-record buffering should be used particularly for

large tables where only a few records are accessed with

SELECT SINGLE. The size of the records being accessed

should be between 100 and 200 KB.

Full buffering is usually more suitable for smaller tables

that are accessed frequently. This is because only one

database access is necessary to load such a table with full

buffering, whereas several database accesses are

necessary for single-record buffering.

2> Generic buffering

With generic buffering, all the records in the buffer whose

generic key fields match this record are loaded when one

record of the table is accessed. The generic key is a part of

the primary key of the table that is left-justified.

3> Full buffering

With full buffering, either the entire table is in the

buffer or the table is not in the buffer at all. All the

records of the table are loaded into the buffer when

one record of the table is read.

When Should you Use Full Buffering?

When deciding whether a table should be fully buffered, you

should take into account the size of the table, the number of

read accesses,

and the number of write accesses. Tables best suited to full

buffering are small, read frequently, and rarely written.

Full buffering is recommended in the following cases:

Tables up to 30 KB in size. If a table is accessed frequently, but

allaccesses are read accesses, this value can be exceeded.

However, youshould always pay attention to the buffer

utilization.

Larger tables where large numbers of records are frequently

************Provide some points if it is helpful.

Rgds,

P.Naganjana Reddy