none of the users can logon through SAPGUI

There can be couple of reason for all the dialog work process to be occupied. Some of the reason are

1. System has not been configured to handle enough dialog users

2. Load balancing has not been configured correctly and all users are directed to one app server.
3. SAPLOGON pad configuration of all user is pointing users only to one app server
4. RFC user/s are occupying all the work process as no limit has been set in RZ12. This typically happens with
transactional
RFC calls.(This is most likely the cause SAP has some good parametrs to limit RFC users from occupying dialog
processes)

To your first question about user not been able to login there can be couple of reason

1. Network issue (If its impacting many users/ Users in one region)
2. Archive is full
3. Things I listed above

1. Archiver stuck
2. No free extended memory
3. If you have small size of redo log size (oracle) and only one set of redo logs and if one long running query is being
executed.
Hi Jason,

When users are unable to logon to SAP system through SAP GUI.

We have to logon to OS level and need to perform the below specified tasks.

1) First we need to check the status of WP using DPMON.

2) File system is full or not ( Usr/sap/SID and Oraarch )
3) Database is open or not.
4) Check DB to application connectivity.
5) in DB check the table spaces status.

In the above any one option fails also your unable to access the system.

If still facing the issue need to check with network team.

I hope it will help you.

Regards,

System Slow is a big Task for a SAP system administrator.

First thing is you see what is that system is doing in SM50 is all the work process occupied?

If occupied then you have to see what activity it is carrying out. ( ex Sequential Read it shows some DB issue or
buffer issue)

Then you have to fine tune the System based on this then go to ST03n, ST22, SM21 and find the further cause of the
error.

Performance tuning involves tuning of the OS, DB and SAP.

Parallel have a look at ST06 for CPU utilization, CPU ideal time.

Thanks & Regards,

Balaji.S

also check for high CPU usage, st06

The system displays the current detail data for the largest CPU users, if they choose Detail analysis menu - Goto Current Data - Snapshot - Top CPU processes in the operating system monitor (see also Detail Data of the Operating
System Monitor).

Check the following performance factors in particular:

Display
Procedure

Is a CPU user constantly active?

Check whether the process is in an endless loop.

Is the average load > 3 (more than three processes are waiting for the CPU)?
Check whether all processes with high CPU usage (memlog, r3trans, nwengine, brbackup...) are necessary.

Is the usage of the CPU zero percent?

Check the analysis for the previous hours.

SAP production performance

issue trouble-shooting
Posted on August 12, 2012

If you as an application performance supporter is wondering where you should

start to address a performance issue reported by a SAP user, then this post
might help you to get started.
SAP performance issue trouble-shooting normally involves following steps.

I would like to point out that performance trouble-shooting can be an iterated

process in some complex situations. There is no clear cut between those steps.
How fast can you trouble-shoot a performance issue, it depends on your
experience/knowledge on SAP architecture, application, database, network and
your SAP application and system.
1. Gather information

When a performance issue is reported by a user, we need to gather information.

The user is expected to provide following information as needed based on the
performance scenario:

What is the performance issue/performance deviation? What is expected

runtime and what is the actual runtime?

Which/what program/job/system/server/user is involved in the issue?

When does the issue start in terms of system time?

What is the solution architecture of the program and data flow of the
program?

Are other users experiencing the same issue with the transaction/program
if more than one user are running the transaction?

How was the underlying transaction/program/job executed?

Is there any change on the way which the program/job is executed?

Is the program/transaction processed more volume than normal when

performance issue happens?

Is there any program code changes on the program and when?

Is there any functional configuration changes related the program and

when?

Is this 1 time an user encounters such performance issue?

Is this one time issue or consistent issue? What is the pattern of the

st

performance issue observed?

What is critical level of this issue from business operation point view? This
understanding would not impact method of trouble-shooting.

Based on above information, you then can dig into system to get more
information. For ongoing issue, you can start with SM50/SM66 to verify current
status of a running transaction; based on work processes status showed in
SM50/SM66, you can decide whether there is an need to check system
health(resource, database and application locks etc) etc; you can use ST12 to
catch one or more performance traces depends on the scenario. For
performance issue happened in the past, you can start with STAD/ST03N/SM37
or /sdf/mon to get statistics data. If it is a job, you can use SAP transaction SM37
to check historical run-time information. If sm50/sm66 shows all dialog
processes are busy, then you can conclude this is a system level performance
issue and issue is likely related to resource; If Sm50/sm66 shows only a few sap

work process are active, then you can conclude that system resource is unlikely
a contributor to the issue etc. However, you might come to CPU resource again
since SM50/SM66 only shows SAP processes if further check find no useful hints
or indicate CPU is still a concern. For example, I did see cases where UX level
non-SAP processes are using too much CPU power which is otherwise available
to SAP application and causing performance issue.
2. Verify performance issue
This is to check system data both current and history to validate the data we
collects related to the issue. This is important to correct any assumption,
communication issue related to the performance issue. At this step, you
normally need to get historical and holistic information related to the incident
from job log and performance database of the system etc.
I had experiences where users were reporting run-time issue but the runtime
was actually in historical run-time range etc Production performance incident
is about performance deviation and restoring normal performance of a
program/job. Also, sometimes, performance issue is due to recent changes
which have been done without users awareness.
3. Classify performance issue and identify solution
Now we come to the point to classify a performance issue and identify the
solution to the issue. Classify the issue and identify solution might involve
following steps and actions:

Resource here is referring to system hardware resources (CPU, Memory, storage)

and their configuration/allocation including CPU, memory, IO and sap basis
configuration/setting. Local system is referring to combination of OS + DBMS +

SAP basis components. Remote system/client is referring to SAP client and

another system which the SAP system needs to communicate with. Business
solution/SAP application here is referring to combination of SAP and customer
code related to a business transaction/function. Network issue is referring to
connection and data flow between different systems. Execution issue is referring
to the way a business user execute a SAP transaction/function.

Resource issue.

User consumption issue more resources are utilized by application

and system and system tools

Application/solution itself like program design etc.

Identify improvement opportunity via SAP performance tools

like ST12/ST05, SE30 etc, change solution design/code.

Resources utilization issue

Load distribution issue can cause resource issue

Redistribute system load via tool /SDF/MON etc.

Resource configuration issue & Resource shortage or malfunction

CPU shortage issue(OS06, STAD and/or SDF/MON )-> Bring

more capacity to application server.

Memory shortage issue(ST02, OS06, ST04 etc) -> increase

physical memory.

Space issue(SM21, ST04 and DB02 etc) -> adjust filespace or

tablespace etc.

IO subsystem issue.

Other system configuration like spool, enqueue etc -> adjust

system setting in spool and enqueue etc.

Local system issue.

Table access issue.

Statistics issue ->Update/maintain statistics(system or sap

table) via DB13, RSANAORA tool etc.

Index/table data fragmentation/ordering issue -> rebuild or

reorder the table/index.

System/database parameters issue -> tune corresponding

system or database parameters/setting.

Kernel issue/system bug.

Work with SAP + DBMS vendor + OS vendor to fix system

issue.

Remote system/client issue.

Contact remote system/application owner to fix the issue.

Business solution/SAP application issue.

Standard SAP code/design issue.

Work with SAP for the solution.

Local developed code/design issue.

Identify improvement opportunity via performance tools

code inspector, st12, se30 or ST05 etc.

ABAP issue->fix corresponding expensive ABAP

statements.
Database access issue -> fix corresponding expensive

SQL statements.
Design/configuration issue -> change program

design/related function configuration.

Data volume management issue.

Network issue.

Review data retention period and archiving solution.

Fix network issue.

Execution issue.

End user execution issue.

Educate end business user or introduce system/program level

control.

Deploy/schedule/process issue (database locks etc)

Redeploy/reschedule application/jobs to different time window

or adjust sequence of execution.

Which steps are needed and what step is executed first depends on the
performance issue scenario and your experience. I am just sharing show a
technical road map of a performance issue resolution from technical point view
and not a business process. For example, if an running program is aborted due
to memory issue, then you can directly check resource used by the program in
ST22 and system memory utilization and configuration via ST02, from here, you
can confirm whether this is a resource issue or program issue quite
straightforward, I would cover this in details in my later posting how to trouble

shot job cancellation due to memory issue.

It is important to classify whether the issue is or will be one time
issue/consistent issue. One time performance issue can be due to one-time
system status, abnormal application volume, network status, improper
execution etc. For one time issue, there is no need to make any system/program
level tuning or changes, we just need to rerun the affected
application/transaction again properly. For example, when user is running a large
one-time load in business busy hours this can cause system performance issue
with symptom like CPU shortage, process shortage or/and memory shortage etc,
but this is not a true system resource issue if the performance issue can be
avoided via more strict control on the execution such as time-window and/or
parallelism degrees.
3. Solution implementation and verification
This is to make corresponding change on relevant technical component and/or
the way the application is executed and verify the performance concern is gone
via needed performance tools like STAD, /SDF/MON etc and/or user confirmation.
I am planning to write more posts in this area like how I can know performance
issue is due to program/design, how I can identify performance bottleneck of a
program andhow I can know system is not a root cause of performance
issue etc.

A number of activities are critical at ensuring high availability of the SAP system. These
administrative tasks are usually performed by the SAP system administrator, who is saddled with the
responsibility of ensuring that the system is performing optimally at any point in time. Find following a
brief description of some critical administrative activities associated with the SAP system. This is the
first part of this two part posting.
1. SAP System R/3 System Status Check: Logon Test
The availability of the SAP R/3 system is a pre-requisite for using the SAP system for data
processing. Suffice to say that for you to establish connection to the SAP system at any point in time,
the system must be up and running. A simple way to ascertain this is to try and log on to the SAP
system.

2. Backup Management: DB12

It is recommended that backup of the SAP system and other non SAP (but relevant files) be carried
out daily, weekly and quarterly. There is more to configuring backup jobs or schedule them in the
SAP system. The success or failure of the backup run has to be monitored daily. Backup as it were
is used to guide against data loss, hence, the need to ensure that it is done properly so that you can
recover the system state when the need arises. When a backup run fails, you should immediately
resolve the problem and possibly perform an emergency backup. There must be no room for
procrastination! With transaction DB12, it is possible to check backup status and status of the
archive directory. Also, a recovery report can be generated to ascertain if all backup are available to
perform a restore and recovery operations.
3. Application Servers Status Check: SM51
The application server is one of the components of the SAP system architecture. Typically, the SAP
system architecture consists of the database server, one or more application servers and one or
more presentation servers. The application servers handle the processing of business logic and
used for load balancing, hence, the need for their availability. The application server represents the
runtime environment for the business application of the SAP system. You can use transaction SM51
to display the status of the instances of your SAP system
4. CCMS Alerts Check: RZ20
Normally, thresholds for certain activities are defined in the CCMS monitor. Alerts are generated if
defined thresholds are executed. The CCMS alert monitor displays monitoring data in a tree-like
structure. It is important to review alerts on a regular basis before they degenerate into serious
problems. Transaction RZ20 allows you to centrally monitor all systems in your SAP system
landscape. Using transaction RZ20, all defined alerts can be monitored. Furthermore, the CCMS
monitor provides a current status view and open alert view which displays recent reporting data and
history information respectively.
5. Work processes Status Check: SM51
Work processes are the engine room of the SAP system. A number of work processes exist in the
SAP system and they include Background, Enqueue, Spool, Update and dialog. Work processes are
essential for the effective functioning of the SAP system; hence it is important to ensure that all
configured work processes possess their correct status at any point in time. The SAP administrator
should be able to know when to add or redistribute work process based on trend analysis.
Transaction SM51 provides an overview of work processes
6. Failed Updates Monitoring: SM13
Failed updates are transaction processing activities that are not committed in the database. Suffice
to say that the supposed modification to the database are not effected and does not reflect in the
database. The SAP system administrator needs to critical review such updates. The administration
data for the update request can be used to investigate the reason why an update process
terminated. In the update report overview displayed via transaction SM13, a terminated update has
the status cancelled. It is the responsibility of the system administrator to critically examine the
cause and reprocess the failed update if need be.
7. System Log Review: SM21
The SAP system has its own system log which records events as they occur. These events are well
categorized thus aiding objective analysis. The system log contains error, warning and problem

messages. The application server records events and problems in the system log and has a log that
contains the messages output. The benefit of reviewing the system log is enormous. Serious system
issues can be averted if the system log is well analyzed on a regular basis. You can use transaction
SM21 to access the system log.
8. Jobs Monitoring: SM37/SM35
Some processing activities in the SAP system have serious implication on the performance of the
system. In order to optimize resources and increase performance, some operations are performed at
the background via batch, defined or standard jobs. Background job as it were, is supposed to
perform a particular task. The SAP system administrator must review the status of jobs that have
been defined in the SAP system and consequently investigate any abnormality or failure.
Transaction SM37 provides an overview of jobs and session overview of batch input job is displayed
using transaction SM35.

I dont see SUM is usable to upgrade from EHP4 to EHP5.

This tool is used for 7.1 and 7.3 platform. Below is the place where you can SUM tool.
Upgrading to SAP NetWeaver 7.3
SAP NetWeaver 7.1-based systems
SAP NetWeaver 7.3 systems
SAP NetWeaver 7.3 systems which have PI Adapters (SWIFT, BCONS, ELSTER) installed on top
SAP NetWeaver 7.3 Java Hub systems which have Business Suite 7 applications installed on top
Installing enhancement packages for the following product releases:
o SAP NetWeaver Process Integration 7.1
o SAP NetWeaver Mobile 7.1
o SAP NetWeaver 7.1 for banking services from SAP 7.0
For EHP5 upgrade is possible to use only EHPI tool and nothing else.

We are in the process of analyzing EHP5 upgrade strategy. My question is:

"Is the SUM tool recommended for ECC upgrade from EHP4 to EHP5 or would the EHPi tool just
work fine... i personally haven't read anywhere that it is mandatory to use SUM tool"

Upgrade from EHP3 to EHP5 you have to use EHPi tool.