Search this blog for other interesting articles

Thursday, 21 June 2012

What are the different developer trace files in SAP?


This article answers following queries:


  • What are the different developer trace files in SAP?
  • In case of issues, what are the trace files do you check ?
  • What is the location of the developer trace files in SAP?
  • What is the typical path for work directory in SAP?
  • What is the naming convention of various developer trace files?
  • What are the different trace files do you check to troubleshoot an issue in SAP?
-----------------------------------------------------------------------------------------

Trace files contain important information which will be helpful to troubleshoot in the event of any problems in an SAP system.

Usually trace files will be stored under Work directory.

Typical menu path for Work directory in Unix will be  /usr/sap/<System ID>/<Instance>/work

Eg: /usr/sap/DP1/P02/work

Path will be similar in other systems based on other operating systems.
In these trace files, the lines that contain error information begin with ***ERROR => .
Lines for which system log (SM21) entries are written start with ***LOG<message id>.

A separate trace file will be written for each component of SAP.

Please find below list of various components and the respective trace file that will be present under the work directory. Based on the component to which the issue is related, respective trace file can be referred to troubleshoot the issue.



































Based on the component with which issue is related, respective trace file need to be investigated.



 For example:

i)  If issue is related to communication problems, files related to message     
   server, gateway, appc-server, RFC etc needs to be referred.
ii)  If issue is related to transports, dev_tp file need to be investigated.
iii) If issue is related to locking, dev_eq<n> file need to be investigated
iv)If issue is related to printing or spool , then corresponding spool trace need to be investigated





Wednesday, 20 June 2012

How to change the developer trace level in SAP?

This article answers the following queries :



  • How to change the developer trace level in SAP?
  • What are trace files and what is their significance in SAP?
  • How to increase or decrease trace level in SAP?
  • What are the different trace levels and their significance in SAP?
  • What is the parameter to set developer trace level in SAP?
  • What is the default developer trace level in SAP?
  • How to activate or deactivate developer traces from the system profile in SAP?
  • What are the advantages or disadvantages in setting high trace levels in SAP?
  • How to limit the trace logging to increase to any arbitrary size?
  • What are the sap parameters used to limit trace logging to any arbitrary size in SAP?

-----------------------------------------------------------------------------------------

Trace files and their significance:

Trace files contain important technical information which will be required by basis consultant to troubleshoot  in event of problems / issues with the SAP system.

Different levels of traces:

There are 4 trace levels in SAP.
Level 0  - No trace
Level 1 – Write error messages in the trace file
Level 2 – Full trace ; The trace entries are being written will vary with the SAP program that is being traced
Level 3 – It is similar to Level 2 but in addition to that it also traces data blocks
SAP profile parameter rdisp/TRACE is used to set the developer trace level in SAP.

Trace level 1 is the “default” trace level set in an SAP system.

Sometimes there may be a requirement to developers or even basis guys to increase trace level from the default value 1 so that much detailed trace can be captured which helps in resolution of an issue.
To change this parameter, goto RZ11 transaction and provide rdisp/TRACE as shown below:













Please click on “Display” button to view the below screen.





























As seen from the above screen, this is a “dynamically switchable” parameter which means that trace level can be changed immediately and it doesn’t need restart of an SAP system for the parameter value to take effect.

If your SAP system contains more application servers, please tick “Same on all servers” checkbox in the above screen so that trace level can be changed dynamically across all the application servers. If you would like to change in a particular application server, it is not required to tick this check box.

In the above screen, default value , profile value and current value are set to 1. In case, it is required to set trace level for temporary period(till restart of the application server), it can be set by modifying current value accordingly. Please note that after restart of the server, the current value will be lost and system will start using the profile parameter that is set for that instance.

To set this parameter value permanently, you need to set this value in RZ10 profile parameter in all the application servers that is required. Once SAP system is restarted, it will read the profile values and come up with the value that is set to this parameter.

Advantages /Disadvantages in setting high trace levels in SAP

While higher trace levels provide much more detailed trace which helps in troubleshooting the issue there are some disadvantages as well.

Trace level 2 or higher influences the system performance and should only be set for error analysis. In addition, trace files grow very rapidly  when trace is activated. We should ensure that enough space is left on the disk on which the SAP directory is located. Using parameter %rdisp/TRACE_LOGGING%, we can ensure the trace files do not grow to an arbitrary size when trace is active.

Trace logging can be activated by setting the parameter rdisp/TRACE_LOGGING to ON. Also specify the size at which once reached, the trace file is logged and the trace level is reset to 1.

Please find below values that can be set to this parameter and their significance
rdisp/TRACE_LOGGING = off :  no tracing
rdisp/TRACE_LOGGING = on, 1000 : trace is logged if the trace file contains more than 1000 bytes
rdisp/TRACE_LOGGING = on, 20k : trace is logged if the trace file contains more than 20KB
rdisp/TRACE_LOGGING = on, 30m , global =on activates trace logging, if the trace file is larger than 30mega bytes. If the pattern searched for has been found in a trace file, trace logging is deactivated on all the servers.

Parameter rdisp/TRACE_PATTERN_0 is used to specify a trace pattern for automatically switching off the SAP trace. This parameter has effect only if trace logging is activated using rdisp/TRACE_LOGGING. In this scenario, trace files are searched for the search pattern. If pattern is found, trace logging is deactivated and trace level is reset to 1.

In this way, setting these parameters avoid trace files to grow to arbitrary size and  limits the trace logging based on the size of file specified.




Tuesday, 19 June 2012

When file system is full – what need to be done?


This article answers the following queries:

  • If file systems in SAP server is full, what need to be done?
  • How to avoid file system full in SAP?
  • How to delete un necessary files in file systems of SAP?
  • How to delete core files in SAP?
  • How to delete trace files in SAP?
  • How to delete stat files manually in SAP?
  • What is the transaction code used to delete stat files manually in SAP?
  • What are various reports to be run to cleanup when file system is full?
  • How to prune the file systems in SAP?
  • How to delete old archive files in SAP?
  • What is the location of work and data directories in SAP?
  • What is the location of global directory in SAP?
  • Can we delete old page file and role files when the SAP system is online?
  • What is the sap parameter to set the trace level in SAP?
-----------------------------------------------------------------------------------------

Sometimes, a basis consultant will get alerts or information from customers that the file systems are full. To avoid system issues and to increase uptime of the SAP system, In those cases, we have 2 options.
i)     Delete un-necessary files in the file system
ii)   In case you found file system is defined as too small then increase the size of them.

  
In this article, am covering the option 1 mentioned above.

Let us assume that the system id(SID) of the sap system is DP1. Then the

i)  Work directory in (Unix, WindowsNT operating system) is  /usr/sap/DP1/DVEBMGSnn/work     (where nn is the instance number)
ii)            data directory in (Unix, WindowsNT) is
/usr/sap/DP1/DVEBMGSnn/data    (where nn is the instance number)
iii)           Global directory (i.e. for all instances)  is
/sapmnt/DP1/global  (for UNIX )
\\<sapglobalhost>\sapmnt\DP1\sys\global  (for WindowsNT)

Please follow below steps to avoid this issue :

1)   Delete core files from work directory

Work directory in Unix often contains old core files which were generated due to previous program terminations. These core files need to be deleted  

2)   Delete old log files and spool files

Under global directory there will be many log files  which can be deleted regularly.

Those files are
Log file type                      Naming Convention

Spool requests            nnnSPOOL ( where nnn=client)
Job logs                      nnnJOBLG
Batch input logs          BI<hostname><instance-number>

Following reports can be run using SE38 or through background job for selective deletion of the files mentioned above.
 RSPO0041  - This report is used for deletion of old spool files
 RSBTCDEL –  Used for deletion of old job logs
RSBDCREO  - Report can be used for deletion of  batch input log files and reorganization.

3)   Deletion of old ABAP/4 trace files

Some trace files with the name AT<instance number>nnnn will be in the data directory. Old files of this type can be deleted. The maximum available space for all files is defined by the parameter abap/atrasizequota. Also transaction SE30 can be used to delete the files.

4)   Deletion of old archiving files

When old data is archived, some files are written to the global directory. The naming convention of those files is Rxxmmddn (xx= application, mm= month, dd=day, n=number). For example, RMM11056

If these files are already saved on tape and these data is no longer required for productive operation, then these files can be deleted from the disk

5)   Deletion of old output requests

Output requests are normally stored on the data directory. Naming convention will be like SP*. Under normal scenarios, they are deleted automatically when the output is completed. In case you see they are not getting deleted, you can delete the same

6)   Page file and Roll file

Under the data directory, normally page files and roll files are stored. Naming convention will be like PAGFILnn and ROLLFLnn. Please note that page file and roll files can only be deleted when the corresponding SAP instance is offline.

Deleting these files hardly makes any sense because these files will start growing  to the allowed maximum extent  during the R/3 system start up. However in some special scenarios (during or after client copy), the required space can be retrieved by deleting these files. As mentioned earlier, please note that this can be done only when the instance is offline.

The maximum size of the roll file is given by
(rdisp/ROLL_MAXFS – rdisp/ROLL_SHM) * 8 Kbytes

A similar formula applies to the paging file also.

In some scenarios, to avoid the file system full issue, we can even move these page and roll files to a different file system by defining alternate values for R/3 parameters DIR_ROLL and DIR_PAGING

7)   Deletion of Old sort and Extract files

By the ABAP commands SORT and EXTRACT, temporary files are created. The location of these files are set using profile parameter DIR_SORT or DIR_EXTRACT. 

The temporary files for sort are named S+++++++<Extension> (On Windows NT .dat is used as extension  and on Unix there is no extension). Similarly for Extract, E+++++++<Extension> will be the file naming convention.

These files will be automatically deleted after the execution of these SORT and EXTRACT commands. However, in some scenarios, an abrupt termination can happen and these files won’t get deleted automatically. Those old files can be deleted by an administrator.

The exact file names for these are stored in the profile parameters FN_SORT or FN_EXTRACT

8)   Deletion of trace files

Trace files are created during a new system startup and they can be deleted. They are contained in the work directory

9)   Deletion of stat file or moving to different location

Please check whether the stat file which consists the work load statistics, has not been reorganized for some time and has therefore become too large. In emergency cases, this file can be either deleted manually or can be moved to different location.

To delete the stat file manually, please proceed as follows:
Goto ST03 transaction , call the delete function on the relevant instance by choosing :
Workload -> Reorganize -> Delete seq.stat.file

To change the location of stat file, change the value of system parameter ‘stat/file’ to a new location.

10) Deletion of job logs at operating system level

In some emergency cases, where you cannot start the R/3 system at all, the measure is to delete the job logs at operating system level and run RSBTCDEL report in forced mode.

Note: How to delete job logs at operating system level will be covered in a separate article later

11) Changing the trace level
If the trace files (dev_*) in the work directory are very large(normal size 0.1 to 20Kbyte), it is likely that the trace level is set to very high value. In SAP, rdisp/TRACE parameter is used to set the trace level. Normal value for trace is 1.  

Please cross check this SAP parameter and reset to 1 if the value is maintained as 2 or higher. If this value is set to high, much more detailed trace will be collected and trace file sizes are likely to increase. Therefore recommending to decrease or set the trace level to 1.


Please refer below link to know, how to set the trace level in SAP.


Iam sure, if you duly follow the steps mentioned above,  file system full issues can be addressed. However, if after carrying out all the above steps there is no improvement, then please consider to increase the file system size by requesting space to the relevant team.






Saturday, 2 June 2012

How to avoid “DEBUGGING IMPOSSIBLE” dump in ST22 of sap?


This article answers the following queries:


  • What is debugger?
  • What is debugging?
  • What is the reason for “DEBUGGING IMPOSSIBLE” dump in ST22?
  • How to avoid “DEBUGGING IMPOSSIBLE” dump in ST22 of sap?
  • What is the parameter used to increase or decrease debugged sessions in SAP?
  • Usually, in which role of sap systems, debugging can be done?
  • How many dialog work processes can be in debugging mode in SAP as per recommendation in development systems?
  • What is the reason for system performance issues, if large numbers of developers are doing debugging in an SAP system simultaneously?
  • Is it suggested to perform debugging in production systems? If not, why?
-----------------------------------------------------------------------------------------

What is debugger?
The debugger is a programming tool that can be used to execute ABAP programs line by line or section by section. With this tool, you can display data objects and check the flow logic of programs.

What is debugging?
Debugging is the process of executing ABAP programs line by line or section by section. This process will be done usually by developers to analyze the flow and issues (like performance problems etc) in the ABAP programs.

What is the reason for “DEBUGGING IMPOSSIBLE” dump in ST22?
In real time scenarios, we may see dump like “DEBUGGING IMPOSSIBLE” in ST22 transaction of SAP as part of monitoring system.  Also, developers might have complained to Basis team that they are not able to debug in SAP system and while they are trying to do debug, they are encountering “DEBUGGING IMPOSSIBLE” dump. The short text of the dump says “ABAP programs cannot be debugged currently”.


































So, it is responsibility of Basis administrator to avoid those dumps and help developers to debug in development systems.
Usually debugging will be done in development systems. It is not suggested to allow debugging in production systems as it impacts system performance because work processes that are in debugging mode cannot be used by other users.
Usually this dump occurs when the maximum number of work processes in debugging mode has already reached.

How to avoid “DEBUGGING IMPOSSIBLE” dump in ST22 of sap?

Please check the process overview (SM50 or SM66 transaction) and find out how many work processes are currently in debug mode.
The number of work processes that are available exclusively for debugging is defined by the profile parameter rdisp/wpdbug_max_no.
Please check this parameter value in a sap system and compare with the number of processes that are currently in debug mode. This dump occurs when the maximum of work processes in debugging mode has already crossed the parameter value set for rdisp/wpdbug_maxno.
So, it is suggested to increase the value of this parameter to avoid these dumps. This is dynamically switchable parameter and can be changed immediately and no need to restart SAP system for the value to take effect.

Note:  Please refer below link to understand how to increase/decrease an sap parameter value.
Details related to this parameter can be checked in Rz11 transaction which will be similar to as shown in below figure.



























However, please note setting this parameter to a very high value leads to performance issues in SAP system, as “work process multiplexing” won’t happen if debugging is being done. That is work processes that are in debugging mode cannot be used by other users.  This reduces the amount of free dialog work processes, which affects system performance.
In development systems, this parameter should be approximately half the number of dialog work processes.

Hint :
Usually, as debugging is not suggested in Production systems, the parameter value rdisp/wpdbug_max_no is set to low value. Most of the times, when a development system is refreshed with production system, the number of debug sessions will be low in the corresponding development system as those values are copied from profile parameter of a production system. So, it is responsibility of basis administrator after system refresh to cross check this parameter value and set correct value as per the recommendations in the development system to avoid these dumps.






Search this blog for other interesting articles

Please subscribe & activate link received to your email id to receive latest articles

Enter your email address:

Delivered by FeedBurner