There are mainly 4 types of RFC communication in SAP. They are

  Synchronous RFC  Asynchronous RFC  Transactional RFC  Queued RFC

Synchronous RFC (sRFC) : In this type of RFC communication, the calling program waits until the requested processing step on the remote system has ended and then continues to work locally.

In other words, both the systems involved must be available at the time the call is made.

Asynchronous RFC (aRFC) : In this type of RFC communication, the calling program gives the request to the remote system and immediately continues to work locally. The requested processing step is executed on the remote system in isolation.

If the remote system cannot be reached at the time of the call, the asynchronous calls of the RFC client are lost

Transactional RFC (tRFC) : This type of RFC communication is similar to asynchronous RFC but by allocating a transaction id(TID) it guarantees that if a request is sent several times because of network problems it is processed only once. Unlike asynchronous RFC, in Transactional RFC the remote system does not have to be available at the moment the RFC client program start the call. The data is held in the source system until the target system is available.

The report program RSARFCSE is called in the background at regular intervals and tries to place the unsuccessful requests, identified by their transaction id again.

Queued RFC (qRFC) : This RFC communication is an extension to the transactional RFC. In this method, all the requests are queued up(inbound queue and outbound queue) and are processed in a sequence only if it is certain that all preceding calls are processed correctly. This method guarantees that all the requests are processed in the sequence in which they are received.

This type of RFCs will be used in SCM (APO) systems for CIF queues etc where requests have to be processed in an order.

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 cause 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 figureout 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

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"

ii) 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 finetuning.

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:

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

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

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 won’t 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 doesn’t 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 won’t 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.

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 to 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 won’t be proper leading to high row fetches, increasing CPU and IO costs.

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.