Category Archives: SAP transaction

SAP transactions/tools used in performance analysis

How to run SAP code inspector to do static ABAP performance check?

In my post “SAP project – Application Development Performance Control”, I mentioned we can validate SAP ABAP program performance via static performance check and dynamic performance testing. Static performance check and Dynamic Performance testing complements each other to make sure that program developed has good performance.  It is mentioned that we can use SAP code inspector (SAP transaction – SCI) to do static performance check on SAP ABAP program.   SAP code inspector can scan through an ABAP program source code line by line to identify common performance pitfalls.  In this post, I would share how to run SAP code inspector to do this. This post would cover.

  • .     Quick start on how to run SAP code inspector to do static code view,
  •     Details of steps of running SAP code inspector,
  •     Advanced way of running SAP SCI and
  •     Further info on SAP SCI, SQLM and SWLT tools.

1. Quick start on how to run SAP code inspector to do static code view on Single Object

  1.    Run SAP code inspector transaction SCI in any SAP window,

 2.   Go to “Create” inspection function by clicking “create” inspection button on the initial screen of code inspector,

 3.   Specify Single ABAP object or Single transport and a list of performance check attributes on the 2nd screen of code inspector,

4.     Execute the inspection by clicking  “execution button” on the 2nd screen,

5.     Review the inspection results.

2. Details of steps of running SAP code inspector

2.1 Run SAP code inspector transaction SCI.

To start SAP code inspector, I typed in SAP transaction code “/nSCI” in the command window of my SAP screen (as showed in following screen) and  hit “return” key to start the SCI transaction.

Figure 1 Start SAP inspector

2.2 Go to “Create” inspection function

Following the hitting “return” key in 2.1 step, initial screen of SAP SCI appeared.

Figure 2 SAP Code Inspector Initial screen

I clicked “create” button in Figure 2, then following screen appeared.

Figure 3 SAP code inspector – specification screen

Assuming that this was the very first time I run SCI in the system, I do not have any “check variant” created so I need to specify my check options manually by checking related boxes in Figure 3.

2.3 Specify Single ABAP object or Single transport and a list of performance check attributes

I need to do static performance check on an ABAP program. So I entered following data and unchecked “security check” options except “Performance check” in Figure 3 and I expanded “Performance checks” to show a list of performance items checked as Figure 4.

Figure 4 SAP code inspector – check on single ABAP object

2.4 Execute the check

I was glad with my input, then I clicked “execution” button( red circled in Figure 4)  to let the code inspector to do static performance check.

2.5 Review result of SAP code inspection

Upon completion of SCI execution in above step, SAP Code inspector displayed a result screen showed as in Figure 5.

Figure 5 SAP code inspector – checking result

SAP classifies the checking result into 3 classes – error, warning and information. SAP provides several features to help you navigate through the result screen – this is helpful many objects are collectively checked with many errors and warning.

In figure 5, static performance check on the code find no error but 4 warning.  To see details, I clicked “result list” button and I got following screen (Figure 6).

Figure 6 SAP code inspector – result list

I double clicked the program line in Figure 6 to see the corresponding ABAP source line related to  “Nested loops”

Figure 7 SAP code inspector – Detection of Nested Loop

With above information, I can discuss with ABAP developer on the concern and reach the decision on whether this should be fixed or exempted before the change can be moved to production.

So far, what I showed is a quick start to use SAP code inspector to do static performance check on a single ABAP object and review the result. This is good enough for one time check on single object (ABAP or transport request). But there are several limitations/disadvantages to run SCI this way:

  • SCI result would not be saved by SAP. You have to download the SCI result manually before you quite from SAP SCI transaction if you would like to keep the result.
  • You can check only single transport or single ABAP object during each execution,
  • You have to enter object name each time you need to check the ABAP object and
  • You have to specify the list of checks every time manually when you execute the SCI.  You can use existing check variant but you have no control on the check variant which you are not responsible for.

If I would like to refer to the static performance check result in the SAP SCI in the future, or I need another person to review the check result via SAP SCI, or I need to check a lot of objects, or if I always do the same set of checks and hate to click those options one by one every time, or is there any option to execute the check in background to avoid timeout or make execution faster when I have a lots of objects to check? Can SAP SCI allow me to do so? Yes, I called it advanced way of running SAP SCI.

3. Advanced way of running SAP SCI

SAP SCI provides several ways for you to define an object set which contains the ABAP objects to be checked. SAP SCI allows you to define a check variant to contain a list of check attribute you like to have so you can use it for similar check again and again. SAP SCI can save the inspection result if you give it a name during execution. SAP SCI provides “background” options to avoid timeout and “parallel execution” option to speed up the execution.

3.1 Define a check variant for regular checks you do normally

Most of time, I use SCI to do performance check and I normally focus on reading table without index, nested-loop, by-passing SAP buffer etc. I would like to create a SAP SCI check variant to contain the list of performance checks I need so I do not enter them every time in the future. 3 steps:

  1.        Name your check variant,
  2.     Select a list of checks you need and
  3.     Save your variant

I named my variant “ERIC_PERF_DB” (free text for all names in SAP SCI), then I clicked “create” button highlighted in Figure 8.

Figure 8 SAP SCI – name check variant

Following clicking on the “create” button, following screen showed up with a list of checks which I can choose from.

Figure 9 SAP SCI – a list of available check

If you would like to understand more about each checking category, you can click the Info button, SAP would pop up a screen to tell you what the check category is for.

Since I am interested in performance only, I checked following choices by clicking the white square “boxes”.

Figure 10 SAP SCI – choose check category and associated check attribute

I saved the “ERIC_PERF_DB” variant by clicking the “Save” button. You can see that my variant is to focus on SQL statements and targeted for programs which mainly spends runtime on database access. For such programs, it makes no sense for SAP SCI to check “low performance operations on internal tables” etc…

You can display, change, copy and delete an existing variant by clicking correspond buttons in the “check variant” section of SAP SCI initial screen.

3.2 Define a object set for SAP SCI check

If you would like to check a lot of objects repeatedly, it is tedious to enter each object every time you run SAP SCI transaction. If there are many objects in a package or in a function group etc. it is tedious to list each object in a package or a function group etc.  SAP SCI provides several ways to allow you to specify a set of objects to be checked together by SAP SCI transaction. Following are steps to define the object set.

  1.  1.    Name your object set,
  2.       Enter your object sets directly or adopt objects from existing object sets created by you or other people earlier you and
  3.        Save your object set.

I named my variant “ERIC _DB_EXTENSIVE_REPORTS”, then I clicked “create” button highlighted in Figure 11.

Figure 11 SAP SCI – name Object set

Following clicking on the “create” button, following screen (Figure 12) showed up with several tabs to give you a lot of options to allow you efficiently to specify objects.

Figure 12 SAP SCI – options for specifying check objects

Here, I am only going to check several programs. So I uncheck all options first, then I checked “Program” Options and click “arrow” button highlighted in Figure 12 to enter a list of objects.

Figure 13 SAP SCI – Sample ABAP objects

Figure 13 is a list of sample objects I specified, then click “continue” button, and SAP returned me to the Object set screen below.

Figure 14 SAP SCI – Objects specified

At last, I clicked “Save” button circled in red color in above Figure 14 to save my object set “ERIC _DB_EXTENSIVE_REPORTS”.

So far, I have defined check variant “ERIC_PERF_DB” and Object set ““ERIC _DB_EXTENSIVE_REPORTS” using SAP code inspector. It is time to run SAP SCI to do the needed checks specified in check variant against those objects through the defined object set.

3.3 Create SAP SCI inspection with a name for future reference

If you enter a “name” for SCI inspection, the SCI static checking result would be saved in SAP database upon completion so this can be reviewed using the name via SCI in the future.  When you have a big object set and SAP SCI returns a long list of result. You might need more than one person to review the SCI result as well. So naming an inspection has at least following benefits

  1.        Save the result for the future reference,
  2.     Separate SCI execution and result reviewing,
  3.     Allow several people to work on the long list of SAP inspection result.

I named my SCI static check or Inspection as “ERIC_CHECK_DB_EXPENSIVE_REP”, then I click create button highlighted in Figure 15

Figure 15 SAP SCI – advanced usage ‘name the inspection’

Following the click, I got following Inspection screen where I used option “object set” and entered the set I created earlier “ERIC_DB_EXTENSIVE_REPORTS” and Selected “ERIC_PERF_DB” check variant as showed in Figure 16.  You can use pull-down button to choose your options from a list.

Figure 16 SAP SCI – using object set and check variant

With specified “object set” and designated “check variant”, I click “execution” button circled in red in Figure 16 to kick off the inspection. After SAP code inspector finished checking/inspection, I got following result screen.

Figure 17 SAP SCI – result screen for named inspection

In Figure 17, you can click “button” circled in red color to review the inspection result. You can filter the result and sort result as well via buttons showed in Figure 17. The green button before the name of inspection indicates that SCI is executed successfully for the inspection.

3.4 Execute SAP SCI in background or using parallel solution

When there is a lot of objects to be inspected, the execution can be long. SAP SCI provides “execution options” to allow you to execute it online or execute it in background using parallel processing.

Figure 18 SAP SCI – execution options

I clicked the button circled in red in Figure 18.  I need to run the inspection in background job and via parallel solution controlled by the server group defined by RZ12, so I specified input based on my environment as showed in Figure 19.

Figure 19 SAP SCI – selected execution option

Number in red in Figure 19 indicates sequence of operations in executing the inspection via options.  Figure 20 shows the job name SAP SCI created in this case. The job name convention = CODEINSP_ + Inspection name + _Version.

Figure 20 SAP SCI – background job for inspection

Here, Server group and parallel processing is provided as an option to do static performance check. If you are interested, you can refer to my post on how to create SAP server group via RZ12 and refer to my post on general introduction on SAP parallel processing.

4. Further info on SCI, SQLM and SWLT

You properly noticed that static performance check on ABAP code is just one of checks offered by SAP code inspector. You can do other checks in the same fashion I mentioned here for performance check. SAP code inspector is focusing coding technique not logic. So it would not tell you logic/design issue – like you execute a operation at sale order line item level while the operation only need to execute once for one sale order.

ABAP code review for static check can be done manually but manual check has many disadvantages like cost, inconsistent result and painful.

SAP code inspector is integrated with SAP object creation and editor tool like SE11 – data dictionary, SE38 (ABAP program editor), SE37, SE24 (class builder) and etc. As a developer, you can call SAP code inspector in the tool to do static check directly. Such check is done via “Default” check variant defined by the developer. For example, SAP developer can invoke the code inspector to do static check from the same SE38 screen where code changes are made.

SAP code inspector is doing a static check based on a predefined set of criteria. It has no information on actual usage of ABAP code in production environment or how big a table is… Due to business changes, a code which is executed frequently might be obsoleted over time.  You do not spend effort on an  obsoleted codes due to code inspector complaining … for that purpose, SAP has introduced another tool SWLT to integrated code inspector result with SQL usage information from SQL monitor which might help drive priority of fixes some times.  In my understanding, SAP SWLT and SAP SQLM is targeted for Hana migration and Hana environment. I would cover SAP tool SWLT and SQL monitor in the future.

Explanation of SAP STAD Single Statistical Records/data

SAP STAD is one of my frequent used SAP transactions in performance analysis. STAD can show you where the time is spent over a list of technical components involved in a job/program execution, so it is often 1st step I would take to review performance of a program/transaction which finished recently. Following my previous post how to run and navigate through SAP STAD transaction, I would share my understanding of STAD data – that is the basis for you to use STAD to do performance analysis.

  1. Structure of STAD statistical data,
  2. Explanation of STAD statistical data and
  3. How to use STAD for performance analysis.

1 Structure of statistical data of a SAP transaction step

SAP has collected various statistical data to record performance of various technical components involved in executing a transaction step. To facilitate performance analysis, SAP groups statistical data into one main record and many optional sub-records. Whether a specific type of optional sub-records exists depends on context of transaction step and system parameter setting (see my post how to run ST03N) Following are the statistical sub-records I often deal with in my SAP environment:

  1. DB (sub records) – Statistical data related to database operations performance in a transaction step.
  2. DB procedure (sub-records) – Statistical data related to execution of database stored procedure in a transaction step. This is more important for SAP SCM boxes where LiveCache is used.
  3. Table (sub-records) – show most expensive tables accessed in the transaction step according to setting /stat/tabrec.
  4. RFC (sub-records) – show overview of RFC statistics from RFC client, RFC Server, RFC Client destination and RFC server destination sub-records according to setting /stat/rfcrec.
  5. Client Info (sub-records) – show origin of transaction step like job name, program name and system name.

Main record for statistical data of a single transaction step is like header record of a SAP business document. Main record contains statistical data related to time profile of transaction step, task and memory information and data volume involved in the transaction step. Sub-records are like details lines of a business document. One business document can have only one line of header record with 1 or more lines of detail records.

One execution of program can have more than one transaction step. SAP performance analysis normally focuses on the most expensive steps.

2
Explanation of STAD statistical data

SAP single statistical record has main records and many sub-records. SAP provides “corresponding buttons” in STAD detail screen to help you locate information of SAP statistical main record and sub-records quickly. Table 1 lists some frequent-appeared buttons showed in my SAP environment.

Button

Related statistics

Time

Time profile of transaction.

DB

Database time breakdown according to type of database operations.

DB Procedure

Details on procedures calls to LiveCache.

Task/Memory

Show memory usage at the end of step.

Table

Database time – table profiles.

RFC

RFC statistics for RFC client, RFC Server, client destination and/or server destination sub records.

Bytes

Data transferred to application.

Client Info

Origins – user, job, server which the transaction step belongs to.

Table 1 SAP STAD – navigation buttons

When a corresponding STAD sub-record exists, a related button would show up in SAP STAD Detail screen. Other buttons like “HTTP” other than what listed in Table 1 are not covered in this post.

2.1 SAP STAD – Time Profile of a Transaction Step

Top of SAP STAD “Single Statistical Records – Details” screen is the section of Analysis of time in work process section similar to Figure 1. You can back to the time profile screen by clicking “Time” button from other STAD details screens.

Figure 1 SAP STAD – Analysis of time consumption

Figure 1 is related to an individual statistical record of background step. Response time in Figure 1 is actually job duration which you would see in SM37 when the program (RMMRP000) is the only step of a background job. In Figure 1, all time components listed in “Response time” box are independent/exclusive.

Response time
= wait for work process time + Processing time( ABAP) + Generation time + Load times + Roll times for rolling in work data + Database time + Enqueue time for logical SAP locks + Roll wait time (not including task types RFC/CPIC/ALE). When DB procedure is used between application server and liveCache, a new component as “DB procedure” would be added to the Response time.

For dialog task, response time is measured at SAP application server from time when a request is received by the SAP application server to the time application server finishes processing and sending data to the client. Please note – Response time starts to tickle from the moment request is arrived at application server not the moment the request is sent by an user and it stops tickling at the moment when the application finishes processing and the last transfer of data from the application server to client is sent. The time used to send request to SAP application server and time used in sending last info back to client is not part of STAD response time but it is a part of end user’s online experience. Network and client impact on dialog user response time can be measured by GUI time and Net time (Figure 1 – right bottom corner under Frontend).For other tasks, Frontend statistics(GUI and Net time) is not relevant any more.

CPU time is not a separate time components but a sum of CPU utilization of each corresponding operation listed in “Response time” like ABAP processing, Program/screen load and generation, Roll-in and Enqueue operation except Database operation.

RFC+CPIC time: time spent by all RFC calls (as a client) in the transaction step. So this time can be bigger than response time if several long asynchronous RFC calls are initiated in parallel.

Wait for work process – time which the transaction step is put in the queue due to shortage of work process to the time when a free work process is available to execute the transaction step.

Processing time – time used in execute ABAP/IV statements.

Database time – time used by database to execute needed database operations like reading table changing existing table data or inserting new data into table. Database time is measured at application server side so it includes network time between application server and database server when applicable. So network latency can impact transaction performance when SAP server/instance used in executing the transactions is from a different server where database is in. Time used in reading data from buffered table at application server is not a part of “Database request time” but part of processing time. Time used between application server and liveCache (SAP SCM) is not part of Database time here.

For all other fields in Figure 1, you can get SAP online explanation in the transaction by placing the cursor into the corresponding data and click “F1”.

In normal ECC environment, significant time components of response time is processing time, database time and Roll wait time (when Synchronous RFC is used). Load time, generating time should be very minimal or zero—otherwise, this can indicate memory issue either setting or physical limit or there is a CPU contention.

After analysis of response time profile, you can navigate to specific time component/sub-record should you need further details.

Checking time profile of a transaction is often the first step of reviewing a business transaction/job performance. This can quickly point to area you should focus in SAP program/transaction performance analysis.

2.2 SAP STAD – Analysis of ABAP/4 Database Request

Click “DB” button in STAD details screen would bring you to screen similar to Figure 2.

This section breakdowns database time into different database operations so you can see individual database operation’s contribution toward database time and their performance.

Figure 2 SAP STAD – Database time breakdown on type of ABAP request

For details explanation on individual field in Figure 2 screen, please click corresponding data and use “F1” key to get SAP online document.

2.3 SAP STAD – Analysis of Table Access

This is to breakdown database time according to tables involved – showing types of operations on a particular table in a transaction step and how much time the transaction step has spent on the particular table. A program might has accessed many tables. For performance reasons, not all tables accessed in the transaction step but up to value specified by SAP online parameter stat/tabrec. Default setting is 5 which is enough for performance analysis.

Figure 3 SAP STAD – Database time breakdown on tables

Dir reads are referring to read table via full primary key. Other type of table reads are sequential read. Changes includes update, insert and delete database requests.

2.4 SAP STAD – Analysis of Remote Functional Call

When a transaction is a RFC step itself or when a transaction step has initiated at least one RFC call, then at least one RFC sub-records exists with the transaction step by default. You can click the “RFC” button to review RFC sub-records. You might get display similar to Figure 4.

Figure 4 SAP STAD – RFC calls over view con

Figure 4 screen is a RFC overview screen of a transaction step. It has two portions – client and server. Dependent on the step, you might see Client portion or server portion only. RFC Client shows 5 connections involved 3 destinations are having total 98 client call with calling time of 3,150 ms and execution time 2,713. RFC Server portion shows 1 connection to 1 destination has executed only 1 RFC call with call time of 27,368 ms against remote execution time of 27,367ms.

Fields

Explanation

Connections

Number of connections between client and server system.

Destination

Number of distinct destination from RFC client/server destination sub-records – Destination indicates the system where the call is sent to by the client. Destination is normally an entry which is configured in SM59 in the client system where the RFC is initiated.

Users

Numbers of distinct users from Client/Server destination sub-records.

Calls

Sum of number of Calls from Client/Server destination sub-records – For RFC client, this is number of calls made to the server. For RFC server, this is number of calls executed in the box where STAD is run.

Calling Time

Sum of calling time from Client/Server Destination sub-records. The time includes network connection/traffic time.

Remote Execution

Sum of remote execution time from each Destination sub-records. Time spent in executing the RFC in server side.

Idle

Sum of idle time between two RFC calls when connection is open.

Sent

Sum of Data sent to server for client call or Data sent back to client for server process based on RFC client/server destination records

Received

Client – Sum of Data received from server; Server – Sum of data received from client. All data are sourced from client/server destination sub-records

Table 2 SAP STAD – RFC Overview fields explanation

If you can click each highlighted fields on figure 4, you can see available SAP statistics for RFC client, RFC client destination, RFC server and RFC server destination sub-records.

2.4.1 RFC Client Destination statistics

You click the highlighted number in the “Connections” field of client portion of STAD RFC overview screen, you would see 1 more client destination record similar to Figure 5.

Figure 5 SAP STAD – RFC client destination record details

A RFC client destination have information:

  • RFC type – synchronous(wait) and asynchronous(non-wait). Here is Synchronous.
  • RFC user name – SAP user account used to execute the RFC call. Here is bgomusr.
  • Destination – Where the RFC is going to be executed. Here is CC*USD.
  • Instance and IP address– The server where the RFC call is requested and its’ IP address.
  • Partner instance and IP address – The server where the RFC call is executed and its’ IP address.
  • Calls – number of RFC calls made to the destination at the transaction step.

Please refer to above table for Explanation for other fields like Calling time and etc.

Name of Destination is normally configured in SM59 except some SAP internally reserved destination name. Name of instance is what you can see in SM51 for SAP system. Calls is total number of call made over the connection to the destination. Calling time, Remote Exec time and idle time is sum of corresponding time from each calls over this open connection to the destination. Data send/receive time together with size of sent/received data are sum of corresponding data from each calls over this open connection to the destination as well. You might see SAP “transaction code” field as well in client destination sub-record when applicable.

2.4.2 RFC Client statistics

You click the highlighted number in the “Call” fields of client portion of STAD RFC overview screen, you would see 1 more RFC client sub-records similar to Figure 6.

Figure 6 SAP STAD – RFC client record details

RFC client shows

  • Call number – RFC call sequence. Here is 1 – means FM XIPAY_CC AUTHORIZATION is the 1st call to the destination CC*USD.
  • Destination – where the FM XIPAY_CC_AUTHORIZATION is executed. Here is CC*USD.
  • Function name – Name of Function module which needs to be executed by the server. Here is XIPAY_CC_AUHTORIZATION
  • Calling time – Duration of RFC call from begin to end as seen from the client side. Here is 2,647ms
  • Remote Exec.time – Time needed to execute FM XIPAY_CC AUTHORIZATION in the destination. Here is 2,501ms.
  • Idle time – Sum of idle time between two RFC calls. Here is 0 ms.
  • Data send time – time needed to send data to Server. Here is 980 bytes
  • Date receiving time – time needed to received data from Server. Here is 1,615 bytes.

The Destination might be a different SAP server/system but it could be the same server/system where SAP transaction STAD is executed.

2.4.3 RFC Server Destination statistics

You click the highlighted number in the “Connections” field of Server portion of STAD RFC overview screen, you would see 1 more server destination record similar to Figure 7.

Figure 7 SAP STAD – RFC Server destination sub- record

A RFC Server destination record shows

  • Caller user name – SAP user name which is used to start the RFC call. Here is bgomusr.
  • Caller client number – SAP client number of the system where the RFC call is started. Here is 4*
  • Destination – The system where the RFC call is executed.
  • Instance and IP address – specific server of the destination where the RFC call is executed and its’ IP address
  • Partner instance and IP address – The server where the RFC call is requested and its’ IP address.
  • Calls – number of calls made to the destination at the transaction step.

Other fields have similar explanation to what we have in client destination. You might see transaction code as well. Execution of the transaction led to execution of the RFC call to the destination.

RFC Server destination is to track total number of RFC calls which the server processes. There might be various remote function modules being called. So it does not make sense to track function module in this context.

2.4.4 RFC Server Call statistics

You click the highlighted number in the “Call” field of Server portion of STAD RFC overview screen, you would see 1 more Server destination record similar to Figure 8.

Figure 8 SAP STAD – RFC Server Sub-record

A RFC Server sub-record shows

  • Call number – RFC call sequence. Here is 1 – means FM APPLICATION_IDOC_POST_IMMEDIAT is the 1st call to the destination *01
  • Destination – where the FM APPLICATION_IDOC_POST_IMMEDIAT is executed. Here is *01.
  • Function name – Name of Function module which has been executed. Here is FM APPLICATION_IDOC_POST_IMMEDIAT.
  • Calling time – Duration of RFC call from begin to end as seen from the client side. Here is 27,368 ms.

Please refer to RFC client statistics for explanation on remaining fields.

The destination is one of SM59 configuration in client system which might be the different system from where the remote function module was executed. This indicates that you might not find destination configured in the system where you run STAD.

Last not least on STAD RFC statistics, I would like to mention controls which SAP has in place to limit number of RFC sub-records a transaction step should keep. One transaction step can make many RFC calls to many destinations. For performance reason, SAP does not generate a RFC sub-record for each Function called and for each destination involved. SAP online parameters stat/rfcrec is used to control number of RFC sub-records a transaction is allowed to keep. The Default setting is 5. When more than 5 RFC client calls are initiated from a transaction step, SAP would only keep statistics for the 5 most expensive RFC calls. When more than 5 destinations (actually connections) are involved in RFC calls in a transaction step, SAP would only keep statistics for 5 most expensive client destinations. The same goes with RFC server and RFC server destination statistics. A RFC call is more expensive if execution time is longer. Since the 5 most expensive calls are captured, those statistics are enough for RFC performance analysis. Increasing /STAT/RFCREC parameter could be dangerous to workload collector performance. It might impact system performance due to larger workload resulted from increasing this parameter.

2.5 SAP STAD – Task and Memory information

Clicking “Task/Memory” button, you would see screen similar to Figure 9.

Figure 9 SAP STAD – Task and memory information

Task and memory information sub-record shows

  • Terminal ID –Only available for SAP DIALOG work process. When it is available- it is either a name of an end user device like a computer name, IP address or server name from which the transaction step is initiated. RFC call, HTTP request, ALE and Dialog requests are executed in SAP via SAP dialog work process. Place your cursor at the terminal field, and process F1, you can see following standard SAP document “Name of the terminal or presentation server from which the dialog step was initiated and to which the
  • Terminal In/Out message: SAP online document “Number of Bytes required by the presentation server (terminal) for communication to and from the dispatcher work process to control the dialog.” Apparently, this field makes sense for Dialog request and HTTP request etc. but not make sense for RFC/ALE and background tasks. When dialog transaction is executed over a poor network connection or poor SAP GUI performance, large terminal in/out message can impact performance.
  • Work Process No: The number of SAP work process used to execute the transaction step.
  • Trans. – ID: a SAP internal assigned ID used to locate each specific execution of a SAP transaction or program. All steps of a specific executed program/transaction would have the same transaction-ID. All RFC child processes launched from the same transaction step with the same function module would bear the same transaction id even it is different from the parent program and each of them is having different session-id.
  • Session-ID: a SAP internal assigned ID used to locate a specific session where the transaction/program is executed. For GUI, each SAP GUI window is a session which has its own session-ID, All dialog transaction steps executed in the same SAP GUI window would have the same session-ID.

Terminal ID and session-id is used to locate the device/gui related to a transaction step of an online transaction, for background job, this would be replaced by job name. Transaction-ID is used to identify all steps/activities of an execution instance of SAP transaction/program. When a program is executed, one or business document can be created or changed.

SAP performance analysis normally focus on cutting runtime and increasing throughput. I did work several cases on cutting memory usage of customized ABAP program/transaction. But I found memory information from this tab is less helpful comparing with information stated in previous sections. I encountered cases where memory usage stated in STAD was much smaller than what it was reported by SM50. Apparently, SAP STAD cannot tell you how long a certain memory is occupied by the system etc. I normally use SAP tool /SDF/MON or SM50 to monitor memory usage of a transaction/process which gives a better picture of memory utilization over course of transaction/program execution.

2.6 SAP STAD – Bytes Transferred

This is to show size of data requested by SAP application to run the transaction step.

Figure 10 SAP STAD – Application data volume

 

2.7 SAP STAD – Client Info or Extended Passport

Here “Client” means the parent which is responsible for generating the transaction step which is different from RFC client which show what RFC call is started by the transaction step.

Figure 11 SAP STAD – Client info

This screen is telling you a lot of information about parent of the transaction step you are reviewing. Above screen shows that transaction step is result of executing a batch job – “S2C-OA_US_REPROC_ST64_ORD_SINGLE” under user “BGOMUSR” from system/server “*00”. All transactions executed by the same user from the same SAP GUI window has the same root context. All steps of a SAP job has the same root context as well.

In my version, system ID and server information are determined during the job creation. When SAP system is migrated, the old server name is still showed unless the business job is deleted and recreated via SAP transaction SM36 etc. after system migration.

3 SAP STAD and performance analysis

At the beginning of the post, it is mentioned that SAP STAD is used to review statistical data of a recent transaction. What can be considered “recent”? This is defined by system parameter stat/max_file. SAP stores stats hourly at OS level which can be overwritten after number of file reach what STAT/MAX_FILE specifies. Where the stat file is stored is controlled by another parameter stat/file.

At this point, hope this post has helped you to get a better understanding of SAP single statistical records. In my future post, I might share tips on how to use STAD for performance analysis and how SAP STAD tools can work with other tools in SAP performance analysis.

How to run SAP transaction RZ12 to configure RFC server group

My previous post, “SAP Parallel Process Introduction“, mentions parallel process can be implemented via SAP background process or SAP dialog process as well as factors which should be considered when we design a parallel solution. When parallel solution is implemented via SAP dialog process, SAP server group is the typical SAP solution used to control resource allocation. Resource allocation includes which server/instance of a SAP system should be engaged and how many “dialog work process” from a SAP instance can be engaged during an execution of a parallel solution. This post would walk you through technical steps on how to use SAP transaction RZ12 to configure and maintain a SAP RFC server group.

  1. How to start SAP RZ12 transaction,
  2. How to run SAP RZ12 transaction to create a new server group?
  3. How to run SAP RZ12 transaction to change existing server group?
  4. Understand SAP RFC Server group quota/resource parameters and
  5. Verify RZ12 RFC server group resource change.

1. How to start SAP RZ12 transaction

You can type “/nRZ12” in the SAP command/OK window to start the technical process of creating RFC server group. After you enter the code “/nRZ12” and press return key, you would see initial RZ12 screen similar to Figure 1.

Figure 1 SAP RZ12 initial screen

From RZ12 initial screen, you can do following

  • Create a new SAP RFC server group,
  • Add a SAP instance to a SAP RFC server group,
  • Change a SAP instance’s RFC quotas/resources on the fly
  • Remove a SAP instance from a SAP RFC server group and
  • Remove a SAP RFC server group and a SAP instance from all SAP RFC server groups.

2. How to create a new SAP RFC server group

A new parallel solution is developed and a new server group is needed. Before you run SAP RZ12 transaction, the server group details like which and how many instance the server group should contain, how many dialog processes is needed etc. should be decided together with server group name. How to understand those RZ12 screen fields/RFC quota parameters is discussed in subsequent section of this post.

Here I would create a new server group “1_order” which would engage two instances/servers.

2.1 Start to create RFC server group

You can click the “create” Icon to create a new server group as showed in figure 1. You would get a pop-up screen similar to figure 2 for you to enter sever group details

Figure 2 Blank RZ12 Server group data screen

2.2 Enter RZ12 RFC server group detail

Based on your parallel solution need and your SAP environment, input to all fields in figure 2 should be decided. Let’s assume following inputs are entered.

Figure 3 SAP RZ12 server group input

Click “copy” button, you would see initial screen of RZ12 again but with the new server group “1_order” as showed in figure 4.

Figure 4 SAP RZ12 new server group creation 1

Now the above process is repeated to add another instance to this server group “1_order”. So the RZ12 sever group “1_order” is as showed in Figure 5.

Figure 5 SAP RZ12 new server group creation 2

If you are satisfied with your changes, you can click the “save” button in Figure 5 to save your changes. Make sure that SAP system message “Changes saved” is appeared after you clicked “Save” button. If you exit RZ12 transaction without save, your changes would be lost.

Please take note, you can only need to enter “sever group name” and “instance”, you can use instance default setting for remaining fields. To do this, you can click “copy” button in Figure 3 without entering “RFC resource parameters”, then click “Yes” on pop-up window similar to Figure 6. If you click “No”, then those RFC parameters would be left “blank”.

Figure 6 SAP RZ12 server group – copy default data

It might be efficient to copy instance default value for RZ12 fields and make additional changes on top of that. If you are using different value from what specified in instance parameters, then the parameter in the instance profile should be updated accordingly in another time. Otherwise your RZ12 value would be overwritten by instance parameters upon SAP instance/server reboot. Your changes to SAP RZ12 parameters become effective upon save. Those RFC resource parameters in RZ12 can be changed dynamically.

3 How to run SAP RZ12 transaction to change existing RFC server group.

3.1 Add new SAP instance to an existing RFC server group

This is similar to creation of new server group. You just need to click expected server group once then click the “creation” icon in the RZ12 initial screen.

3.2 Remove a SAP instance from an existing server group

To remove an instance from a server group, you can click the instance of a group which you would like to remove, then click the “Delete Assignment” button in figure 1. Here, I clicked server “b*10” entry in “1_order” group first, then I click the “Delete Assignment” button, then following screen showed up

Figure 7 RZ12 server group – remove instance

Click the “delete” button in Figure 7, you would back to RZ12 initial screen reflecting your changes, which actually gave me the same screen I had in Figure 4. If you are ok with your changes, you can save your changes now by clicking the “save” button before you exit. All RZ12 changes are not automatically saved by the system.

3.3 Change SAP RFC resources/quotas dynamically

RFC resources change is at instance level. All server groups would share the same RFC resources/quotas for the same server/instance. All RZ12 resources/quota changes are dynamic changes and it can be lost upon system reboot. If your changes are going to be permanent, you need to update the corresponding RFC parameter in the instance profile to reflect RZ12 change.

To change a resource, you can double click on any entry which contains the expected instance. Here I double clicked “B*04” instance in the initial screen, Figure 8 screen appeared

Figure 8 RZ12 Server group – change RFC resources

You can make expected changes in Figure 8. The typical change is to increase or reduce data showed in “Max. Number of WPs Used (%)” and “Minimum Number of Free WPs” fields. After you changes, you can click “copy” button in Figure 8, that brings you back to initial screen where you can save your changes.

3.4 Remove a SAP RFC server group and remove a SAP instance from all RFC server groups

To remove a server group, you can click any entry of the server group in the initial screen, then click “Delete Group” button, then the entire group is removed from RZ12.

Sometimes, an instance might be removed from the system. so this instance needs to be removed from all existing server groups in the system, to do that, you need to click “Remove Instance” button , provide instance name in following window , then click “delete” button

Figure 9 RZ12 server group – remove instance

As usual, your changes would only come into effect after you click “Save” button.

4 Understand SAP RFC Server group quota/resource parameters    

Up to now, we have gone through the process of maintaining RFC server group. Here I would like to help you to understand what those parameters mean. Please refer to following chart to understand RFC parameters

Table 1 SAP RZ12 RFC quotas/parameter explanation

Screen Field Explanation Associated Profile Parameter Example
Activated (0 or 1) 0:  Routine for resource determination is deactivated
1:  Routine for resource determination is activated. You should always use 1.
Rdisp/rfc_use_quotas
Default value: 1
 
Max. Requests in Queue (%) The maximum number of waiting requests in the dialog queue of the dispatcher based on number specified by rdisp/elem_per_queue. This is to ensure that system is not overloaded further when queue has been built up.
When number of waiting requests hits this quota, then No more parallel process can be started.

 

Current queue length can be checked via menu Goto ->Server name -> information-> queue information in SAP transaction SM51.

rdisp/rfc_max_queue
default value: 5

5 means 5%.

Assume rdisp/elem_per_queue = 2,000 (SAP default) and rdis/rfc_max_queue = 5 , then no more parallel process can be started if number of waiting request is 100 (2,000 X 5%) or more.
Max. No. of Logons (%) The maximum percentage of logons to this instance (maximum total number rdisp/tm_max_no) that can be due to asynchronous RFCs. The remaining % is the reserved for non-RFC users like dialog and HTTP users. So those operations are not impacted by RFC.
Every RFC is linked to a logon in the targeted instance/server. When number of active logons hits this quota, then No more parallel process can be started.

 

SAP transaction SM04 can be used to display logon – one entry in SM04 screen is counted one logon in this view.

rdisp/rfc_max_loginDefault value: 90

90 means 90%

Assume rdisp/tm_max_no = 200(SAP default) and rdisp/rfc_max_login = 90, then no more parallel process can be started if number of RFC logon showed in SAP SM04 transaction is 180 or more for this instance.
Maximum No. Separate Logons(%) The maximum percentage of logons to this instance (maximum total number rdisp/tm_max_no) that can be due to the asynchronous RFCs of one user. User is referring to USERID. If you are sharing same logon with different people, all logons are counted under one user.
When number of active logons for a user hits this quota, then user cannot start RFC process anymore.

SAP transaction SM04 can check active logons.

Rdisp/rfc_max_own_loginDefault value: 25 Assume rdisp/tm_max_no = 200 and rdisp/rfc_max_own_login = 25, the no more parallel process can be started for a particular user after # of logon under the user is 50 or more.
Max. Number of WPs Used (%) The maximum percentage of the dialog work processes that can be occupied by one RFC user session or a single job.
 

SAP transaction SM50 can be used to check active SAP work process.

 

SAP parameter rdisp/wp_no_dia shows # of dialog work process in an instance.

rdisp/rfc_max_own_used_wp
Default value: 75
Assume rdisp/wp_no_dia = 50 and rdisp/rfc_max_own_used_wp = 75. Then no more parallel process can be started if # of concurrent dialog process used by the parallel session has reached 37 ( 50 X 75% = 37.5 ).
Minimum Number of Free WPs Number of dialog work processes that cannot be occupied by RFCs. At least this number of dialog work processes is therefore reserved for dialog users to avoid RFC processing impact online user activities. When number of free dialog work process is equal or less than this number, no more RFC call can be started in the instance/server. SAP transaction SM50 can be used to check number of free dialog process in an instance.
Total number of available dialog work process for RFC = rdisp/wp_no_dia – rdisp/rfc_min_wait_dia_wp. Number of available dialog work process for RFC in the instance should be bigger than quota specified by rdisp/rfc_max_own_used_wp.
rdisp/rfc_min_wait_dia_wp
Default value: 1
Assume rdisp/wp_no_dia = 50 and rdisp/rfc_min_wait_dia_wp = 10. Then no more parallel process can be started if number of free dialog work process showed in SM50 is equal or less than 10.
Total number of work processes which can be used by RFC call is 40 (50 -10 = 40).
Max. No. of Comm. Entries (%) the maximum percentage of communication entries of an instance (rdisp/max_comm_entries) may be occupied by parallel RFCs. You can review current active # of communication entry via menu path “Goto ->Server name -> information-> Communication Table” in SAP transaction SM51. This is to ensure that there is enough free communication entries in the instance.
When Number of entry in communication table is bigger than the quota specified by this parameter, then No more parallel process can be started.
rdisp/rfc_max_comm_entries
Default value: 90
Assume rdisp/max_comm_entries = 500 and ridsp_max_comm_entries = 90, then no more parallel process(RFC call) can be started if number of entries in the communication table reaches 450( 500 X 90%).
Max. wait time The maximum period of time in seconds which system waits for subsequent check when resource is not available after load check in the system.  The wait time is calculated dynamically using following formula –
wait = min (max(1,count-quota), max_wait). The count is number of used resources which are specified in above parameters like dialog process, communication entries, and quota is the resource requirement specified by the RFC parameters. Few resources that are available, the longer the wait time up to Max_wait.

You can increase the wait time to accept a longer wait time when there is a resource bottleneck.

rdisp/rfc_max_wait_time
Default value: 10
Assume the same quota as above and rdisp/rfc_max_wait_time is 10 seconds. If there are 455 communication entries, then the wait time would be 5 seconds.
Wait = min( max( 1, 455 – 450), 10). For 458 entries, wait would be 8 seconds, if active entry is above 460 seconds, then the wait time would be 10 seconds.

 

In table 1, all fields with % are percentage number. For most of SAP RFC quotas, we normally use SAP default data. The often changed fields are rdisp/rfc_max_own_used_wp and rdisp/rfc_min_wait_dia_wp. Rdisp/rfc_max_own_used_wp specifies how many concurrent dialog processes a single job/user-session can engage at the same time. This should be determined based on actual performance of the business transaction/process, projected volume growth and the business performance goal for the transaction/process. I would suggest that we do not give more parallel processes than what business really needs. More parallel processes means more risk – any bug(now and future) in the solution would be amplified. In most cases, there is no linear performance improvement with added parallel processes. A parent job can launch child process which can launch it’s own RFC call some times. So higher degree of parallel process can create higher risk where resource lock( work process level lock) among RFC calls due to resource shortage can occurs. a higher value for parameter rdisp/rfc_min_wait_dia_wp instead of SAP default value 1 should be selected so online user’s experience are not impacted by possible activities. Of course, this is not an issue, if your RFC solution and online users activities happened in different hours…

In Summary, RFC quota parameters specify quotas in

  1. Caps on how many ARFC logons in an instance – no more aRFC is allowed in the instance if the caps is reached.
  2. Caps on how many ARFC logons by a single SAP user – no more aRFC allowed in the instance if this cap is reached.
  3. Caps on how many requests in a dispatcher queue in an instance – no more aRFC is allowed in the instance if this caps is reached.
  4. Caps on how many communication entries should be exist in an instance – no more aRFC is allowed in the instance if this caps is reached.
  5. Caps on how many parallel work processes a single execution of program/transaction can engaged – no more aRFC is allowed if this caps is reached.
  6. Caps on how many dialog work process should be kept free for online activities at least– no more aRFC is allowed if this caps is reached.

If a SAP instance of a SAP RFC server group is “passive”, then the instance would not be engaged in parallel solution. However, MRP job can still engaged “passive” SAP instance for parallel processing as long as the passive server is set up in SAP transaction OMIQ in the SAP version I am working with. SAP transaction SM51 can be used to check SAP server/instances status.

Again, those parameters are at instance/server level not at RZ12 RFC server group level. If you are using different value other than what specified in SAP instance profile. Please remember to update the SAP instance profile before the instance is rebooted so your changes are not lost.

5 Verify RZ12 RFC server group resource change

You can use SPBT to verify your SAP server group RFC resource quota configuration. To do this, you can run SAP transaction SPBT, then do following

  1. Enter SAP RFC server group you would like to check
  2. Click on “Init PBT Env.” Button
  3. Review the result to see whether it is what you expected in terms of instance engagement and number of concurrent dialog processes can be engaged by a single job/user session.

 

Figure 10 SPBT validate RFC resources

In Figure 10:

  • Max. WPs = rdisp/wp_no_dia – rdisp/rfc_min_wait_dia_wp. SAP Instance level
  • Free wps = rdisp/rfc_max_own_used_wp * rdisp/wp_no_dia / 100
  • Total Wps = Sum of Max. WPS from all instance.

SAP RFC Server group name is “case sensitive” so make sure that you use the server group name exactly as what showed in RZ12.

6 Further clarification

SAP IDOC inbound program, CIF model activation program, SAP inbound and outbound scheduler etc. are using server group in their parallel solution. Some parallel solutions are not using server group, for example MRP program is using transaction OMIQ to configure the RFC resources quota.

Even RFC server group is configured but there is no guarantee that resource configured is available since quotas configured is shared by all RFC calls at SAP instance/server and resource picture of a SAP instance/server is very dynamic.

You can use SAP transaction RZ11 to review and change SAP parameters like SAP RFC resource parameters. There is another RFC parameter rdisp/RFC_CHECK. This parameter determines level of details of check on whether enough free dialog work processes are available for aRFC calls. SAP recommends that you do not change default value for this parameter.

There are parallel solutions which depend on SAP job server group. SAP job server group can be configured via SAP transaction SM61. I can cover how to use SM61 this in separate post.

How to run SAP transaction ST05 to trace a SAP program execution and review trace

SAP transaction ST05 can be used to trace execution of SAP program/job to catch performance statistics related to SQL statement execution, SAP enqueue operation, SAP RFC activities, SAP Buffer access and HTTP activities. So you can analyze trace to validate performance or identify performance bottleneck. SAP ST05 allows you to enter a SQL statement and analyze its’ execution plan without executing a program.

This post talks about

  • How to use SAP ST05 to do a trace such as SQL trace?
    • How to start ST05 transaction?
    • How to check ST05 trace status?
    • How to start/activate desired ST05 trace?
    • How to stop/deactivate a ST05 trace and display trace?
  • How to save, display/navigate through SAP ST05 trace?
    • How to understand information in the detailed trace screen.
    • How to understand SQL summarize SQL statement.
  • Other ST05 Trace lists and Call Stack trace.
  • How to enter SQL statement and verify execution plan?

If a SAP system has more than one instance/server, SAP ST05 can trace a program/job only when the program/job is executed in the server where SAP ST05 is turned on. Depends on your SAP ST05 version, your screen might looks a little bit difference from what is showed here but usage of each screen and information showed in each screen should be similar.

  1. How to use ST05 to do a SQL/Enqueue trace?

To trace an end-to-end SAP ABAP program execution: Run ST05 -> Check trace status -> start/activate trace with or without filter -> execute the SAP program -> stop/deactivate trace after the SAP program finishes.

  1. How to start ST05 transaction?

You can access SAP SQL tracing tool by typing “/nST05” transaction code into command window of your SAP screen with a “return/enter” key, Then initial screen of SAP ST05 similar to Figure 1 would appear.

Figure 1 ST05 SQL trace initial screen

Figure 1 – shows 5 steps of conducting a ST05 performance trace.

1.2 How to check trace status to know it is ready to turn on a ST05 trace?

ST05 transaction is an exclusive transaction – which means that there should not exist any ‘active’ trace on the SAP server/instance where you are going to do a trace. SE30 ABAP trace and ST12 ABAP trace (Not ST12 SQL/performance trace) can go parallel with ST05. If message like “All Traces are switched off ” is showed up in ST05 Initial screen like Figure 1, the system is ready for you to turn on the trace on the SAP server/instance.

Figure 2 ST05 status – not “ready” for new trace status

If ST05 initial screen showed that at least one traces is activated like what showed in Figure 2, it is not ready for you to do a trace on the server at the moment. In such situation, you can try one of following options

  1. Wait for completion of existing tracing.
  2. Try another server to do test and trace if possible.
  3. Ask other user to exit from the existing trace.
  4. You can proceed with your trace by deactivating active trace on “right” situations.

If a system has two or more application servers, two or more ST05
tracing can be turned on at the same time – each on one of application servers.

  1. How to start/activate desired ST05 trace?

To activated desired trace, you need to specify type of ST05 trace you need, filter and limited the trace to specific business process and start the trace.

1.3.1 Select ST05 trace type

SAP ST05 can do several types of trace – not all traces are relevant to a SAP program and not all relevant traces needs to be turned on dependent on the SAP program being traced.

To tell ST05 that what traces are expected, you can check or uncheck needed trace in “Select Trace” section showed in Figure 1. More than one trace at the same time based on your performance analysis requirement can be checked. Most of time, SAP ST05 is used to do SQL trace and/or ENQUEUE trace in my SAP experience.

1.3.2 Select SAP program/process to be traced

Normally many programs/processes like Figure 3 are running in one SAP server/system, we need to tell SAP ST05 which business process to be traced.

Figure 3 SM50 many running programs/processes

SAP ST05 provides several options for you to enter filters to make ST05 trace more specific. Highlighted columns in Figure 3 are related to the predesigned ST05 filters which can be used to limit ST05 trace to specific job/transactions. If you do not specify filters, many headaches await you like a big trace file, overwritten trace file etc.

To enter the filters, you can click “activate trace with filter” button in Figure 1, then screen similar to Figure 4 would be showed up for you to enter filter to be able to trace specific process.

Figure 4 – ST05 Trace Restriction/Filter and start trace

User name is the SAP userID under which the program is going to run or has been running. Transaction/program name is the business transaction which we need to put trace on. Process number is SAP work process number where a business transaction is running with. Table name is the table which a transaction/program would access. Table 1 lists common filters and their explanation.

Table 1 – ST05 Filters and explanation

ST05 Filter Entered Explanation
User name Enter a user name to trace all activities happened under this specific user.
Transaction name Enter a transaction name to trace all executions of the transaction.
Program name Enter a program name to trace all execution of the program.
Process number Enter a SAP work process number to trace all activities which is executed in the SAP work process. This is to put a trace on an already- running process such as an active SAP background job. There is no way to know number of SAP work process which SAP would use to execute a SAP program unless the system has only 1 process of each type. So if end-to-end trace is needed, using an exclusive user-id might be a better choice.
Table Names Enter one or table names to trace all operations involved that particular table.
User + Transaction Trace all execution of that particular transaction under the specified user. If same user executes the same transaction two times at the same time, two executions would be captured into trace as well.
User + Process Number Trace all activities executed in the specified SAP work process as long as it is under the specific user.

 

In Figure 4, ST05 is instructed to collect SQL trace and Enqueue trace for all activities happened under a specific user in current SAP server.

If there is only one transaction running under your SAP logon and that is what you would like SAP ST05 to trace, you can simply click “Activate Trace” in Figure 1 after trace type is selected.

1.3.3 Start the ST05 trace

After desired filter is entered, you can start the ST05 trace by clicking the continue button showed in Figure 4. Your screen could looks like Figure 5, This means your trace request is started. Please check trace status to make sure that your trace request is accepted by SAP system. If you are doing an end-to-end trace on an online program execution, now the program can be executed.

Figure 5 – SAP ST05 Traces started

If you see message similar to what showed in Figure 6, then your trace is not started due to an active ST01 trace. You need to deactivate the trace using SAP transaction ST01 first to continue.

Figure 6 – ST05 Trace conflict with ST01

SAP ST05 cannot detect ST01 trace earlier in the way it detect other ST05 trace or ST12 trace.

1.4 How to stop/deactivate SAP ST05 trace?

You need to stop /deactivate the trace after business transaction being traced is completed or after desired duration. To stop trace, you click button “Deactivate Trace” showed in Figure 5. After ST05 trace is stopped, the ST05 screen is like what showed in Figure 7

Figure 7 – ST05 Trace stopped

2 How to save, display/navigate through SAP ST05 trace?

After Step 1.4, you have a SQL trace. Now you can save your trace for future review or you can review your trace now. Most important ST05 screens are trace list screen which is available for all ST05 trace, Summarized SQL statement screen and SQL execution plan screen which are applicable for SAP ST05 SQL trace only. You can also access Call stack screen. ns

2.1 How to save/delete a SAP ST05 Trace?

Following the menu path “Performance Trace -> Save Trace”, the ST05 would ask you to give a file name to save your trace. Under the same menu, ST05 provides options to delete saved trace as well.

The reason to save a trace is to avoid the trace being overwritten by subsequent trace activities.

2.2 How to display a SAP ST05 Trace?

You can display a ST05 trace by clicking “Display Trace” button in Figure 7. You can use menu path “Performance Trace -> Displayed Saved Trace” to display a previous saved ST05 trace

Following the click, SAP ST05 would present a screen similar to Figure 8 to allow you to specify what trace records would be selected and displayed.

Figure 8 Filters to display trace

You can make following choices:

  1. Trace type – if you have collected several traces at the same time, you can analyze one trace such as SQL trace at a time.
  2. Trace window –If you have traced a long time, you can specify a smaller period of that tracing for review or review the period you are interested
  3. Further restriction – If you are doing trace based on SAP transaction code and several users are running that transaction during the trace period, you can review the trace records related to specified SAP user by entering his USR ID here.

After needed input is provided, you can click “continue” button in Figure 8 to display trace records. If number of trace records which meets your above choice is more than 5,000 records, then a pop-up window similar to Figure 9 would show up.

Figure 9 – more ST05 trace record meets your selection

You can click “yes” to display all records or no to display just 1st 5,000 records depends on your situation. For example, if your program is keeping executing a same set of SQL again and again, 1st 5,000 records might be enough. It takes time and system resource to display all records. In worst cases, ST05 can get timeout/memory error due to huge number of records collected.

How many trace records would be collected depends on two factors – trace period and program design. If a program is long running but with a few database accesses, SQL trace on such program would have a few records.

In normal case, SAP ST05 would present “Trace List” screen similar to Figure 10.

Figure 10 – ST05 Trace List screen

SAP ST05 displays all trace records according to the time sequence when it is captured by default. You can return to Figure 8 screen by clicking one of two SAP screen navigation buttons in Figure 10 so you can select to review another trace. allow you to exit current SAP screen and return to previous SAP screen.

Pay attention to menu item “Trace list” (red circled in Figure 10), you can access several other ST05 screens. I normally use “Summarized SQL Statements” screen first. If “summarized SQL statements” screen shows a lot of “Identical selection”, I might go back to “Trace List” screen” to review “List Identical Select Statements” screen. Referring to Figure 11 for the menu path for those additional ST05 screens

Figure 11 – ST05 Trace List dropdown Menu

To get “Summarized SQL statements” screen similar to Figure 12, you can click “Trace List”->”Summarize Trace by SQL Statement”.

Figure 12 – SAP ST05 Summarized SQL statements

To get “Identical Select statements” screen similar to Figure 13, you can click “Trace list” -> “Display Identical Selects”

Figure 13 – SAP ST05 Identical Select Statements

Sometimes, SAP ST05 might send you a pop-up window with message “File end of performance trace file detected -> See long text” instead of display the trace list. If you see message like this, this normally means that trace has not captured anything or something unexpected happens. This can be your error(wrong input) or sap/system problem. You got to redo the trace.

2.3 SAP ST05 Trace List screen

SAP trace list screen layout is shared by all SAP ST05 traces. The same column in Trace list screen might mean something different in different trace.

2.3.1 SAP ST05 Trace List Screen – Understanding trace records

Please refer to Table 2 to understand fields/columns of trace records.

Table 2 – SAP ST05 Trace record explanation

Column Explanation
Time when trace record was created.
Duration of the recorded operation in the same row.

  • SQL trace: duration of SQL operation.
  • Enqueue trace: duration of a lock operation.
  • RFC trace: Duration of RFC operation.
Name of program which is related to the statement of the row.
Depending on the type of trace, the object to which the trace statement refers is specified here.

  • SQL trace:   Name of the table or DB procedure.
  • Enqueue trace: Name of the lock object.
  • RFC trace:       Abbreviated name of the instance on which the function module is executed.
Type of operation executed:

  • SQL trace: FETCH, OPEN etc
  • RFC trace: CLIENT or SERVER
  • Enqueue: ENQUEUE, DeQUEUE or DEQAll etc.
Cursor # (SQL trace only), blank for other traces
maximum number of rows requested from or sent to the database (SQL trace only), “0” for other traces
Depends on trace type.

  • SQL trace – Number of records returned or changed or inserted.
  • Enqueue trace – number of granules.
  • RFC trace – number indicates type of the RFC trace records. 1 – completed
Return code for the operation. Operation success indicator.

  • SQL Trace: return code of Database system.
  • Enqueue Trace: 0 – success, 2 – collision, 8 internal error.
  • RFC trace: 0 – success.
Name of database connection
Operation details.

  • SQL trace: SQL statements.
  • Enqueue trace: Lock mode, table, lock argument.
  • RFC Trace: Source, target, client/server, FM, bytes sent or received.

 

2.3.2 SAP ST05 Trace list screen – associated operations

SAP has built in many operations/functions for you to review and analysis performance in Trace List screen. Please refer to Table 3 for list of functions and how to execute a function.

Table 3 – SAP ST05 trace list – Associated operations

Icon/Button Explanation How to use this
Display details about operation Select a line/row in the trace list screen, then click this.
Display Dictionary data Select a line/row in the trace list screen, then click this.
Display SQL execution plan Select a line/row in the trace list screen, then click this.
Display SQL source code Select a line/row in the trace list screen, then click this.
Display Call stack/Hierarchy Select a line/row in the trace list screen, then click this.
Analyzed SQL statement Select a line/row in the trace list screen, then click this.
Replace “placeholder” in SQL
statement with value
Select a line/row in the trace list screen, then click this.
Display details of trace record Select a line/row in the trace list screen, then click this.
Sort Trace list Click on the row header like duration, then click this.
Search in the Trace list Click this icon, then enter search string( table name etc) to continue.
Filter display Click this icon, then select a column (like object), enter data like table name etc.

 

2.4 SAP ST05 Summarized SQL statements screen

Unlike Trace list screen, summarized SQL statement screen is only applicable to SQL trace. If you would like to review SAP program’s SQL performance or tuning SQL performance, i would suggest that you start with this screen. If you would like to validate a SQL change, the summarized SQL statement screen can help as well, of course, you need two summarized SQL statements screen – one is before change and one is after change.

2.4.1 SAP ST05 Summarized SQL Statements screen – Understanding Summarized SQL statement

You need to understand the screen first before we can take next step to analyze SQL performance. Table 4 is to help you to understand the summarized SQL screen of SAP st05 SQL trace.

Table 4 – SAP ST05 Summarized SQL statement field explanation

Column Explanation
Total number of executions of the statement by database engine – not logical execution based on source.
= number of the SQL execution hit the same table record – 1.
Percentage of statements that are identical. For example, if you read the same order from order table 10 times for different fields at different time, total number of execution would be 10, total number of redundancy would be 9. % would be 90%.
Summarized duration of all executions for the SQL statement.
Number of processed records for all executions.
Average execution time per SQL statement execution.
Average number of rows (records) processed per SQL statement execution
Average processing time required per record/row.
Minimum processing time required per record/row.
Record length of the table.
Type of buffer if table is buffered. FUL – bully buffered, DeFul – fully buffer is possible but not enabled.
Table type.
Name of table or database procedure.

 

2.4.2 SAP ST05 Summarized SQL Statements screen – Associated Operations

In ST05 Summarized SQL statement screen, SAP has built in many operations/functions for you to review and analysis performance. Please refer to Table 5 for a list of common operations/functions and their operations.

Table 5 ST05 Summarized SQL statements – associated operation

Icon/Button Explanation How to execute to the function
Display all trace records for the summarized statements Select a line/row in the screen, then click this.
Display SQL statements Select a line/row in the screen, then click this.
Display Dictionary data Select a line/row in the screen, then click this.
Display SQL execution plan Select a line/row in the screen, then click this.
Display SQL source code or calling positions if SQL is called from different location of program Select a line/row in the screen, then click this.
Analyzed SQL statement Select a line/row in the screen, then click this.
Different views of a row Select a line/row in the trace list screen, then click this.
Sort Trace list Click on the row header like duration, then click this.
Search in the Trace list Click this icon, then enter search string( table name etc) to continue.
Filter display Click this icon, then select a column (like object), enter data like table name etc.
Dowload/save list as word document or html document etc Click this icon, choose select download file type, then follow screen instruction.

 

Most accessed function is “display SQL execution plan” – this would be covered in below section.

You can review SAP ABAP source code related to a particular SQL as well. Figure 14 shows navigation steps from summarized SQL statements to SAP program source code. It also demonstrates that one SQL in summarized SQL statements screen can have multiple call locations/positions. In SQL Trace list, it would take you directly to the source code after you click “review source code” icon/button. Reviewing source code can help you to understand why the SQL has been executed so many times etc., for example, the SQL might be inside a ABAP loop.

Figure 14 ST05 trace – From summarized SQL statement to source code

2.5 ST05 SQL Trace – SQL execution plan screen

When a ST05 SQL trace shows that a SQL is expensive with a few executions, The SQL and its’ execution plan has to be reviewed. You can access execution plan of a SQL in “Trace list screen” and “summarized SQL statements” screen etc. To get execution plan for a SQL, you select the SQL by placing cursor on the line/row, then you click “Explain” button/icon, SAP ST05 display would be changed and you would see screen similar to Figure 15 showing execution plan for specified SQL.

Figure 15 ST05 Trace – SQL execution plan

From Figure 15, you can review further information on the table and index status, index details for the index being used, SQL table Access Predicates and records filters. Based on the review, you might like to take further action like table/index rebuilt or statistics updates etc. which can be accessed from SQL execution plan screen as well. I clicked the table name and index name in Figure 14, I got Figure 16 showing Table index information and detailed index information. Rebuilding of table and index and updating of table statistics are done by a separate SAP program or Database tool.

Figure 6 – ST05 Trace Table & index info as well as current index details

I have to stop short of Explaining data in Figure 15 like index selectivity (Number of Distinct fields), Clustering factor to keep this post short.

3 Other ST05 Trace lists and Call Stack trace

Here only Enqueue trace list and RFC trace list are showed here so you know what they looks like.

3.1 SAP ST05 Enqueue trace list

When SAP locking is an issue to performance, you can take an enqueue trace for performance analysis. Figure 17 is a part of SAP enqueue trace list.

Figure 17 ST05 Enqueue Trace list screen

If you double click the statement, you would see screen similar to Figure 18

Figure 18 ST05 Enqueue trace record detail

Please pay attention to the red circle fields in Figure 18. They can tell what user and process is blocking current lock request. This is important to identify root cause of SAP enqueue( SAPLSENA ) issue.

3.2 SAP ST05 RFC trace list

RFC trace can tell you what RFC is executed during the program execution. If you need to do such trace, you can get trace list screen similar to Figure 19.

Figure 19 – ST05 trace – RFC trace list

This would help to identify which RFC call is bottleneck of the performance so improvement plan can be worked on.

3.3 SAP ST05 Call stack

If you read status message carefully in Figure 1, there are three messages ” All trace “, “Call stack deactivated” and “Progress display off”. Call stack or Call Hierarchy is a calling tree so you know which subroutine is executing the operation such as SQL execution and who is calling the subroutine and so on. When Call Stack is deactivated, SAP ST05 would not track the call hierarchy. Call hierarchy can help you understand the business logic/process related to an operation like SQL execution. When Progress display is on, then SAP ST05 would show you progress status of formatting trace records when you try to display “trace list”.

If SAP ST05 is expected to log call hierarch, you need to activate call stack tracing before you click “activate” or “Activate Trace with Filter” button in Figure 1. To turn on the stack trace, follow the menu path “Performance trace ->Activate Stack Trace”. After trace is completed, you just click the row and then click the “Call stack” button to know the hierarchy of the call in Trace list screen. Figure 20 is a call stack sample screen from ST05 SQL trace list.

Figure 20 – ST05 Call stack list

4 How to use ST05 to enter an SQL statement and verify SQL execution plan?

You might need to verify index execution plan across SAP landscape or verify whether a table statistics update etc. has made any difference to SQL execution plan. For example, if one SQL in a program has production performance issue due to table access and the program is working fine in testing environment, you might want to check SQL execution plan difference between two boxes. Of course, you can execute the program in two boxes with ST05 trace to find this out. But SAP ST05 has a quick way for you to verify SQL execution plan in different boxes such as testing box and production box.

In Figure 1, you can click button “Enter SQL statement”, following screen would appear for you to enter SQL statement for analysis.

Figure 21 ST05 – Enter SQL statement

Following is the SQL statement I need to verify –

SELECT “REGIO”, “LAND1” FROM “KNA1” WHERE “MANDT”=:A0 AND “KUNNR”=:A1

Figure 22 – ST05 Analysis SQL statement – Entered SQL statement

After I clicked “Explain” button, Execution plan of above SQL in the system is displayed as showed in Figure 23.

Figure 23 – ST05 analysis SQL statement – execution plan

You can manipulate the where clause of the SQL statement like adding other fields from the table to see how execution plan would change or playing with database hints. You can copy a SQL from SQL cache and paste here or load a SQL from a local file instead of typing.

5 Further information

SAP transaction ST12 can be used to do both SQL and ABAP trace. It is my preferred SAP performance tracing tool. But if you would like to do only SQL trace, SAP transaction ST05 can be easier and can be quickly launched. ST05 tool can tell you whether there is a trace conflict. While ST12 cannot tell you this unless another user is using ST12 tracing tool based on current version of ST12. ST05 allows you to enter SQL and do SQL execution plan verification and analysis directly. ST12 allows you to do this only when you are reviewing an existing SQL trace.

This post is on how to do a trace and navigation. If you would like to know how to tune SAP SQL performance, please refer to my post How to analyze SQLTrace to tune SAP program performance. I also have a post talking about how to analyze ABAP trace to tune ABAP program performance. For overall process of tuning SAP ABAP program performance, you can refer to my post SAP ABAP program performance tuning process .

SAP transaction ST05 can be used to trace execution of SAP program/job to catch performance statistics related to SQL statement execution, SAP enqueue operation, SAP RFC activities, SAP Buffer access and HTTP activities. So you can analyze trace to validate performance or identify performance bottleneck. SAP ST05 allows you to enter a SQL statement and analyze its’ execution plan without executing a program.

This post talks about

  • How to use SAP ST05 to do a trace such as SQL trace?
    • How to start ST05 transaction?
    • How to check ST05 trace status?
    • How to start/activate desired ST05 trace?
    • How to stop/deactivate a ST05 trace and display trace?
  • How to save, display/navigate through SAP ST05 trace?
    • How to understand information in the detailed trace screen.
    • How to understand SQL summarize SQL statement.
  • Other ST05 Trace lists and Call Stack trace.
  • How to enter SQL statement and verify execution plan?

If a SAP system has more than one instance/server, SAP ST05 can trace a program/job only when the program/job is executed in the server where SAP ST05 is turned on. Depends on your SAP ST05 version, your screen might looks a little bit difference from what is showed here but usage of each screen and information showed in each screen should be similar.

  1. How to use ST05 to do a SQL/Enqueue trace?

To trace an end-to-end SAP ABAP program execution: Run ST05 -> Check trace status -> start/activate trace with or without filter -> execute the SAP program -> stop/deactivate trace after the SAP program finishes.

  1. How to start ST05 transaction?

You can access SAP SQL tracing tool by typing “/nST05” transaction code into command window of your SAP screen with a “return/enter” key, Then initial screen of SAP ST05 similar to Figure 1 would appear.

Figure 1 ST05 SQL trace initial screen

Figure 1 – shows 5 steps of conducting a ST05 performance trace.

1.2 How to check trace status to know it is ready to turn on a ST05 trace?

ST05 transaction is an exclusive transaction – which means that there should not exist any ‘active’ trace on the SAP server/instance where you are going to do a trace. SE30 ABAP trace and ST12 ABAP trace (Not ST12 SQL/performance trace) can go parallel with ST05. If message like “All Traces are switched off ” is showed up in ST05 Initial screen like Figure 1, the system is ready for you to turn on the trace on the SAP server/instance.

Figure 2 ST05 status – not “ready” for new trace status

If ST05 initial screen showed that at least one traces is activated like what showed in Figure 2, it is not ready for you to do a trace on the server at the moment. In such situation, you can try one of following options

  1. Wait for completion of existing tracing.
  2. Try another server to do test and trace if possible.
  3. Ask other user to exit from the existing trace.
  4. You can proceed with your trace by deactivating active trace on “right” situations.

If a system has two or more application servers, two or more ST05
tracing can be turned on at the same time – each on one of application servers.

  1. How to start/activate desired ST05 trace?

To activated desired trace, you need to specify type of ST05 trace you need, filter and limited the trace to specific business process and start the trace.

1.3.1 Select ST05 trace type

SAP ST05 can do several types of trace – not all traces are relevant to a SAP program and not all relevant traces needs to be turned on dependent on the SAP program being traced.

To tell ST05 that what traces are expected, you can check or uncheck needed trace in “Select Trace” section showed in Figure 1. More than one trace at the same time based on your performance analysis requirement can be checked. Most of time, SAP ST05 is used to do SQL trace and/or ENQUEUE trace in my SAP experience.
A great book on SAP performance – SAP Performance Optimization Guide: Analyzing and Tuning SAP Systems, SAP Basis, SAP Administration

1.3.2 Select SAP program/process to be traced

Normally many programs/processes like Figure 3 are running in one SAP server/system, we need to tell SAP ST05 which business process to be traced.

Figure 3 SM50 many running programs/processes

SAP ST05 provides several options for you to enter filters to make ST05 trace more specific. Highlighted columns in Figure 3 are related to the predesigned ST05 filters which can be used to limit ST05 trace to specific job/transactions. If you do not specify filters, many headaches await you like a big trace file, overwritten trace file etc.

To enter the filters, you can click “activate trace with filter” button in Figure 1, then screen similar to Figure 4 would be showed up for you to enter filter to be able to trace specific process.

Figure 4 – ST05 Trace Restriction/Filter and start trace

User name is the SAP userID under which the program is going to run or has been running. Transaction/program name is the business transaction which we need to put trace on. Process number is SAP work process number where a business transaction is running with. Table name is the table which a transaction/program would access. Table 1 lists common filters and their explanation.

Table 1 – ST05 Filters and explanation

ST05 Filter Entered Explanation
User name Enter a user name to trace all activities happened under this specific user.
Transaction name Enter a transaction name to trace all executions of the transaction.
Program name Enter a program name to trace all execution of the program.
Process number Enter a SAP work process number to trace all activities which is executed in the SAP work process. This is to put a trace on an already- running process such as an active SAP background job. There is no way to know number of SAP work process which SAP would use to execute a SAP program unless the system has only 1 process of each type. So if end-to-end trace is needed, using an exclusive user-id might be a better choice.
Table Names Enter one or table names to trace all operations involved that particular table.
User + Transaction Trace all execution of that particular transaction under the specified user. If same user executes the same transaction two times at the same time, two executions would be captured into trace as well.
User + Process Number Trace all activities executed in the specified SAP work process as long as it is under the specific user.

In Figure 4, ST05 is instructed to collect SQL trace and Enqueue trace for all activities happened under a specific user in current SAP server.

If there is only one transaction running under your SAP logon and that is what you would like SAP ST05 to trace, you can simply click “Activate Trace” in Figure 1 after trace type is selected.

1.3.3 Start the ST05 trace

After desired filter is entered, you can start the ST05 trace by clicking the continue button showed in Figure 4. Your screen could looks like Figure 5, This means your trace request is started. Please check trace status to make sure that your trace request is accepted by SAP system. If you are doing an end-to-end trace on an online program execution, now the program can be executed.

Figure 5 – SAP ST05 Traces started

If you see message similar to what showed in Figure 6, then your trace is not started due to an active ST01 trace. You need to deactivate the trace using SAP transaction ST01 first to continue.

Figure 6 – ST05 Trace conflict with ST01

SAP ST05 cannot detect ST01 trace earlier in the way it detect other ST05 trace or ST12 trace.

1.4 How to stop/deactivate SAP ST05 trace?

You need to stop /deactivate the trace after business transaction being traced is completed or after desired duration. To stop trace, you click button “Deactivate Trace” showed in Figure 5. After ST05 trace is stopped, the ST05 screen is like what showed in Figure 7

Figure 7 – ST05 Trace stopped

2 How to save, display/navigate through SAP ST05 trace?

After Step 1.4, you have a SQL trace. Now you can save your trace for future review or you can review your trace now. Most important ST05 screens are trace list screen which is available for all ST05 trace, Summarized SQL statement screen and SQL execution plan screen which are applicable for SAP ST05 SQL trace only. You can also access Call stack screen. ns

2.1 How to save/delete a SAP ST05 Trace?

Following the menu path “Performance Trace -> Save Trace”, the ST05 would ask you to give a file name to save your trace. Under the same menu, ST05 provides options to delete saved trace as well.

The reason to save a trace is to avoid the trace being overwritten by subsequent trace activities.

2.2 How to display a SAP ST05 Trace?

You can display a ST05 trace by clicking “Display Trace” button in Figure 7. You can use menu path “Performance Trace -> Displayed Saved Trace” to display a previous saved ST05 trace

Following the click, SAP ST05 would present a screen similar to Figure 8 to allow you to specify what trace records would be selected and displayed.

Figure 8 Filters to display trace

You can make following choices:

  1. Trace type – if you have collected several traces at the same time, you can analyze one trace such as SQL trace at a time.
  2. Trace window –If you have traced a long time, you can specify a smaller period of that tracing for review or review the period you are interested
  3. Further restriction – If you are doing trace based on SAP transaction code and several users are running that transaction during the trace period, you can review the trace records related to specified SAP user by entering his USR ID here.

After needed input is provided, you can click “continue” button in Figure 8 to display trace records. If number of trace records which meets your above choice is more than 5,000 records, then a pop-up window similar to Figure 9 would show up.

Figure 9 – more ST05 trace record meets your selection

You can click “yes” to display all records or no to display just 1st 5,000 records depends on your situation. For example, if your program is keeping executing a same set of SQL again and again, 1st 5,000 records might be enough. It takes time and system resource to display all records. In worst cases, ST05 can get timeout/memory error due to huge number of records collected.

How many trace records would be collected depends on two factors – trace period and program design. If a program is long running but with a few database accesses, SQL trace on such program would have a few records.

In normal case, SAP ST05 would present “Trace List” screen similar to Figure 10.

Figure 10 – ST05 Trace List screen

SAP ST05 displays all trace records according to the time sequence when it is captured by default. You can return to Figure 8 screen by clicking one of two SAP screen navigation buttons in Figure 10 so you can select to review another trace. allow you to exit current SAP screen and return to previous SAP screen.

Pay attention to menu item “Trace list” (red circled in Figure 10), you can access several other ST05 screens. I normally use “Summarized SQL Statements” screen first. If “summarized SQL statements” screen shows a lot of “Identical selection”, I might go back to “Trace List” screen” to review “List Identical Select Statements” screen. Referring to Figure 11 for the menu path for those additional ST05 screens

Figure 11 – ST05 Trace List dropdown Menu

To get “Summarized SQL statements” screen similar to Figure 12, you can click “Trace List”->”Summarize Trace by SQL Statement”.

Figure 12 – SAP ST05 Summarized SQL statements

To get “Identical Select statements” screen similar to Figure 13, you can click “Trace list” -> “Display Identical Selects”

Figure 13 – SAP ST05 Identical Select Statements

Sometimes, SAP ST05 might send you a pop-up window with message “File end of performance trace file detected -> See long text” instead of display the trace list. If you see message like this, this normally means that trace has not captured anything or something unexpected happens. This can be your error(wrong input) or sap/system problem. You got to redo the trace.

2.3 SAP ST05 Trace List screen

SAP trace list screen layout is shared by all SAP ST05 traces. The same column in Trace list screen might mean something different in different trace.

2.3.1 SAP ST05 Trace List Screen – Understanding trace records

Please refer to Table 2 to understand fields/columns of trace records.

Table 2 – SAP ST05 Trace record explanation

Column Explanation
Time when trace record was created.
Duration of the recorded operation in the same row.

  • SQL trace: duration of SQL operation.
  • Enqueue trace: duration of a lock operation.
  • RFC trace: Duration of RFC operation.
Name of program which is related to the statement of the row.
Depending on the type of trace, the object to which the trace statement refers is specified here.

  • SQL trace:   Name of the table or DB procedure.
  • Enqueue trace: Name of the lock object.
  • RFC trace:       Abbreviated name of the instance on which the function module is executed.
Type of operation executed:

  • SQL trace: FETCH, OPEN etc
  • RFC trace: CLIENT or SERVER
  • Enqueue: ENQUEUE, DeQUEUE or DEQAll etc.
Cursor # (SQL trace only), blank for other traces
maximum number of rows requested from or sent to the database (SQL trace only), “0” for other traces
Depends on trace type.

  • SQL trace – Number of records returned or changed or inserted.
  • Enqueue trace – number of granules.
  • RFC trace – number indicates type of the RFC trace records. 1 – completed
Return code for the operation. Operation success indicator.

  • SQL Trace: return code of Database system.
  • Enqueue Trace: 0 – success, 2 – collision, 8 internal error.
  • RFC trace: 0 – success.
Name of database connection
Operation details.

  • SQL trace: SQL statements.
  • Enqueue trace: Lock mode, table, lock argument.
  • RFC Trace: Source, target, client/server, FM, bytes sent or received.

2.3.2 SAP ST05 Trace list screen – associated operations

SAP has built in many operations/functions for you to review and analysis performance in Trace List screen. Please refer to Table 3 for list of functions and how to execute a function.

Table 3 – SAP ST05 trace list – Associated operations

Icon/Button Explanation How to use this
Display details about operation Select a line/row in the trace list screen, then click this.
Display Dictionary data Select a line/row in the trace list screen, then click this.
Display SQL execution plan Select a line/row in the trace list screen, then click this.
Display SQL source code Select a line/row in the trace list screen, then click this.
Display Call stack/Hierarchy Select a line/row in the trace list screen, then click this.
Analyzed SQL statement Select a line/row in the trace list screen, then click this.
Replace “placeholder” in SQL
statement with value
Select a line/row in the trace list screen, then click this.
Display details of trace record Select a line/row in the trace list screen, then click this.
Sort Trace list Click on the row header like duration, then click this.
Search in the Trace list Click this icon, then enter search string( table name etc) to continue.
Filter display Click this icon, then select a column (like object), enter data like table name etc.

2.4 SAP ST05 Summarized SQL statements screen

Unlike Trace list screen, summarized SQL statement screen is only applicable to SQL trace. If you would like to review SAP program’s SQL performance or tuning SQL performance, i would suggest that you start with this screen. If you would like to validate a SQL change, the summarized SQL statement screen can help as well, of course, you need two summarized SQL statements screen – one is before change and one is after change.

2.4.1 SAP ST05 Summarized SQL Statements screen – Understanding Summarized SQL statement

You need to understand the screen first before we can take next step to analyze SQL performance. Table 4 is to help you to understand the summarized SQL screen of SAP st05 SQL trace.

Table 4 – SAP ST05 Summarized SQL statement field explanation

Column Explanation
Total number of executions of the statement by database engine – not logical execution based on source.
= number of the SQL execution hit the same table record – 1.
Percentage of statements that are identical. For example, if you read the same order from order table 10 times for different fields at different time, total number of execution would be 10, total number of redundancy would be 9. % would be 90%.
Summarized duration of all executions for the SQL statement.
Number of processed records for all executions.
Average execution time per SQL statement execution.
Average number of rows (records) processed per SQL statement execution
Average processing time required per record/row.
Minimum processing time required per record/row.
Record length of the table.
Type of buffer if table is buffered. FUL – bully buffered, DeFul – fully buffer is possible but not enabled.
Table type.
Name of table or database procedure.

2.4.2 SAP ST05 Summarized SQL Statements screen – Associated Operations

In ST05 Summarized SQL statement screen, SAP has built in many operations/functions for you to review and analysis performance. Please refer to Table 5 for a list of common operations/functions and their operations.

Table 5 ST05 Summarized SQL statements – associated operation

Icon/Button Explanation How to execute to the function
Display all trace records for the summarized statements Select a line/row in the screen, then click this.
Display SQL statements Select a line/row in the screen, then click this.
Display Dictionary data Select a line/row in the screen, then click this.
Display SQL execution plan Select a line/row in the screen, then click this.
Display SQL source code or calling positions if SQL is called from different location of program Select a line/row in the screen, then click this.
Analyzed SQL statement Select a line/row in the screen, then click this.
Different views of a row Select a line/row in the trace list screen, then click this.
Sort Trace list Click on the row header like duration, then click this.
Search in the Trace list Click this icon, then enter search string( table name etc) to continue.
Filter display Click this icon, then select a column (like object), enter data like table name etc.
Dowload/save list as word document or html document etc Click this icon, choose select download file type, then follow screen instruction.

Most accessed function is “display SQL execution plan” – this would be covered in below section.

You can review SAP ABAP source code related to a particular SQL as well. Figure 14 shows navigation steps from summarized SQL statements to SAP program source code. It also demonstrates that one SQL in summarized SQL statements screen can have multiple call locations/positions. In SQL Trace list, it would take you directly to the source code after you click “review source code” icon/button. Reviewing source code can help you to understand why the SQL has been executed so many times etc., for example, the SQL might be inside a ABAP loop.

Figure 14 ST05 trace – From summarized SQL statement to source code

2.5 ST05 SQL Trace – SQL execution plan screen

When a ST05 SQL trace shows that a SQL is expensive with a few executions, The SQL and its’ execution plan has to be reviewed. You can access execution plan of a SQL in “Trace list screen” and “summarized SQL statements” screen etc. To get execution plan for a SQL, you select the SQL by placing cursor on the line/row, then you click “Explain” button/icon, SAP ST05 display would be changed and you would see screen similar to Figure 15 showing execution plan for specified SQL.

Figure 15 ST05 Trace – SQL execution plan

From Figure 15, you can review further information on the table and index status, index details for the index being used, SQL table Access Predicates and records filters. Based on the review, you might like to take further action like table/index rebuilt or statistics updates etc. which can be accessed from SQL execution plan screen as well. I clicked the table name and index name in Figure 14, I got Figure 16 showing Table index information and detailed index information. Rebuilding of table and index and updating of table statistics are done by a separate SAP program or Database tool.

Figure 6 – ST05 Trace Table & index info as well as current index details

I have to stop short of Explaining data in Figure 15 like index selectivity (Number of Distinct fields), Clustering factor to keep this post short.

3 Other ST05 Trace lists and Call Stack trace

Here only Enqueue trace list and RFC trace list are showed here so you know what they looks like.

3.1 SAP ST05 Enqueue trace list

When SAP locking is an issue to performance, you can take an enqueue trace for performance analysis. Figure 17 is a part of SAP enqueue trace list.

Figure 17 ST05 Enqueue Trace list screen

If you double click the statement, you would see screen similar to Figure 18

Figure 18 ST05 Enqueue trace record detail

Please pay attention to the red circle fields in Figure 18. They can tell what user and process is blocking current lock request. This is important to identify root cause of SAP enqueue( SAPLSENA ) issue.

3.2 SAP ST05 RFC trace list

RFC trace can tell you what RFC is executed during the program execution. If you need to do such trace, you can get trace list screen similar to Figure 19.

Figure 19 – ST05 trace – RFC trace list

This would help to identify which RFC call is bottleneck of the performance so improvement plan can be worked on.

3.3 SAP ST05 Call stack

If you read status message carefully in Figure 1, there are three messages ” All trace “, “Call stack deactivated” and “Progress display off”. Call stack or Call Hierarchy is a calling tree so you know which subroutine is executing the operation such as SQL execution and who is calling the subroutine and so on. When Call Stack is deactivated, SAP ST05 would not track the call hierarchy. Call hierarchy can help you understand the business logic/process related to an operation like SQL execution. When Progress display is on, then SAP ST05 would show you progress status of formatting trace records when you try to display “trace list”.

If SAP ST05 is expected to log call hierarch, you need to activate call stack tracing before you click “activate” or “Activate Trace with Filter” button in Figure 1. To turn on the stack trace, follow the menu path “Performance trace ->Activate Stack Trace”. After trace is completed, you just click the row and then click the “Call stack” button to know the hierarchy of the call in Trace list screen. Figure 20 is a call stack sample screen from ST05 SQL trace list.

Figure 20 – ST05 Call stack list

4 How to use ST05 to enter an SQL statement and verify SQL execution plan?

You might need to verify index execution plan across SAP landscape or verify whether a table statistics update etc. has made any difference to SQL execution plan. For example, if one SQL in a program has production performance issue due to table access and the program is working fine in testing environment, you might want to check SQL execution plan difference between two boxes. Of course, you can execute the program in two boxes with ST05 trace to find this out. But SAP ST05 has a quick way for you to verify SQL execution plan in different boxes such as testing box and production box.

In Figure 1, you can click button “Enter SQL statement”, following screen would appear for you to enter SQL statement for analysis.

Figure 21 ST05 – Enter SQL statement

Following is the SQL statement I need to verify –

SELECT “REGIO”, “LAND1” FROM “KNA1” WHERE “MANDT”=:A0 AND “KUNNR”=:A1

Figure 22 – ST05 Analysis SQL statement – Entered SQL statement

After I clicked “Explain” button, Execution plan of above SQL in the system is displayed as showed in Figure 23.

Figure 23 – ST05 analysis SQL statement – execution plan

You can manipulate the where clause of the SQL statement like adding other fields from the table to see how execution plan would change or playing with database hints. You can copy a SQL from SQL cache and paste here or load a SQL from a local file instead of typing.

5 Further information

SAP transaction ST12 can be used to do both SQL and ABAP trace. It is my preferred SAP performance tracing tool. But if you would like to do only SQL trace, SAP transaction ST05 can be easier and can be quickly launched. ST05 tool can tell you whether there is a trace conflict. While ST12 cannot tell you this unless another user is using ST12 tracing tool based on current version of ST12. ST05 allows you to enter SQL and do SQL execution plan verification and analysis directly. ST12 allows you to do this only when you are reviewing an existing SQL trace.

This post is on how to do a trace and navigation. If you would like to know how to tune SAP SQL performance, please refer to my post How to analyze SQLTrace to tune SAP program performance. I also have a post talking about how to analyze ABAP trace to tune ABAP program performance. For overall process of tuning SAP ABAP program performance, you can refer to my post SAP ABAP program performance tuning process .


How to execute SQL statements directly via SQL command editor in SAP ST04

Sometimes, you might want to execute a SQL command/script directly without using ABAP program in SAP system. You cannot write an ABAP code in non-development box directly or you do not want to write a full ABAP program just for executing a SQL etc. This post would show you on how to enter SQL code and execute them directly without any ABAP program via SQL command editor function provided by SAP DBA cockpit or SAP ST04 transaction. You got to have SQL knowledge to do thisJ – That is a pre-condition. My environment is based on Oracle 11.0 and SAP ECC 6.0. Contents of the post:

  1. What is SAP utilities for executing SQL command directly
  2. General steps to execute SQL command in SAP system
  3. A few examples
  4. Other features of SQL command editor



1 What is SAP utilities for executing SQL command

SAP DBA Cockpit provides a SQL command editor for you to enter a SQL statement/script, parse it, execute it and review the result directly without any ABAP knowledge. You can access SAP DBA Cockpit via SAP transaction code DBACOCKPIT, or SAP transaction ST04, DB02 etc. After you are in SAP DBA cockpit, you can use following path to access SQL command editor functions in the cockpit navigation panel: Performance ->Additional functions -> SQL Command Editor. Double click “SQL Command Editor” to launch the SQL command editor screen – refer to figure 1.

Figure 1 – SAP SQL Command Editor Screen

2 General steps to execute SQL command in SAP system

Now steps to run SQL statement in SQL command editor:

  1. Enter SQL command in the “ENTER SQL Statement” tab ( refer to Figure 1 )
  2. Parse SQL command via drop-down menu SQL Command -> Parse (F7 key)
  3. Execute SQL command via drop-down menu SQL Command -> Execute
  4. Review the result – SQL result is showed in “Result” tab of SQL command editor

You can bypass “Parse” step and directly go to “Execute”. If you do that, SAP would combine “Parse” and “execute” in one step. If SQL syntax is not correct, you need to fix the syntax error. You can refer to other online document to understand SQL syntax and how to fix SQL syntax error.

Please take note some SAP ABAP SQL KEY words is not supported in SQL command editor like Single etc. and some Operators like “EQ” cannot be used as well.

Need to know more? check book – Expert Oracle Database Architecture

3 A few examples to execute SQL statement using SQL command editor

Here I would show cases to query data from SAP configuration table, SAP transaction table, SAP SIS table and Oracle system table. I would show example on select on single table, multiple table and oracle hints technically. Hope to give you some basic concept on executing SQL statement via SQL command editor.

3.1 Retrieve SAP Configuration data – one table

In this example, we need to get company description for a list of company code from SAP table T001 table. The SQL is

SELECT mandt, bukrs, butxt

FROM t001

WHERE mandt = ‘430’ AND

bukrs IN (‘0001’, ‘AU01’)

ORDER BY bukrs

 

Enter above SQL statement into “Enter SQL Statement”, Do parsing(F7), then execute (F8), Data is returned in Result tab. Please refer to Figure 2.

 

Figure 2 retrieve company description via SQL command editor

A great book on SAP performance – SAP Performance Optimization Guide: Analyzing and Tuning SAP Systems, SAP Basis, SAP Administration

3.2 Retrieve SAP transactional data – two tables

This SQL is to get order information from order header VBAK and order item table VBAP.

SELECT h.vbeln, l.posnr, l.matnr, l.kwmeng

FROM vbak h, vbap l

WHERE h.vbeln = l.vbeln

h.vbeln = ‘0010033682’

 

Please refer to Figure 3 for the SQL and result.

Figure 3 Retrieve order info via SQL command editor



3.3 Retrieve data from Oracle system review and table

This is to retrieve information related to an existing SQL based on SQL-ID. Please refer to Figure 4 for detail

Figure 4 – Retrieve SQL text via SQL command editor

Please take note that figure 5 show the SQL ID based on Oracle database views

 

Figure 5 – Part of SQLStats

 

3.4 Using Oracle hints in SQL command editor

Oracle hints can be used to influence SQL access path. Please refer to Figure 6( Full table access hints) and Figure 7(index hints)

Figure 6 Using Oracle Full table Hints in SQL Command Editor

Figure 7 Using Oracle Index hints in SQL command editor

4 Other features of SQL command editor

You can save the SQL you entered for sharing or late reference by clicking “Save” of pull-down menu “SQL command” ( see figure 1). You need to give an SQL statement ID. The SQL statement ID can be used for loading the saved SQL statement into SQL command editor for execution/modification. You can load a “pre-saved” SQL via statement id by clicking “Load” in “SQL Command” pull-down menu.

You also execute the SQL in background job by clicking “Execute Background” in Figure 1. In this case, you can check result via SAP SM37 transaction, result of SQL execution is output to spool file (Figure 8). For a long query, you might wish to execute it in background instead of online since duration of an online process is normally limited by system setting for a dialog process.

Figure 8 Execute SQL in Command Editor via background job

 

5 Further Information

If you are interested in learning SQL commands, you can refer to Oracle online document: http://docs.oracle.com/html/A95915_01/sqcmd.htm.

So far, you can see that you can get information from SAP tables and Oracle tables by executing SQL command directly from SQL command editor. You might wonder so what and how that would help on SAP application performance analysis and trouble-shooting. You can use SQL command editor to verify which execution plan is better for performance. You also can verify whether performance is a cause of unexpected index change… I would cover this via example in my future post.



How to run and understand SAP transaction SM12

In a SAP system, many processes/online business users can change the same business object like the same sale order. To protect data integrity, we need to allow only one process/one user to change one business object at one time. To that purpose, SAP has introduced application level lock protocol – SAP lock/Enqueue to handle concurrent access of the same data object by different processes/users. SAP transaction SM12 is a SAP lock monitor to allow you monitor/manage SAP application lock entries/lock status. In this post, I would talk:

  1. How to start SAP application lock monitor and
  2. How to navigate to frequent accessed SM12 screens/functions and understand SAP SM12 screens/functions.
    1. Reviewing and deleting existing application locks/Enqueue entries,
    2. Reviewing SAP application lock/Enqueue statistics,
    3. Testing the SAP lock management and
    4. SAP SM12- SAP lock “Error Handling” functions.

1 How to start SAP application lock monitor

You can access SAP lock monitor by typing “/nSM12” transaction code into command window of your SAP screen and following by a “return/enter” key, then following initial screen of SAP application lock monitor appears ( please refer to figure 1).

Figure 1 SAP SM12 – Initial screen

Initial Screen, only Extras menu has accessible functions. Other SM12 specific menus like “Lock Entry” etc are in “grey” and not accessible.

2 SAP SM12 Navigation and Explanation

From the initial screen of SAP SM12 transaction, following functions are available:

  1. Reviewing and Deleting existing SAP locks,
  2. Reviewing application lock/enqueue statistics,
  3. Testing the SAP lock management and
  4. Turn on SAP lock “Error Handling” function.

2.1 Reviewing and deleting existing application locks/Enqueue entries

2.1.1 Reviewing existing application locks

Referring to figure 1, SM12 initial screen provides 4 input fields – “Table name”, “Lock argument”, Client and “User name” which you can use to instruct SAP SM12 to display locks which meet your selection criteria. In Default, The Client and “User name” field is automatically populated which you can overwrite them with proper authorization. Wild card like “*” is supported. If you enter a “*” to a field or leave it blank, this means you would like see all possible values for that field.

Table 1-SAP SM12 – selection parameter

Field name

Explanation

Table name

Providing a name of SAP table which SAP locks is related to. Enter table name “VBAK” to display all SAP locks related to “VBAK”. Enter “VB*” to display all locks for any table whose table name start with “VB” like VBAK, VBAP etc..

Lock argument

Provide a specific business object. If you have customer order# – 1234, entry “*1234*” to see all lock entries related to that order.

User name

Enter “prod*”, lock entries from all SAP users which starts with “PROD” would be displayed. Enter “prod”, only lock from user PROD would be displayed.

Input in Lower case or upper case would have same the result.

If you leave all parameter fields blank, SAP SM12 would report all SAP application lock entries at that moment.

When there are hundreds of thousands SAP lock/enqueue entries, using those SM12 selection criteria is a better practice when there

  1. Use less system resource(memory, network traffic) by filtering un-necessary data –
  2. Make it easy for you to find what you are looking for since data is filtered.

Here I used blank “User name”, “blank” “lock argument and “blank” table name – I needed to review all applications locks in the system, then I pressed “Enter” key or clicked on “List” button at figure – 1, following screen appeared with all application locks:

.

Figure 2 SAP SM12 – Lock Entry List screen

Please pay attention to different color of rows. They are not there for fun.

Blue row means that the lock has already been transferred to the update task and lock entry has been written to a system level backup file. This SAP mechanism is to prevent lock/Enqueue loss due to system failure. When system reboot, lock entry in backup file would be imported to SAP lock/Enqueue table which is in memory.

White means that the lock in that row is (still) held by the non-updating task owner like SAP dialog work process.

On SAP SM12 Lock Entry List screen, SAP provides several other utilities like Refresh, Sorting, filtering, check details etc to help you to review lock entries.

To review details of each SAP lock, you can double click a lock entry or place cursor on it and click on display icon. I double click 1st blue row in figure 2, I got following “Lock Entry Details” screen of a SAP lock (Figure 3)

Figure 3 – SM12 Lock Entry details

Backup flag field in Figure 3 is checked – this means that updating task owns the lock. Following Figure 4 is Lock Entry Details for a white entry, you can see that Backup flag is not set.

Figure 4 – SM12 Lock entry details – before update task

Please refer to Table 2 for explanation on field displayed in Lock Entry List and Lock Entry Detail screen.

Table 2 – SM12 Lock Entry List and Lock Entry Detail screen Explanation

Field

Explanation

User name

Name of the user who has has started transaction/program which places the lock.

Time

The moment when the transaction/report/job starts – not necessary when the lock is placed. Lock can be placed much later but this field would have the same data for all the locks request from the same job instance.

If transaction is started on the same day, time is displayed. Otherwise, date is displayed.

Table name

Name of the table which hold the locked application objects/documents

Lock argument

Specify what to be locked from the table – could be one or more entries whole table depends on application logic. A job can place more than one individual locks on different business documents – that would be different lock arguments.

Lock owner

Lock Owner which is unique, ID of Logical Unit of Work (LUW) which consists of Date + work process# + SAP system # + SAP hostname.

There could up to two owners depend on application design(lock scope).

So all locks placed by the same background job instance would have the same lock owner.

Host name

Name of the host system where the user generated the lock.

System number

System number of the instance.

Work Process

Number of SAP work process which places the locks.

Date

Timestamp when the transaction/report starts. Not when the lock entry is placed.

Backup flag

When this is set, the lock owner is passed from dialog/background process to updating process. The lock entry is output to file specified by RDISP/ENQLOG system parameter.

Transaction code

SAP transaction code which places the locks

Lock Object name

Name of the lock object in the Data Dictionary that belongs to the lock entry

 

2.1.2 Deleting existing application locks

It is simple to delete SAP lock entries. You just click on the entry you need to need in Figure 2, then click Icon , finally click “yes” in the pop-up window. Lock entry would be deleted. Please refer to Figure 5

Figure 5 – SM12 delete SAP lock entries

It is a simple operation to delete existing SAP lock entries but it might take some effort to know that a SAP lock entry can be deleted safely. Normally an “orphan” SAP lock entry which does not belong to a logon SAP user or an active work process or pending for updating can be safely deleted. If you delete an active SAP lock entries, this might create data integrity issue or resulted in double business posting to database.

2.2 Reviewing SAP application lock/Enqueue statistics

2.2.1 Review Lock/Enqueue statistics

You get SAP lock/Enqueue Statistics screen (Figure 7) by clicking “Statistics” under “Extras” pull down menu in SAP SM12 initial screen (Figure 6)

Figure 6 SAP SM12 – Extra -> Statistics

Figure 7 – SAP Lock/Enqueue statistics

SAP lock/enqueue statistics showed in Figure 7 is the accumulation data since lock/enqueue server was started last time. Table 3 is SM12 lock statistics explanation.

Table 3 SM12 Lock statistics explanation

Statistics

Explanation

Enqueue Operations

Number of SAP lock/Enqueue requests executed.

Rejected

Number of Rejected lock/Enqueue requests.

Errors Occurred

Number of Errors in Enqueue operation.

Dequeue operations

Number of SAP Lock Release requests (DEQUEUE) executed.

Errors Occurred

Number of SAP lock Release (dequeue) errors.

Dequeue-All Operations

Number of Release of all locks for a LUW.

Cleanup operations

Number of Release of all locks in a server(when server down).

Backup Operations

Number of requests passed to the update process.

Read Operations

Number of requests to read lock entries by program like SM12.

Compress operations

  

Verify operations

  

Records written

Write accesses to file.

to the backup file

Write accesses to backup file.

Maximum Number of Lock Owners

Maximum number of concurrent owners which a system allows.

Maximum Fill Level

High-water mark on concurrent owners stored in the lock table.

Current Fill Level

Current number of concurrent owners in the lock table.

Maximum Number of Lock Arguments

Maximum number of concurrent lock arguments which a system allows.

Maximum Fill Level

High-water mark on number of concurrent lock arguments stored.

Current Fill Level

Current number of lock argument stored in the table.

Maximum Number of Lock Entries

Maximum number of lock entries can be allowed in the system.

Maximum Fill Level

High-water mark on number of concurrent lock entries which ever reached.

Current Fill Level

Current number of lock entries in the stable.

Update, Fill Level at Maximum

Maximum number of accumulated update requests.

Current Fill Level

Number of outstanding update requests which hold SAP locks.

Time in Lock Table / Seconds

Total time required for lock operations

Wait for Lock Table / Seconds

Total waiting time of all work processes for accessing lock table

Time in Lock Server /Seconds

Total time needed for lock operations by all processes in the enqueue server

 

Statistics review is to focus that high-water mark on fill-level should be 10-20% lower than maximum allowed.

2.2.2 Review SAP locks – Top Capacity Used

Please refer to Figure 6, There are 3 functions under menu Extra->Top Capacity Used:

  1. Current – To review current SAP lock top users who have placed most of SAP locks at polling
  2. History – To review SAP lock overflow history and users who are major contributor to the SAP lock/Enqueue table Overflow
  3. Delete History – To clear SAP lock overflow history.

Figure 8 SM12 Top Capacity Usage – current

Figure 9 SAP SM12 Top Capacity usage – top SAP locks user when overflow

Figure 9 screen should be blank mostly. In another word, there should not be any SAP lock/enqueue table overflow. If there is an SAP lock overflow and more details is needed, you can double click the entry to get further information like server, work process and program and transaction involved (Figure 10). In this case, one user requested 267,512 locks concurrently – this is too much. The way which user executed the program or design of the program needs to be reviewed.

Figure 10 – SAP lock Overflow details

2.3 Testing the SAP lock management

When you have SAP locking issue, you might wonder whether SAP enqueue/lock server is working fine. SAP SM12 provides you with diagnosis functions for this purpose. Please refer to Figure 6, you can see two testing functions under pull-down menu “Extras”:

  1. Diagnosis – Test whether SAP enqueue server can handle lock operation (Enqueue and Dequeue etc) well in a SAP work process( Online program or background job).
  2. Diagnosis in Update – test whether SAP lock can be passed down to updating task and released upon completion of updating task.

When no errors are reported in both tests, then SAP lock management or SAP enqueue/lock server is working as expected

2.3.1 Diagnosis – Testing new SAP lock/enqueue request

If you click “Diagnosis” menu in Figure 6, SAP would simulate the new lock request and releasing process from a SAP work process and testing result would report back to you like what showed in Figure 11

Figure 11 – Diagnosis – testing result

Figure 11 shows that testing is OK. If there is an error, you need to take action based on error message.

2.3.2 Diagnosis in Update – Test lock passing and SAP lock handling in updating task

If you click Diagnosis in Update in Figure 6, SAP SM12 would simulate the lock passing and lock management process in updating task, report you back the result like what showed in Figure 12.

Figure 12 SM12 Diagnosis in Update – testing result

2.4 SAP SM12- SAP lock “Error Handling” functions

2.4.1 Access SM12 “Error Handling” function

SAP provides more error handling functions for you to trouble-shoot SAP lock management issues. To access them, you just need to enter “test”(without the “”) in the command/OK-code field (See Figure 13) , and press the Enter key, you would see additional “pull-down” menu called “Error handling”( See Figure 14).

Figure 13 – SM12 – Enter “test”

Figure 14 SM12 – Error handling functions

2.4.2 Introduction on SM12 “Error handling” functions

Following are some quick introduction for Error handling function.

  • Special Diagnosis – This would do the same SAP lock test operations covered in “Diagnosis” in my SM12 version.
  • Logging – This would allow you to turn on system log for all SAP Lock/Enqueue operations.
  • Diagnosis Environment – Run this to do extensive checking on SAP lock/enqueue configuration, various SAP lock operations performance and known issue.
  • Lock Management – allow you to turn on or turn off lock management. When lock management is turned off, two different users can open the same business document in “change mode”. When lock management is turned on, only one user can open a business document in change mode normally unless program uses “Optimistic lock”.
  • Backup – You can switch Backup on/off. When Backup is switched off, lock entry passed to updating request would not written to backup file. This is a risk in terms of system failure.
  • Test Tools – There are several testing functions: Mass calls, Single calls, Performance, lock table dump. I have not used them.
  • Reorganization Tools – I have not used those tools.

I would share part of result screen for “Diagnosis Environment” to enhance your understanding on this function. You would get similar screen to what showed in Figure 15 if you click “Diagnosis Environment” under “Error handling” pull-down menu.

Figure 15 SM12 Error handling – Diagnosis environment

You might like to establish baselines of Diagnosis Environment during your system peak hours. Then you can find this handy when you are trouble-shooting enqueue related performance issue in the future.

SAP SM12 enqueue logging can be helpful to understand what is going on in terms of SAP lock/enqueue operation. You use path “Error Handling”-> Logging -> “Switch on” to enable logging. Then you use path “Error Handling” -> Logging -> “Switch off” to disable logging after expected logging duration. Finally, you can use path “Error Handling” -> Logging -> Display to review the Enqueue operation happened during the logging period. Please refer to Figure 16 to get a glimpse of logging result. It might take some effort to find what you need from a huge list. You can delete all Enqueue log entries using “Switch off and Delete” option under “Logging Menu”. If you need more details, you can check out SAP Note 125041 – Analysis of enqueue errors with enqueue logging.

Figure 16 SAP enqueue/log logging result

I would like to share that Enqueue log should be turned off promptly after it is turned on since Enqueue logging is consuming disc-space. Normally, a 10 minutes log is well enough. In a busy system, a couple of minutes might do the purpose.

3 Further clarification

SAP lock/enqueue table exists in main memory of lock server for performance reason. SAP lock is an application lock which is different from database lock. SAP lock is a program/application logic which is placed explicitly while database lock is placed by database management system automatically. SAP lock can last longer as long as the application logic needs while database lock is normally brief. You can refer to SAP online SAP lock document to understand more about SAP lock concept like type of locks, lock scope and owner etc.

I would talk about typical performance analysis using SAP SM12 and frequent-seen SM12 performance issue in the future.

How to run SAP transaction ST03/ST03N and navigate through SAP workload monitor screens

ST03/ST03N is a SAP transaction for workload monitor used to review SAP workload distribution both from time vertically and servers horizontally. After you review my post – SAP workload monitor overview, you get some idea on what this SAP tool is up for, now you wonder how to run SAP st03n and navigate through frequent accessed ST03N screen. This is the focus of this post:

  1. How to start SAP workload monitor ST03N.
  2. How to navigate through SAP ST03N workload monitor.

How to understand ST03N data and what we can use ST03/ST03N for in SAP system/program/job performance analysis would be covered in subsequent posting.

1. How to start SAP workload monitor ST03N

To start SAP workload monitor, you can either use menu path or run SAP transaction ST03/ST03N directly. The initial screen of workload monitor is similar to what showed in Figure 1 normally.

Figure 1 ST03 Initial screen – Navigation panel and Overview of instances

2. How to navigate through SAP ST03N workload monitor

You can navigate through SAP ST03N screens easily via built-in navigation planel showed in above Figure 1. On ST03N initial screen, you can access following functions:

  1. Workload – So you can analyze SAP historical workload for each uniqe combination of period, application-server or system, workload under this portion are aggregated,
  2. Detailed Analysis – So you can analyze SAP “current” workload data which can be drilled down to individual statistical record,
  3. Load history and Distribution – So you can compare and analyze performance overall several periods in one screen and
  4. Collector and performance database – this allows you to define retention period for different performance data collected. It also allow you to control what performance statistical data should be make available for SAP work load – business transaction analysis tool STAD.

Please refer to figure 2 for a brief description on navigation options. I would cover more details in following sections.

Figure 2 ST03N workload navigation option overview

Only entries starting with in ST03N represents an executable function. You need to click “” or “” icon to see ” entry” in navigation panel. To start a ST03N function via ST03N navigation panel, you need to double click on a entry like in Figure 2.

2.1 SAP Workload Review

ST03N organizes workload data into different views/profiles to facilitate performance analysis. Data in each workload view is organized into different tabs based on performance focus.

A workload view can be available for one period or one server/instance ,but not available in another period or server when underlying data is not available. Data is not available due to two reasons: data is deleted and data has not been collected. You can make proper setting via ST03N or system parameter maintenance transaction RZ11 to control data collection and retention. For example, you do not see view in the lower portion of navigation panel showed in Figure 3. I would talk more in later portion of this post.

2.1.1 SAP workload overview screen

Data from SAP workload overview screen allows you to analyze SAP performance at system/server and task type level.

Now assuming that I need to review workload situation at system level (TOTAL) for a particular day, so I click the “Total” entry first, then “Day” entry, i double clicked the date –here June 17 2013, Screen similar to Figure 3 would show up.

Figure 3 ST03N Workload Overview screen

Please note the main display has 3 components:

  • Part 1 is navigation panel. Workload navigation panel has two portions – the upper portion is the ST03N transaction original navigation panel, the lower portion shows a list of available analysis views for SAP workload analysis.
  • Part 2 is workload header information – showing period (a customer period, a day, a week or a month) where workload is related, instance (a specific instance or total) and task type (a specific task type or all). Please double check with 1st records and last records and time period field to ensure that you got all workload from the period you selected.
  • Part 3 is workload details.

Workload over view screen is the initial view presented by ST03N for load analysis. The workload overview shows times statistics consolidated according to SAP task types. In a SAP ECC system, Dialog, Background, RFC, ALE and Updating task performance are most critical to business function. Workload overview screen provides a performance overview on task type level.

 

There are several tabs in Workload overview to help you to quickly locate the data you might need. The user tab shows number of accumulated users from the system/instance for the selected period.

In the left bottom corner of Figure 3 is a list of analysis views available for the workload in the selected period and server scope. You can navigate to any view by moving your cursor and double clicking the view like “standard” under “Transaction Profile”.

 

2.1.2 ST03N Transaction profile

Data from transaction profile allows you to do application performance analysis.

There are two versions of transaction profile – one is “Standard”, the other is “EarlyWatch”. Standard profile has more navigation feature and provides workload breakdown based on SAP task types.

Double click “Standard” under “transaction Profile”, You would get screen similar to figure 4

Figure 4 SAP workload – standard transaction profile

In figure 4, “All data” tab is organized into several child tabs – Times, Database, Parts of response time, GUI times with default tab “Times” displayed. GUI Times tab is only applicable to Dialog type task.

EarlyWatch transaction profile is similar to “standard” transaction profile. The difference between them is that EarlyWatch consolidates workload displayed in Figure 4 based on the 1st column – “Report or Transaction name”. This helps if you want to know top load programs in the system.

Table 1 – Workload view navigation buttons

Your goal Button should be clicked Comment
Filter display by task type You select corresponding “task type” from the pull-down menu which has “Dialog”, “BACKGROUND”, “RFC” and etc. You can select “Dialog” task type so only online executed transactions are displayed.
Aggregate workload This allows you to aggregate workload on one of SAP predefined levels: Application such as CO, LE, MM, FI and etc, Subapplication like MM-IM, MM-PUR etc , package and transaction. Default level is transaction.
Check individual statistical records To use this, you need to place cursor on selected row first. This works only with “current data” while STAD works. Current data is normally referring to data related to transaction executed in recent 48 hours.
Check Column full name Long-short name to give you more meaning of the column or save the column width.
Filter display by column Filter display based on column like Disk reads, Program name etc. You can click a column first or you can select columns for sorting from available fields after you click the filter button.
Sort display Sort in Ascending or Descending in expected column. Click the column name first before the sort button is clicked.
Search on the screen You can search the display based on specific value from any column.
Summarize numeric column You need to select the numeric column like “# steps”, then click this button
Export the display to a local file Save displayed workload data to local file.
Chang display You can control what column should be displayed and their position and save it for future use.

 

The same button has the same usage regardless of ST03N analyst views you are working with although some buttons are only applicable to specific views like “single records” button which is not available in workload default view – workload overview.

2.1.2 ST03N time profile

Data from ST03N time profile view allows you to analyze performance/load difference between different hours.

Double click “Time Profile” entry in navigation panel (see Figure 3), you would see screen similar to figure 5.

Figure 5 ST03N SAP workload time profile

Time profile separates workload from a period ( a day, a week or a month) into hourly fashion. So you can know the busiest hours in terms of workload.

If your display is not in hourly fashion, you might need to refer to following ossnote :

  • 17750 workload: time profile also for night hours and
  • 910897 ST03N: Configuration of time profile.

2.1.3 ST03N RFC Profiles – RFC Server profile

Data from ST03n RFC profiles allows you to analyze RFC performance.

You can use ST03N to review RFC workload. RFC workload is further separated into RFC client profile, RFC server profile, RFC Client Destination and RFC Server Destination profile. This makes it easier for you to do specific workload analysis.

Figure 6 ST03N – RFC Server profile

RFC Server Destination profile

Figure 7 ST03N – Destination profile

2.1.4 SAP ST03N Response Time Distribution view

Data from this view can allow you to see transaction step distribution based on duration.

Double click “Response Time Distribution” entry in workload navigation panel, you would get screen like Figure -8.

Figure 8 ST03N Response Time Distribution

Number of dialog steps under 1 second is often used to measure a system performance based on % of dialog response time under 1 seconds.

2.1.5 SAP ST03N – other workload analysis views

You can navigate to other workload analysis views like Memory Use Statistics, Ranking lists, User and Settlement Stat etc in the same fashion. You might need to review those views based on specific situation – for example, if you would like to tune memory usage and need to identify top memory consumer, ST03N Workload – Memory Use Statistics view is a good place to start.

2.2 Detailed Analysis

Here, you can analyze “current” workload which might not show up in workload analysis we have covered in previous section of this post, you can access individual SAP statistical record via button showed in figure 4.

2.2.1 Business Transaction Analysis

Click this entry, it would start SAP STAD transaction giving you access to recent individual performance statistical records. You can refer to my post on how to run SAP STAD transaction.

2.2.2 Last Minute’s load

To see last minute’s workload, you need to click a server or total( whole system) , input the data and then hit the execution or continue key. Please refer to Figure 6 with input data.

“Time profile granularity” might be helpful for you to organize workload data into “good” period and “bad” period for easy comparison in performance analysis.

Figure 9 ST03N last minute’s Load initial screen

After you enter your data and hit execution, you would get all normal views we covered in “workload” section of this posts and you can access those workload views in the same way which is covered in workload section of this post.

When I hit “OK” or continue button in figure 6, I got a “workload” overview screen normally. However I presented ” time profile” view of workload in Figure 7 as an example.

Figure 10 ST03N last minute’s load – time profile

Each time you run SAP ST03N to review workload for selected server/instance, the default view would be workload overview. However if you would like to review workload in another server etc., the default view is the last analysis view you review with previous workload analysis.

2.3 Workload History and Distribution

In this section, three analysis options are available

  • Load history,
  • Instance Comparison and
  • Users per Instance.

You use navigation panel to access those analysis option by clicking corresponding leaf entry.

2.3.1 ST03N Load History

Data from load history view allows you to analyze performance trend of a SAP system/application/task types.

You can review workload history of single instance/server or workload history of whole system. If you double click on “total” entry, you would get workload history screen similar to Figure 8.

Figure 11 ST03N workload history at system level

Click button “Task type” in figure 11, you can review workload for the expected workload type. Click Week and Month button in Figure 11, Number of steps would be summarized and response time would be averaged in expected time interval.

2.3.2 Instance Comparison

Data from instance comparison allows you to analyze performance among different instances.

Workload data in different application server can be compared in day, week and month interval. Please refer to figure 12 for navigation path.

Figure 12 ST03N Instance comparison

 

2.3.3 Users per Instance

Double click “User per Instance ” under path “ST03N -> Load History and Distribution”, you would see screen similar to Figure 13.

Figure 13 ST03N Users per instance

2.4 Collector and performance DB

Here, SAP ST03N allows you to define retention period for data used in SAP ST03N. It also allows you to have control over some online parameters which control statistical sub-record generation or collections temporarily. Those online parameter changes could be lost or replaced by the value from sever/instance profile. Please refer to Figure 14 for function details

2.4.1 Define data and workload review retention period

Double click on “Reorganization” under path “SAP ST03N -> Collector and Performance DB -> Performance Database ->Monitoring Database”, You would see screen similar to

Figure 15 Performance database retention period

You can overwrite the those number based on your specific need.

Double click on “Control” under path “ST03N -> Collector and Performance DB -> Performance Database -> Workload Collector Database -> Reorganization”, You would see screen similar to

Figure 16 – SAP ST03N workload collector views retention period

Here you can define retention period for Daily/Weekly/Monthly Aggregates Retention Period workload data for specific view. In figure 16, daily aggregates data would be kept for 14 days only – after they would be deleted automatically.

2.4.2 Statistics Records – Online parameters

ST03N allows you to change online parameters to influence statistics data generation on the fly – you navigate to the screen, overwrite the data and save the changes. Your changes come into effect immediately upon saving. It can be lost immediately after the system is reboot/restarted as well.

Double Click “Dialog Step Statistics” under path “ST03N-> Collector and Performance DB -> Statistics Records & File->Online Parameters”, you would see following screen

Figure 17 ST03N online parameters of Statistics

Please note those changes are applied to all task types in the server where it is effected not just applicable to online transactions. If you would like to see what are top 3 tables which a transaction step spends its’ time on, you can overwrite value to “3” under parameter “STAT/TABREC” column in figure 17. If you are only interested in top 3 table for a specific business transaction like order creation transaction “VA01”, you can enter “VA01” under “stat/tcode1” column, otherwise the setting would be effect for all transactions. There are general SAP guidelines/default values for those parameters. Remember it is a load to system to generate and collect statistics, set it up when there is a real need. A blank or “Zero” means that corresponding statistics are not collected.

3 Further clarification

I have not navigated to all screens/features under SAP transaction ST03N to keep the post short. But Most of frequent accessed ST03N views and features has been displayed here base on my experience so far. Using navigation panel of ST03N, you should be able to navigate to other screens you are interested. My subsequent posts would talk on what SAP ST03N can be used for performance analysis and how to understand the ST03N data.

 

SAP workload monitor overview

An execution of a SAP program/job in a SAP system is a workload to the SAP system. If you are wondering what programs a SAP system has executed, how much workload a SAP system has processed, who bring those workload to a system, where time has been spending by a program, interface etc… SAP workload monitor via transaction ST03/ST03N can help you to find answers.

SAP system has pre-delivered programs to collect and aggregate workload statistics like runtime statistics, who starts the transaction etc. and stores them in SAP performance database. Time statistics is further break down – wait time, processing time, database time, roll-in time and etc. SAP transaction ST03/ST03N can be used to review SAP workload and performance related to any specific user or any specific interface, any specific server or the whole system, any specific period and etc.

This post would give you a high-level description on following capabilities/functions of SAP workload monitor:

  1. Workload,
  2. Detailed Analysis,
  3. Load History and Distribution,
  4. Collector and performance DB and
  5. ST03N and performance analysis.

1 Workload

SAP workload monitor (SAP ST03N or ST03) allows you to review “aggregated” workload which a specific SAP sever or whole SAP system handles during one of available periods – a day, a week or a month. So you know their performance of an SAP transaction/program/jobs on the instance/system during a specific period and its’ impact on different system resources such as CPU, memory, database, network traffic etc.

There are huge amount of data to review. SAP ST03/ST03N provides many views on workload to facilitate performance analysis. At a workload view, SAP ST03N can allow you to review workload from one of available task types or all task types. Further workload data in a view can be presented in different tabs. Please refer to Figure 1 for the workload display breakdown structure.

Figure 1 SAP ST03N workload display structure

Not all views/profiles have the same tabs due to different performance analysis need. You can use SAP ST03N to identify top CPU expensive programs or top memory usage programs. You need different set of data for CPU load analysis than memory load analysis. Some views can have limited task types like RFC profile/views.

2 Detailed Analysis

Statistics data generated at each transaction step are normally aggregated in hourly fashion via standard SAP program RSCOLL00 in a background job. So there are statistics data which have been aggregated or statistics data which are not aggregated. SAP ST03N function “Last minutes’ load” allows you to review those workload statistics data after latest run of program RSCOLL00. Since data is not aggregated, you can review individual statistics records related to each execution of program or job etc. That is why SAP calls this ST03N “Detailed Analysis”.

What covered in previous section like workload reviews and structure is applied to “Last minutes’ Load” function as well.

Here, you can review selected statistical records in details associated with a user and a program/transaction etc. for recent activities – normally past 48 hours.

3 Load History and Distribution

Here you can review performance data at SAP task level for a specific instance or whole system over a list of available periods. This would not go down to individual program or user level.

You also can compare performance data among different instances of a SAP system from a period to another period.

You can re users distribution over period and instance as well.

4 Collector and performance data

SAP workload monitor is based on SAP performance database which are populated and kept according to various setting which can be maintained via SAP st03n. You can define data retention period for different workload profiles/views – such as how long daily workload data should be kept, how long weekly workload data should be kept and so on…

Here you can define online parameters to have some influence on what data is available in statistics record generated for each transaction.

5 SAP workload monitor and SAP performance analysis

SAP workload monitor can help in following performance works

  1. Trend monitoring and analysis
    1. SAP System performance trend monitoring and analysis.
    2. Single SAP job/program/interface performance trend monitoring and analysis.
    3. System resources(CPU, memory and SAP work process) consumption trend monitoring and analysis.
  2. Load analysis
    1. SAP workload balance analysis across all servers or all past periods.
    2. SAP workload pattern analysis over a day, over a week or over a month.
    3. Identify top expensive program in different categories normally CPU time and database time.
  3. Performance trouble-shooting – this can be system level performance issue or individual application process issue

Analysis from workload monitor can point to potential performance area which needs more detailed analysis – for example, if you see “wait” time has a trend of increasing, you need to do detailed analysis on SAP work process utilization via various tools.

In addition to above “traditional usage”, SAP workload monitor can answer following frequent asked questions related to transaction/job history:

  1. Who executed a SAP program/job/transaction?
  2. What SAP programs/transactions/jobs have been executed by a user?
  3. How many users have executed a SAP program/transactions/job?
  4. Whether a SAP program/transactions/job has ever executed etc.?

6 Further information

Up to now, you would have overview of SAP workload monitor’s capabilities.ST03N has a function of “BI load”, I am not sure of its usage and have not used it. I normally log into BI system and use ST03/ST03N transaction to review workload situation. ST03N is a “New” version of original SAP transaction ST03. Your system might only have ST03 transaction.

If you are wondering on how to run SAP workload monitor transaction ST03/ST03N, how to understand SAP St03n data and how to do performance analysis using SAP ST03/ST03N. Please stay tuned for my future posts.