The questions were taken from SAP course UADM315 (course version 2018 / Q2).
Work process utilization data of all instances of an SAP system
Automatically refreshed information on local work process utilization
The status of an individual work process, for example, waiting, running, on hold, etc.
The process ID of the work process
The program that is currently executed by the work process
Work processes that are started in certain situation and are stopped again when no longer needed
Dialog work processes that can only be used for a specific task
Work processes used to communicate with printer
Work processes used to perform non-urgent changes to a database
How often is the statement executed
Which user is executing the statement
What the contribution is to the system's overall response
Which work process type is executing the statement
Check if load can be distributed to other servers with spare CPU capacity
Check the 'Top 40 CPU Processes' in transaction Operating System Monitor (ST06(n))
Check that there are enough Dialog work processes configured on the instance(s) on that server
Perform a detailed analysis of the memory configuration of the SAP system
Local Work Process Overview (SM50)
Operating System Monitor (ST06)
Global Work Process Overview (SM66)
Workload Monitor (ST03n)
In the cursor cache of the DBA cockpit
In the transaction Operating System Monitor (ST06(n))
In transaction SQL trace (ST05 or ST12)
In transaction Work Process Overview (SM50 and SM66)
Yes, because database request time is measured at SAP instance level
No, because database request time is measured by the database
Its total response time and average response time are high
Its average CPU time and/or database time are high
Its number of steps is very low
Its average CPU time is greater than average processing time
As the timespan between the dispatcher receives a request till he sends out the final response to the front end
As the timespan between the browser sends a request to the backend till he completely rendered the response
As the timespan between the roll-in and the roll-out of a work process is once completed
As the timespan between an ABAP requested is being loaded into the program buffer till the request processing is finished
If it is a database process, you use the database monitor (ST04) and check if this activity can be tuned or moved to another time
If this process leaves 10% or less overall CPU idle time, there is no need for further action because there is still headroom
If it is an SAP work process, you compare the process ID (PID) to the list of transactions in SMSO to find out what activity is causing the load
If it is the SAP gateway process, you might check if update processing can be moved to another instance
The fields specified in the WHERE clause of the SQL statement
How often an SQL statement is executed
The number of database records that will be retrieved
The availability of indexes for the queried tables
Not enough CPU resource available to hold the object in the buffer.
Not enough user activity to preserve the object in the buffer
Not enough space left in the buffer for buffering the new object
No enough directory entries to buffer the new object
LAN check by ping in transaction Operating System Monitor (ST06(n))
Connection test in Work Process Overview (SM5O/SM66)
Trace, in transaction Single Transaction Analysis (ST12). Trace, in transaction Single Transaction Analysis (ST12)
Check Cursor Cache in transaction DBA Cockpit (DBACOCKPIT)
Data that is NOT bound to a specific user context
Authorization data to enable faster user access
Local heap memory in the work process that is not assigned to a user context
Data associated with individual users and their open transactions
CPU memory
Physical memory
OS paging file/OS swap space
File system cache
The database is updated and the buffer of the current application server is invalidated
Changes are written to table DDLOG, which is read at a certain interval to invalidate the buffered content on the other application servers
The buffered table is updated at all application servers and the database is updated afterward asynchronously by report DDLOG
Changes are written to table DDLOG, which is read at a certain inten/al to update the content of the database
Synchronous RFC (sRFC)
Asynchronous RFC (aRFC)
Transactional RFC (tRFC)
Background RFC (bgRFC)
Synchronous RFC (sRFC)
Asynchronous RFC (aRFC)
Transactional RFC (tRFC)
Queued RFC (qRFC)
If the table is larger than 1MB
If the table experiences many invalidations
If the table is already buffered in the database buffer
If the table is frequently accessed
Roll wait time
Roll out time
Processing time
Time to establish the RFC connection
Database request time
Wait time
Roll-in time
Enqueue time
Rendering time
Design time
High CPU utilization near 100%
High swap/paging activity
High database time
High wait time
If there is one instance on one host, only one SAPOSCOL process is required
If there are multiple instances on one host, multiple SAPOSCOL processes are required
If there are multiple instances on one host, only one SAPOSCOL process is required
If there are multiple virtual hosts, only one SAPOSCOL process is required
An SAP proprietary standalone program for collecting Operating System usage information
An alternative to transaction Operating System Monitor (ST06(n)) for non-ABAP systems
The built-in tool in ABAP systems for collecting Operating System usage information
A third party tool for collecting Operating System usage information
RFC client profile
RFC server profile
RFC client-destination profile
RFC server-destination profile