126600539 Transactions STAD SM19 SM20

Transactions STAD, SM19, SM20

Statistical Records Part 1: Inside STAD

What are statistical records?

The ABAP statistical records are very useful if you want to know what’s going on in your system. It’s a technical logging feature implemented in the SAP kernel, and completely independent of the applications. Each dialog step is recorded, an information like user and program name, response time, CPU time and more is logged. This information is very useful when you want to analyze the performance (or a performance bottleneck) of your SAP system. From the statistical records you can get a hint where you should continue with a detailed analysis: CPU or database performance, memory issues, analysis of a particular application, and more.

How are statistical records created?

Statistical records are created by the work processes (WP) of an ABAP application server. At the end of a dialog step the WP collects the necessary information like user ID, program name, start time and end time of the dialog step, calculates metrics like response and DB time, and stores all this together in a so-called statistical record. This record is then stored in a shared buffer. All WP of an ABAP application server share the same buffer, and the statistical records are stored in the buffer chronologically.

When the buffer is full it is flushed to a file in the file system. Each SAP application server has it’s own statistics files.

The following screenshot illustrates the architecture.

Where are they stored?

The SAP kernel uses not only one single file for the statistical records. Each hour a new file is created where the statistical records are stored. This keeps the file size small and allows a flexible reorganization of the files (see below).

The files are stored in a directory like /usr/sap/<SysID>/<Instance Directory>/DATA. Try transaction AL11 to display the DIR_DATA directory. You’ll find one file named stat and many files named statnnn (where nnn is a number). These are the statistics files. Don’t try to display these files, they contain binary data only.

Page: File:1 of 14 130455493.doc


How are the stat files reorganized?The kernel itself maintains the number of statistics files. The profile parameter stat/max_files is used to control the maximum number of statistic files. Each hour a new file is created and the oldest file is deleted automatically. Make sure you have enough disk space available for all the statistic files. Otherwise the syslog (transaction SM21) shows the following message:

> File: /usr/sap/BCE/D26/data/stat

Failed to write to file, error 0028

How can I access statistical records?

Using transaction STAD you can access the statistics files and display the statistical records. Here is a screenshot of the start screen of STAD.

Just specify date, time, and length of the interesting interval and hit the enter key. If necessary you can narrow your search by specifying values for the filter parameters:



If you select the button Server selection you can select the application servers you want to analyze. By default the statistical records of all servers are collected by STAD. Be sure that the checkbox Include statistics from memory is checked. This will force a buffer flush (see above) before reading statistical records from the file system.

Now hit the Enter key. STAD presents the result as a simple list.

Each line represents one dialog step. You can see the starting time of that dialog step, the application server name, and the program or transaction name, respectively.

For each dialog step the several metrics are shown, e. g. response time, CPU time, and DB time (scroll to the right to see these columns).

Please note: you need the authorization profile S_TOOLS_EX to see all user names. Without this profile you will see only your own user name. All other user names will be deleted and STAD only displays “-?-“ instead.

There is one thing I would like to point out here. We have specified an interval starting from 10:04:00, but the list shows a statistical record from 09:59:47. Is this an error? No, because 09:59:47 is the start time of the dialog step. The response time of this dialog step is 621 seconds, so the step ended at 10:10:08. At that time the statistical record was created and written to the shared buffer. And 10:10:08 is definitely inside the



interval we have specified for STAD. So, if you are looking for the statistical record of a long running batch job then you need to know when this job ended (e. g. from the job log). In STAD specifiy an appropriate interval around this point of time. STAD will display the records sorted by their start time.

If you double-click one line you will see the details of this statistical record. All metrics are shown. You will have to scroll down a few pages to see all of them. The following example just shows a small part of it.

The section is titled Analysis of time in work process. The executed program was SAPWL_ST03N. The dialog step was started at 15:24:24 and ended at 15:24:30. The response time was 6087 ms, while CPU time was 210 ms. This information helps if you want to analyze the performance of a single dialog step. You can see why the response time is larger than 6 seconds. CPU consumption is not an issue here in this example, but DB time is very high. So this could be the point where an optimization could start.

Summary

You can see that STAD shows many technical details. All metrics are measured during the execution of the dialog step, and they describe what really happened. This makes the statistical record a valuable source of information about the performance of an application server. The statistical records are used to calculate aggregations (shown in ST03N), and they are used for SAP services like Going Live and Earlywatch Alert.

Andreas Vogel works as a developer and project lead in SAP Netweaver.

Statistical Records Part 2: RFC Statistics

My last blog [1] introduced the statistical records of an ABAP application server. This time I would like to talk about the internal structure of the statistical records. As an example the RFC records are introduced. This blog is about SAP_BASIS 700 which comes with Netweaver 2004s. The overall concept described here has not changed very much since release 4.6C, but details could be different.


https://weblogs.sdn.sap.com/pub/wlg/5511

https://weblogs.sdn.sap.com/pub/u/4242


Structure of Statistical Records

First let's have a look at the structure of the statistical records. A statistical record consists of several parts. The first part is the so-called main record where we find information like transaction code and program name, start and end time, response time, etc. This main record is part of every statistical record.

Additionally we may find other optional parts. Whenever database operations have been performed we will get a database subrecord for this dialog step. If stored procedures were executed on the database we will get a subrecord for DB procedures. If a report has been executed as a batch job we will get a batch subrecord, telling us e. g. the job name and job ID. The following picture illustrates the structure of a statistical record.

All these subrecords are optional, and the SAP kernel will generate these on demand. This saves a lot of disk space in the file system and speeds up writing and reading the statistics file. Here is the complete list of subrecords:

• batch subrecords • database subrecords • db table subrecords • db procedure subrecords • spool print subrecords • spool activity subrecords • ADM message subrecords • client information subrecords • RFC client subrecords • RFC server subrecords • RFC client destination subrecords • RFC server destionation subrecords • http client subrecords • http server subrecords • http client destination subrecords • http server destionation subrecords • smtp client subrecords • smtp server subrecords • smtp client destination subrecords • smtp server destionation subrecords • VMC subrecords • ESI subrecords (SAP_BASIS 710) • ESI destination subrecords (SAP_BASIS 710)

Don't get confused, we'll not discuss all of them in detail now. Instead let's have a closer look at the RFC subrecords.



What are RFC statistics records?

The RFC statistical records can tell us some details of the RFC activity of a program. If a program performs RFC calls then you will get RFC client and RFC client destination records. An RFC server process receives RFC calls and will write RFC server and RFC server destination records. If the RFC server process itself performs RFC calls then it is a client and a server simultaneously. In this case you will see all four different RFC subrecords within one statistical record. STAD displays the RFC overview, if RFC subrecords are present.

RFC Client Let's start with the RFC client records. The following picture is a screenshot from STAD for an overview of RFC client process.

We can see that 30 RFC calls have been performed over (at least) 5 connections to 5 destinations for this dialog step. The calling time for the client was 7.212 ms in total, while the remote execution time (for all servers) was 6.688 ms. The calling time includes codepage conversions and network transport. The remote execution time is measured by the RFC server and includes authority check and function execution only. 11.330 bytes have been sent to the servers, and 14.225 bytes have been received. The idle time is the time between two subsequent RFC calls for an open connection. There are two highlighted fields on this screen: Connections and Calls. You may click on these fields to display more details. Let's continue with the calls, which will display the RFC client records.

An RFC client record describes exactly one single RFC call. The most important information is the function name, the execution time of this function, and the amount of data transported in both directions. The following screenshot of STAD shows an RFC client record.

This screen shows an RFC call of a function called START_TCOLL_REPORT. The Call number is 6, indicating that this call is the 6th call over this particular RFC connection. The Connection ID of this



connection is displayed (a GUID) as well as the name of the destination. The calling time and the remote execution time are given, and a few hundred bytes have been transferred between client and server. The time for data transfer (data send time and data receive time) is less than 1 ms. The field communication step shows that sending and receiving happened during the same dialog step which should be the normal situation for a synchronous RFC. For asynchronous RFC sending and receiving may happen during different dialog steps.

Of course it is not possible to log each individual RFC call in this way. The amount of data would be too large to handle. Instead the SAP kernel logs the five most expensive RFC client records only, all others are discarded. Expensive means "expensive in terms of execution time". The profile parameter stat/rfcrec controls the maximum number of RFC subrecords (default value = 5). Increasing this value is dangerous, because the file system will be flooded with statistical records. And it affects the system performance, because all these statistical records have to be processed by the SAP workload collector (which will be the topic of another blog).

Instead of logging every single RFC call the RFC client information is summarized, and for each RFC connection an RFC client destination record is written. From this record we can see how many RFC calls were performed for this particular connection, how many bytes have been transported in total, and of course the total execution time. Again the maximum number of RFC client destination records is limited by the profile parameter stat/rfcrec. If a client performs RFC calls across more than 5 connections than only the 5 most expensive connections (in terms of execution time) are logged. The following screenshots of STAD shows an RFC client destination record.

This screen shows the details for a particular RFC connection. We can see the connection ID, the type of RFC (synchronous), the types of the local and the partner engines (R/3 System in both cases), and the combination of user name and client number used for logon. Destination is the name of the RFC destination (see Tx SM59). Instance is the name of the local application server from where this call was issued, and IP address is the local IP address. From the remote application server we see Partner instance, Partner IP address, and Partner Release (not all RFC server will provide this information, but a SAP application server will do so). In total six calls have been performed for this particular connection during this dialog step, and the total calling time was 2624 ms.



RFC Server

To show the complete picture the following STAD screenshots depicts the RFC server records. Again we start with the overview.

This screen shows the overview for an RFC server process during a dilaog step. One incoming RFC call from one connection has been received. The RFC server has received 12.415.680 bytes, and the server execution time (authority check and function module execution) was 711 ms, while the calling time (including code page conversions and network transfer) was 6.656 ms.

Let's go to the details of that particular RFC call (click on the hotspot behind the field Calls). The following screen is very similar to the one of an RFC client. We can see the name of the executed function module, the connection ID, and the destination name NONE (an RFC call within the same application server) as well as the performance metrics.

The next screenshot shows the RFC server destination record. It shows the details of the RFC connection and the summary of all RFC calls for this connection. We can see that this connection has been used for an asynchronous call without a response. The details of this screen are similar to the RFC client destination record (see above).



Please note that the lifetime of an RFC connection is independent of a dialog step. Depending of the scenario and the implementation an RFC connection may be used during several subsequent dialog steps of an application or program. The RFC client/server destination records are created in the context of a dialog step and will always show the activity for a connection during this dialog step.

There are some details of an RFC server process which are important to know. Let's assume an RFC client performs several calls to an RFC server. If the connection is not closed explicitly then it will be used for all these calls. But when will the RFC server process write a statistical record? After each RFC call? No, that's not the case. The SAP kernel will write a statistical record after the roll-out of the RFC server process from the work process, and the roll-out will occur if no subsequent RFC call is received within a timeframe of 500 ms. At that point the data for the statistical record is collected, and this includes the RFC subrecords, of course. If subsequent RFC calls follow within 500 ms then the context of the RFC server will not be rolled out from the work process. This is a performance optimization, because it avoids frequent roll-out and roll-in which would increase the RFC execution time. Please note that the overall response time of an RFC server process may be 500 ms larger than the calling time. The overall response time is shown by STAD on the main list, while the calling time is shown with the RFC details (see the RFC server destination record).

The design principle of client/server single records and client/server destination records has also been used in a similar way for the http and smtp subrecords. Check it out, STAD will display all of them.

To learn more about RFC please read the interesting article by Masoud Aghadavoodi Jolfaei and Eduard Neuwirt [3]: Master the five remote function call (RFC) types in ABAP.

If you want to learn more about SAP performance optimization the following book might be interesting for you: T. Schneider, SAP Performance Optimization Guide, 4th ed., SAP PRESS, ISBN 978-1-59229-069-7


https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f078394a-4469-2910-c4bf-853c75674694


Security Monitor Use

You can use this monitor to monitor messages in the Security Audit Log, broken down into various areas, and to monitor security-relevant messages in the system log (see also Comparing the Security Audit Log and the System Log).

Prerequisites

You must have activated the Security Audit Log (transaction SM19).

Features

The monitor contains the following monitoring tree elements (MTEs):

MTE Name(MTE Class)

Meaning

Logon(SecurityLogon)

System logon events reported by the Security Audit Log: Successful logons, unsuccessful logon attempts,

and log offs by a user Locking of a user due to unsuccessful logon

attempts, and the removal of the lockRFCLogon(SecurityRFCLogon)

RFC/CPIC logon events reported by the Security Audit Log: Successful RFC/CPIC logon Unsuccessful RFC/CPIC logon attempt

TransactionStart(SecurityTransactionStart)

Transaction events reported by the Security Audit Log: Transaction started and failed transaction start Transaction locked or unlocked

Page: File:10 of 14 130455493.doc

http://help.sap.com/saphelp_nw04/helpdata/en/b6/d6af7f6bc011d1a56c0000e835363f/frameset.htm

http://help.sap.com/saphelp_nw04/helpdata/en/b6/d6af7f6bc011d1a56c0000e835363f/frameset.htm

http://help.sap.com/saphelp_nw04/helpdata/en/68/c9d8375bc4e312e10000009b38f8cf/frameset.htm

http://help.sap.com/saphelp_nw04/helpdata/en/23/c9833b3bb1780fe10000000a11402f/frameset.htm


MTE Name(MTE Class)

Meaning

ReportStart (SecurityReportStart)

Events connected with starting reports reported by the Security Audit Log:

Successful start Failed start

RFCCall (SecurityRFCCall)

Events connected with calling Remote Function Calls (RFCs) reported by the Security Audit Log:

Successful call Unsuccessful call

UserMasterRecords (SecurityUserMasterRecords)

Events connected with changes to user master records reported by the Security Audit Log:

User deleted, locked, or unlocked User master or authorizations of a user changed Authorization/authorization profile created,

changed, or deletedSystem (SecuritySystem)

Events connected to system parameter changes reported by the Security Audit Log:

Configuration of the Security Audit Log changed Application server started or stopped

Miscellaneous (SecurityMiscellaneous)

Other events reported by the Security Audit Log: Download of a file Call of a digital signature Test message

System Log Messages(R3SyslogSecurity)

Messages in the system log for the security category; you can set the category in which a message is reported, the message text, and the severity and criticality of the alert using the message ID in transaction SE92

The system records security-relevant actions in the Security Audit Log. You decide which actions are recorded there and which should trigger an alert in the Alert Monitor on the Security Audit Log configuration screen (transaction SM19).

See also Defining Filters

ActivitiesTo start the monitor, follow the procedure below:1. Start the Alert Monitor using transaction RZ20 or choose CCMS → Control/Monitoring → Alert Monitor.2. On the CCMS Monitor Sets screen, expand the SAP CCMS Monitor Templates set.3. Start the Security monitor from the list by double-clicking it.

Page: File:11 of 14 130455493.doc

http://help.sap.com/saphelp_nw04/helpdata/en/b6/d6af856bc011d1a56c0000e835363f/frameset.htm

http://help.sap.com/saphelp_nw04/helpdata/en/1f/8311784bc511d189750000e8322d00/frameset.htm


The Step required to Audit at the User Level

The followings will help you to Understand how to Audit at the Users level:

Creating a User Audit Profile

1. Log on to any client in the appropriate SAP system. 2. Go to transaction SM19. 3. From the top-most menu bar on the Security Audit: Administer Audit Profile screen, click Profile ->

Create. 4. On the Create new profile popup, type in a new Profile name and click the green Enter picture-icon. 5. On the Filter 1 tab of the Security Audit: Administer Audit Profile screen, click the BOX to the left of

Filter active to place a TICK in the box. In the Selection criteria section, select the Clients and User names to be traced. In the Audit classes section, click "on" all the auditing functions you need for this profile. In the Events section, click the radio button to the left of the level of auditing you need. Once you have entered all your trace information, click the Save picture-icon. You will receive an Audit profile saved in the status bar at the bottom of the screen.

6. Please note that while the user trace profile has been saved, it is not yet active. To activate the user trace, see the next section Activating a User Audit Profile.

7. You may now leave the SM19 transaction.

Activating a User Audit Profile

1. Log on to any client in the appropriate SAP system. 2. Go to transaction SM19. 3. On the Security Audit: Administer Audit Profile screen, select the audit profile to be activated from

the Profile dropdown. Click the lit match picture-icon to activate it. You will receive an Audit profile activated for next system start in the status bar at the bottom of the screen. The audit will not begin until after the SAP instance has been recycled.

4. You may now leave the SM19 transaction.

Viewing the Audit Analysis Report

1. Log on to any client in the appropriate SAP system. 2. Go to transaction SM20. 3. In the Selection, Audit classes, and Events to select sections of the Security Audit Log: Local

Analysis screen, provide your information to filter the audit information. If you need to trace the activities of a specific user, be sure to include that user's ID. Click the Re-read audit log button.

4. The resulting list is displayed. This list can be printed using the usual methods. 5. You may now leave the SM20 transaction.

Page: File:12 of 14 130455493.doc


SAP security audit log setup

1. IntroductionThe Security Audit Log is a tool designed for auditors who need to take a detailed look at what occurs in the SAP system. By activating the audit log, you keep record of those activities you consider relevant for auditing. This information is recorded on a daily basis in an audit file on each application server. You can then access this information for evaluation in the form of an audit analysis report. Statistical information can easily be retrieved on transactions and reports. Although it was not designed for this purpose, the information it generates is invaluable when estimating the number of resources needed for the next upgrade project and when you want to know to which transactions or reports most attention and effort should go to.

The following information can be recorded in the Security Audit Log:

2. Activating the audit logThe following instance profiles must be set in order to activate audit logging (use transaction RZ10 to do so).

rsau/enable: Set to 1 to activates audit loggingrsau/local/file: Name and location of the audit log filersau/max_diskspace/local: Max. space of the audit file. If maximum size is reached auditing stops.rsau/selection_slots: Max. number of filters

The settings are activated after the instance has been restarted.

3. Defining FiltersTo access the Security Audit Log configuration screen from the SAP standard menu, choose:Tools → Administration → Monitor → Security Audit Log → Configuration (or transaction SM19).

Filters define what needs to be recorded. The following information can be specified:

Filters can be static (permanently) or dynamic

Transactions SM18, SM19, SM20 deals with security Audit Log.

SM18To archieve or delete old audit log files

SM19you can configure the Static/Dynamic fileters here.The system administrator or security administrator defines the events you want to audit in filters. Filters consist of the following information:. Client. User. Auditclass. Weight of events to audit

The audit class returns information about the following:. Dialog logon. RFC/CPIClogon. Remotefunctioncall(RFC). Transaction start. Reportstart. User master change

You can specify the weight of events to audit:. Audit only critical

Page: File:13 of 14 130455493.doc


. Audit important and critical

. Auditallevents

SM20SM20 to assess the security audit log. Soppose if you wanted to find out the transaction run by a perticular user in certain period. You can get this information in SU20.Try also transaction SM20N. It is similar to SM20 but offers advanced selection options.

Please visite:http://help.sap.com/saphelp_46c/helpdata/en/95/d2a8e96d6611d1a5700000e835363f/frameset.htm

Check the below link which explains all about Auditing and logging in SAP.http://help.sap.com/saphelp_nw04s/helpdata/en/8a/a8b5386f64b555e10000009b38f8cf/frameset.htm

If you want to log only 3 users you have to create 3 filters. May be you can use a generic filter (for example user* or *user). For generic filters you have to set the system profile parameter rsau/generic_users to 1.

You need to create audit log parameters by using SM19.You need to check the parameters involved with SM19 audit. Please go, in Tx SM19, menu "Environment" (actually my SAP is in Spanish, it's the menu before "Systems") and select the option of Parameters.

See book:http://books.google.com/books?id=Wrwq0Sa50WQC&printsec=frontcover&hl=ro&source=gbs_v2_summary_r&cad=0#v=onepage&q=&f=false

Book: SAP Security Configuration and Deployment

http://rapidshare.com/files/277071367/doc.part41.rar

http://www.easy-share.com/1903563419/SAP_Security_Configuration_Deployment.rar

Elena: Buna Gabi. Am si eu o intrebare: stii cumva o tranzactie din care pot scoate, pentru un interval de timp dat, de cate ori a fost folosita o anumita tranzactie . Practic ne trebuie sa scoatem o statistica cu asa ceva si am gasit noi ceva (ST03N) dar nu pare a fi ce ne trebuie. Merci mult.Gabi Grecu: SCU3 dacav e activata. -> modificari pe tabeleGabi Grecu: ST03N e bun, dar e super incalcit.Gabi Grecu: STAD pe durate scurte (cel mult o zi in urma).Gabi Grecu: Poti sa ma suni?

Activat sist.de audit de BASIS: SM19, SM20

These transactions are for Security administration.

SM20 - Security Administrator run this report periodically to get the details of 'Failed logons' of the users in the Production system and investigate the causes. Apart from that other details e.g.Failed transations,users running the critical reports etc can also be obtained.SM18 - to delete old Security logs.SM19 - Audit Profile can be maintained.Go to 'Detailed Display',you can see the various Events correspond to their criticality.

Page: File:14 of 14 130455493.doc

http://www.easy-share.com/1903563419/SAP_Security_Configuration_Deployment.rar

http://rapidshare.com/files/277071367/doc.part41.rar

http://books.google.com/books?id=Wrwq0Sa50WQC&printsec=frontcover&hl=ro&source=gbs_v2_summary_r&cad=0#v=onepage&q=&f=false



http://help.sap.com/saphelp_nw04s/helpdata/en/8a/a8b5386f64b555e10000009b38f8cf/frameset.htm

http://help.sap.com/saphelp_46c/helpdata/en/95/d2a8e96d6611d1a5700000e835363f/frameset.htm

126600539 Transactions STAD SM19 SM20

Documents

Transcript of 126600539 Transactions STAD SM19 SM20