Introduction

You can follow the process of various operations in your SAP system with trace functions. This allows you to monitor the system and isolate problems that occur. There are two types of trace: the performance trace and the system trace. You can also use developer traces and the system log to correct problems. The following trace options exist in the system:

• System Log (SM21)

• Dump Analysis (ST22)

• System Trace (ST01)

• Performance Trace (ST05)

• Developer Traces (ST11)

You can use the System Log (transaction SM21) to detect and correct errors in your system and its environment. SAP application servers record events and problems in system logs. Every SAP application server has a local log that contains the messages output by this server.

If unpredictable errors occur during runtime when you call an ABAP program, a runtime error that generates a short dump can occur (transaction ST22).

If you want to record the internal SAP system activities, such as authorization checks, database accesses, kernel functions, and RFC calls, use the System Trace function (transaction: ST01).

The Performance Trace (transaction ST05) allows you to record database calls, lock management calls, and remote calls of reports and transactions in a trace file and to display the logged measurement results as lists. The Performance Trace also offers extensive support for a detailed analysis of individual trace records.

Technical information about internal SAP problems is logged in developer traces.

System Log

Events and problems are recorded locally on each application server and displayed in the system log in the SAP system.

If you are using the UNIX operating system, you can also work with central logging. In this case, each application server copies its local logs to a central log. Central logging is not possible on Microsoft Windows NT and AS/400 hosts. Technically, the system log is written to a ring buffer. If this log file reaches the maximum permitted size, the system begins to overwrite the oldest data.

To display a log, choose Tools -> Administration -> Monitor -> System Log or call transaction SM21. By default, the system reads the log for the last one to two hours. As well as the local system log, you can display system logs for other application servers in transaction SM21. To do this, choose the menu path System Log -> Choose -> All Remote System Logs or System Log -> Choose ->Central System Log.

In expert mode (menu path Edit -> Expert Mode), you can extend the selection criteria so that it is possible to search for entries for a particular terminal. To do this, choose the Attributes button.

In UNIX systems, you can display the status of the send process in the SAP system with transaction SM21 or by choosing Environment -> Process Status.

You can define the path and file names for local and central log files with the following system profile parameters:

• rslg/local/file: File name for the local log (Default: SLOG)

• rslg/central/file: File name for the active central log (Default: SLOGJ); does not apply for Microsoft Windows NT and AS/400 platforms

By default, the log files for the local system log are stored in the following directory: /usr/sap///log. The central system log is stored in /usr/sap//SYS/global

You can also schedule system logging as a background job. There are two ABAP programs provided to do this:

• RSLG0000: To create the local system log

• RSLG0001: To create the central system log (not on Microsoft Windows NT and AS/400 platforms)

Dump Analysis

ABAP programs are checked statically when they are created and dynamically when they are running. Error states, which are not statically predictable and only occur at runtime are dynamically identified by the ABAP runtime environment. States of this type lead to exceptions. If an exception is not handled or cannot be handled, a runtime error occurs. If a runtime error occurs, the ABAP runtime environment terminates the execution of the program, generates a short dump and branches to a special screen for analyzing the short dump. You can also find short dumps in transaction ST22 or by choosing the menu path Tools -> ABAP Workbench -> Test -> Dump Analysis.

A short dump is divided into different sections that document the error. The overview shows what other information is output in the short dump, such as contents of data objects, active calls, control structures, and so on. You can branch to the ABAP Debugger at the termination point from the short dump view. The following different error situations exist:

• Internal Error

The kernel identifies an error state. In this case, notify SAP.

• Installation and Environment/Resource Error

In this case, an error occurred that was caused by incorrect system installation or missing resources (such as the database being shutdown).

• Error in Application Program

Typical causes of errors are:

- Content of a numerical field not in the correct format

- Arithmetic overrun

- An external procedure is not available

- Type conflict when transferring parameters to an external procedure

By default, short dumps are stored in the system for 14 days. The transaction for managing short dumps is ST22. You can delete short dumps in accordance with a time specification using the Reorganize function, which you can call by choosing Goto -> Reorganize. You can save a short dump without a time limit using the Keep function, which you can choose under Short Dump -> Keep/Release.

If problems that you cannot solve yourself occur with ABAP programs, you can send an extract of the short dump to SAP. A short dump is the basis on which the SAP Hotline and remote consulting solve problems.

• If a runtime error occurs, a short dump is generated. You can use transaction ST22 to analyze this short dump.

• Dump data is stored in the database.

• Dump data can be reorganized.

• Individual short dumps can be flagged for retention.

SAP System Trace

You can use the system trace to record internal system activities. The system trace is primarily used if an authorization trace is to be created. SAP recommends that you use the system log or the developer trace for system monitoring and problem analysis. You can call the SAP System Trace using transaction ST01 or by choosing the menu path Tools -> Administration -> Monitor -> Traces -> System Trace. You can also use transaction ST01 to display the inactive trace file.

You can use the SAP system trace to monitor the following components:

• Authorization checks

• Kernel functions

• Kernel modules

• DB accesses (SQL Trace)

• Table buffers

• Lock operations (client-side)

You select the components to be logged on the initial screen. If the trace is activated for the authorization check, all authorization checks performed by the system are recorded. During the evaluation, you can identify which authorizations the system checked at which times. The following detail information is also provided: Date, time, work process number, user, authorization object, program, line, number of authorization values, authorization values.

You can use the SQL Trace to follow how the Open SQL commands in reports and transactions are converted to standard SQL commands and the parameters with which the SQL commands are transferred to the database system in use. The results of the SQL command are also logged, such as the return code and the number of records found, inserted, or deleted by the database. Logging the execution time and the callpoint in the application program allows you to perform more advanced evaluations.

With the enqueue trace, you can follow which lock instructions the SAP system performs on which lock objects, and which parameters the system uses for these locks. The program that triggered the lock, the owner of the lock, and the time that the enqueue server required to release the lock again are all also logged in the trace file.

You can use the RFC trace to follow which remote calls the SAP system executes, and the instance on which these calls are executed. You can see from the trace which function modules were called remotely by the program that is to be analyzed, and whether the RFC was successfully executed. The total time required for the execution of the remote call and the number of bytes sent and received during the RFC are also logged in the trace file.

Performance Trace

The performance trace provides the following functions:

• Recording database calls

• Recording lock management calls

• Table buffers

• Recording remote calls of reports and transactions

• Detailed analysis of individual trace records

• Analysis of an SQL statement

The performance trace provides similar trace options to the system trace. It allows you to record database calls, calls to lock management, calls to table buffers, and remote calls of reports and transactions from the SAP system itself in a trace file. You can call the Performance Trace using transaction ST05 or by choosing the menu path Tools -> Administration -> Monitor -> Traces -> Performance Trace. On the initial screen of transaction ST05, you can choose the Explain SQL button to analyze an SQL statement without branching to a specific trace file.

The performance trace is integrated into the ABAP Workbench as a test tool and can therefore be called there.

Configuring the Trace File

You can use system profile parameters to restrict the size of the trace files and to specify an appropriate path.

The SAP System Trace writes the trace data in its trace files. For performance reasons, this is not done directly, but rather using a process-internal buffer. The profile parameter rstr/buffer_size_kB determines the size of the buffer. Since SAP Web AS 6.10, the SAP trace stores the data in multiple files, which are written in turn. The parameter rstr/filename defines the base name of these files. There is always a file with exactly this name. When the file becomes full (parameter rstr/max_filesize_MB ), the file is renamed and a new file is generated with the base name. When the file is renamed, a number between 00 and 99 is added to the file name. The parameter rstr/max_files determines the maximum total number of files. If this value is exceeded, the files are overwritten.

Developer Trace

Developer traces are recordings that contain technical information and that are used if errors occur. This type of process trace is especially useful to investigate host and internal SAP problems that are affecting your SAP system. Developer traces dev_ * are written to files in the directory /usr/sap///work of the SAP application server that generated the trace.

You can access the developer traces using the operating system, using transaction AL11, or from transaction SM50 (Work Process Overview). In transaction SM50, you can switch to the individual dev_* traces by choosing Process -> Trace -> Display File. You can display additional details in the displayed traces by expanding individual entries.