Basis interview questionsDescribe how SAP handles Memory Management?

ST02 / ST03 In general via table buffers, you could go into the whole Work Process, roll in, roll out,

heap (private) memory, etc. however just as a Unix or DBA admin would know, is you look this up

when needed for the exact specifics.

ST02

ST03

Describe where you would look at the buffer statistics, and what steps you would use to

adjust them?

ST02 and RZ10

Basis Interview QuestionsThe standard list of t-codes is pretty much

SM50, SM51, SM66, SM12, SM13, SM21, DB01, DB02, DB13, ST01, ST02, ST03, ST04, ST05, ST06,

SU01, SUIM, PFCG, SCC4, SE01, SE09, SE10, SPAM, SM35, SM36, SM37, SPAD, SP01 SCC3, SCCL,

SCC9 this are pretty much you heavy hitters for monitoring and support.

DB01: Oracle Lock Monitor

SM13: Update Requests initial screen

SM12: Select Lock Enteries

DB02 : Database Performance : Table and Indexes

Learnings from Remote Client Copy1. Take offline backup just before the activity and switch off the archive logs otherwise, they will

pile up and fill up the filesystem.

2. Execute the Test run before actual activity but it may not give practical results, in our scenario

test run gave 2 hours but actually it took 12 hours for the copy to complete.

3. Lock users both in Target System and Source System, otherwise inconsistencies specially in

number ranges may occur.

4. Take offline backup after Copy and don't forget to switch on archive logs before releasing the

sytem for use.

SAP may remain up during offline database backupWithin an SAP environment, the SAP system may remain up and running during an offline backup to

preserve the buffers of the SAP application servers. All SAP work processes are disconnected from

the database and remain in a reconnect state during the offline backup. After the backup has been

finished, the work processes reconnect to the database using the reconnect feature of the SAP

Database Support Layer (DBSL). - DB2 UDB for SAP Guide

5 steps to configure HADR on db2

Here is all the setup required for HADR

on one slide. Note the steps are quite simple.

Backup database on primary

Restore database on secondary

Set config parms (which are all pretty straight forward, hostname, port to listen on, remote instance

name)

Start standby

Start primary

That’s it!

St02 Call Statistics Hit Ratio

Yesterday we did a test run of client copy from PRD to DEV client. It took 2 hours during peak load.

Today I checked the buffer it is showing hit ration 51% in call statistics the

"Select" is showing only 4-5% hit ration in both PRD and DEV instance.

The above is more or less in both PRD and DEV

servers, then I read one blog and it said :

"Transport activity triggers flushing of SAP buffer. Hence it is always advisable to do transport in the least loaded

segment of a day." -

http://soumen.wordpress.com/performance-tuning-of-sap-another-experiance/5-st02-another-

magic-transaction-for-sap-tuners-ii/

After above scenario, we should take care even test run should be scheduled after peak hours. Any

other suggestions on tuning are welcome.

SAP Tuning – Gather Symtomps.

***************** 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

7. A handy reference for SAP Memory

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

Tuning SAP does always need a considerable range of observation before prescribing or implementing anything on the

system. It needs a considerable amount of patience to listen to the existing tech team, users and over and above all some

managers ( bunch of jokers – never do things right – habitually only manage the scenario). Besides one also need to listen

what system monitoring transactions, system logs, debugging utilities etc are screaming…..

To start with we do need to come across a questionnaire, which must carry some of the following questions…..

When you are experiencing system is slow? during a transaction or during execution of a report or a transaction

associated with a report for generating some online documents? – User

When you are experiencing a slow response? During using of SAP standard Tcodes and Programs or the customised (Z)

Tcodes and programs? – User

What are the available downtime? – Service Level Management

What is your storage architecture? – Release Management…

Are you using some kind of middle-ware product, which provide only complied version of their library routines? – Release

Management

What are the sampling rate of error messages? Do you have some ready made history documents of such ready in hand?

– Basis and Functional consultants.

What is the standard network response between Application level and Presentation level? Basis administrators.

What are the known issues (pardon I am not using the many-referenced phrase known error) with the hardware you are

using, with storage, with the OS, with the middle-ware, Oracle database version and obviously the release and versions of

SAP itself you are using? – system administrator, storage administrator, database administrator, basis administrator and

the fact sheets, notes, whitepapers from the respective vendors. Many already argued on this thought of mine, saying that

this particular set of documents can bias the investigation and then the remedy but believe me it is always better to have

these documents in hand. Otherwise the whole thing may end up in chasing wild goose. Remember whether OEM support

is there or not may bother you heavily when you are going to implement some solution….oh yes even tuning solution…..

Do you have an ABAP program benchmarking existing for the customised ABAP programs? If yes then check the

relevancy of the same with the data growth rate (yes this is very important) else you make your own. I have something of

my own and will be sharing here.

These are some basic things one should gather to undertake a tuning job for SAP. Otherwise, one’s  may land up with some

tuning suggestion which is impractical or not cost effective. In the whole series of these shareable document, I tried to restrict

the suggestions which do not involve additional costing.

ST04 – A Magic Transaction for SAP performance tuning – I

 

 

 

 

 

 

4 Votes

***************** 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

7. A handy reference for SAP Memory

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

I already have expressed that performance of SAP system is depended on many things. Hardware, OS, storage box, storage

agent, clustering agent, database, customized (Z) programs and overall the usage intelligence of the users. But as a basis

tuning expert you might always fill the need of a mirror which will reflect at least the image how your system is being utilized

and behaving. I found SAP transaction code ST04 alone is going to help you out on the same. It basically shows detail face of

the database behave and usage, both history as well as online.

Question may arise saying that why DB? But DB performance will show you all e.g. excess I/O will also point to OS issue as

well as improper load balancing as well as the use of a query or the query itself.

So what are the areas we must look into the ST04? I am writing here the use of the same where ORACLE is used as the

database of SAP.

In the first screen only it shows you a lot of statistics and indications, but my interest is on looking at the data buffer cache size

and quality. Quality must be above 97%, and then apparently there is no major problem. If less than 95 % then it is

problematic. But even a improperly tuned recursive query some time false take your quality value higher than 97%. So there is

always a deeper investigation is required.

My second favorite look is the sort sections. It should be less than 0.1% of total sorts.

Another Important area is to look in the shared pool statistics. DD (data dictionary) cache quality should be more than 99%,

similarly the SQL area get ratio, but if the database is oracle 10.2.0.2 it may show you some abnormally low figure. This is due

to Oracle bug 5452234 and if you need to rectify then need to install the patch set 10.2.0.4.

There is also another interesting data, which is instance performance. There are some interesting statistics which ensures you

the parsing status in the system. They are Soft parse ratio max value is 1 which is not possible because at least once the SQL

is hard parsed and then soft parsed in its next executions. But this must be as close as possible to 1 for a healthy system.

Similarly there is another fact which is in-memory sort ratio; this is for a healthy system should have higher values. In fact the

less the disk sorts the better.

There are a lot of magic in the detail screen, which attracts me in this transaction code. One of the most interesting options

which attract me more is the…This shows an excerpt of the shared cache. Just run the report keeping everything blank.

Normally this gives you a list of SQLs hitting database sorted descending values of disk reads. Yes highly important. The more

use of disk, the more slow the operation. But a very large database system with huge growth rate and lot of customized

program can show you some startling figure here. Not all those programs and SQL statements in the top 10 rows…As a next

step from the same list I will just sort the list in descending order based on the column which shows buffer gets/row. And will

note those programs and SQL statements. A combination of these two will mainly point out which programs/SQLs are main

causes slowing down the performances.

ST04 transaction has another beautiful magic. Click on any of such identified SQL statements, it provides you the plan of

execution and the line of the program from where such SQL …

Today upto this much is enough…….I am in favour providing some screenshot in this article to give a better illustration. Let

see whether that is possible…..I am running this blogsite free..so limited space..

ST04 – A Magic Transaction for SAP performance tunning – II

 

 

 

 

 

 

5 Votes

***************** 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

7. A handy reference for SAP Memory

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

Go to the detail screen of ST04.

This has some exciting buttons – namely – Oracle Session, SQL request, Table access etc….These will actually lead you to

see the facts inside SAP database.. What is happening? Who is killing your SAP? Unless there is a bug in the system, or

some user is selecting parameters abnormally in the any report executing transaction, normally SAP system does not

misbehave or slowdown. At least in that case you can directly refer to SAP support and get it done. Eliminating these two rest

is the customised programs, for which SAP support can be accessed on charge basis.

Remember here you are getting free guidelines on SAP customized program tuning ;)…

Anyway, jokes apart,  out of all those buttons mentioned above, Oracle session is for something what helps to see the actual

session which is being processed whereas SQL request is showing current as well as history of the SQL statements. This SQL

statements are comming out as a result of OpenSQL statements used in ABAP.

Clicking on “SQL Request” button will show you another screen with parameters, keep everything empty there and execute.

Roughly it will bring out most of the SQL statements with their calling program name (remember Program Name not the SAP

Transaction ). The straight method is to

1. Search for those lines which have maximum Disk Read and maximum buffer fetch per record.

2. Now click on each of those line will show you the resource cost of the SQL statement.

3. Also you can go the line of the abap code from the statement is generated.

4. Show the same to the ABAPER and ask to tune. You may also look into the scenario of possibility of creating index or

wrong/incomplete joins and dig further.

5. If you are preparing a report and handover all the problematic situations together then also check out / include those

programs which are using too much buffer but fetching relatively low number of records…These programs slow poisoning

your system, they are not only running inefficiently but also not allowing other programs to use the resources required.

Some of you may raise your eyebrows and say I am not using Top Down Attitude of the tuning…But I storngly belive that if

some thing can be tuned and built better even in incorrect global / system wide parameters, that will run more better in case of

those global / system wide parameters are corrected.

This transaction also have a good button which allows different dynamic performance views (V$) which are a very good

resource for looking into more deep..Memory analyzing etc…..

ST02 – SAP Tuning – Another Magic transaction – I

 

 

 

 

 

 

2 Votes

***************** 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

7. A handy reference for SAP Memory

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

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.

 

Srl

Screen Shots

1

 

2  

3  

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

ST02 – SAP Tuning – Important SAP Parameters – II

***************** 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

7. A handy reference for SAP Memory

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

As I have pointed out earlier the three main points we need to concentrate when dealing with SAP buffer. I am going to discuss one by one of them here.

The first point was whether buffer configuration is correct?

To derive the answer on a TOP level is very easy…use transaction ST02 and then if you see any RED highlighted background figures simply say there is some problem and start investigating on that. So which areas one need to concentrate more for? Need to check where swaps are happening? Is it on the SAP Buffer, Memory or in Call statistics?

The thumb rule for call statistics is very easy; the hit ratio must be above 95% for “Select” and “Select Single”.

The thumb rule for Buffer and Memory is if you see a red highlight you increase it using transaction for viewing and changing profiles (RZ10 and/or RZ11). In fact in most of the cases on the web sites discussing about the ways of mitigating these red highlighted areas in ST02 suggest that. But this is not the right approach. One should go thru the history of such buffers for analyzing the situation. Always remember that an ill planned/calculated increase in the

SAP memory limit and further allocation could stimulate the paging activity and can be fatal in turn. This is especially true in case your central instance and database remain in the same physical server, and remember that database paging is dangerous as far as SAP performance is concerned.

This also needs a simultaneous observation data on the disk I/O, memory I/O and paging activity from the OS side. Requirement is there also to analyze whether your transport schedule are correct or not? Transport activity triggers flushing of SAP buffer. Hence it is always advisable to do transport in the least loaded segment of a day. If you have three-tier architecture with application server a careful observation of SAR reports and trend analysis will show you the same.

Check also the table buffers and the content of the buffers. How many Z table your programmer kept in the buffer? Are they really required? Have you benchmarked the performance of the associated programs before you have buffered the said table?

Some important parameters are listed below as far as changing the parameter is concerned. Use transaction RZ10 and RZ11 for manipulating…Feel this is enough for closing the ST02 topic. Rest everything is depended on the SAP and the Basis Consultaunts intelligence.

1. For Table Buffer or TABLa. zcsa/table_buffer_area – for size of table buffer data area.b. zcsa/db_max_buftab – for directory entries – one for every resident table

2. For Single key table Buffer or TABLEP.a. rtbb/max_tables – Directory Entries – One for each table.b. rtbb/buffer_length – Size of data area

3. Program buffera. abap/buffersize – Only parameter. No of directory entries are calculated automatically.

4. For Screen Buffer or PRES.a. zcsa/bufdir_entries – Directory size – One per screen.

b. zcsa/presentation_buffer_area – Total screen buffer size in KB.5. CUA buffers

a. rsdb/cua/buffersize – total Buffer in KB and no of directories are caluated by dividing the same with 2K.

6. Role and paging buffer.a. rdisp/ROLL_SHM – For role bufferb. rdisp/PG_SHM – For paging buffer

7. Calendar Buffer zcsa/calendar_area

***************** 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

7. A handy reference for SAP Memory

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

https://soumen.wordpress.com/performance-tuning-of-sap-another-experiance/5-st02-another-magic-transaction-for-sap-tuners-ii/

ST03n – The meter gauge for SAP tuning

 

 

 

 

 

 

2 Votes

***************** 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

7. A handy reference for SAP Memory

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

I want to start this with a scorecard. This score card will tell you when and where to look for tuning activities for

your SAp servers and uses different values you actually see using transaction ST03.

SAP Tuning Scorecard - ST03

This is a very handy tip , when we are looking into ST03 transaction. Let us see the ST03 transaction and the

factors mentioned above in the variable1 and variable2 and some definitions of them. You can always find the

relevant information in http://help.sap.com but this is a ready made chart.There are a lot of inside happenings in

a SAP system. A small configuration mistake can slow poison your entire system.CPU time is actually the total

time used by the application server CPU for loading, generating of ABAP source codes and processing screen

from the database information, creati

A handy reference for SAP Memory

 

 

 

 

 

 

1 Votes

***************** 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

7. A handy reference for SAP Memory

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

I wanted to start writing this page for a ready reckoner, when users are reporting slowness in the system. so at

the first level, I tried an impossible i.e. creating a summary line for SAP memory structure and usage which is

actually well elaborated and written in different books, SAP online help etc in a single drawing.

So the above drawing is something which I can always keep on my desk for a ready reference. Apart from this

screen I will also like one to read the SAP Note 103747.