st03

Workload Monitor

HE

LP

.BC

CC

M

Re lease 620

SAP Online Help 03.07.2002

Copyright

© Copyright 2002 SAP AG. 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.

Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation.

IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries.

ORACLE® is a registered trademark of ORACLE Corporation.

UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.

Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

JAVA®is a registered trademark of Sun Microsystems, Inc.

JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP, mySAP.com, 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 in several other countries all over the world. MarketSet and Enterprise Buyer are jointly owned trademarks of SAP Markets and Commerce One. All other product and service names mentioned are the trademarks of their respective owners.

Workload Monitor 620 2


Symbols

Symbol Meaning

Caution

Example

Note

Recommendation

Syntax



Workload Monitor 5

Operating the Workload Monitor 7

User Mode 9

Structure of the Workload Tree in the Workload Monitor 10

Display the Business Transaction Analysis 11

Display the Last Minutes’ Load 12

Load Distribution in the Workload Monitor 13

Display Users per Instance 15

Collector and Performance Database 16

Analysis Views of the Workload Monitor 18

Workload Overview 20

Displaying Transaction Profiles 22

Displaying Transaction Details 24

Displaying Application Statistics 25

Displaying the Time Profile 26

Hitlists: Display 40 Worst Response Times 27

Displaying Memory Usage Statistics 28

Displaying RFC Profiles 29

Displaying User Profile and Account Statistics 30

Displaying Frontend Statistics 31

Displaying Spool Statistics 32

Displaying the Response Time Distribution 33

Response Times: Rough Guide 34

Displaying Table Access Statistics 35

Displaying Load from External Systems 37

Configuration of the Workload Monitor 38

Saving User-Specific Views 39

Configuring Performance Monitor Collectors 40

Performance Database Collectors 42

Workload Collector Settings 45

Reorganizing the Performance Database MONI 47



Workload Monitor Purpose You can use the workload monitor to analyze statistical data from the SAP Kernel. To analyze the performance of a system, begin with the Workload Overview [Page 20]. In addition, you can, for example, display the total values for all instances and the compare the performance of individual instances over specific periods of time. You can quickly determine the source of possible performance problems using the large number of possible analysis views [Page 18] and the collected data.

The workload monitor is primarily intended for use by EarlyWatch and GoingLive teams. The workload monitor was reworked as part of the EnjoySAP initiative, so that the workload overview is now simpler and more intuitive.

You can use the workload monitor to display the following, among other things:

• Number of configured instances for each SAP R/3 System

• Number of users working in the different instances

• Distribution of response times

• Distribution of workload by transaction steps, transactions, packages, subapplications, and applications

• Transactions with the highest response time and database time

• Memory usage for each transaction or each user per dialog step

• Workload through 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

• Table accesses (optional)

• Workload and transactions used broken down by users, settlement numbers, and clients

• Workload generated by requests from external systems

For all of this data:

• You can display the data for any instance (not only the one to which you are logged on), or optionally totaled for all instances.

• Depending on your user mode, you can choose the time period for which you want to display the data between day, week, and month, or using the Last Minutes‘ Load [Page 12] function.

• For most analysis views, you can display all or only certain task types.

Integration The workload monitor completely replaces the old ST03 transaction.

Features The workload monitor has an interfaces that is divided into two parts. Use the tree structures on the left of the screen to make the following settings:

• Select the user mode [page 9]

• Select the time period for which you want to display the workload

• Select various functions and analysis views (which data you want to display)

The system then displays the result on the right of the screen in a standardized ALV Grid Control. With it, you can:



• Adjust the layout of the data output

• Find the information you want using sort and filter functions

• Save user-specific views

• Display statistics graphically



Operating the Workload Monitor Use The workload monitor is a one-screen transaction that has as few additional menus as possible. This means that operation is significantly simpler and more intuitive.

Features

Analysis views:Which aspect of the workload statistics should be displayed?

- User- Transaction- RFC destination...

User mode:Which functions andwhich periods should be displayed?

Functions:Which period should be displayed?

Also:

Other functions andcontrol of the workload monitor

Screen Elements of the Workload Monitor

Edit views: Save, load, and change views; view history

Output area: Workload by the user mode, period, and analysis view defined in the left-hand part of the screen,displayed in a flexible ALV Grid Control

Header data:Specifies intances,period, andtask type of the data fields displayed in the subscreen below

Activities The meanings of the individual screen elements of the workload monitor are as follows:

User Mode After starting the workload monitor, you should first choose a user mode [page 9]. Through this, you gain access to precisely the functions and time periods that are relevant for the selected role.

Functions In the Functions subscreen, choose an icon by double clicking it:

Function Meaning

Workload [page 10] Here you can define instance and time period that you want to analyze, in accordance with the user mode.

Detailed analysis These functions read the workload directly from the statistics files of the individual instances.

Business transaction analysis[page 11]

Here you can perform a very precise analysis of indi-vidual transactions, down to the level of individual steps.



Function Meaning

Last minutes‘ load [page 12]

Here, you can analyze the workload data that has not yet been written to the MONI performance database.

Load history and distribution

Load history [page 13]

Instance comparison [page 13]

Users per instance [page 15]

Here (unlike in the workload monitor), you cannot display the workload for a particular instance and a particular time period, but instead you can compare the workload for different instances or time periods.

A comparison of the most important data allows you to directly compare the instances.

Collector & Perf. Database [page 16]

Here you can determine, among other things, which values the statistics collector collects, and how often, and for how long they should be retained in the performance database, at what level of detail.

Analysis Views An analysis view displays a particular aspect of the workload. In the analysis views [page 18] subscreen, choose the view that you want to analyze by double clicking it.

Only those Analysis Views are shown that are active in the selected user mode and for which there is data.

Output Area The output area uses an ALV Grid Control with which you can tailor the selected view to your requirements to a large extend. 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 in the output area to obtain the data that is relevant for you:

• The data for most analysis views is grouped in tab pages by various topic areas.

• To obtain an overview of which data fields exist for an analysis view, choose the All Data tab page.

• You can use the standard functions of the ALV Grid Control to:

− Show and hide columns

− Sort rows by the contents of a column

− Set and delete filters

− Perform summations

− Export tables in a file type of your choice

− Display tables as graphics

− Save sort orders, filters, and selected columns as your layout

Edit Views Choose one of the following pushbuttons in the Edit Views screen area:

Pushbutton Meaning

Save View Saves the current view as your initial screen for the workload monitor (see also Saving User-Specific Settings [Page 39])

Previous View or Next View Moves one view forward or backward in the view history

Full Screen: Show/Hide Tree Shows or hides the Functions and Analysis Views sections in the left part of the screen



User Mode Definition The user mode determines the view of the statistics data of the workload monitor. The design was conceived with different users in mind, so that the system displays different functions and time periods of monitoring depending on which user mode you choose.

Use There are three different user modes, each of which displays different types of information.

• Administrator Mode This is the default user mode. We recommend that you use this user mode. It provides quick access to the workload statistics for the current day and gives an overview of the workload distribution. In this mode, you can also access the workload collector log and the reorganization parameters of the performance database.

• 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 more detailed analysis of the workload. This user mode is set up especially for SAP Service. By default, the system displays the total statistics for all application servers.

• Expert Mode

This mode provides you with all of the functions that are 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 ST03N.



Structure of the Workload Tree in the Workload Monitor Definition In the workload tree, the workload monitor provides you with a hierarchy of between one and three levels in the Functions subscreen, depending on the selected user mode. You can use this hierarchy to quickly determine the instance and the time period for which you want to analyze the workload. You can also use the TOTAL entry (see also: Workload Collector Settings [page 45]), which displays the workload for all instances in the system.

Structure Depending on the selected user mode, you can decide for what period of time and for which instances you want to analyze the workload. To this, select the desired entry be double clicking it.

User Mode Structure of the Workload Tree

Explanation

Administrator <Instance>/TOTAL The system displays the workload for today. Choose the desired instance, or choose TOTAL if you want to analyze the workload for all instances of a system.

Service-Engineer

Previous Week/Today

<Instance>/TOTAL

The system displays a two-level hierarchy in which you select first the time period and then the desired instance.

Expert <Instance>/TOTAL

<Period>

<Time Period>

The system displays a three-level hierarchy in which you select first the instance, then the period to be studied (Day, Week, or Month) and finally the actual time period.



Display the Business Transaction Analysis Use You can use the workload monitor to display the business transaction analysis. This analysis calculates the use of system resources by individual transactions and provides the most detailed analysis of a transaction and dialog steps. The selection criteria include: user, transaction, program, task type, start date, and start time.

The time frame that is analyzed may be larger than the interval that was set by Read Time, as the system always attempts to analyze complete transactions. A complete analysis is, however, not always possible for long-running transactions. As the business transaction analysis is time-intensive, set the interval that you want to monitor to as short a value as possible (around ten minutes).

Procedure 1. To start the workload monitor, call transaction ST03N.

2. Choose the Expert or Service Engineer user mode.

3. Choose Detail Analysis → Business Transaction Analysis.

4. The system displays the Select Statistical Records dialog screen. In the Select the display mode group box, choose one of the following display modes:

− Show all statistic records, sorted by start time: The system displays a chronological list of dialog steps with their resource usage(this corresponds to the individual record statistics 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 transaction. The list contains the individual dialog steps for a transaction.

− Show business transaction sums: The system displays a list with totals of workload data for each transaction. This is the variant that is most frequently used.

If you set restrictions for certain users or transactions, and so on, only the corresponding records are displayed in the first display modes above. For the third display mode, the system reads all records, but only displays those that match the selection criteria. Ensure that you take this into account, if you choose Disp. mode to switch to a different display mode.

In the Tools group box, choose one of the following commands:

− Include statistics from memory: The system first buffers the statistical data, before reading it into the STAD file. This option forces the buffer to write the data to the file before the analysis starts. This ensure that all transactions can be analyzed.

− Include application statistics: Choose this selection field to also display the application statistics [page 25].

− Server selection: This pushbutton restricts the analysis to specific instances in the system. Select the desired instances.

− Additional options: These can be used to set the wait time for the Remote Function Call (RFC), the maximum runtime of the analysis, and the time interval that you set for the analysis.



Display the Last Minutes’ Load

Use The workload monitor usually reads the workload from the MONI performance database, which is supplied the 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 the MONI table.

So that you can also monitor the latest changes in the system performance, there is an additional function, Last Minutes‘ Load. Using this function, you can access the statistics files for the individual instances directly, and display the system performance for a time period of your choice (such as for the last 15 minutes).

Use 1. To start the workload monitor, call transaction ST03N.

2. Choose Service Engineer or Expert user mode.

3. Expand Last Minutes‘ Load and choose the instance that you want to investigate by double clicking it.

4. The system displays the Last Minutes‘ Load for <Instance_name> dialog screen. On this screen, you can make more detailed specifications about the workload that you want to analyze.

5. The system displays the usual output area, in which the requested workload is displayed in an ALV Grid Control.



Load Distribution in the Workload Monitor Purpose The workload monitor is conceived in such a way that you can output the workload for a specific instance and for a particular period of time, and can compare the workload for these circumstances through various transactions, users, RFC destinations, external systems, and so on.

Some questions cannot, however, be answered with these output conditions. You will often be interested in the development of the workload over time (Workload History) or the distribution of the workload over different instances (Comparison of Instances).

Process Flow Workload History 1. To start the workload monitor, call transaction ST03N.

2. Choose Service Engineer or Expert mode.

3. You can find the workload history in the Functions subscreen under the Load History and Distribution entry. Expand this tree and the Load History tree.

4. The system displays a list of all of the available instances and optionally the TOTAL entry for all instances (see also: Workload Collector Settings [page 45]). Choose the required instance by double clicking it.

5. The system displays the Workload: Compare all periods for one selected instance screen. The system displays a list of the workload at different times for the selected instance. You can choose between the following output views:

Output View Meaning

Summary of average workload Average workload

Summary of workload Total workload

Summary of DB accesses Database accesses

Summary of response time distribution Response Time Distribution

Summary of recording time Time stamp of the first and last statistics records during the selected time period

You can use the following commands:

Pushbutton Meaning

By day(s), By week(s), By month(s) Period for the output rows

Sort Sort by the chosen column

Other task type Change the task type for which workload is displayed in the list

>>, << Navigation between different output views

Choose period Display the task type overview for the selected period



Instance Comparison 1. To start the workload monitor, call transaction ST03N.


3. You can find the comparison of instances in the Functions subscreen under the Load History and Distribution entry. Expand this tree.

4. Choose Instance Comparison by double clicking it.

5. The system displays the Workload: Compare all instances for one selected period screen. The system displays a list of all instances and their workloads during a particular period of time. The same output views are available as for the workload history. You can use the following commands:

Pushbutton Meaning

Choose Displays the task type overview for the selected time period

<<, >> Navigation between different output views

Sort Sort by the chosen column

Period-

Period+

Change the displayed time period by one unit of the chosen period; you can select days, weeks, or months, by choosing Edit → Choose period type

Other task type Change the task type for which workload is displayed in the list

The workload history and the instance comparison display the same data that you can select using the Analysis Views [page 18]. The different is that in the workload history, you can compare workloads in one list that are otherwise always in different output tables due to the structure of the workload monitor. The system displays the same data in a different format.

Users per Instance Another comparison that you can display for the load distribution is the number of users per instance [page 15].



Display Users per Instance Use You can use the workload monitor to display the number of users that are working on an instance. You can display the number of dialog steps that each user has executed, and check the response times on the instances.


2. Select the appropriate user mode.

3. Choose Load History and Distribution (or Load Distribution in the Administrator user mode) and then User per Instance.

The system displays the Performance: Display users and used instances screen. The system displays a list with the number of users logged on to each instance. You can use the following commands to obtain more information:

Pushbutton Meaning

Choose instance Displays all users, the number of dialog steps executed by them and the response times on the selected instance

Instances per user or User per instances

Switches between two views (the pushbutton displays the view to which you can change, not the active view):

• Instances per User: For each user, the system displays all instances that the user has logged on to during the selected time period.

• User per instances: For each instance, the system displays the number of users that were logged on during the selected time period.

Period-, Period+ Change the displayed period of time by one unit of the selected period

Filter... Restricts the users to those with response time or number of dialog steps above a threshold value of your choice (only in the Instances per User view)

By days, By weeks, by months

Period for the output rows



Collector and Performance Database Use There is a statistics collector for the workload monitor that usually reads statistics data once an hour from the statistics files of all instances of a system and writes them to the database table MONI (performance database).

You can make settings about which workload data the statistics collector collects, and how often, and how long it should be retained at what level of detail in the performance database.

Use these functions, above all, if you want to analyze particular transactions in detail, or if problems occur when working with the workload monitor.

Changing certain settings in this area can have a negative effect on system performance. You should therefore always ensure that the workload created by the statistics collector itself does not become too large.

Features To start the workload monitor, call transaction ST03N. You can find the functions for the collector and the performance database in the Functions subscreen.

Performance Database The statistical data about the workload is collected by various collectors and aggregated and stored in the performance database MONI. As the performance database is constantly growing due to these reports, regular reorganization of the performance database MONI [page 47] is required. During this reorganization, the data is aggregated into less detailed time periods (for example, from days to weeks), and the more detailed data is deleted. You can decide how long each type of data is stored in the system.

Performance Monitor Collector Can you set the execution time and frequency of the reports [page 40] that deliver data to the performance database MONI, and view the log.

Workload Collector In addition to the setting about which report should collect data about the workload, and how often, there are a large number of Workload Collector Settings [page 45], with the purpose of enabling the collector to collect as much as possible of the relevant data for you while using as small an amount of system resources as possible. You can view the log of the workload collector to help you identify errors.

Statistics Records and Statistics File There are a number of profile and online parameters that are relevant for the workload collector. You can view the relevant profile parameters for each individual instance by choosing Collector & Perf. Database→ Statistics Records and File → Relevant Profile Parameters, although you cannot change them directly here. You can change the parameters using transaction RZ12 (Profile Parameter Maintenance).

Online parameters are profile parameters whose changes take effect immediately (without a restart of the affected instance). In contrast to the profile parameters, you can change the online parameters directly in the workload monitor by choosing Collector & Perf. Database → Statistics Records and File → Online Parameter. You require online parameters for, among other things:

• Table Access Statistics [page 35]

• Application Statistics [page 25]



Note that changes to the parameters affect the number of statistics records for each dialog step, which can lead to performance problems in the statistics collector.

Delete File In rare cases (such as in the case of space problems in the file system), it can become necessary to delete the statistics file of an SAP instance. In this case, you can either delete the file for the dialog step statistics, STAT, or the application statistics file ASTAT for an instance. If you are working with separate statistics files for every hour (profile parameter stat/max_files > 0), all statistics files are deleted.



Analysis Views of the Workload Monitor 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 [Page 20] Workload distribution for the individual task types.

Transaction Profile [Page 22] Most important performance data for all executed transactions; you can also display the data for different summarization levels Packages, Subapplications or Applications

Application Statistics [Page 25] Statistics about workload distribution within a transaction step (activation at transaction level required)

Time profile [page 26] Temporal distribution of transaction steps over a day; this allows you to easily identify periods of high and low workload

Hitlists [page 27] The 40 transaction steps with the highest response time and database time; the same hitlists also exist for application statistics

Memory Usage Statistics [page 28]

Average and maximum memory usage per dialog step for each transaction and each user

RFC profiles [Page 29] Workload caused by Remote Function Calls on client and server side, broken down by transactions, function modules, or destinations

User profile [page 30] and

Account statistics [page 30]

Workload broken down by users, account numbers, and clients

Frontend statistics[page 31] Sent and received data volume and the frontend processing time of the individual presentation server

Spool statistics [page 32] Statistics about the number and volume of spool requests

Response time distribution [page 33]

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 [page 35] Workload, broken down by table accesses (optional)

Load from external systems [page 37]

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



You can use various analysis views, depending on your user mode:

User Mode Administrator Service Engineer Expert

Possible Analysis Views

Workload overview Transaction profile Time profile Hitlists Memory usage stats. User profile Spool statistics Response time distribution Table access statistics Load from external systems

Workload overview Transaction profile Application statistics Time profile Hitlists Memory usage stats. RFC profiles User profile Frontend statistics Response time distribution Load from external systems DB procedure calls

Workload overview Transaction profile Application statistics Time profile Hitlists Memory usage stats. RFC profiles User profile Account statistics Frontend statistics Spool statistics Response time distr. Table access statistics Load from external systems DB procedure calls



Workload Overview Definition The workload overview displays data about the workload that is written by the SAP Kernel and displayed using the workload monitor. It provides system administrators with various detailed information about the workload such as the CPU time, the number of database requests, the response times, and so on.

In SAP Basis 4.6C, the workload monitor was extended, so that it now also includes GUI times, frontend network times, and the RFC time.

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:

Information Explanation

Average CPU Time

Average time that a work process uses the CPU of the application server (loading, generation, 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 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 completed and the data is transferred to the presentation layer

The response time does not include the time for transferring the data from the SAP frontend to the application server. For networks with bad performance, a more subjective response time can therefore emerge. The transfer time is contained in the GUI time and the frontend network time.

Average Wait Time

Average time that 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 to the application process immediately after receiving the request from the dialog step. The average wait time is then only a few milliseconds. If the application server or the entire system is under a heavy load, this can lead to tailbacks 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 calls to the database

DB Access Number of logical ABAP accesses to the 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 into the SAP buffers, no database calls to the database server are required. The ratio of calls to accesses therefore gives an indication of the efficiency of the table buffering. A good ratio is 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 frontend 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

When 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 also 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, buffering, and on the input/output capabilities of the database server. The access times for buffered tables are much faster and are not considered here.

The response time is usually split into wait time plus execution time. The SAP response time is made up 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 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 the total of the individual components of the utilized CPU time. The CPU time is therefore an additional, independent piece of information about the response time.



Displaying Transaction Profiles Use In the workload monitor, you can display the workload in various Analysis Views [page 18], which each display a particular aspect of the workload. One of these aspects is the question of which transactions are causing what workload.

Prerequisites If you want to display the transaction details for specific transactions, you must first activate the Transaction Detail Profiles for these transactions (see Displaying Transaction Details [page 24]).


2. Choose the appropriate user mode.

3. In the Workload tree, choose the instance to be analyzed and time period.

4. Under Analysis Views, choose the Transaction Profile option.

5. Choose the required analysis view: Standard, EarlyWatch or Details.

6. The system displays the usual output area, in which the requested transaction profile is displayed in an ALV Grid Control.

Result In the analysis views Standard and EarlyWatch, the output areas displays the most important data about the workload, broken down by transactions executed. You can restrict the view to one particular task type using the Task Type dropdown menu.

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 selected level, the data is summarized in accordance with the component hierarchy by:

• Packages (previously: development classes)

• Sub-applications(BC-CCM)

• Applications (BC, FI, CO, ...)

You can display more information for a data record by double clicking the row for the corresponding transaction profile. The system opens a second window to display this detailed information. 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 lists are grayed out.

You require a special authorization (profile S_TOOLS_EX) to display the data for individual users.

As long as you are displaying daily data for the current day, the Individual Records pushbutton is shown by the system. You can directly call the STAD transaction with the selection parameters Instance, Transaction/Report, and, if necessary, User, with this button.



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 the average values per transaction step and average values per Logical Unit of Work (LUW) for a transaction

Details Analysis of individual transaction steps for a transaction (see Displaying Transaction Details [page 24])



Displaying Transaction Details Use The dialog step statistics of the workload monitor enable you to analyze individual transaction steps of a transaction by their function code. The analysis does, however, require detailed knowledge of the function codes for the application. Therefore activating the Transaction Detail Profiles only makes sense when analyzing concrete problems and it is therefore deactivated by default.

There are various parameters for the dialog step statistics that you can set if necessary for concrete analyses. Note, however, that activating these parameters means that significantly more statistics records are written, and that the load caused by the statistics collector can also rise significantly because of this.

You should therefore only change the values of the parameters temporarily for individual analyses, as the number of statistics records can otherwise rise greatly, and this can lead to performance problems in the statistics collector.

Prerequisites To be able to display dialog statistics for individual transactions, you must first activate them:

Activating Dialog Step Statistics 1. To start the workload monitor, call transaction ST03N.

2. Choose the Expert user mode.

3. Choose Collector & Perf.Database → Workload Collector → Statistics to be created.

4. The system displays the Selection of Data to Cumulate dialog screen. Enter the transaction codes for exactly the transactions to be analyzed in the Transaction Detail Profiles group box.

5. Save your changes.



3. In the Functions subscreen, choose the instance to be analyzed and the time period.

4. Choose Analysis Views → Transaction Profile → Details → <Transaction_code>.


If no dialog step statistics are available for the specified instance or the specified time period, the system does not display the icon for the details.

See also: Workload Collector Settings [page 45]



Displaying Application Statistics Use The application statistics allow you to analyze resource consumption in more detail than using the workload overview. Using special calls within the ABAP coding, the system collects separate statistics for individual parts of an application. While the workload statistics always analyze a complete dialog step, you can analyze the resources used by an individual function within a dialog step (such as price determination) using the application statistics. In some cases, the application statistics can therefore replace an SQL trace.

The statistical data collected by the application statistics are the same as the standard system workload statistics (response time, and so on).

Prerequisites To be able to use the application statistics, you must have implemented the relevant function calls in the application programs. Without these calls, application statistics cannot be collected. You must also set the following profile parameters: stat/as_level = 1stat/as_collect = 2

In addition, you must also have scheduled the collector for the application statistics (see Configuring Performance Monitor Collectors [page 40]). You must also activate the individual components of the application statistics by calling transaction ST03N and choosing Collector & Perf. Database → Statistics Records & File → Application Statistics .



3. In the Workload tree, choose the instance to be analyzed and the time period.

4. Under Analysis Views, choose the Application Statistics option.


If no application statistics are available for the specified instance or the specified period, the system does not display the icon for the application statistics.

Result The output area contains the desired workload data broken down by transaction. To display the data broken down by users, choose a row by double clicking it.

You require a special authorization (profile S_TOOLS_EX) to display the data for individual users.



Displaying the Time Profile Use In the workload monitor, you can display the workload in various analysis views [page 18], which each display a particular aspect of the workload. One of these aspects is the question of how the workload changes over the hours of the day.

The time profile displays the time distribution of transaction steps over a day, so that you can easily identify periods of high and low workload. The time profile therefore shows the workload grouped by the hours of the day.

Procedure 1. Start the workload monitor by calling transaction ST03N.



4. Under Analysis Views, choose the Time Profile option.

5. The system displays the usual output area, in which the requested distribution of the response times is displayed in an ALV Grid Control.

Result The output area displays the most important workload data, 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 list, you can restrict the display to the desired task type. By double clicking a row, you can display the transactions executed in the corresponding time period.



Hitlists: Display 40 Worst Response Times Use In the workload monitor, you can display the workload in various analysis views [page 18], each of which displays a particular aspect of the workload. One of these aspects is the question of which dialog steps and application steps have the longest response times 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 In these hitlists, 40 transaction steps are listed 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 In these hitlists, 40 application statistics steps are listed 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 are using most resources.

Using the hitlists, you can answer the following questions, among others:

• Is it always the same program that has high response times?

• Is this program running at the same time in several sessions (and therefore locking work processes)?

• How many kilobytes of information are transferred?

• Could the program be started at night in the background?


2. Choose the appropriate user mode. You can display hitlists in every user mode, although the restriction on the time period due to the choice of user mode also applies to the hitlists.


4. Under Analysis Views, choose the Hitlists option.

5. Choose the desired hitlist.

6. To display more details, choose a row of the table by double clicking it.

See also: Response Times: Rough Guide [page 34]



Displaying Memory Usage Statistics Use In the workload monitor, you can display the workload in various analysis views [page 18], each of which displays a particular aspect of the workload. One of these aspects is the question of the average or maximum values for the memory requirements for a particular transaction or a particular user per dialog step.


2. Choose the appropriate user mode. You can display the memory usage statistics in every user mode, however the restriction on the time period due to the choice of user mode also applies to the memory usage statistics.


4. Under Analysis Views, choose the Memory Usage Statistics option by double clicking it.


Result The output area contains two tab pages with the following properties:

Tab Page Properties

Transactions The memory usage is sorted by the transactions executed during the analysis period. Double click a row to display the memory usage for the selected transaction sorted by user.

User The memory usage is sorted by the users logged on during the analysis period. Double click a row to display the memory usage for the selected user, sorted by transaction.

You require a special authorization (profile S_TOOLS_EXE) to display user-specific data.



Displaying RFC Profiles Use In the workload monitor, you can display the workload in various analysis views [page 18], each of which displays a particular aspect of the workload. One of these aspects is the workload caused by Remote Function Calls (RFC).

By displaying the RFC profiles, you can answer the following questions:

• Which transaction, which function modules, 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 RFC are executed during a transaction step, only the five calls with the largest execution times are logged, which is sufficient for performance analyses. A larger value for stat/rfcrec can lead to performance problems in the collector. See also Collectors and the Performance Database [page 16].

The RFC client and RFC server records contain data about individual RFCs, such as execution time and called function. The RFC destination records contain the total of all RFC calls for each destination and therefore no additional information about the called function modules.




4. Under Analysis Views, expand the RFC Profiles option, and choose the desired RFC profile.


Result The output area contains the following tab pages, depending on the selected RFC profile:

Tab Page Meaning

Function Module Transaction User

What workload is caused by the function modules, transactions, or users (depending on the selected RFC profile as an RFC client or an RFC server)?

Targets Remote Destinations Local Destinations

Where is the RFC workload created?

To obtain information about any row, choose the corresponding row by double clicking it.



Displaying User Profile and Account Statistics Use In the workload monitor, you can display the workload in various analysis views [page 18], each of which displays a particular aspect of the workload. One of these aspects is the question of how the workload is distributed among the various 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 particular user must wait on average, and how is this time split?

• How many dialog steps has a particular user executed?

• Which database accesses with what workload did a particular user cause?

You require a special authorization (profile S_TOOLS_EX) to display the data for this analysis view.




4. Under Analysis Views, choose the User Profile option. In the Expert user mode, expand the desired option under Analysis Views → User and Account Statistics.


Result User Profile Analysis View The output area contains five tab pages that display the most important workload data for individual users. Choose a user by double clicking to see a breakdown of the workload caused by this user, sorted by the individual transactions.

If you have chosen TOTAL as the Workload, the system displays the workload for the individual users totaled for all instances. Choose a user by double clicking to obtain a breakdown of the workload caused by this user, sorted by the individual instances.

Account Statistics Analysis View The output area displays the corresponding workload in this system in the tab pages Clients, Account Numbers, and Clients and Account Numbers. Every user is usually assigned to an account number in the user master. Choose a client or an account number by double clicking it to obtain information about the individual users of this client or this account number.



Displaying Frontend Statistics Use In the workload monitor, you can display the workload in various analysis views [page 18], each of which displays a particular aspect of the workload. One of these aspects is the question of how the workload is split between the various presentation servers and instances. With this information, you can answer questions such as:

• What data volume is exchanged between individual presentation servers and SAP instances?

• Which response times arise at the frontend (GUI, frontend-network, and so on)?

• Which presentation servers are causing what workload in a particular instance?




4. Under Analysis Views, choose the Frontend Statistics option.



Tab Page Description

Frontends The workload is displayed, sorted by the presentation servers for the selected instance. The values displayed are for the aspects of the workload that are connected to the presentation servers, such as the number of communication steps, transferred data volume, or frontend wait time.

Instance(s) If you have chosen the TOTAL workload (see also: Workload Collector Settings [page 45]), the same aspects of the workload are displayed sorted by instance of the system. To display the workload for the presentation servers assigned to an instance, double click on that instance.



Displaying Spool Statistics Use In the workload monitor, you can display the workload in various analysis views [page 18], each of which displays a particular aspect of the workload. One of these aspects is the question of how much workload is caused by 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 whole 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.


2. Choose the Administrator or Expert user mode.


4. Under Analysis Views, choose the Spool Statistics option.

If no spool statistics are available for a particular instance, the system does not display the icon for the spool statistics.



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 In the workload monitor, you can display the workload in various analysis views [page 18], each of which displays a particular aspect of the workload. One of these aspects is the question of how the 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), which are in a particular response time category (such as, response time between 0.4 s and 0.5 s).

• Percentage of the transaction steps whose response time is not longer than the upper limit of a particular response time category (such as response time between 0 s and 0.5 s).

This analysis view therefore provides a way of finding out very quickly what percentage of all transaction steps have a response time below a specific threshold value.

For more information about what response times you can expect, see: Response Times: Rough Guide [page 34].

As 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 frontend systems and the network from the calculation of the response time distribution.




4. Under Analysis Views, choose the Response Time Distribution option.


Result The output area contains three tab pages with the following characteristics:


Steps The system displays the absolute number of transaction steps in each response time category, broken down by task type.

Percentage The system displays the percentage of transaction steps in each response time category, broken down by task type.

Percentage (Cumulated)

The system displays the percentage of transaction steps with a response time between 0s and the upper limit of the response time categories, broken down by task type.



Response Times: Rough Guide Definition The following data provide you with a short overview of the optimal response times in your SAP system. You can display the current response times 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 proportion of the response time that is CPU time should not fall below 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 time for dialog transactions should not be more than a second.

Typical Times for Database Access

Database Access Time

Direct Read < 10 ms

Sequential Read < 40 ms

Sequential Changes > 25 ms

Possible Causes for Bad Response Times

High Value for Possible Reasons

DB Request (Change/Comm.) Problems with the database or the 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, the times for direct reads and changes should not be more than 10 milliseconds; time for sequential reads should not be more than 30-40 milliseconds.



Displaying Table Access Statistics Use In the workload monitor, you can display the workload in various analysis views [page 18], each of which displays a particular aspect of the workload. One of these aspects is the question of which transactions have accessed which database tables, and how often.

As the number of statistics records greatly increases by logging table accesses of this kind, this option is deactivated by default. You should only activate it for individual analyses and for individual transactions, as performance problems can occur in the statistics collector otherwise.

Prerequisites To be able to display table access statistics for individual transactions, you must first activate them.

Activating Table Access Statistics 1. To start the workload monitor, call transaction ST03N.


3. Choose Collector & Perf. Database → Statistics Records and File → Online Parameters → Dialog Step Statistics.

4. The system displays the Change Runtime Parameters for Statistics Collection dialog screen.

Here, you can change the online parameter stat/tabrec, which specifies the maximum number of table access statistics subrecords that the kernel can write for each transaction step. The N most expensive accesses of a transaction step are stored.

If you only want to activate the table access statistics for specific transactions, you can specify a maximum of five transactions in the online parameters stat/tcode1 to stat/tcode5. The table access statistics are then produced for only these transactions.

Change the parameter stat/tabrec only temporarily for individual analyses. The parameter should be set to 0 at all other times. Otherwise, the number of statistics records increases greatly, which can lead to performance problems in the statistics collector.




4. Under Analysis Views, choose the Table Access Statistics option.

If no table access statistics are available for a particular instance, the system does not display the icon for the table access statistics.

5. The system displays the usual output area, in which the requested table access statistics are displayed in an ALV Grid Control.





Tables The database tables that the activated transactions accessed are displayed with the most important workload data (number of selected, read, and modified data records, access time). If you choose a table by double clicking it, the system displays another screen, showing the transactions that accessed this specific table.

Transactions The activated transactions are displayed with the most important workload data with respect to table accesses (see above). If you select a transaction by double clicking it, the system displays another screen, showing the tables that this specific transaction accessed.



Displaying Load from External Systems Use In the workload monitor, you can display the workload in various analysis views [page 18], each of which displays a particular aspect of the workload. One of these aspects is the question of how much load occurs in a system due to actions from other systems.

If there is no connection to another SAP system in your system landscape, this analysis view does not exist.




4. Under Analysis Views, choose the Load from Ext. Systems option.


Result The output area displays the most important workload data that was triggered by actions in external systems, grouped by various viewpoints in five tab pages. Each row contains data from one particular external system.

Using the Aggregation dropdown list, you can sort the list by action and user. You can display more details by double clicking a row.

You require a special authorization (profile S_TOOLS_EXE) to display user-specific data.

Background Information When a transaction is started, the system generates a unique identifier, the trans-ID, which is transferred with Remote Function Calls (RFC) (as of SAP Basis 4.6D). This ID is retained even for RFCs over several systems, so that it is possible to identify the system at the beginning of the chain that originally triggered the action.



Configuration of the Workload Monitor Purpose You can use the workload monitor to analyze statistical data from the SAP Kernel. You can influence the type and scope of the data collection and the data storage in a large number of ways. This process presents these methods of influence.

As with every tool for monitoring a system, you must find an appropriate compromise with the workload monitor between the need for system monitoring that is as exact as possible on one hand, and the need not to damage system performance by monitoring on the other.

Process Flow You can intervene at various points in the data collection and storage:

Storage of data in the statistics files STAG for the individual instances Using the system parameters stat/max_files and stat/as_max_files (for application statistics) you can control how many statistics files the kernel uses. If the parameter is greater than zero, a new statistics file is created for every hour. With the sizes of these system parameters, you specify the maximum number of statistics files that can exist, before the oldest of them is deleted.

You can also increase the scope of the logging of statistics for particular transactions using various online parameters in the workload monitor (Collector & Perf. Database → Statistics Records & File → Online Parameters). For more information, see:

Displaying Table Access Statistics [page 35]

Displaying Application Statistics [page 25]

Note, however, that in this situation, significantly more statistics records are written by the kernel and that the load due to the statistics collector can also increase significantly.

Only use these functions temporarily when searching for concrete errors.

Scope and frequency of reading of STAD statistics files for the individual instances in the performance database MONI The statistics collector RSSTAT83 is responsible for transferring the data from the STAD statistics files to the performance database MONI. This and other collectors must run regularly in the system. You can find out how you can change the frequency of these runs in Configuring Performance Monitor Collectors [page 40]. For more information about which collectors there are, and what they mean, see Performance Database Collectors [page 42].

In addition to the frequency, you can determine the scope of the data transfer. As the collector runs in dialog, the collector cannot process any number of records during each run, as it would be stopped by the restriction on the runtime. You can therefore specify what type of statistics data the collector should read and which threshold values should exist for the processing of statistics records for each run. For more information about this, see Workload Collector Settings [page 45].

When the data is transferred from the STAD statistics files to the performance database MONI, it is always aggregated. If you want to analyze the data from the STAD files, use the Business Transaction Analysis [page 11] or the Last Minutes‘ Load [page 12].

Retention time for the data in the performance database MONI The smaller the performance database, the better the performance of all applications that access it. You should therefore only retain data in the database for as long as you require it. For more information, see Reorganizing the Performance Database MONI [page 47].

As well as the collection and storage of the statistical data, you can also influence the way in which the data is displayed. For more information, see Saving User-Specific Views [page 39].



Saving User-Specific Views Use You can save user-specific views in the workload monitor. If, for example, you are mainly interested in the analysis of response times for a time profile [page 26] in the Service Engineer user mode, you can save this as your default view. The next time you call transaction ST03N, the system automatically displays this view.

You can save a specific analysis view [page 18], with the selected tab page, task type, and the ALV layout in a user-specific view.

If you 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 user mode, the total of all instances (TOTAL) is displayed by default (see also Workload Collector Settings [page 45]).

Procedure 1. Start the workload monitor by calling transaction ST03N.


3. Expand the tree structure in the Functions subscreen and choose the instance and/or time period that you want to analyze by double clicking.

4. Select the desired analysis view and specify the task types and parameters that you want to display as your default view.

5. Choose the Save View pushbutton.

Result The next time you call transaction ST03N, the system automatically displays the view that you have just saved.



Configuring Performance Monitor Collectors Use The workload monitor takes the workload statistics from the performance database MONI. Various collectors must be run automatically at regular intervals so that this database table always contains current data.

This is performed using report RSCOLL00. This report activates the collectors in accordance with the entries in table TCOLL. RSCOLL00, in its turn, is executed by the hourly scheduled background job SAP_COLLECTOR_FOR_PERFMONITOR.

By changing the entries in TCOLL, you can determine which collectors should run, and how often they should run. Normally, you do not have to change these settings. There are two possible situations in which you could have to change the entries in TCOLL:

• The performance database MONI is too large due to the quantity of collected data.

• The collectors themselves are creating too large a workload.

Note that the collectors for the table TCOLL not only form the basis of the data for the workload monitor, but are also important for other transactions (ST02, ST04, ST06, and ST10).



3. In the Functions subscreen, choose the Collector & Perf. Database → Perf. Monitor Collector → Execution Times.

4. The system displays the Contents of table TCOLL screen, showing an execution timetable for the various collectors. Each row specifies for one collector on which days of the week and at which times of the day the corresponding report is executed. For an execution, both conditions, week day and hour, must be fulfilled. See also: Performance Database Collectors [page 42].

In the System column, you can specify on which instances the report should run:

Entry in the System Column

Meaning

C The report runs on the central instance of the system.

* The report runs on every instance of the system (the background job SAP_COLLECTOR_FOR_PERFMONITOR distributes the report).

E The report runs on the instance of a system on which the enqueue process is running; this is important for systems in which the central instance shares a host with other instances.

5. If you want to change the execution time, choose Table Maintenance.

6. The system displays the Performance Collector: TCOLL maintenance screen. Each row contains the execution times for a report.

− In the column Days M-W-F-S, you specify on which days of the week the report should be executed by entering seven characters. Enter a character for every week day, beginning with Monday: X (the report should be executed on the corresponding weekday) or a space (the report should not be executed on the corresponding weekday).



− Make a specification in the same way in the Hours 0-2-4-6-8-0-2-4-6-8-0-2- column, in which the 24 individual characters stand for the hours of a day from 00:00 hours to 23:00 hours.

− In the R column, you specify how often the report should be executed per rotation.

− In the Alternative System column, you specify on which instance the report should be executed.

See also: Collector and Performance Database [page 16]



Performance Database Collectors A short description follows of the ABAP programs that can be started from the RSCOLL00 data collection program. Using the descriptions, you can decide which of the programs you should run in your system by scheduling them in table TCOLL (see also Configuring the Performance Monitor Collector [page 40]).

For recommendations about which report should be executed, see SAP Note 0127642.

RSHOSTDB

This program updates the MONI performance database with operating system data. It reads data for the operating system monitor from the main memory of the host and writes it to the database tables OSMON and MONI.

As the data is retained for a maximum of 24 hours in the main memory, you should schedule the program in table TCOLL on every system so that it runs at least once a day on every SAP instance. If several instances of the same SAP system are on the same host, the data collector starts the program only once on this host.

RSHOSTPH This program checks whether system parameters of the host operating system have been changed since the last time the program ran, and logs any changes that have been made to database table PAHI.

As the parameter changes are only stored once a day, it is sufficient to schedule this program in table TCOLL on each system so that it runs of every SAP instance once a day. If several instances of the same SAP system are on the same host, the data collector starts the program only once on this host.

RSORASNP RSORASNP collects database statistics (such as the number of user calls, searches of long tables, and so on). For this, it reads the current database statistics from the Oracle table V$SYSSTAT and stores it in table DBSNP. At the same time, the program deletes obsolete entries from this table. The number of entries that it deletes depends on the setting for the parameter STATS$TABLES_DAYS_TO_KEEP in table TSEXC; the default value is 120 days.

This report is called for Oracle indirectly through the report RSDBPREV, which means that you do not need to schedule it directly in table TCOLL.

RSDBPREV This program calls a database-specific report that generates and stores current statistics for the database system. For an Oracle database, this report is RSORASNP.

RSDB_TDB The program RSDB_TDB replaces RSORATDB (see also SAP Note 12103). It analyzes the growth of certain tables, indexes, and tablespaces, and writes the results to the performance database MONI. The program creates forecasts on the basis of values from the past, in order to be able to issue warnings about possible storage bottlenecks in good time.

The results are stored with a time stamp. This means that you should execute the program at least once a day on the database server (entry in table TCOLL with System = C). If there is no active dialog instance on the database server, the data collector switches to the first available application server.

Considerable CPU resources may be required on the database server to run RSDB_TDB depending on the database size. You should therefore schedule this program only infrequently. This means that the collected data will not always be up-to-date, but will reflect the status at the time of the collector run.



RSDB_PAR The program RSDB_PAR replaces RSORAPAR (see also SAP Note 12103). It logs changes to the database parameters. RSDB_PAR checks whether database parameters were changed since the last time this program was executed and logs the changes to database table PAHI.

As the parameter changes are only stored once a day, a daily execution of the program on the database server is sufficient (entry in table TCOLL with System = C). If there is no active dialog instance on the database server, the data collector switches to the first available application server.

RSORA811 The program deletes old backup logs that were generated by the SAP utility programs BRBACKUP and BRARCHIVE. It deletes obsolete log entries in the database tables SDBAH and SDBAD. For more information about the SAP utility programs BRBACKUP/BRARCHIVE, see the online documentation (SAP/Oracle-DBA in CCMS).

RSSTATPH The RSSTATPH logs changes to the SAP parameters, like the RSHOSTPH and RSORAPAR programs. You should execute the program daily in every SAP instance (entry in table TCOLL with System = *).

RSSTAT60 The program reorganizes the performance database MONI. Data that is older than the age specified in the corresponding parameters is deleted.

Due to the number of affected database accesses, schedule RSSTAT60 in table TCOLL so that it runs on the database server (entry in table TCOLL with System = C). A dialog instance must be active on the database server.

RSEFA350 This program updates the statistics for tables with major changes in Informix systems. On Oracle platforms, it analyzes the size of the SAP tables. The execution of RSEFA350 requires a lot of time and causes a high system workload. You should therefore only run this program when it is absolutely necessary to do so.

RSHOSTDC This program reads the operating system workload on a database server with no SAP instance and stores the data in the performance database MONI.

RSDB_WDB The program RSDB_WDB replaces RSORAWDB (see also SAP Note 12103). It is responsible for database analysis on DB2/6000 platforms and should normally only be scheduled for one run per week.

RSSTAT83 The program RSSTAT83 replaces RSSTAT80. Unlike RSSTAT80, it runs on all hosts simultaneously and only sequentially on the instances of a host. For more information, see SAP Note 127642.

The program transfers local statistics. It reads the local statistics for the various SAP instances and writes the statistics data to the performance database (entry in table TCOLL with System = *). The program makes a record of which data has already been read, thus ensuring that no data is read or transferred more than once.



Schedule this program hourly using table TCOLL. RSSTAT83 writes its own log, which you can view in transaction ST03N in Expert user mode [page 9] by choosing Collector and Performance Database → Workload Collector → Log.

RSSTAT81 This program stores specific performance analysis data in the performance database MONI.

RSSTAT90 This program reads table access statistics and stores them in the performance database MONI.

RSSTAT98 This program logs active instances in table SAPWLSERV.

RSSTAT89 This program reads application statistics records, compresses them, and stores them in the performance database MONI.

RSTUNE80 This program reads the buffer statistics and stores them in the performance database MONI.

RSRFCDLT This program deletes certain entries in the RFC statistics table.

RSORAVSH This program analyzes wait situations on the database (ORACLE only) and stores them in the performance database MONI.



Workload Collector Settings Use The statistics collector RSSTAT83 reads the statistics data from the STAT file for an instance. After aggregation, this data is stored in the performance database MONI. In these settings, you define, among other things, how many statistics records the workload collector reads and how long they should be retained.

In doing so, you set the guidelines for the usual compromise between the desire for monitoring of the system that is as exact as possible on one side, and monitoring that does not affect system performance on the other.

Activities To start the workload monitor, call transaction ST03N. Choose the Expert user mode.

Logging Choose Collector & Perf. Database → Workload Collector → Log to display the collector log. For more information about the collector runs during a day, choose the corresponding row by double clicking it. Among other things, the number of records processed on the individual instances for each collector run is logged.

Use this function when you are searching for the cause of errors, if the workload collector does not function without errors.

Control Choose Collector & Perf. Database → Workload Collector → Control, to define the most important parameters for the collector:

• You can define how many collectors can run simultaneously in the system using Maximum Number of Parallel RFCs in Workload Collector Run.

• You can define how many records can be processed per run using Number of Dialog Step Statistics Records and Number of Applications Statistics Records.

You should not set this limit too high, as the collector runs in dialog mode, and is stopped by the system with a timeout, if the maximum permissible runtime is exceeded (profile parameter rdisp/max_wprun_time). Rather, you should set this limit low enough that the collector can process the set number of records within the permissible runtime.

• In the Retention Time/Size of the Statistics File group box, you can specify the maximum length of time for which statistics files are stored separately for dialog step statistics and application statistics. In this way, you determine that individual records are still available for analysis for a defined period (such as the last 24 or 36 hours).

Prerequisites:

− You require sufficient storage space in the file system (SAP directory data).

− The profile parameters stat/max_files and stat/as_max_files (which specify the maximum number of concurrently existing dialog step statistics or application statistics before the oldest data is deleted) cannot be smaller than the desired retention time in hours. The reason for this is that the workload collector runs once an hour and writes a statistics file each time.

The statistics data in the STAT file contains the statistics records as they are written from the kernel after each transaction step, while the data in the MONI table has already been aggregated, meaning, for example, that the analysis of parts of a transaction is no longer possible. After the length of time specified in the Retention



Time/Size of the Statistics Files group box has expired, it is no longer possible to perform an analysis below transaction level.

Statistics to Be Created To activate or deactivate various statistics, choose Collector & Perf. Database → Workload Collector → Statistics to Be Created.

Depending on your requirements, TOTAL statistics, the total of all instances, can be created, for example. You can also deactivate individual profiles in the workload statistics, reducing the runtime of the collector and the storage requirements of the performance database. Note, however, that certain statistics are a necessary prerequisite for SAP Service (weekly totals, hitlists, memory usage statistics, RFC statistics, and statistics for the load from external systems).

You can activate Transaction Detail Profiles for individual transactions here. The analysis of the data does, however, require detailed knowledge of the function codes for the application. Therefore activating a transaction detail profile only makes sense when analyzing concrete problems.

See also: Collector and Performance Database [page 16]



Reorganizing the Performance Database MONI Use The performance data is stored long-term in the MONI performance database. As new performance data is constantly being stored, the table must be reorganized regularly. The data is retained for a specified period of time and then deleted. This is performed automatically using the ABAP program RSSTAT60.

The MONI table is specially encrypted and cannot be accessed using conventional methods.

You can specify how much data you want to retain in MONI. In this way, you limit the size of the table, to optimize performance of the CCMS monitors. The smaller MONI is, the better the various CCMS monitors perform.

If you use the recommendations below for the parameters for the standard statistics and other data, MONI requires between 10 MB and 50 MB of space on the hard disk, depending on the size of your system and the type of statistics to be collected.

As of SAP Basis 4.6C, server statistical data is collected and aggregated once a day in table MONI. Data for the weekly, monthly, and total statistics is then generated using this daily data.

This means an improved performance in comparison to earlier releases, where the weekly and monthly statistics were collected every hour. The total instance statistics are also no long collected daily at 0400 hours. Instead, they are aggregated when all of the data is available for the previous day. This means that the workload monitor statistics are more consistent.

Activities To start the workload monitor, call transaction ST03N and choose the Expert user mode.

Schedule Program RSSTAT60

1. Choose Collector & Perf. Database → Perf. Monitor Collector. → Execution Times.

2. The system displays the Contents of table TCOLL screen. The execution times of the report are displayed in the RSSTAT60 row. It must be executed at least once a day. To change the execution times, choose Table Maintenance. See also: Configuring the Performance Monitor Collectors [page 40].

Setting the Reorganization of Table MONI To set the parameters that affect the reorganization of the MONI table by RSSTAT60, choose Collector & Perf. Database → Performance Database → Reorganization.

The system displays the Retention Times for Performance Data dialog screen. The settings for Standard Data and Other Data are displayed on the screen. The performance database is divided into two parts. The data for each part is retained for a different length of time. You can see which data belongs to which group in the corresponding group boxes.

During a reorganization run, RSSTAT60 deletes all data whose retention time has expired.

When statistics are replaced by new statistics during the reorganization of the performance database MONI, you can only recover them using the standard techniques for database recovery.



We recommend the following retention times:

• Standard Data This data is very detailed and requires a great deal of storage space. You should therefore set the retention time to a relatively short time. Set a value of at least 2 for each of the three statistics types, so that the statistics are retained for two days, two weeks, and two months. However, you should set longer retention times for small and mid-sized SAP systems, and for testing new SAP releases.

• Other Data

This data is less detailed than the standard data and therefore requires significantly less storage space. You can therefore set a longer retention time than for the standard data. Use a retention time of 20 days, 20 weeks, and 14 months.

See also: Performance Database Collectors [page 42]


Documents

st03