Performance Tuning

1. Expensive SQL statements and their consequences

This article answers the following queries:

What are expensive SQL statements?

What are the consequences of expensive SQL statements?

What factors to be considered to tune expensive SQL statements?

What are the transactions or tools available in SAP to identify expensive SQL
statements?

-----------------------------------------------------------------------------------------

A few SQL statements may reduce the performance of the database as well as the
SAP system. It is the responsibility of Basis administrator/ Database administrator to
identify those statements and action them accordingly.

Expensive SQL statements are caused by many reasons like

i) Bad programming

ii) Inappropriate use of functions of SAP (like not specifying proper selection criteria
while running reports)

Expensive SQL:

Expensive SQL statements are also known as expensive selects. Expensive

statements are those statements which cause more disk reads or buffer reads to the
database.

As a rule of thumb, the statements which contribute to more than 5% of total block
reads for answering are considered as expensive SQL statements

Consequences of expensive SQL statements:

A few expensive statements can hamper the performance of the SAP system. Few
consequences are listed below:

i) While an expensive SQL statement is being executed, as it has to fetch more

blocks, already existing blocks in the database buffer are displaced to accommodate
the blocks of this statement. This impacts performance of the other SQL statements
and could impact performance of following requests
ii) As database will be busy ready many blocks to satisfy expensive SQL statement,
there are chances of slowdown of other database tasks which eventually may
impact the performance of the SAP system

iii) While an expensive SQL is being executed, a work process is blocked till the
completion of the request. So, it is not available for other requests which increases
the wait time of other processes (like waiting in the dispatcher queue)

Factors to be considered to tune expensive SQL

It is not practically possible to tune each and every expensive SQL. So, we have to
identify the statements to be tuned based on the impact of those. Impact of
expensive SQL statements on the SAP system performance depends on many
factors like

i) On what frequency the expensive SQL is running?

(If an expensive SQL is running once in 6months, then it is acceptable to run but it
an expensive statement is running more frequently like 24 times a day then it is
worth tuning that statement)

ii) What is the time of expensive SQL execution?

(If an expensive SQL is running during peak load than it because more performance
issues leading to high response time and wait times to other processes/jobs. So it is
important to consider at what time these expensive SQL are being executed. It is
best to execute expensive SQL during periods of low work load on the system)

iii) Impact of the expensive SQL on the performance of the system

(It is worth taking note of the impacts the expensive SQL statement is creating on
the response time, throughput and performance of the system. Also the duration of
the performance problem also to be considered to figure out the impact of an
expensive SQL)

SAP transactions to identify expensive SQL

Based on the above factors, an expensive SQL statement can be selected for
tuning.

SAP provides so many tools or transactions to identify Expensive SQL statements.

Some of them are SM50, SM66, DBACOCKPIT, ST03, ST04 and ST05

2. Analyzing expensive SQLs using SM50/SM66

This article explains the following query :

How to analyze expensive SQL statement using SM50/SM66 ?

Go to transaction SM66 and have a look at the global workprocess overview.

i) Have a look at Action column and identify any long running Sequential
read/ direct read /insertion /updation etc.

ii) If so, please note the respective report that is being run and the table that
is being used for the same. From the report we can make whether it is SAP standard
report or customized report. If it is customized, we can take help of ABAPer to see if
the report can be finetuned in cases of bad programming. Table details can be used
to figure out the size of the table and whether statistics are upto date for the table
or not.

Please note : "Updatestats job should run daily so that system will have recent
statistics about all the tables. These statistics will be useful for Cost based optimizer
to identify optimized execution plan for an SQL statement"

iii) Also, please note the user who is running that process. So that, later user can be
approached and a trace(ST05) can be kept for his activity to understand his
transaction in detail which would help for fine tuning.

iv) SM50 transaction can be used to view the detailed display of the process and the
SQL statement that is being executed

For example, Please refer below screenshot of SM66 :

In the below screenshot,

i) Highlighted user is running ZFI_TDS* report on RBKP table in dialog mode and
sequential read action is happening on the same.

ii) User DDIC is running RBDMONI_* report (in background mode) on table BDCP2
and direct read is happening on the same. It has already consumed 783 seconds of
CPU time.
To analyze point i) scenario in the above case, please note the server name on
which this process is running. Go to that server through SM51 and have a look at
SM50 transaction.

Identify the respective PID of the process which you have suspected as expensive
SQL from the overview and double click on that process which opens up detailed
display as below:
3. How to activate a Trace for a user in SAP system ?

This article answers the following queries :

What are the different types of traces in SAP ?

How to activate a Trace for a user in SAP system ?

How to do performance analysis in SAP system ?

What are the different types of traces in SAP ?

SQL Trace (Trace for SQL statements)

Enqueue Trace (Trace for enqueue/lock requests, waiting etc)

RFC Trace

Table Buffer Trace

How to activate a Trace for a user in SAP system ?

Goto transaction ST05 and you will get the below screen :
Select the type of trace you would like to activate and press activate trace to start
tracing.

Please find below functionality of various functions in the above screenshot :

Activate Trace : This is used to activate the trace for the same user who is starting
the trace
Activate Trace with Filter : This functionality is used to trace the activity of a
different user(other than the user who is starting the trace) and filter can be done to
trace a specific transaction or program.
Deactivate Trace : This functionality is used to deactivate the trace
Display Trace : This functionality is used to display trace

Click on tick mark to display the trace

Click on Yes to display the trace as below:

Enter SQL Statement : This functionality is used to analyse an SQL statement

Click on this pushbutton to view the below screen :

Trace Status : This area is used to inform about the status of the trace at that
point of time like traces activated, deactivated etc
4. Identifying expensive SQLs using ST04 transaction

This article answers the following query:

How to identify expensive SQLs using ST04 transaction ?

As shown below, go to transaction ST04 and navigate to SQL statement analysis ->
Shared cursor cache
Double-click on the shared cursor cache while leads you to the following screen.
In the above screen, please provide Buffer gets as 50,000 for example and in the
List sort options select Buffer gets radio button and execute.

It displays all the SQL statements whose buffer gets are more than 50,000 and sorts
them in descending of buffer gets as shown below

As highlighted in the above screen, identify the top 5 or 10 statements as per buffer
gets. These are expensive or costly SQL statements.

Also look at executions column and figure out the value. If value is greater for
executions it means that the SQL is frequently getting executed and it is worth
tuning that statement.
Afterwards click on the corresponding SQL statement which opens the SQL
statement as below

In the above screen, click on explain icon (highlighted) which opens up another
window as below
In the above window, you can view :

Estimated costs to execute the SQL

Estimated rows to be fetched

Estimated CPU costs

Estimated IO costs

Ideally, all of these parameter values should be low for an optimized SQL statement.
For expensive SQL statements, these values will be of very high impacting system
performance.
Also, in the above window find out whether FULL SCAN is present. If present it
means indexing is not proper for the table involved in this SQL statement.

Please double click on the table name or index name which is going for full scan, to
view similar window as below :
In the screen, you can note Last statistics date. If this date is too old, it is
recommended
run update statistics for this table or index. This improves performance of the SQL
statement as it provides correct recent statistics so that execution plans for SQL
statement will be done properly.
Due to outdated statistics, execution plan wont be proper leading to high row
fetches, increasing CPU and IO costs.

5. Guidelines for activating a Performance trace

This article answers the following queries :

What are the guidelines to be followed for activating a performance trace ?

Guidelines for activating a Performance trace

1. If you are tracing a particular activity of a user, please make sure that the
particular user is not performing any other activity in the system. Otherwise
trace file will be difficult to analyze. For reasons of simplicity, please request
user to perform only one activity while the trace is activated.

2. Please make sure that no background jobs or update processes are running
in that SAP for that particular user whose activity is being traced. Otherwise
trace wont be clear

3. By default, SQL trace is selected in ST05 transaction. Incase you would like
to trace others( like RFC trace, buffer trace) please activate them also.

4. Normally we are interested in the buffer load processes that get recorded
while tracing an activity through SQL trace. Therefore, it is suggested to
execute the program or activity that is to be traced once before actually
tracing it so that all the buffer loads processes will happen. In the next run,
since buffers were already loaded SQL trace doesnt capture un-necessary
details related to buffer load which makes it easy to analyze the trace.

5. In cases of distributed SAP system, where there are number of application

servers then you need to activate the trace in the particular application
 server where the user is performing the activity. In other words, trace wont
get recorded if you activate trace in one application server and user is
performing the activity in another application server.

6. If you would like to record a trace for background job or for an update
request in a distributed SAP system, it is suggested to activate the trace in all
the application servers that are present in the SAP system. This is required
because you will never know to which application server the particular
request goes for execution.

If you are tracing an activity of any other user you can look at following monitors
during the trace :

Workprocesses overview (SM50/SM66)

Operating system monitor of Database server to identity any CPU bottlenecks

in database server)

Database process monitor for monitoring the execution of SQL statements

Profile parameter settings for Performance Trace (ST05):

Please note that trace cannot be taken for very long duration as the size of the
trace file is limited as set by SAP profile parameter. When the trace file is full, the
oldest entries are deleted or overwritten by the newest entries i.e. writing to the
trace file is cyclical.

The SAP profile parameter rstr/max_diskspace is used to set the size of the trace
file in a SAP system. The default trace file size is 16MB

For a trace file, default file name also can be set using the SAP profile parameter
rstr/file.
6. Memory allocation sequence to dialog work processes in SAP

This article answers the following queries:

What is the memory allocation sequence to dialog work processes in SAP?

When does a work process go to PRIV mode?

How to avoid or minimize work process going to PRIV mode ?

What are the SAP parameters used to define initial roll area, extended
memory, heap memory, roll area ?

Memory allocation sequence to dialog work processes in SAP :

--------------------------------------------------------------------------------------

1. Initially , a defined roll area is used. This roll area is defined by the SAP
parameter ztta/roll_first.

Usually ztta/roll_first is set to 1 in SAP so that only technically necessary amount is

allocated to roll memory.

If the memory from the initial roll area( i.e. ztta/roll_first) is not sufficient for the
user context then

2. Extended memory is used until the extended memory is full or until the user
quota is reached

Extended memory is defined by the SAP parameter em/initial_size_MB and the user
quota for dialog workprocess is defined by the parameter ztta/roll_extension_dia.

If this memory is also not sufficient, then

3. The rest of the roll area is used. This roll area is defined by SAP parameter
ztta/roll_area.

Once this is also fully occupied then

4. The system is forced to use local heap memory (Private memory). Then the
work process goes into PRIV mode

Heap memory is available until one of the following occurs :

i) Either the limit of the heap memory for dialog workprocesses is reached
(abap/heap_area_dia) or the entire heap memory of all work
processes(abap/heap_area_total) for an application server reaches its limit.

ii) Operating system limit for allocation of memory

iii) The swap space in the host system is used up or the upper limit of the
operating system address space is reached.

The memory allocation strategy for dialog work processes, aims to prevent work
processes from allocating R/3 heap memory and thus entering PRIV mode.

When a work process enters PRIV mode, it remains connected to the user until the
user ends the transaction. Most of the time, we should try to avoid the situation of
work process going into PRIV mode for better performance of the SAP system. This
can be done by optimally defining abap/heap_area_total parameter.

7. Memory allocation sequence to non dialog work processes in SAP

This article answers the following queries:

What is the memory allocation sequence to non dialog work processes

(background, update, enqueue and spool workprocesses in SAP?

What are the SAP parameters used to define initial roll area, extended
memory, heap memory, roll area ?

What is the memory allocation sequence to non dialog work processes in

Windows NT?

=================================================

Memory allocation sequence to dialog workprocesses is same in SAP for all the
platforms.

However memory allocation sequence to non-dialog workprocesses is bit different

based on Platform. In Windows NT, memory allocation sequence for non-dialog
workprocesses is same as that of dialog workprocess memory allocation sequence
in other platforms.
Memory allocation sequence to non dialog work processes in SAP as below (except
in windows NT) :

1. Initially memory is assigned from the Roll memory. Roll memory is defined by
SAP parameter ztta/roll_area and it is assigned until it is completely used up.

If the roll memory is full then

2. Heap memory is allocated to the non-dialog workprocess. Heap memory is

available until one of the following occurs :

Either the limit of the heap memory for non-dialog workprocesses is reached
(defined by the SAP parameter abap/heap_area_nondia) or the entire heap
memory of all workprocesses of an SAP application server reaches its limit
which is defined by parameter abap/heap_area_total

Operating system limits of allocating memory

The swap space in the host system is completely used up. However this
situation should not occur often which results in severe performance
issues.Please check swap space requirements for various platforms and
define swap space optimally to avoid this issue.

If all the above mentioned heap memory is completely used up then a non-
dialog workprocess can use the SAP extended memory defined by SAP
parameter em/initial_size_MB.