ST03N Workload Monitor

Workload Monitor
PDF download from SAP Help Portal:

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/2d/b8be3befaefc75e10000000a114084/frameset.htm
Created on April 30, 2014
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
2014 SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC
2014 SAP AG or an SAP affiliate company. All rights reserved.
Page 1 of 27
Table of content
1 Workload Monitor
1.1 Operating the Workload Monitor
1.1.1 User Mode
1.1.2 Structure of the Workload Tree in the Workload Monitor
1.1.3 Analysis Views of the Workload Monitor
1.1.3.1 Workload Overview
1.1.3.2 Displaying Transaction Profiles
1.1.3.3 Displaying Transaction Details
1.1.3.4 Displaying Application Statistics
1.1.3.5 Displaying the Time Profile
1.1.3.6 Hitlists: Display 40 Worst Response Times
1.1.3.7 Displaying Memory Usage Statistics
1.1.3.8 Displaying RFC Profiles
1.1.3.9 Displaying User Profile and Account Statistics
1.1.3.10 Displaying Front End Statistics
1.1.3.11 Displaying Spool Statistics
1.1.3.12 Displaying the Response Time Distribution
1.1.3.12.1 Response Times: Rough Guide
1.1.3.13 Displaying Database Procedure Calls
1.1.3.14 Displaying Table Access Statistics
1.1.3.15 Displaying Load from External Systems
1.1.3.16 Displaying Web Statistics
1.1.3.17 Displaying Database Connection Statistics
1.1.3.18 Displaying VMC Statistics
1.1.4 Displaying a Business Transaction Analysis
1.1.5 Displaying the Last Minutes Load
1.1.6 Displaying the Workload History and Workload Distribution in the
1.1.7 Displaying Users per Instance
1.2 Configuring the Workload Monitor
1.2.1 Controlling and Monitoring the Generation of Statistics Data
1.2.2 Displaying and Deleting Contents of the Workload Collector Datab
1.2.3 Displaying and Changing the Scheduling of Performance Collectors
1.2.4 Reorganizing and Monitoring the Monitoring Database MONI
1.2.5 Saving User-Specific Views
PUBLIC
Page 2 of 27
1 Workload Monitor
Purpose
You can use the workload monitor (transaction ST03) to analyze statistical data for the ABAP kernel. If you are analyzing the performance of a system, you should
normally start with the workload overview. You can also display the total values for all instances, and compare the performance of particular instances over a
period of time. A wide range of analysis views and data helps you to find the source of performance problems quickly and easily.
You can use the workload monitor to display the following, among other things:
Number of instances configured for your system
Number of users working on the different instances
Response time distribution
Distribution of workload by transaction steps, transactions, packages, subapplications, and applications
Transactions with the largest response times and database time
Memory usage for each transaction or each user per dialog step
Workload caused by RFC, broken down by transactions, function modules, and destinations
Number and volume of spool requests
Statistics about response time distribution, with or without the GUI time
Optional: table accesses
Workload and transactions used by users, broken down by users, accounting numbers, and clients
Workload generated by requests from external systems
The following applies to all of this data:
You can display data for any instance (not only the instance that you are logged onto), or optionally summarized for all instances.
Depending on the user mode, you can choose the period for which you want to display data between day, week, and month, or specify the Last Minutes Load
as you require.
For most analysis views, you can display all or only certain task types.
Features
The workload monitor has an interface that is divided into two parts. Use the tree structures on the left to make the following settings:
Select the user mode
Select the period for which you want to display the workload
Select different functions and analysis views (which data do you want to display?)
The system then displays the result on the right in a standardized ALV Grid Control. You can use this to:
Adjust the layout of the data output
Find any information using sort and filter functions
Save user-specific views
Display statistics graphically
More information:
Operating the Workload Monitor
Configuring the Workload Monitor

1.1 Operating the Workload Monitor
Use
The Workload Monitor (transaction ST03) is a one-screen transaction that has as few additional menus as possible. This makes operation significantly easier and
more intuitive.
Features
PUBLIC
Page 3 of 27
Activities
The individual screen elements of the workload monitor have the following meanings:
Navigation Area
Choose any icon by double-clicking it:
Function Meaning
Workload
Depending on the user mode, you can define the instance and the period that you want
to analyze here.
Detailed Analysis
These functions read the workload directly from the statistics files of the individual
instances.
Business Transaction Analysis
You can perform a very precise analysis of individual transactions here, down to the level
of individual steps.
Last Minutes Load
You can use this function to analyze the unaggregated workload data that has not yet
been written to the database.
Load History and Distribution
Workload History
Instance Comparison
Users per Instance
With these functions, you cannot display the workload for a particular instance and a
particular period (as in the other workload monitor functions), but rather compare the
workload of different instances or periods.
Display the most important data together therefore allows a direct comparison of the
instances.
Collector & Perf. Database
Among other things, you can use this function to define which values the statistics
collector collects, how often, and how long they are to be retained in the database in what
time resolution.
Analysis Views
An analysis view displays a particular aspect of the workload. In the Analysis View subscreen, choose the view that you want to analyze by double-clicking it.
Only the analysis views that are active in the selected user mode and for which data exists are displayed.
Output Area
The output area uses an ALV Grid Control, with which you can greatly tailor the selected view to your requirements. For most load parameters, the workload
monitor displays more data fields than are required for your analysis. You therefore have a considerable amount of help available in the output area to find the
information relevant for you:
The data of most analysis views is grouped in the results area by tab pages for different topic areas.
To obtain an overview of which data fields exist for an analysis view, choose the All Data tab page.
Using the standard functions of the ALV Grid Control, you can execute the following commands:
Show and hide columns
Sort rows by the contents of a column
Set and delete filters
Perform summations
Export tables as a file type of your choice
Display tables as graphics
Save sort orders, filters, and selected columns as your layout
Editing Views
PUBLIC
Page 4 of 27
Choose one of the following buttons in the Edit Views screen area:
Button Meaning
( Save View )
Saves the current view as your initial screen for the workload monitor (see also Saving
User-Specific Views)

(Previous View)

( Next View )
Moves one view forward or back in the view history
Full Screen On/Off Shows or hides the navigation bar and the available analysis views on the left of the
screen
Workload Monitor start page

1.1.1 User Mode
Definition
The user mode determines the view of the statistics data of the workload monitor (transaction ST03). The design was conceived with different users in mind, so that
the system displays different functions and time periods of monitoring, depending on the user mode you choose.
Use
There are two different user modes. Each shows different information.
Service Engineer mode
This mode provides you with the workload statistics for the current day and for the previous week, as well as an overview of the workload history and
distribution, and a detailed analysis of the workload. This user mode is set up especially for SAP Service.
By default, the system displays all statistics for all application servers.
Expert mode
This mode provides users with all of the functions available in the workload monitor. You can display all available workload data (daily, weekly, and monthly
data).
Integration
The user mode that you choose determines the functions that are displayed on the initial screen of transaction ST03.

Structure of the Workload Tree in the Workload Monitor
Definition
In the workload tree, the workload monitor displays a hierarchy of two or three levels in the Functions subtree, depending on the selected user mode. You can
use this to quickly define the instance and period for which you want to analyze the workload. You can also optionally use the TOTAL entry (see also Controlling
the Generation and Retention Period of Statistics Data) at instance level. This displays the workload for all instances of the system.
Structure
Depending on the selected user mode, you can decide for what period of time and which instance you want to analyze the workload.
Mode Workload Tree Structure Explanation
Service Engineer Previous Week/Today
<Instance>/TOTAL
The system displays a two-level hierarchy in which you
select first the period and then the desired instance.
Expert
<Instance>/TOTAL
<Period>
<time period>
The system displays a three-level hierarchy in which you
select the instance, then the period to be investigated
( Day , Week , or Month ), and finally the actual time
period.

Analysis Views of the Workload Monitor
PUBLIC
Page 5 of 27
Definition
An analysis view is a particular aspect of the workload. Depending on which aspects of the workload you are interested in, you can display various workload
parameters, sorted by different sort criteria (such as by users, transaction steps, RFC destinations, and so on).
Use
To activate a particular analysis view, choose the desired view in the Analysis Views subscreen by double-clicking it.
Structure
The following analysis views are available:
Analysis View Description
Workload Overview
Workload distribution for the individual task types
Transaction Profile Most important performance data for all executed transactions; you can also output the
data for summarization levels Packages , Subapplications , or Applications
Application Statistics Statistics about workload distribution within a transaction step (activation at transaction
level required)
Time Profile
Temporal distribution of transaction steps over a day; this allows you to easily identify
periods of higher and lower workload
Hitlists The 40 transaction steps with the highest response time and database time; the same
hitlists also exist for application statistics
Memory Usage Statistics
Average and maximum memory per dialog step for each transaction and each user
RFC Profiles Workload caused by Remote Function Calls on the client- and server-side, broken down
by transactions, function modules, or destinations
User Profile and
Account Statistics
Workload broken down by users, account numbers, and clients
Frontend Statistics
Volume of data sent and received and the frontend processing times of the individual
presentation servers
Spool Statistics
Statistics about the number and volume of spool requests
Response Tie Distribution
Statistics about the distribution of the response times, showing what percentage of the
system requests were dealt with in what time (with or without GUI time)
Table Access Statistics
Workload, broken down by table accesses (optional)
Load from External Systems
Workload for a system caused by requests from other systems, broken down by
systems, actions, or users
DB Procedure Calls
Statistics about the called database procedures, optionally broken down by the calling
transaction
Web Statistics
Workload caused by Internet calls, on the client- and server-side, broken down by hosts,
transactions, users, or the URL
DB Connection Statistics
Workload caused by database operations, broken down by the current database
connection in each case, or by the calling transaction
VMC Statistics
Workload due to the operation of the VM Container: Resource usage and time usage
by VMC actions (Garbage Collection, and so on)
You can use various analysis views, depending on the user mode you have selected:
User Mode Service Engineer Expert
Possible Analysis Views Workload overview
Transaction profile
Application statistics
Time profile
Hitlists
Memory usage statistics
RFC profiles
User profile
Frontend statistics
Load from external systems
DB procedure calls
Web statistics
DB connection statistics
Workload overview
Transaction profile
Application statistics
Time profile
Hitlists
Memory usage statistics
RFC profiles
User profile
Account statistics
Frontend statistics
Spool statistics
Load from external systems
DB procedure calls
Web statistics
DB connection statistics
VMC Statistics
PUBLIC
Page 6 of 27

1.1.3.1 Workload Overview
Definition
The workload overview displays data about the workload that is written by the SAP kernel and displayed with the workload monitor (transaction ST03). The
workload overview provides system administrators with various detailed information about the most important workload data, such as the CPU time, the number of
database changes, the response times, and so on.
Structure
You can display the workload overview for all task types ( Dialog, Background, RFC, ALE, and Update ), or only for one particular task type. The system
displays the following data:
In the case of the HTTP task type, the workload is, by default, not displayed broken down by applications or pages (URLs). Instead,
SAPMHTTP is used as a dummy name. If you require a relevant breakdown, choose the following path in the navigation bar:

Collector and
Performance DB Workload Collector

Parameters , and choose the desired radio button in the Created Profiles group box.
Information Explanation
Average CPU time Average time that a work process uses the CPU; during a dialog step, the CPU of the
application server is used for processing (loading, generating, processing database
requests, ABAP processing, and so on).
The CPU time is determined by the operating system. At the end of a transaction step,
the SAP work process queries the CPU time from the operating system. The CPU time
is therefore not an additive component of the response time, unlike the wait time, roll in
time, load time, and database time.
Average response time Average time between the time at which a dialog process sends a request to a dispatcher
work process, and the time at which the dialog is complete and the data is transferred to
the presentation layer.
The response time does not include the time for transferring the data from the SAP front
end to the application server. Networks with bad performance can therefore have larger
subjective response times. The transfer time is included in the GUI time and the front
end network time.
Average wait time Average time an unprocessed dialog step waits in the dispatcher queue for a free work
process.
Under normal circumstances, the dispatcher work process should pass a dialog step
immediately after receiving the request from the dialog step. In this situation, the average
wait time should be only a few milliseconds. If the application server or the entire system
is under a heavy load, this can lead to traffic jams in the dispatcher wait queue.
Average Load and Generation Time Average time required to load and generate objects such as ABAP source code and
screen information from the database
DB Calls Number of parsed accesses to the database
DB Access Number of logical ABAP accesses to data in the database; these accesses are made
through the SAP database interface and are parsed into individual database calls.
The ratio of database calls to database accesses is important. If the access to information
in a table is buffered in the SAP buffers, no database calls to the database server are
required. The ratio of calls/accesses therefore gives a good indication about the efficiency
of the table buffering. A good ratio would be 1:10.
GUI Time Response time between the dispatcher and the GUI during the roundtrips (roundtrips are
communication steps between the SAP system and the front end during a transaction
step)
Roll ins Number of rolled-in user contexts
Roll outs Number of rolled-out user contexts.
Roll In Time Processing time for the rolling in of user contexts
Roll Out Time Processing time for the rolling out of user contexts
Roll Wait Time Wait time in the roll area.
If synchronous RFCs are called, the work process performs a roll out and waits for the
end of the RFC in the roll area. The RFC server programs can wait for other RFCs to be
sent to them in the roll area.
Average Time per Logical Database Call Average response time for all commands sent to the database system (in milliseconds).
The time depends on the CPU capacity of the database server, the network, the
buffering, and on the input/output capabilities of the database server. The access times
for buffered tables are far faster and are not considered here.
You can restrict the display to a particular task type. The task type depends on the task of the associated application process and is an identifying element of
every statistics record. There are the following task types:
PUBLIC
Page 7 of 27
Task Type Explanation
AUTOABAP Automatically-processed report (for example, for monitoring tools)
B.INPUT Transaction step in batch input mode; it is processed by the dialog work process (update
dialogs generated in batch input are always processed synchronously, they belong to the
UPDATE task type).
BACKGROUND Transaction step that was started by a background processing work process.
BUFFER SYNC A synchronization of the local table buffers regularly requested by the SAP system (the
time interval is controlled by the profile parameter rdisp/bufreftime).
DIALOG Usually a transaction step started online by a user (for example, editor dialogs or manual
postings).
RFC Remote Function Call in the ABAP system; it is processed by the dialog work process
CPIC Other communication using the CPIC interface; it is processed by the dialog work
process
SPOOL Transaction step of a spool work process
UPDATE Transaction step of the SAP update task; it is automatically started by the dispatcher on a
host with an active update process (update processes are usually installed on the
database host)
UPDATE2 V2 update
ALE IDoc processing; it is processed by the dialog work process
LCOM The Fast RFC (fRFC or LCOM-RFC) is a very fast form of data transfer that uses a
shared memory pipeline. It is only used in internal communication between ABAP and
Java in the SAP Web AS.
HTTP, HTTPS, NNTP, SMTP, FTP Requests from the ICM that are based on the corresponding Internet protocols
ENQUEUE Enqueue handler
DIALOG(-)GUI Dialog without GUI
EXT.PLUGIN
AUTOTH ( Auto task handler)
RPCTH (Task handler remote procedure call)
RFCVMC (RFC inside VMC)
DDLOG CLEANUP
DEL. THCALL (Delayed task handler call)
AUTOJAVA
HTTP/JSP, HTTPS/JSP
The statistical evaluations of these task types are only relevant for internal SAP
purposes.
The task types therefore correspond to the work process types with the exception of the task types RFC , CPIC , ALE , AUTOABAP , and BUFFER SYNC ,
which simply represent specific applications in the dialog work process. TOTAL is the total across all task types.
Background Information
The response time is usually split into wait time plus execution time. The SAP response time consists of the following components:
Response time = wait time + execution time
where: execution time =
Generation time during the run
+ Load time for programs, screens, and graphical user interfaces
+ Roll times for rolling in the work data
+ ABAP processing time
+ Database time
+ Enqueue time for logical SAP lock processes
+ CPIC/RFC time
+ Roll wait time (excluding task types RFC/CPIC/ALE).
The CPU time is not an additive component of the response time, but rather the total of the CPU time used by the individual components. The CPU
time is therefore additional, separate information about the response time.

1.1.3.2 Displaying Transaction Profiles
Use
In the workload monitor, you can display the workload in different analysis views which highlight the workload from a particular perspective. One of these aspects
is the question of which transactions cause which workload.
Prerequisites
If you want to display the transaction details for specific transactions, you need to activate the Transaction Detail Profiles for these transactions first (see:
Displaying Transaction Details).
PUBLIC
Page 8 of 27
Procedure
1. Start the Workload Monitor by calling transaction ST03.
2. In the Workload tree, choose the instance and period to be analyzed.
3. Choose Analysis Views Transaction Profile.
4. Choose the desired analysis view: Standard , EarlyWatch , or Details .
5. The system displays the usual output area, in which the requested transaction profile is displayed.
Result
In the Standard and EarlyWatch analysis views, the output area shows the most important workload data, broken down by transactions executed. You can use
the Task Type dropdown menu to restrict the view to a particular task type.
You can choose the different levels of data aggregation using the Aggregation dropdown menu. By default, the system displays the Transaction level.
Depending on the level that you select, the data is summarized in accordance with the component hierarchy by:
Packages (previously: development classes)
Subapplications (BC-CCM)
Applications (BC, FI, CO, and so on)
You can display more information for a data record by double-clicking the line for the corresponding transaction profile. The system opens a second window to
display this detailed data. You can also choose different levels of data aggregation here although the level in the detailed view can be at most one level beneath
the level in the main view. The entries that you cannot choose in the dropdown menus are grayed out.
You require a special authorization (profile S_TOOLS_EX) to display user-specific detailed data.
As long as you are displaying daily data for the current day, the system displays the Single Records button. You can use this button to directly call the
transaction STAD with the selection parameters Instance , Transaction/Report , and, if necessary, User .
There are three transaction profiles with the following special features:
Transaction Profile Special Features
Standard None
EarlyWatch Different combination of the individual values
No task type selection
You can switch between average values per transaction step and average
values Logical Unit of Work (LOW) of a transaction
Details Analysis of individual transaction steps of a transaction (see Displaying Transaction
Details)

1.1.3.3 Displaying Transaction Details
Use
The dialog step statistics in the workload monitor allow you to analyze individual transaction steps of a transaction by their function codes. This analysis does,
however, require detailed knowledge of the function codes of the relevant application. Therefore, it is only makes sense to activate the Transaction Detail Profile
when analyzing actual problems and it is deactivated by default.
There are various parameters for the dialog step statistics that you can set for specific analyses if required. Note, however, that activate these parameter means
that significantly more statistics records are written and that the load caused by the statistics collector can significantly increase.
You should therefore change the values of the parameters only temporarily for individual analyses, since the number of statistics records can
significantly increase, and this can lead to performance problems in the statistics collector.
Prerequisites
To display dialog step statistics for individual transactions, you first need to activate this:
2. Choose the Expert user mode.
3. Choose Collector & Performance DB Workload Collector Parameters
4. The Selection of Data to Cumulate dialog screen appears. Enter the transaction codes for the transactions to be analyzed in detail in the Create transaction
detail profiles for group box.
5. Save your changes.
Procedure
2. Choose the instance and period to be analyzed by double-clicking.
PUBLIC
Page 9 of 27
3. Choose Analysis Views Transaction Profile Details <transaction code>.
4. The system displays the usual output area, in which the requested workload is displayed.
If no dialog step statistics are available for the specified instance or period, the system does not display the icon for the details.

1.1.3.4 Displaying Application Statistics
Use
The application statistics allow you to analyze resource consumption in more detail than the workload monitor. Using special calls within the ABAP coding, the
system collects statistics for individual parts of an application. While the workload statistics always analyze a complete dialog step, you can use the application
statistics to analyze the resources used by an individual function within a dialog step (such as price determination). In some cases, the application statistics can
therefore replace an SQL trace.
The statistical data collected by the application statistics is the same as the workload statistics (response time, and so on).
Prerequisites
To use the application statistics, corresponding function calls must be implemented in the application programs. No data can be collected for application statistics
without these calls. You also need to ensure that the following profile parameter values are set:
stat/as_level = 1
stat/as_collect = 2
You must also have scheduled the collector for the application statistics. In addition, you need to activate the individual components of the application statistics, by
calling transaction ST03 and choosing Collector & Performance DB Statistics Records + File Application Statistics .
Procedure
3. Choose Analysis Views Application Statistics.
4. The system displays the usual output are, in which the requested workload is displayed.
If no application statistics are available for the specified instance or period, the system does not display the icon for application statistics.
Result
The output area contains the desired workload data, broken down by transaction. To display the data broken down by users, double-click a line.
You require a special authorization (profile S_TOOLS_EX) to display user-specific data.

Displaying the Time Profile
Use
is the question of how the workload is distributed over the hours of the day.
The time profile displays the temporal distribution of transaction steps over a day, meaning that you can easily identify periods of higher and lower workload. The
time profile therefore displays the workload grouped by the hours of the day.
Procedure
3. Choose Analysis Views Time Profile .
4. The system displays the usual output area, in which the requested distribution of the response times is displayed in an ALV Grid Control.
PUBLIC
Page 10 of 27
Result
The output area displays the most important data about the workload, broken down by the hours of the day.
By default, the Time Profile analysis view displays all task types. By selecting an entry in the Task Type dropdown menu, you can restrict the display to the
desired task type.
You can display the executed transactions in the relevant period by double-clicking a line.

Hitlists: Display 40 Worst Response Times
Use
is the question of which dialog steps and application steps have the longest response and database times. These are the hitlists. There are two hitlists of this type
for the dialog statistics and for the application statistics:
Hitlists for Dialog Step Statistics
These hitlists list 40 transaction steps for each task type. There are hitlists for the transaction steps with the largest response time and those with the largest
database time.
Hitlists for Application Statistics
These hitlists list 40 application statistics steps for each task type. There are hitlists for the application statistics steps with the largest response time and
those with the largest database time.
The hitlists therefore allow you to identify the transaction steps that use most resources.
Using the hitlists, you can answer the following questions, among others:
Is it always the same program that has high response time?
Is this program running at the same time in several sessions (locking work processes)?
How many kilobytes of information were transferred?
Could the program be started at night in the background?
Procedure
2. Choose the appropriate user mode. You can essentially display hitlists in any user mode, but the time period is also restricted for hitlists through the
selection of the user mode.
4. Choose Analysis Views Hitlists .
5. Choose the desired hitlist.
6. To display more details, choose a line in the table by double-clicking it.

1.1.3.7 Displaying Memory Usage Statistics
Use
In the workload monitor, you can display the workload in different analysis views which highlight the workload from a particular perspective. One of these
perspectives is the question of the average or maximum values for the memory usage for a particular transaction or a particular user per dialog step.
Procedure
2. Choose the appropriate user mode. Essentially, you can display the memory usage statistics in any user mode, but the restriction of the time period due to
the selection of the user mode also applies to the memory usage statistics.
4. Choose Analysis Views Memory Use Statistics.
Result
The output area contains two tab pages with the following characteristics:
PUBLIC
Page 11 of 27
Tab Page Properties
Transactions The memory usage is sorted by the transactions executed during the analysis period.
Double-click a line to display the memory usage of the selected transaction sorted by
user.
User The memory usage is sorted by the user logged on during the analysis period. Double-
click a line to display the memory usage of the selected user, sorted by transactions.
A special authorization (profile S_TOOLS_EXE) is required to display user-specific data.

1.1.3.8 Displaying RFC Profiles
Use
is the workload caused by Remote Function Calls (RFC).
By displaying the RFC profiles, you can answer the following questions:
Which transaction, which function module, and which user caused what workload through RFC calls as an RFC client or an RFC server?
What workload do the transactions, function modules, or users cause in which local or remote RFC destinations?
For transaction steps with RFC, the kernel writes subrecords with additional information about the processing time, the destination, and the function
module used. The parameter stat/rfcrec (default: stat/rfcrec = 5) specifies the maximum number of subrecords of each type (RFC client, RFC
server, RFC client destination, and RFC server destination) that the kernel writes. If more RFCs are performed during a transaction step, only the
five calls with the longest execution time are therefore logged, Which is sufficient for performance analyses. The restriction to a maximum of five
records represents a compromise between the required accuracy on one side and the workload created by the performance collector on the other
side. A larger value for stat/rfcrec can lead to performance problems in the collector (see also Configuring the Workload Monitor).
The RFC client and RFC server records contain data such as execution time and called function for individual RFCs. The RFC destination records
contain the total of all RFC calls per destination and therefore no additional information about the called function modules.
Procedure
3. Choose Analysis Views RFC Profile , and choose the desired RFC profile.
Result
Depending on the RFC profile selected, the output area shows the following tab pages:
Tab Page Description
Function Module
Transaction
User
What workload is caused by the function modules, transactions, or users (depending on
the selected RFC profile, as the RFC client or the RFC server)?
Remote Destination
Remote Server
Local Server
Where is the RFC workload created?
On all tab pages: if you double-click a line, a new screen appears showing detailed information about the selected line.

Displaying User Profile and Account Statistics
Use
is the question of how the system load is distributed among the different users and what the workload profile of an individual user looks like. With this information,
you can answer questions such as:
How long is the response time that a user must wait on average how is this time split?
How many dialog steps has a particular user executed?
PUBLIC
Page 12 of 27
Which database accesses with what workload did a particular user cause?
You require a special authorization (profile S_TOOLS_EX) to display this analysis view.
Procedure
2. Ensure that you are in the Expert user mode.
4. Choose Analysis Views User and Settlement Statistics , and choose the desired analysis view.
Result
User Profile Analysis View
The output area contains five tab pages that display the most important workload data for individual users. To see a breakdown of the workload caused by a user,
sorted by the individual transactions, double-click the user.
If you have chosen TOTAL for the Workload , the system displays the workload data for individual users totaled for all instances. To see a breakdown of the
workload caused by a user, sorted by the individual instances, double-click the user.
Settlement Statistics Analysis View
The output area displays the corresponding workload in this system on the tab pages Clients , Account Numbers , and Account Numbers . Every user is
usually assigned to an account number in the user master record (see also: User Maintenance Functions). To view information about the individual users of a
client or account number, double-click the client or account number.

1.1.3.10 Displaying Front End Statistics
Use
is the question of how the workload is distributed among the various presentation servers and instances. With this information, you can answer questions such as:
What volume of data is exchanged between the individual presentation servers and SAP instances?
Which response times arise at the front end (GUI, front end network, and so on)?
Which presentation servers are causing what workload in a particular instance?
Procedure
3. Choose Analysis Views Frontend Statistics.
Result
Frontends The workload is displayed, sorted by the presentation servers of the selected instance.
The values displayed are for the aspects of the workload that arise in connection with the
presentation server, such as the number of communication steps, transferred data
value, or front end wait times.
Instance(s) If you have chosen the TOTAL workload (see also Controlling and Monitoring the
Generation of Statistics Data), the same aspects of the workload are displayed, sorted by
instances of the system. To display the workload for the presentation servers assigned to
an instance, double-click that instance.

PUBLIC
Page 13 of 27
1.1.3.11 Displaying Spool Statistics
Use
is the question of how much workload occurs due to spool requests. With this information, you can answer questions such as:
How many spool requests with which properties were executed on the selected instance or the entire system?
How long was the average response time and the average wait time for spool requests?
Which and how many logical transaction steps were there in spool work processes?
The spool statistics are therefore useful for spool administrators who want to check what was output in each application server.
The analysis view Spool Statistics may not be available for every configured application server in your SAP system.
Procedure
2. Ensure that you are in the Expert User Mode.
4. Choose Analysis Views Spool Statistics.
If no spool statistics are available for certain instance, the system does not display the Spool Statistics icon.
Result
Tab Page Meaning
Overview The most important workload data for the executed spool requests
Spool Activity The workload of the spool work processes

Displaying the Response Time Distribution
Use
is the question of how response times are distributed with respect to the different task types.
The response time for the transaction steps is split into 10 categories: t < 0.1 s; 0.1 s < t < 0.2 s, and so on You can choose between two different types of
display:
Number of transaction steps (absolute or percentage) that are in a particular response time category (such as a response time between 0.4 s and 0.5 s).
Percentage of transaction steps whose response time is not longer than the upper limit of a particular response time category (such as a response time
between 0 s and 0.5 s).
This analysis view therefore allows you to check quickly what percentage of all transaction steps have a response time below a certain threshold value.
For more information about what response time you can expect, see: Response Times: Rough Guide.
Since the response time has included the communication between the SAP system and the presentation server since SAP R/3 4.6 (see also
SAP Note 203924), you can display the response time for the Dialog task type either including or excluding the GUI time in this analysis view.
In this way, you can remove the influence of the performance of the front end systems and the network from the calculation of the response time
distribution.
Procedure
3. Choose Analysis Views Response Time Distribution .
4. The system displays the usual output area, in which the requested distribution of the workload is displayed.
Result
PUBLIC
Page 14 of 27
The output area contains three tab pages with the following characteristics:
Steps The system displays the absolute number of transaction steps in the individual response
time categories, broken down by task type.
Percentage The system displays the proportion of transaction steps (as a percentage) in the
individual response time categories, broken down by task type.
Percentage (Cumulated) The system displays the proportion of transaction steps (as a percentage) with a response
time between 0s and the upper limit of the individual response time categories, broken
down by task type.

1.1.3.12.1 Response Times: Rough Guide
Definition
The following times provide you with an overview of the optimal response times in your SAP system. You can display the current workload overview for your
system with the workload monitor.
Proportions of the Response Time
Performance Data Time
Average response time Around 1 second (dialog), < 1 second (update)
Average CPU time Around 40% of the average response time
Average wait time < 1% of the average response time
Average load time < 10% of the average response time
Average database time per dialog step Around 40% of the average response time
- The operating system can affect these values by up to around 10%.
- The ratio of the CPU time to the total time should not fall under 5%. A smaller proportion could mean that there is an input/output bottleneck or
that a database overload has caused long wait times.
- The average response times for dialog transactions (online transactions) should not be more than a second, since a higher value would strain
the patience of the user too much.
Times for Database Access
Database Access Time
Direct read < 10 ms
Sequential read < 40 ms
Changes > 25 ms
Possible Causes of Bad Response Times
High Value For Possible Causes
DB request (Change/Comm.) Problems with database or index
Load time Buffer too small
Transports to the productive system
Wait time Insufficient work processes
Inactive update
Incorrect operation mode
Locked tasks
Long-running transactions
- In a database system that is functioning properly, the times for direct reads and changes should not be more than 10 milliseconds.
- The time for sequential reads should not be more than 30-40 milliseconds.

Displaying Database Procedure Calls
PUBLIC
Page 15 of 27
Use
In the workload monitor, you can display the workload in different analysis views that highlight the workload from a particular perspective. One of these aspects is
the question of how much load is generated due to calls of database procedures.
Procedure
3. Choose Analysis Views DB Procedure Calls .
Result
Tab Page Meaning
DB Procedure Workload due to database procedure calls, broken down by the different database
procedures. To display the workload broken down by different transactions or reports that
called a specific procedure, select that procedure.
Transactions Workload due to database procedure calls, broken down by the different transactions or
reports. To display the workload broken down by different database procedures that were
called by a specific transaction, select that transaction.

1.1.3.14 Displaying Table Access Statistics
Use
is the question of which transactions have accessed which database tables, and how often.
Since the number of statistics records greatly increases by logging table accesses of this type, this option is deactivated by default. You should only activate it
temporarily for individual analyses, and for individual transactions, since performance problems can occur in the statistics collector otherwise.
Prerequisites
To display table access statistics for individual transactions, you first need to activate this:
2. Ensure that you are in the Expert User Mode.
3. Choose Collector & Performance DB Statistics Records & File Online Parameters Dialog Step Statistics .
4. The Change Runtime Parameters of Statistics dialog screen appears.
You can change the online parameter stat/tabrec , which specifies the maximum number of table access statistics subrecords that the kernel is to write for
each transaction step. The N most resource-intensive accesses of a transaction step are stored.
If you only want to activate the table access statistics for certain transactions, you can specify a maximum of five transactions in the online parameters
stat/tcode1 to stat/tcode5 . The table access statistics are then only produced for these transactions.
Change the parameter stat/tabrec only temporarily for individual analyses. It must be set to 0 (zero) at all other times. Otherwise, the number of
statistics records increases significantly, which can lead to performance problems in the statistics collector.
Procedure
3. Choose Analysis Views Table Access Statistics.
If no table access statistics are available for certain instance, the system does not display the icon for the table access statistics.
4. The system displays the usual output area, in which the requested table access statistics are displayed.
Result
PUBLIC
Page 16 of 27
Tables The database tables that the activated transactions accessed are displayed with the most
important load data (number of selected, read, and modified data records, access time). If
you choose a table by double-clicking it, another screen appears, showing the
transactions that accessed this specific table.
Transactions The activated transactions are displayed with the most important load data concerning
table accesses (see above). If you choose a transaction by double-clicking it, another
screen appears, showing the tables that this specific transaction accessed.

Displaying Load from External Systems
Use
is the question of how much workload in a system arises on the basis of actions from other systems.
If there is no connection to another SAP system in a system landscape, this analysis view does not exist.
Procedure
3. Choose Analysis Views Load from External Systems.
4. The system displays the usual output area, in which the requested workload statistics are displayed.
Result
The output area displays the most important workload data that was triggered by actions in external systems, grouped by different points of view on five tab
pages. Each line contains the data from a specific external system.
You can break down the list further by action and user using the Aggregation dropdown menu. You can display additional details by double-clicking a line.
Background Information
When a transaction is started, a unique ID, the trans ID, is generated. This is transferred together with the data during Remote Function Calls (as of SAP R/3
4.6D). This ID is retained even for RFCs over multiple systems, meaning that it is possible to identify the system that is at the start of the chain and that originally
triggered the action.

1.1.3.16 Displaying Web Statistics
Use
is the question of how much workload occurs due to requests from the Internet. With this information, you can answer questions such as:
What quantities of data are sent to which URL, how often, and how much time is required to do so?
Which host/port combinations function as Web servers, and what workload is generated?
Procedure
3. Choose Analysis Views Web Statistics.
4. Choose the desired statistics:
Statistics Description
PUBLIC
Page 17 of 27
WEB Client Statistics Workload due to requests for which the system acts as a Web client
WEB Client Dest. Statistics Workload due to requests for which the system acts as a Web client, broken down by
different client destinations
WEB Server Statistics Workload due to requests for which the system acts as a Web server
WEB Server Dest. Statistics Workload due to requests for which the system acts as a Web server, broken down by
different server destinations
Result
The output area contains four tab pages with the following characteristics:
Host Breakdown of the workload by host names and port numbers that act as Web servers or
Web clients
Transactions Breakdown of the workload by reports or transactions that act as Web servers or Web
clients
User Breakdown of the workload by users and clients that act as Web servers or Web clients
URL Breakdown of the workload by URLs that act as Web servers or Web clients

Displaying Database Connection Statistics
Use
is the question of how the workload generated by accesses to databases is distributed across the various database connections.
Procedure
3. Choose Analysis Views DB Connection Statistics .
Result
Tab Page Meaning
Connections Workload due to accesses to the database, broken down by different database
connections. To display the workload broken down by different transactions or reports that
used a specific database connection, select that database connection.
Transactions Workload due to accesses to the database, broken down by different transactions or
reports. To display the workload broken down by different database connections used by a
transaction, select that transaction.

1.1.3.18 Displaying VMC Statistics
Use
In the workload monitor, you can display the workload in different Analysis Views, which highlight the workload from a particular perspective. One of these
views shows how the available resources are made use of at specific times when the VM Container is operating. With this information, you can answer questions
such as:
How often has the VM Container been called up?
How often has the garbage collector been called for the various memory areas (old generation, young generation, shared objects)? (see Memory
PUBLIC
Page 18 of 27
Management in the VM Container)
How much time has the system spent in the various garbage collections?
How many IT compilations have there been?
Procedure
Start the Workload Monitor by calling transaction ST03.
1. Ensure that you are in the Experts User Mode.
2. In the Workload tree, choose the instance and time period to be analyzed.
3. Choose Analysis Views VMC Statistics .
The system displays the usual output area, in which the requested workload is displayed.
Result
The output area shows the workload in this system in the corresponding tab pages, Times , Memory , Shares, Parts of Response Time and All Data .
You can get information about these display modes via the F1 help.
You can find information about the memory types, garbage collections, and so on, in Memory Management in the VM Container.

Displaying a Business Transaction Analysis
Use
You can use the workload monitor to display the business transaction analysis. The analysis calculates the system resource usage of individual transactions and
returns the most detailed analysis of a transaction and the dialog steps. The selection criteria include user, transaction, program, task type, start date, and start
time.
The business transaction analysis uses the statistics files STAT and ASTAT (dialog step statistics and application statistics) in the file system of the relevant
instances as its data sources. This data basis allows more detailed analysis than the other analysis views of the workload monitors, which use the aggregated
data from the workload collector database as their data source. Note that you can only execute the business transaction analysis for the period for which the
statistics files are retained (by default, 48 hours).
The analyzed time period can be larger than the interval defined by Read Time , as the system analyzes complete transactions as far as
possible. However, it is not always possible to perform a complete analysis for long-running transactions. As the business transaction analysis is
time-consuming, you should use as short an interval as possible (around 10 minutes).
Procedure
1. Call transaction ST03 to start the Workload Monitor.
2. Choose Detailed Analysis Business Transaction Analysis .
3. The Select Statistical Records dialog screen appears . You can make the following settings here:
Choose one of the following display modes in the Display Mode group box:
Show all statistics records, sorted by start time
The system displays a chronological list of dialog steps with their resource usage (this corresponds to the individual statistics records and the transaction
statistics).
Show all records, grouped by business transaction
The system displays a list of dialog steps with their resource usage, grouped by transactions. The list contains the individual dialog steps of a
transaction.
Show business transaction sums
The system displays a list with totals of workload data for every transaction. This variant is used most frequently.
In the first two cases if you have restricted the data to certain users or transactions, and so on the system reads only the corresponding
records. In the third case, the system reads all records, but displays only the records that match the selection criteria. You should consider this if
you switch to a different display mode by choosing Disp. Mode .
Use filters in the Filter Parameter group box to define which statistics data you want to display.
In the Tools group box, choose one of the following commands:
Include statistics from memory
The statistics data is buffered first, before it is read into the STAD file. This option forces the buffer to write the data to a file before the analysis is
performed. This ensures that you can analyze the most recent transactions.
Include application statistics
Choose this check box to display application statistics in addition.
Server selection
This pushbutton restricts the analysis to certain instances in the system. Select the desired instances.
Additional options
You can set the wait time for the Remote Function Call (RFC), maximum runtime of the analysis, and the time period to be used for the analysis.
PUBLIC
Page 19 of 27

Displaying the Last Minutes Load
Use
The workload monitor usually reads the workload data from the workload collector database, which is supplied with data from the statistics files for the individual
instances once an hour. This means that you usually cannot show any data that is less than an hour old and has not yet been written to the database.
So that you can also monitor the latest changes in the system performance, there is an additional function, Last Minutes Load . You can use this function to
directly access the statistics files for the individual instances and to display the system performance for any period (such as for the last 15 minutes).
After you have selected an instance, the usual analysis views are available with data for the selected period.
Procedure
1. First start the Workload Monitor by calling transaction ST03.
2. Expand the Last Minutes Load subtree and double-click the instance for which you want to investigate the system performance.
3. The Last Minutes Load on <instance name> dialog screen appears. You can make more precise specifications about the workload that you want to analyze
on this screen.

Displaying the Workload History and Workload Distribution in the
Workload Monitor
Purpose
The workload monitor is conceived in such a way that the workload for a particular instance that you can display the workload for a specific instance and a
particular period of time, and compare the load for these circumstances caused by various transactions, users, RFC destinations, external systems, and so on.
Some questions cannot, however, be answered with these display conditions, such as the development of the workload over time ( Load History ) or the
distribution of the workload for different instances ( Instance Comparison ).
Process Flow
Workload History
Use the Load History to check how the workload develops for a selected task type and a selected instance.
2. Expand Load History and Distribution Load History .
3. The system displays a list of the available instances and optionally the TOTAL entry for all instances (see also Controlling the Creation and Retention Period
of Statistics Data). Choose the desired instance by double-clicking it.
4. The Workload: Compare all The Workload: Compare all periods for one instance screen appears. The system displays a list of workloads for the selected
instance at different times. You have the following options on this screen:
Changing the Aggregates
You can display the workload for different Days , Weeks , or Months for the selected instance. Choose the corresponding button to do this.
Changing the Output View
You can use the output view to select which workload data is displayed on the screen. You have the following options:
Output View Description
Mean Values Selected workload values from the Workload Overview analysis view, for the selected
task type in each case
Total Values
DB Access
Response Time Distribution See Displaying the Response Time Distribution
Measurement Interval Time stamp of the first and last statistics records during the selected period
Sorting the Output
You can sort the output by any column. To do this, select the desired column and choose the Sort button.
Changing the Task Type
You can specify the task type for which workload is to be displayed. To do this, choose Other Task Type , and select the desired type.
Instance Comparison
In the Load History , you displayed the workload data for an instance for different times; in the Instance Comparison , you display the workload data for different
PUBLIC
Page 20 of 27
instances for one period.
2. Expand Load History and Distribution and then double-click Instance Comparison .
3. The Workload: Compare all The Workload: Compare all instances for one period screen appears. The system displays a list of all instances and their
workloads during a particular period. You can use the following commands:
Changing the Output View
You can use the output view to select which workload data is displayed on the screen. The same output views are available as in the Load History .
Sorting the Output
You can sort the output by any column. To do this, select the desired column and choose the Sort button.
Changing the Task Type
You can specify the task type for which workload is to be displayed. To do this, choose Other Task Type , and select the desired type.
Changing the Period
You can determine the time period for which workload data is to be displayed. To do this, choose the Previous Period and Next Period buttons (you
can select a period of Days, Weeks, and Months by choosing Edit Choose Period Type ).
The Load History and Instance Comparison display only data that you can select using the Analysis Views. The difference is that in the Load History, you can
compare workloads directly in one list, which would otherwise always be in different output tables due to the structure of the workload monitor.
It is therefore a summary the system displays the same data in a different format.
Users per Instance
Another comparison that you can display for workload distribution is the number of users per instance.

1.1.7 Displaying Users per Instance
Use
You can use the workload monitor to display the number of users working on an instance. You can display the number of dialog steps that each user has
executed, and check that the instance response times are acceptable.
Procedure
2. Choose Load History and Distribution Users per Instance.
The Performance: Display instances and their users screen appears. This shows a list with the number of users logged on to each instance. You can use
the following commands to obtain more information:
Instances/User and Users per Instance
Button to switch between two views (the button always shows the view to which you can switch, not the active view):
Button Meaning
Instances/User For each user, the system shows all instances that the user logged on to during the
selected time period.
Users per Instance For each instance, the system shows the number of users that were logged on during
the selected time period.
Switching the Time Period
You can determine the time period for which workload data is to be displayed. To do this, choose the Previous Period and Next Period buttons (you
can select a period of days, weeks, or months by choosing the By Days , By Weeks , or By Months buttons).
Displaying the Users on an Instance
You can display the users on a particular instance by double-clicking the desired instance in the Users per Instance view. The system displays
another list of the users on that instance.
To then display the corresponding data for another instance, choose the Previous Instance or Next Instance buttons.

1.2 Configuring the Workload Monitor
Purpose
You use the workload monitor to analyze statistical data from the SAP kernel. You can influence the type and scope of the data entry and the data storage in a
number of ways. This process presents these influence methods.
You do not need to configure the Workload Monitor before you use it for the first time. The delivered settings usually ensure correct operation. You
therefore only need to change the parameters of the collector and of the performance database when troubleshooting or if performance problems
occur.
PUBLIC
Page 21 of 27
Prerequisites
Note that to display statistical data, you need to have scheduled the job SAP_COLLECTOR_FOR_PERFMONITOR (see Background Jobs to Be Scheduled
Regularly).
Process Flow
You can intervene at various points in the data collection and storage:

Controlling and Monitoring the Generation of Statistics Data
You can determine whether statistics data is to be saved in the workload collector database at all, broken down by different profiles (which correspond to the
various analysis views). You can also determine in the same way how and after how long this data is to be reorganized. For more information, see Controlling and
Monitoring the Creation of Statistics Data.
In addition to the workload collector database, there is also the monitoring database MONI, which contains performance data that is displayed in
other transactions. You can, however, monitor the scope and reorganization of MONI from the workload monitor (see Reorganizing and Monitoring
the Monitoring Database MONI).
Displaying and Deleting Contents of the Workload Collector Database
If problems occur when reorganizing the statistics data, you can display and manually delete the corresponding contents of the workload collector database (see
Displaying and Deleting the Contents of the Workload Collector Database).
Displaying and Changing the Scheduling of Performance Collectors
Various performance collectors are responsible both for the collection of the workload data and for collecting performance data for other transactions. The collectors
run at regular intervals.
These times are saved in the table TCOLL. By changing the entries in TCOLL, you can determine which collectors run, and how often (see Displaying and
Changing the Scheduling of Performance Collectors).
Displaying and Changing Profile Parameters for Statistics Records
There are a number of relevant profile and online parameters that are relevant for the workload collector. You can display the relevant profile parameters
separately for each instance by choosing Collector & Performance DB Statistics Records and File Relevant Profile Parameters in the
navigation bar. Since you cannot change these profile parameters during running operation, but only by a restart of the relevant instance, you can only display the
parameters. To change the parameters, use transaction RZ10 ( Edit Profiles ). The two following profile parameters are especially important:
stat/max_files specifies how many statistics files the kernel uses. If the value of the parameter is greater than 0, a new statistics file is created for each
hour. The size of the value determines how many statistics files are to exist simultaneously before the oldest file is deleted. The default value of the parameter
is 48. This means that you can access the statistics data of the dialog step statistics within two days.
stat/as_max_files specifies the corresponding value for the application statistics.
Online parameters are profile parameters for which changes take effect immediately (without a restart of the affected instance). Unlike the relevant profile
parameters, you can change the online parameters directly in the workload monitor. To do this, choose Collector & Performance DB Statistics Records
& File Online Parameters . You require the online parameters for the following statistics, among others:
Table Access Statistics
Application Statistics

PUBLIC
Page 22 of 27
Controlling and Monitoring the Generation of Statistics Data
Use
At every transaction step, ABAP work processes first write statistics and application statistics data to a buffer. This data is then saved in file system files on the
host of the relevant instance. Separate files of this type are created for the statistics and the application statistics every hour. The total number of files is usually
restricted to 48 (profile parameters stat/max_files or stat/as_max_files ). This data is therefore stored for two days before it is overwritten.
At the next level, this statistics data is aggregated and saved as daily aggregates (that is, with the time resolution of days) in the workload collector database. A
corresponding report runs once an hour on every instance for this. You can define yourself the profiles for which statistics data is to be saved in the database.
These profiles each cover a separate topic area and represent the existing Analysis Views of the Workload Monitor. In detail:
Profile Analysis View
AA Application profile Application Statistics
AB Application hitlist: DB accesses Hitlists Top DB Accesses functions
AC Application hitlist: response times Hitlists Top Response Time functions
EA Component hierarchy This data does not create a separate analysis view, but
rather provides additional information for other analysis
views.
EB Orgunit
WA Task types profile Workload overview
WB Time-dependent task types profile Response time distribution
WC Time, program, task types profile Time profile
WD Database procedures profile DB procedure calls
WF External Systems Workload from External Systems
WG Function code profile Transaction details
WH Frontend profile Frontend statistics
WJ Memory usage profile Memory usage statistics
WK Spool activity profile Spool statistics
WL Table profile Table access statistics
WM User, transaction profile Transaction profiles and User profile and accounting
statistics user profile
' WN' User profile User profile and accounting statistics Accounting
statistics
WO RFC client profile RFC profiles RFC client profile
WP RFC client destination profile RFC profiles RFC client destination profile
WQ RFC server profile RFC profiles RFC client profile
WR RFC server destination profile RFC profiles RFC server destination profile
WT Hitlist: database accesses Hitlists Top DB accesses dialog steps
WU Hitlist: response times Hitlists Top response time dialog steps
WV Spool profile Spool statistics ( Overview tab page)
WW HTTP client profile Web statistics WEB client statistics
WX HTTP client destination profile Web statistics WEB client destination statistics
WY Database connection DB connection statistics
The statistics data at file system level contains the statistics records as they are written by the kernel after each transaction step, while the data in
the workload collector database is already aggregated, meaning, for example, that it is no longer possible to analyze parts of a transaction. This
means that after two days, you can no longer perform an analysis below transaction level.
The daily aggregates are also further aggregated, in two different ways:
The statistics data of all instances in a system is combined to a TOTAL instance, which you can display as an additional instance of a system in the workload
monitor.
The daily aggregates are combined into weekly and monthly aggregates.
You can also define in this case the profiles for which the weekly and monthly aggregates and the aggregates for the TOTAL instance are to be created.
By default, daily, weekly, monthly, and TOTAL aggregates are generated for all profiles. You can define the retention periods for all of these
aggregates, broken down by profiles.
Activities
To change the generation and retention period of the statistics data, or to monitor the correct functioning of the corresponding collectors, start the workload monitor
(transaction ST03) and ensure that you are in the Expert user mode.
PUBLIC
Page 23 of 27
Creating the Daily Aggregates
To determine the profiles for which daily aggregates are to be created in the workload collector database, choose the following path in the navigation bar:
Collector and Performance DB Workload Collector Instance Collector Control . You can only display data in the workload monitor
for profiles that are activated in this table.
To check that the corresponding collector is functioning correctly, choose the following path in the navigation bar: Collector and Performance DB
Workload Collector Instance Collector Log . You can view the corresponding error logs, broken down by time periods. The collector runs
every hour on every instance of the system.
Creating the Weekly, Monthly, and TOTAL Aggregates
To determine the profiles for which the above aggregates are to be created in the workload collector database, choose the following path in the navigation bar:
Collector and Performance DB Workload Collector TOTAL Collector Control .
To check that the corresponding collector is functioning correctly, choose the following path in the navigation bar: Collector and Performance DB
Workload Collector TOTAL Collector Log . You can view the corresponding error logs, broken down by time periods. The collector runs
system-wide once every three hours.
Retention Periods of the Different Aggregates
To determine how long the different aggregates are to be stored in the workload collector database, choose the following path in the navigation bar: Collector
and Performance DB Performance Database Workload Collector Database Reorganization Control .
Note that, depending on the size of the screen, the important part of the column headers may not be visible, and the time unit for the different
aggregates is different. The table consists of the following columns:
No. Heading Unit
1 Daily Aggregates Retention Period Day
2 Weekly Aggregates Retention Period Week
3 Monthly Aggregates Retention Period Month
4 Daily Aggregates Retention Period (TOTAL) Day
5 Weekly Aggregates Retention Period (TOTAL) Week
6 Monthly Aggregates Retention Period (TOTAL) Month
To check that the above reorganization is functioning correctly, choose the following path in the navigation bar: Collector and Performance DB
Performance Database Workload Collector Database Reorganization Log . You can view the corresponding error logs, broken down
by time periods. The collector runs system-wide once a day.

Displaying and Deleting Contents of the Workload Collector
Database
Use
The data of the workload collector database, which contains the workload data for the system is automatically reorganized and deleted after the set retention periods
are exceeded (see Controlling and Monitoring the Generation of Statistics Data). However, if problems occur during the reorganization of the statistics data, you can
also display the corresponding content and delete it manually.
Activities
To display or delete the contents of the workload collector database, start the workload monitor (transaction ST03), and ensure that you are in the Expert user
mode.
Displaying Contents of the Workload Collector Database
To check the periods, instances, and aggregates for which there is data in the workload collector database, choose the following path in the navigation bar:
Collector and Performance DB Performance Database Workload Collector Database Contents .
The period type specifies the type of aggregate.
Period Type Aggregate
D Daily aggregate
W Weekly aggregate
M Monthly aggregate
Deleting Contents of the Workload Collector Database
To delete data from the workload collector database for individual periods, instances, and aggregates, choose the following path in the navigation bar: Collector
PUBLIC
Page 24 of 27
and Performance DB Performance Database Workload Collector Database Contents . Select the desired data and choose ( Delete ).
Deleting Statistics Records in the File System of the Instance
You can also directly delete the unaggregated statistics files in the file system of the individual instances. To do this, choose the following path in the navigation
bar: Collector and Performance Database Statistics Records & File Delete File , and select the desired instance by double-clicking it. The
system asks whether you want to delete the dialog step or the application statistics file.
If the workload collector is running correctly, both files are automatically deleted when they exceed a certain age (by default, two days). You should
therefore only delete the corresponding files manually if there are problems when reading and processing the statistics files.
The deletion is performed without aggregation of the data in the workload collector database. After the deletion, this statistics data is also no longer
available for detailed analysis.

Displaying and Changing the Scheduling of Performance Collectors
Use
The workload monitor reads the workload statistics from the workload collector database. Various collectors must run at regular time intervals so that this database
always contains current data.
This is done using the background job SAP_COLLECTOR_FOR_PERFMONITOR. This job runs once an hour on an instance of the system. The job executes
report RSCOLL00, which starts the various collectors in accordance with the entries in table TCOLL.
Note that the collectors in table TCOLL not only form the basis of the data for workload monitor, but are also of importance for other transaction
(ST02, ST04, ST06, ST10). This means that the collectors supply not only the workload collector database, but also the monitoring database
MONI with values.
By changing the entries in TCOLL, you can determine which collectors are to run and how often. Usually, you do not need to change these settings. There are two
conceivable situations in which you would need to change the entries in TCOLL.
The workload collector database or the monitoring database MONI is too large due to the quantity of collected data.
The collectors themselves are causing too much workload.
For information about the various collectors, for which the scheduling is determined using the entries in table TCOLL, see SAP Notes 12103 and
127642. Both SAP Notes are regularly updated.
Procedure
2. Ensure that you are in the Expert user modesapurl_link_0003_0001_0002.
3. In the navigation bar, choose the entry Collector & Performance DB Performance Monitor Collector Execution Times. The TCOLL List
screen appears.
This shows an execution timetable for the various collectors. Each row specifies for a collector on which week days and at which hours of the day the relevant
report is executed. For an execution, both conditions (week day and hour) must be fulfilled.
Note that the columns for the week day all have the same column heading Day or Weekday . The first column of this type stands for Monday,
and the columns then run in the normal sequence.
The Type column the instances on which the report is to run.
Type Meaning
S The report is executed exactly once in the system (in the local background work process).
A The report is executed on every instance.
H The report is executed once per host.
% The report is executed on the instance specified in the Application Server field.
4. If you want to change execution times, choose the Table Maintenance button. The Performance Collector: TCOLL maintenance screen appears.
5. Each row contains the execution times of a report.
- Use seven characters in the column Days:M-W-F-S to specify the week days on which the report is to be executed. Enter a character for every weekday,
starting with Monday: X (the report is to be executed on the corresponding weekday) or space (the report is not to be executed on the corresponding
weekday).
- Proceed in the same way in the Hours: 0-2-4-6-8-0-2-4-6-8-0-2- column, in which 24 individual characters stand for the hours of a day from midnight to 11
p.m.
- Specify how often the report is to be executed per pass in the column R.
- Specify where the report is to be executed in the column S (see the Type column).
- You can explicitly specify an instance in which the report is to be executed in the Alternative System column.

PUBLIC
Page 25 of 27
Reorganizing and Monitoring the Monitoring Database MONI
Use
Up to SAP NetWeaver 04 (SAP Web AS 6.40), workload data and various other performance data was stored in the monitoring database MONI in the long term.
With SAP NetWeaver 7.0 (SAP Web AS 7.00), the workload statistics that are displayed in transaction ST03 are stored in the workload collector database.
However, the monitoring database MONI is still used. It contains, among other things, performance data from the following sources:
Table call statistics
Function code statistics
Operating system statistics
Buffer statistics
SQLR summary
Although this data is not displayed in the workload monitor, you can still set the reorganization of this data in the monitoring database MONI in transaction ST03.
You can determine the retention period of the existing data in MONI. In this way, you limit the size of the table to optimize the performance of the CCMS monitors.
The smaller MONI is, the better the performance of the various CCMS monitors is.
Activities
To perform the following functions, start the workload monitor (transaction ST03) and ensure that you are in the Expert user mode.
Setting Retention Periods for the Performance Database
To set the parameters that affect the reorganization of the table MONI, choose the following path in the navigation bar: Collector and Performance DB
Performance Database Monitoring Database Reorganization. The Retention Time for Performance Data screen appears.
This displays settings for Default Statistics Data and Other Statistics Data . The monitoring database is therefore divided into two parts, and the data for each of
these is retained for different lengths of time. You can see which data belongs to which group in the respective group boxes.
During a reorganization run, the system deletes all data whose retention time has expired.
When statistics are deleted through the new retention times used in a reorganization of the monitoring database MONI, these lost statistics cannot
be recovered except through the standard techniques for database recovery.
We recommend the following retention periods:
Standard Data
This data is very detailed and requires a great deal of storage space. The retention period should therefore be relatively short. Set a value of at least "2" for all
three types of statistics, so that the statistics are retained for two days, two weeks, and two months respectively. However, you should use longer retention
periods for small and medium-sized SAP systems and for testing new SAP releases.
Other Data
This data is less detailed than the standard data and requires significantly less storage space. The retention period can therefore be longer than the retention
period for the standard data. Use a retention period of 20 days, 20 weeks, and 14 months.
Displaying and Deleting Contents of the Monitoring Database
To obtain an overview of the contents of MONI, choose the following path in the navigation bar: Collector and Performance DB Performance
Database Monitoring Database Contents. The Performance: Contents of Performance Database MONI screen appears.
This shows the rows of the database, where one row is characterized by the following data:
Data source (such as type of data and instance)
Period (day, week, or month)
Date
The table MONI is specially encrypted and cannot be accessed using conventional methods.
To delete data, choose the desired command from the Extras Delete Data menu.

1.2.5 Saving User-Specific Views
Use
You can save user-specific views in the workload monitor. If, for example, you are mainly interested in the response time analysis of a time profile in the Service
Engineer user mode, you can save this as the standard view. The next time you call transaction ST03, the system automatically displays this view.
You can save a specific analysis view, with the selected tab page, task type, and the ALV layout in a user-specific view.
If you want to save a user-specific view, the instance in which you logged on to that view is included in the Expert and Administrator user
modes.
If you have chosen the Service Engineer mode, the total of all instances ( TOTAL ) is displayed by default (see also Controlling the Generation
PUBLIC
Page 26 of 27
and Retention Period of Statistics Data).
Procedure
2. Choose the instance and/or the period that you want to analyze by double-clicking.
3. Select the desired analysis view, and specify the task types and parameters that you want to display as your standard view.
4. Choose Save View.
Result
The next time you call transaction ST03, the system automatically displays the view that you have just saved.

PUBLIC
Page 27 of 27

ST03N Workload Monitor

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ST03N Workload Monitor

Enviado por

Direitos autorais:

Formatos disponíveis

Workload Monitor

PDF download from SAP Help Portal:

Você também pode gostar