4. ST02 – SAP Tuning – Another Magic transaction – I

***************** Index of Pages on the topic…. ****************************

1. SAP Tuning – Gather Symptoms.

2. ST04 – A Magic Transaction for SAP performance tuning – I

3. ST04 – A Magic Transaction for SAP performance tuning – II

4. ST02 – SAP Tuning – Another Magic transaction – I (Part 4)

5. ST02 – SAP Tuning – Important SAP Parameters – II

6. ST03n – The meter gauge for SAP tuning

******************************************************************************

This is a beautiful transaction where SAP actually is producing the image of its architecture. Everyday I look back into it with a hope of learning something more of the inner details of SAP and I never returned empty handed. Besides showing the current performance scenario, it also shows the how effectively the system landscape is designed. How effectively the design is synchronized with SAP architecture, how effectively the load balancing is done?

A Screenshot1, 2 and 3 is a part of initial display of a ST02 transaction. As transaction ST02 shows you the current snapshot scenario of buffer, SAP memory, and the call statistics in the initial screen, and believe me it gives enough information in this screen itself. Once you glance thru, lot of questions will come to your mind like the buffering techniques, overflows, swapping etc.

Let us take an example to narrate the scenario in detail. You are in a need of specific brand of pencil and went to the shop. Guess what can happen to you. Broadly either of the two, the branded pencil is available of the shelf or not. In later case the shopkeeper will politely ask you to order and wait till he get your requirement either from the store or from the manufacturer, – Huh…Look into the word wait, it represents delay or slowness of the process. So the basic ideology is clear, to get your things done properly, you must have right things in right amt and quality of the shelf, i.e. the BUFFER. The primary aim of a SAP tuner must be looking into this basic frame of mindset i.e.

Whether Buffer Configuration is correct?
Who/what is behind nonsense use of buffer?
What are the possibilities to rectify (technical job) and control (service management processes) the situation?

(Please note that the incorrect configuration or usage of buffer alone can make server CPU utilization, DISK I/O and Network I/O explode and it will be a nightmare for the basis team as well as their manager).

SAP maintains its buffer as an additional layer over to the database buffer layer. So something what is not available in SAP buffer, required to fetch from the database buffer layer which once again may required to be fetched from the physical database files. As it is evident in the Screenshot1, that initial record for buffer is performing better than the other parts and has less database access. If your application server and database server is in different hardware (normal trend in 3 tier architecture) you always add an extra process of network i/o between application and database and response time increases.

This is just a preface on the importance of ST02 transaction in SAP. Lot of other questions will play into mind about the architectural summary and the SAP parameters (this is a normal SAP Basis consultant approach – to learn by heart TCODE and parameters) required to be tuned etc. I am preparing my understanding on the same and will do it on next phase.. hope by another couple of days I will be able to do it.

Once again I remind and request, please express your view if you fill I am wrong somewhere, this will help increase my knowledge too.