Basis interview questions

Describe 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 Questions

The 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 Copy

1. 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 backup

Within 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
Thats 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-anothermagic-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, ones 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 theThis 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 rowsAs 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 recordsThese 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 tuningBut 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,
HuhLook 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.

S
rl

Screen Shots

***************** 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 easyuse 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 manipulatingFeel this is enough for closing the ST02 topic. Rest
everything is depended on the SAP and the Basis Consultaunts intelligence.

1.
a.
b.
2.
a.
b.
3.
a.
4.
a.
b.
5.
a.
6.
a.
b.
7.

a.

For Table Buffer or TABL

zcsa/table_buffer_area for size of table buffer data area.
zcsa/db_max_buftab for directory entries one for every resident table
For Single key table Buffer or TABLEP.
rtbb/max_tables Directory Entries One for each table.
rtbb/buffer_length Size of data area
Program buffer
abap/buffersize Only parameter. No of directory entries are calculated
automatically.
For Screen Buffer or PRES.
zcsa/bufdir_entries Directory size One per screen.
zcsa/presentation_buffer_area Total screen buffer size in KB.
CUA buffers
rsdb/cua/buffersize total Buffer in KB and no of directories are caluated by dividing
the same with 2K.
Role and paging buffer.
rdisp/ROLL_SHM For role buffer
rdisp/PG_SHM For paging buffer
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-st02another-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.