Buffering Types?

Q. 1
Hi folks.
I would like to know the difference between Different types of buffering with respect to
accessed data, situations and performance criteria.
Regards Harsh.
Thread: Buffering Types?
This question is answered.
Q. 2
Hi folks.
I would like to know the difference between Different types of buffering with respect to
accessed data, situations and performance criteria.
Regards Harsh.
Re: Buffering Types?
Posted: Jun 30, 2008 3:33 PM

in response to: Harsh Dave

Reply

Harsh,
The buffering type defines whether and how the table should be buffered.
There are the following types of buffering:
single-record buffering
generic area buffering
full buffering
In generic area buffering, a number of key fields between 1 and no. of key fields-1 must
be specified.

Single-record buffering
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.
When should single-record buffering be selected?
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.
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.
Generic buffering
In a read access to a record of a generically buffered table, all the records whose leftjustified 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.
When should generic buffering be selected?
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.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.
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.
Language-specific tables are an example of good use of generic buffering (with the
language key field as generic key area).
Full buffering
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.
When should you select full buffering?

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.
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.
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.
Database Logical Unit of Work (LUW)

From the point of view of database programming, a database LUW is an inseparable

sequence of database operations that ends with a database commit. The database LUW
is either fully executed by the database system or not at all. Once a database LUW has
been successfully executed, the database will be in a consistent state. If an error occurs
within a database LUW, all of the database changes since the beginning of the database
LUW are reversed. This leaves the database in the state it was in before the transaction
started.

The database changes that occur within a database LUW are not actually written to the
database until after the database commit. Until this happens, you can use a database
rollback to reverse the changes. In the R/3 System, database commits and rollbacks can
be triggered either implicitly or using explicit commands.
Implicit Database Commits in the R/3 System
A work process can only execute a single database LUW. The consequence of this is
that a work process must always end a database LUW when it finishes its work for a
user or an external call. Work processes trigger an implicit database commit in the

following situations:

When a dialog step is completed

Control changes from the work process back to the SAP GUI.

When a function module is called in another work process (RFC).

Control passes to the other work process.

When the called function module (RFC) in the other work process ends.
Control returns to the calling work process.

When a WAIT statement interrupts the work process.

Control passes to another work process.

Error dialogs (information, warning, or error messages) in dialog steps.

Control passes from the work process to the SAP GUI.

Explicit Database Commits in the R/3 System
There are two ways to trigger an explicit database commit in your application programs:

Call the function module DB_COMMIT

The sole task of this function module is to start a database commit.

Use the ABAP statement COMMIT WORK

This statement starts a database commit, but also performs other tasks (refer to
the keyword documentation for COMMIT WORK).
Implicit Database Rollbacks in the R/3 System
The following cases lead to an implicit database rollback:

Runtime error in an application program

This occurs whenever an application program has to terminate because of an
unforeseen situation (for example, trying to divide by zero).

Termination message

Termination messages are generated using the ABAP statement MESSAGE with
the message type A or X. In certain cases (updates), they are also generated with
message types I, W, and E. These messages end the current application program.
Explicit Database Rollbacks in the R/3 System
You can trigger a database rollback explicitly using the ABAP statement
ROLLBACK WORK. This statement starts a database rollback, but also performs
other tasks (refer to the keyword documentation for ROLLBACK WORK).
From the above, we can draw up the following list of points at which database LUWs
begin and end.
A Database LUW Begins

Each time a dialog step starts (when the dialog step is sent to the work
process).

Whenever the previous database LUW ends in a database commit.

Whenever the previous database LUW ends in a database rollback.

A Database LUW Ends

Each time a database commit occurs. This writes all of the changes to the
database.

Each time a database rollback occurs. This reverses all of the changes made
during the LUW.
Database LUWs and Database Locks
As well as the database changes made within it, a database LUW also consists of
database locks. The database system uses locks to ensure that two or more users
cannot change the same data simultaneously, since this could lead to inconsistent data
being written to the database. A database lock can only be active for the duration of a
database LUW. They are automatically released when the database LUW ends. In order
to program SAP LUWs, we need a lock mechanism within the R/3 System that allows us
to create locks with a longer lifetime (refer to

Data Class
Use
If you choose the data class correctly, your table is automatically assigned to the correct
area (table space or DB space) of the database when it is created. Each data class
corresponds to a physical area in which all the tables assigned to this data class are
stored.
There are the following data classes:

APPL0 (master data):

Data that is seldom changed. An example of master data is the data contained in
an address file, such as the name, address and telephone number.

APPL1 (transaction data):

Data that is frequently changed. An example of transaction data is the goods in a
warehouse which change after each purchase order.

APPL2 (organizational data):

Customizing data that is defined when the system is installed and seldom
changed. An example is the table with country codes.
Two further data classes, USR and USR1, are provided for the customer. These are for
user developments. The tables assigned to these data classes are stored in a table
space for user developments. In the following figure you can see tables assigned to
different data classes. The figure presents the tables in the ABAP Dictionary and in the
database.

Sap ABAP polymorphism in oops

Scenario Introduction
There are two ways to implement polymorphism a concept of Object oriented
programming using ABAP Objects. I make an attempt to explain each one of them with a
elaborate sample ABAP Report in which I will try to implement most of the concepts
related to polymorphism.
I have used elements of Object oriented programming in a report, which is written
following structural programming methodology.
Requirement: We take an example of a company, which makes and sells electronic
goods that it manufactures and retails through its various stores. It takes bulk sales order
and determines the price of each item sold according to the customer type. The
customers are of 3 types to keep it simple
1) First time customers: New customers, which are ordering from the company for the
first time. There is no discount given by the company
2) Regular customers: Customers which order products from the company from time
to time

3) Valued customer: Customers which order large quantities and have a=had a long
purchase history with the company
P.S. : The below code snippet makes certain assumption for the sake of enhancing the
stress on concept of Polymorphism. Hence standards like Data validation are not
followed.
Explanation: Most of the ABAP report starts with Data declaration and generally all class
and interface definitions are defined at the start of report.

Implicit Enhancement Options in ABAP Source Codes

Use
In ABAP programs, implicit enhancement options are predefined at the following places:

At the end of an include. There are some restrictions, for example, not at the
end of a method include.

At the end of a PUBLIC-, PROTECTED-, PRIVATE-SECTION of a class.

At the end of the implementation part of a class (before the ENDCLASS, which
belongs to CLASS IMPLEMENTATION).
At the end of an interface definition (before the ENDINTERFACE).

At the end of a structure definition (before TYPES END OF, DATA END OF,
CONSTANTS END OF, and STATICS END OF).

At the beginning and at the end of a procedure (FORM, FUNCTION,

METHOD). That is, after commands FORM, FUNCTION, and METHOD, and
before statements ENDFORM, ENDFUNCTION, and ENDMETHOD.

At the end of the CHANGING-, IMPORTING-, EXPORTING-parameter list of a

method. These enhancement options are located in the middle of a statement.
Enhancement Spots

Definition
The enhancement spots are used to manage explicit enhancement options.
Enhancement spots carry information about the positions at which enhancement options
were created. One enhancement spot can manage several enhancement options of a
Repository object. Conversely, several enhancement spots can be assigned to one
enhancement option.
Use
You create an explicit enhancement option when processing a Repository object with the
relevant tool by creating an enhancement spot element definition at a point where this is
possible. This enhancement option can then be called at different points using
enhancement spot element calls. The enhancement spot element definition and the

corresponding enhancement spot element calls make up the definition of an

enhancement option. For example, when editing an ABAP program with the ABAP
Editor, you can define explicit enhancement options in the form of the ENHANCEMENTPOINT statement, which also represents the element definition and element call.
Each enhancement spot element definition must be assigned to at least one
enhancement spot. For this, an enhancement spot element definition is assigned one or
more simple enhancement spots, which in turn are assigned to at least one composite
enhancement spot. Simple and composite enhancement spots are Repository objects
that form a tree-like structure, where the leaves and branches represent simple and
composite enhancement spots respectively. A simple enhancement spot is always
assigned to exactly one enhancement technology (ABAP source code enhancement or
BAdI).
Composite enhancement spots are used for the semantic grouping of simple
enhancement spots. A composite enhancement spot contains either one or more simple
enhancement spots and/or one or more composite enhancement spots of the relevant
type. You can use composite enhancement spots to combine simple enhancement spots
into meaningful units:

Diff between user exist and customer exist

Check these differences:
User exits (Function module exits) are exits developed by SAP. The exit is implementerd
as a call to a functionmodule. The code for the function module is writeen by the
developer. You are not writing the code directly in the function module, but in the include
that is implemented in the function module.
Customer exits are not available for all programs and screens found in the SAP System.
You can only use customer exits if they already exist in the SAP System.
Business add-ins are enhancements to the standard version of the system.
Business Add-In is a new SAP enhancement technique based on ABAP Objects.
They can be inserted into the SAP system based on specific user requirements.
Each Business Add-In has:

 at least one Business Add-In definition

a Business Add-In interface
a Business Add-In class that implements the interface
In order to enhance a program, a Business Add-In must first be defined
Subsequently two classes are automatically generated:
An interface with IF_EX_ inserted between the first and second characters of the BADI
name.
An adapter class with CL_EX_ inserted between the first and second characters of the
BADI name.
The Application developer creates an interface for this Add-In.
Hope this resolves your query.
Reward all the helpful answers.

What tools can be used to help with performance tuning?

ST05 is the performance trace. It contain the SQL Trace plus RFC, enqueue and buffer
trace. Mainly the SQL trace is is used to measure the performance of the select
statements of the program.
SE30 is the Runtime Analysis transaction and can be used to measure the application
performance.
SAT transaction is the replacement of the pretty outdated SE30. Provides same
functionality as SE30 plus some additional features.
transaction (part of ST-A/PI software component) is a combination of ST05 and SAT.
Very powerful performance analysis tool used primarily by SAP Support.
One of the best tools for static performance analyzing is (SCI). There are many options
for finding common mistakes and possible performance bottlenecks.