There can be couple of reason for all the dialog work process to be occupied. Some of the reason are
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.
In the above any one option fails also your unable to access the system.
Regards,
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.
Parallel have a look at ST06 for CPU utilization, CPU ideal time.
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).
Display
Procedure
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.
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?
Is this one time issue or consistent issue? What is the pattern of the
st
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 issue.
IO subsystem issue.
issue.
statements.
Database access issue -> fix corresponding expensive
SQL statements.
Design/configuration issue -> change program
Network issue.
Execution issue.
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
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.
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.