Errors in the SAP System that must be analyzed more closely. The Syslog information and short dump are not sufficient.
Reason and Prerequisites
There is an error in the C-kernel that is not logged in the Syslog/SNAP.
Solution
Depending on profile variable "rdisp/TRACE", trace and error information is stored for each SAP process and component. This mechanism was originally intended as support for C developers only, and is therefore called "Developer trace", in contrast to the "official" (syslog) SAP Trace.
Values of profile variable "rdisp/TRACE":
----------------------------------------
rdisp/TRACE =0 store no information
rdisp/TRACE =1 store only error information
rdisp/TRACE =2 also store trace messages
rdisp/TRACE =3 also fully trace data blocks
Trace components "rdisp/TRACE_COMPS"
-------------------------------------
rdisp/TRACE_COMPS = All all components on
rdisp/TRACE_COMPS = all all components off
Additionally, individual components may be activated with a capital
letter and deactivated with a lowercase letter.
Individual components are:
M Taskhandler
A Abap-Proc.
Y Dynp-Proc.
R Rolling
E Lock management
S Printing
N Security
T Debug System
J VM-Container
H ICF
L Background
C Database
B Database (DBSL)
P Paging
D Diag-Proc.
I IPC
X Extended Memory
G Language Support
W WebGui
For example, if you only want to activate the components "Taskhandler"
and "Abap-Proc", use:
rdisp/TRACE_COMPS = all, MA
for all other components apart from "Taskhandler" and "Abap-Proc", use:
rdisp/TRACE_COMPS = All, ma
The profile variables are only read when the system is booted.
If absolutely necessary (use carefully), you can change the value of TRACE for a process (Pid) at runtime using the following commands
under Unix:
kill -USR2
kill -USR1
under Windows:
sapntkill.exe -USR2
sapntkill.exe -USR1
USR2:
Increase TRACE by 1. With a USR2 signal, a current stack trace is generated additionally.
USR1: Reduce TRACE by 1. If TRACE = 0, all open TRACE files are closed. (In this state, the files can be reset to a size of 0 bytes, using the Unix command cp /dev/null 'Tracefilename' or echo > 'Tracefilename')
As of Release 7.00, a combined C-/Java stack dump can be generated with VMC activated:
kill -QUIT
or
sapntkill.exe -QUIT
Trace Logging (as of 6.20)
-----------------------
It may be necessary for some error analyses to increase the trace level significantly. To prevent an overflow in the file system, methods exist to reset the Trace files or to set the trace level back to 1.
rdisp/TRACE_LOGGING
(also refer to the documentation in Transaction RZ11):
You can use this parameter if the trace needs to be active for a longer
period of time in order to carry out an error analysis. To prevent the
trace files from increasing in size too much, you can activate an
automatic reset when the files reach a certain set size. Prior to reset,
the trace files are saved in a log file. This log file has the same name
as the trace file, with the extension ".old". Checks and necessary
resets are carried out in intervals defined by the parameter
rdisp/autothtime. The trace logging takes effect for work process
traces, the dispatcher and the gateway trace.
Valid input, formats, areas:
The parameters must have the following syntax:
rdisp/TRACE_LOGGING = on, [k m] [global=on off] off
The first part states whether the logging is active. Input "on" or "off"
is allowed here. With active logging, you can enter the file size
in the second part as of which the trace file is logged and a new trace
file is written.
Examples:
rdisp/TRACE_LOGGING = off
==> no Trace logging
rdisp/TRACE_LOGGING = on, 1000
==> Trace logging if the trace file contains more than 1000 bytes
rdisp/TRACE_LOGGING = on, 20 k
==> Trace logging if the trace file contains more than 20 kilobytes
rdisp/TRACE_LOGGING = on, 30 m
==> Trace logging if trace file contains more than 30 megabytes
The addition global=on or global=off only takes effect, if the parameter
rdisp/TRACE_PATTERN_0 is set together with the parameter
rdisp/TRACE_LOGGING.
The parameter states whether upon finding a pattern the trace logging
is deactivated globally on all servers or only locally on the server
which has found the pattern.
rdisp/TRACE_PATTERN_0
rdisp/TRACE_PATTERN defines a search pattern for the automated
switch off of the SAP trace. This parameter only takes effect if
the trace logging has been activated using rdisp/TRACE_LOGGING.
In this case, the trace files are searched for the search pattern prior
to automatic reset. If the search pattern is found, trace logging is
deactivated and the trace level is set to the value 1. Following
trace files are included in the search:
- All work process trace files dev_w*
- Dispatcher trace file dev_disp
- Gateway trace file dev_rd
- ICM trace file (if present) dev_icm
- Message server trace file (if present) dev_ms
The search pattern may contain the symbols * for any string of
characters and ? for any character. The symbol \ devalues
special characters, that is these take on the meaning of a normal
character. Note: To increase readability, the search patterns
in the following examples have been enclosed by quotation marks;
when you define search patterns in Transaction RZ11 or use them
in the profiles, you must leave the quotation marks out.
The trace pattern consists of any string of characters, which can also
contain the special characters * or ? as wildcards.
Examples:
Pattern
"word1 * word?"
is found in line
"one example with word1 and word2"
but is not found in line
"one example with word1 and word"
Pattern
"10 \* 10 ="
is found in line
"Multiplication: 10 * 10 = 100"
but is not found in line
"Addition: 10 + 10 = 20"
The values of parameter rdisp/TRACE_LOGGING and rdisp/TRACE_PATTERN_0
can be changed dynamically in Transaction RZ11.
The information is located in the following files:
Process File
------------------------------------
Dispatcher dev_disp
Work process dev_w
Message srver dev_ms
Sapgui dev_st< LoginName>
Gateway dev_rd
Gateway work processes dev_wp
RFC dev_rfc
ICM dev_icm
VMC vmc_w.log
vmc_w.trc
These files are created in the working directory of each instance (for example /usr/sap/C11/DVEBMGS00/work)
Contents of the developer trace files:
-------------------------------------
The actual trace information (TRACE > 1) follows no defined format.
The lines that contain error information start with
*** ERROR => .....
if no Syslog entry was written for this error
***LOG Q01=> .....
if a Syslog entry was also written for this error
(in this case Q01)
An "ERROR line" contains:
The name of the calling function (reference to context)
A description for the faulty action (normally the name of the
called function)
In UNIX system calls, the UNIX error number and corresponding error text
C module name and line number are at the end of the line
Example:
*** ERROR => MsAttach: connect (61: Connection refused) [msxxtcp. 0234]
***LOG Q0L=> DpLoopInit, MsAttach () [dpxxdisp 0598]
Meaning:
C function DpLoopInit calls C function MsAttach (connection setup to message server). MsAttach calls the Unix syscall Connect, which returns Unix errno 61, because the message server cannot be reached. MsAttach (in C module msxxtcp.c, line 234) writes the ERROR line, DpLoopInit writes (in C module dpxxdisp.c, line 598) the additional SysLog Q0L, which is not given any variable data -> ()
Remarks:
Trace files are overwritten when the instance is restarted. Therefore they must be saved (copied) before restart, if you want to analyze them later on. As of Release 4.6 a backup copy with the extension .old is created on startup.
Trace files can be displayed in the R/3 system using Transaction ST11 or AL11.