Tracing and Logging in the SAP System

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.

System log is the analysis option for errors in the system and its environment.

There are functions that combine the properties of traces and logs, such as developer traces.

There are many trace options in SAP systems. The main ones are listed in Trace and Log Options.

You can use transaction SM21 to determine and correct errors that occur 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, such as errors, warnings, and information, logged by this server.

If unpredictable errors occur at runtime when you call an ABAP program, a runtime error that generates a short dump is logged (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).

You can use the Performance Trace function (transaction ST05) to record database calls, lock management calls, and remote calls of reports and transactions in a trace file, and display the logged measurement results as lists. The Performance Trace also offers extensive support for a detailed analysis of individual trace records. You can find all the functions of the Performance Trace in the System Trace as well. The Performance Trace is a more suitable analysis tool for certain problems, since the reduced scope of functions makes it is easier to handle.

Technical information about internal SAP problems is logged in the developer traces (transaction ST11).

Events and problems are recorded locally on each application server and can be displayed in the system log (syslog) in the SAP system, as shown in the following figure.

You display a system log with 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. On the initial Display the system log screen, you can specify for which instances the syslog should be displayed. The syslog messages will then be displayed for all selected instances.

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

rslg/local/file: File name for the local log (standard: SLOG<SAPSYSTEMNUMBER>)

By default, the log files for the local system log are stored in the following directory: /usr/sap/<SID>/<instance_directory>/log.

The log file has a maximum size that can be configured with profile parameter rslg/max_diskspace/local. The oldest entries will be overwritten as soon as the limit is reached.

ABAP programs are checked statically when they are created and dynamically when they are running. Errors that are not statically predictable and only occur at runtime are identified dynamically 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. When a runtime error occurs, the ABAP runtime environment terminates the execution of the program, generates a so called short dump, and branches to a special screen for analyzing the short dump. You can access short dumps using transaction ST22.

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, send a message to 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 shut down).

• 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 28 days. 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 from the Detail View 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 an important basis on which the SAP Hotline and remote consulting solve problems.

You can use the SAP system trace (system trace for short) to record internal system activities. You can call the system trace using transaction ST01. You can also use transaction ST01 to display the non-actively displayed trace file.

You select the components to be logged on the initial screen. You can use the system trace for tracing authorization checks. 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 detailed information is also provided: Date, time, work process number, user, authorization object, program, line, number of authorization values, and 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 call point 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. From the trace recording, you can see which function modules were called remotely by the program to be analyzed and whether the RFC call 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.

The performance trace is used for analyzing the following:

• Database calls (SQL Trace)

• Lock management calls (Enqueue Trace)

• Accesses to table buffers (Buffer Trace)

• Remote calls of reports and transactions (RFC Trace)

• HTTP communication (HTTP Trace)

• Single SQL statements (Enter 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.

Developer traces are recordings that contain technical information and 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/<SID>/<instance directory>/work of the SAP application server that generated the trace, as shown in the figure Developer Traces.

You can access the developer traces in the operating system, in transaction AL11, transaction ST11, or 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.

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 trace files. For performance reasons, this is not done directly, but instead using a process-internal buffer. The profile parameter rstr/buffer_size_kB determines the size of this buffer. The SAP trace stores data in multiple files, which are written sequentially. The parameter rstr/filename defines the base name of these files. There is always one file with exactly this name. If the file is full (parameter rstr/max_filesize_MB), the file is renamed and a new file is created 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 number of files. If this value is exceeded, the files are overwritten.