Performance Optimization

Introduction
Where to start??? --> Identify the problem, Check the
obvious, Create Recommendation List, Apply
Recommendations, and Verify the Tuning Results
System Check

Transactional Overview

ST02: Buffer Area

ST03:Workload Analysis
ST04: Database Performance Analysis
ST05: Trace Analysis
ST06: OS Monitor
ST07: Application Monitor

BASIS System Analysis Report

Questions/Comments

DB01: Exclusive Waits

DB02: Database Space Statistics
SM12: Shared Lock Entries
SM13: Update Records
SM21: System Log
SM50: Work Process Overview
ST22: Dumps Analysis

Where to Start?
Strategy
Identifying Performance Problems
Performance Questionnaire

Check the obvious transactions

Create a Recommendation List
Apply Recommendations
Verify the Tuning Results
Start to Create a new Recommendation if
problem persists

Identify Performance Problem

Ask Consumer Detailed Questions about the
Problem
Use the Performance Questionnaire if helpful handout
Find out the impact ($$$, not able to ship, no
invoices printing, etc)
Contact Business Liaison and Web page to
check if this is the only recording of the problem

Check the Obvious

Transactions - SM12

Lock entries are system objects in charge of protecting

the integrity of the data by synchronization, so the
users cannot modify the same data at the same time
Reasons for locks: abnormal termination of gui,
inactive gui, and problems in update processing
Fields: Client, User, Time, Shared Table (more then
one user locked table), and Lock argument (fields
used by the lock entry)
Use TEST Transaction carefully for extra menu
(logging of updates and error resolution).
Diagnosis Menu will allow you to test for enqueue
problems

Check the Obvious

Transactions - SM13
Able

to display the system update

records with error status or have not yet
been processed
If there are update errors, you may
activate the updates. (Please consult
with user before doing so.)
Before doing so, activate the updates in
test mode.

Check the Obvious

Transactions - SM21

4 types of system logs types:

Local logs: displays only the logs on the current application server
Remote system log: displays logs on a server other than the one you are on
All remote system logs: Displays the logs for all the SAP instances which make up
the SAP system.
Central Logs: difference from the previous option is that a central place collects the
log messages by all application servers which have been configured to send their
messages
Size of system log is defineable in parameter: /rslg/max_diskspace/local and central and
is located in /usr/sap/SID/SYS/global
In the user field you can put CPIC or SAPSYS to see:
CPIC: can display log events which are initiated by SAP instances at the request of
other instances
SAPSYS: to display messages generated by the background processing system
If user id is blank, this indicates system messages such as startup or shutdown logs
To download a list of available system log messages, run the ABAP report RSLG0011

Check the Obvious

Transactions - SM50/SM66
Check to make sure :
there are available work processes via SAP or OS
no work processes are stopped or being hogged by a single user
none of the work processes are in PRIV status
Priv mode means that a work process has been reserved for a
private use in a particular ABAP requiring a large paging area
check for no long running ABAPs
CPU time on each individual work processes

SM66 will allow you to see the following if configured

memory usage
RFC usage
reason for waiting process if configured

Check the Obvious

Transactions - ST02

Information is displayed only for the system you are logged onto
Hit Ratios should be close to 100% for optimal performance
Free space is the available space in the buffer. It is a good
indicator for correct sizing
Swaps occur when an object has to be taken out of the buffer
for making room for another object
SAP recommends allocating more memory to the buffers rather
than distributing it to the database
Use current parameters to determine what parameters to
increase

Check the Obvious

Transactions - ST03

Average response time should fall below 1500 milliseconds (SLA

states 2000 milliseconds for dialog)
CPU time is the total CPU time needed for completing the SAP
process requests. The ratio between the CPU time and the elapsed
time should not fall below 5%
Average wait time should fall below 100 milliseconds -- high wait
times can indicate in sufficient work processes
Time per database request measures the performance of the
database. Direct reads should not exceed 10 milliseconds and
sequential reads should be below 40 milliseconds
STAT is located in this transaction; it will allow you to look at a
specific transaction statistical data today
Compare recent data to see if anything is different from the day
before

Check the Obvious

Transactions - ST04

Primary focus on overall buffer quality. Should be in high

nineties.
Sync Buffer Quality should be in nineties
Catalog Cache Quality should be in high nineties
Package Cache Quality should be in high nineties
To improve the parameters review Liwens documentation
Any deadlocks which occur should be reported to business to
optimize ABAP
Number of IO Cleaners and Servers should not be set to the
default value of 6 (calculate by number of disks and CPUs)
You can review database parameter changes to evaluate
performance optimization

Check the Obvious

Transactions - ST05

Important tool for analyzing programs with database

access problems
Be extremely careful of leaving on and filling
/usr/sap/SID
Make sure of the following: user logged-on once, on
the same server as the user, and no background or
updates running for this user
Monitors only accesses to the database
Look for the longest running step in trace

Check the Obvious

Transactions - ST06

CPU Utilization is divided into user, system, and idle. These values
indicate:
User: being consumed by processes such as R/3 work processes or
database processes
System: Being consumed by the operating system
Idle: Not being consumed at all - should be at least 20%
If load is greater then 3, consider tuning ABAP or buying faster CPUs
Field count indicates the number of processors
Load average is the average number of work processes waiting for a
free processor and is indicated for the previous 5, 10 and 15 minutes
Swap space should be 2-3 times larger then main memory
Disk with constant highest response time should be evaluated and
information should possibly be redistributed
It is possible to do LAN PINGS through ST06

Check the Obvious

Transactions - ST07

Allows you to look at load profiles for application

modules
Much of the information found here is elsewhere but
is grouped together for module evaluation
Allows one to look at active users by groups
(performed transaction the last 30 seconds)
Able to look at pretty pie charts for Dialog steps,
response time, db time, and cpu time according to
application module

Check the Obvious

Transactions - ST22

Short dumps are are kept in a special table

called SNAP which must be frequently
checked to see if it is full of extents
Overview Menu will allow you to view via
client, user id, system, etc..
Statistics will allow you to see the size of
the SNAP table used
To delete old SNAP entries, GOTO ->
Reorganize

Check the Obvious

Transactions
DB01
Exclusive lock waits occur when a user locks a row in a table

(i.e. with an update statement) and another is also trying to lock

the same row that user has to wait until the first user releases
the row
Database locks are necessity and should not be regarded as
performance problems.
To eliminate database locks:
you can kill an external process (outside R/3) if it is holding the lock
(be very cautious)
Check with the user to see if the program is still working properly
Work with the ABAPers to determine if the programs are running
parallel locking the row
Check if Batch job is running which could be holding the lock

Check the Obvious

Transactions - DB02
Can

use this transaction to quickly look

at table space statistics instead of
control center
Detailed tracking of containers and
tablespaces
History of database growth
Determine if there are missing indexes

Create a Recommendation List

Make a list of possible recommendations

with:

what change is recommended

the chance it could be the silver bullet
what risk is associated
if system needs to be recycled

Give recommendation to Senior Technical

Staff/Management

Apply Recommendation

When applying the recommendation, always

have a backout plan in case the
recommendation backfires
If possible, try to eliminate the risk by
implementing the change to all development
systems before putting into production
If a production fix, work with Sue Leach to
create a change ticket -- allow ample time

Verify the Tuning Results

Try to quantify the changes you have made.

Dont hesitate to start over if the problem persists. Often times the problem is
resolved by a bunch of small fixes instead of the silver bullet