When managing a SAP R/3 Enterprise system from a technical point of view, there are quite a few areas that need to be controlled and monitored on a regular basis in order to procure a healthy environment. Availability of resources, stability and performance of the available resources are aspects to look at. In the following topics, we will touch base on troubleshooting techniques in general system administration of SAP systems.
Troubleshooting the Update Process
The update work processes are in charge of recording changes in transactional data and send requests to the database of such changes, as users work normally in the system. The update work processes perform their functions when the ABAP applications are programmed with a statement IN UPDATE TASK. This type of updating is performed asynchronously in the system, meaning that the programs leave update records in a queue to be processed and then continue the execution. Even though the updating processes run without management intervention; nonetheless, SAP includes utilities to monitor, check, and perform management operations on the updating process, which can be very useful in case that problems arise.
To access the Update Monitor, follow the menu path Tools | Administration | Monitor | Update. Alternatively, enter transaction code SM13 in the command field. The system displays the initial Update Monitor screen, where you can select to display data according to your selection criteria. It is normal practice to check this monitor on a daily basis, though you can select a time period that includes data and time to filter.
Initial selection screen in the Update Monitor
You can select to display the type of update records of your choice, by client and user, although you can enter a wildcard (*) to select all clients and all users as well. When you click on Execute, you will display a list with the records you selected and their status, as well as the user and transaction executed. From there, it is possible to retrieve user information and repeat updates, unless there is an error and the system will display so. In such case, the user needs to post the transaction from the beginning to avoid inconsistencies.
The Update Process Administration
You may access the Update Process Administration utility by executing transaction SM14 or from the Update Monitor clicking on Administration. This tool allows you to manage more complicated features in the Update process.You can display all canceled update records, all update requests, reorganize incomplete update requests and deactivate the update process. Only when troubleshooting the update process and it rare cases you will need to deactivate the update process (if there is a stuck situation, for example).
However, it is best practice to reorganize incomplete update records, because they take space in the database (you will see table VBDATA growing). There is another way to perform this reorganization automatically, which consists on setting the parameter rdisp/vbreorg to 1, which mandates the update server to reorganize incomplete update records when the instance is restarted. This also helps you to avoid inconsistencies, because you would not be reorganizing update requests during online hours.
The tabs Update Server and Server Groups in this tool help you to define update servers and server groups for load balancing. In addition, the Parameter tab allows you to define certain parameter settings dynamically and to display all parameter settings related to the update process to function properly. Finally, click on Statistics to obtain very specific statistics on response time broken down by actions in the database by the update process, such as Delete, Insert, and Commit. Be sure to understand clearly how the updating process can affect the system before performing any management options on update records. More information on update process management can also be found in the Online Help.
Troubleshooting Lock Entries
Lock entries are system objects in charge of protecting the integrity of the data by synchronizing the access, so users cannot modify the same data at the same time. The lock objects are defined in the ABAP dictionary as a mechanism to lock data and can consist on a table, a row, or even a whole transaction, so users cannot change the same data at the same time. To display and perform some basic operations on lock entries, from the main menu, select Tools | Administration | Monitor | Lock Entries or execute transaction code SM12.
You can select lock entries specifying client, user or objects that have been locked (lock entry arguments). By entering the wildcard (*) in the client and user, the system displays all current lock entries with the users holding locks and what table is affected by the lock. Frequent monitoring of lock entries should be a common practice by either SAP R/3 administrators or operators, since unrelcased locks can block other users from working in the same transactions for updating information.
Normally, Jocks are automatically released when transactions are committed or when users are finished working on the data. Special attention must be given to locks, which are held unreleased for several hours. Although this is not always a cause of alert, because in special circumstances, such as long-running background jobs which update the database, it can be a completely normal operation. The lock monitoring functions offer the utility to manually delete unreleased locks. To manually delete a lock entry from the lock entry list, click on the line holding the lock you want to release and press delete from the application toolbar or select Lock Entry | Delete from the menu.
However, you should not delete locks directly before analyzing the reason for the lock.
As much as possible try to avoid manually deleting lock entries, and do it only when you are sure that it will not affect an update process, a background job, or an active user. Otherwise, it might lead to data inconsistencies.
Some of the most frequent reasons for unreleased locks are as follows:
Only update modules with status INIT or AUTO (unprocessed updates) can holdlocks. Normally, the lock entry list will highlight those entries that are held by update processes. If you press the Refresh button often on the lock entry list, you can sometimes see highlighted entries, which are released very quickly.
The System Log
SAP systems includes extensive log facilities to display and possibly correct the problems and errors occurred during system operation in the so-called system log. Each application server registers a local system log. In a distributed environment, you can configure a central system log that collects the log records of all servers, but this is not available in all operating systems. Physically, the individual application server log files (local system logs) are stored under the specific instance directory /usr/sap/<SID>/<INSTANCE_NAME>/log, with the name SLOG<INSTANCE_NUMBER>.
The log messages are written in a single circular file. When the file reaches the maximum allowable size, a log switch takes place and the system starts overwriting the file from the beginning. The maximum allowed size of a log file is specified in the system profile parameter rslg/max_diskspace/local. However, when the central system log is configured, it uses two files: an active file and an old file. The active file contains the current log. When the active file reaches the maximum length specified in the system profile parameter rslg/max_diskspace/central, the system performs a log switch.
The system deletes the old log file, copies the active file as the old log file and creates a new active log file. This process is performed transparently to the administrator and does not offer any notification when it replaces the old log. The central system log is located under the SAP-shared global directory /usr/sap/<SID>/SYS/global with the default name SLOGJ.To access the System Log from the main menu, select Tools | Administration | Monitor | System Log or execute transaction SM21.
The selection criteria to filter the display of the system log messages includes date and time, user ID, transaction code, type of work process and type of problems logged. It is important to remember that the system log records events, problems and warnings that are relevant to the kernel (work processes and such), therefore, not certain problems, such as database or operating system problems will be recorded (but if these affect the kernel, they may be recorded).
By entering DP in the SAP Process field, you will filter messages logged by the dispatcher processes. If you enter D<n> or B<n> or S<n> or V<n>, where n is the work process number, you will filler by dialog, background, spool or update work process number as displayed by the Work Process Overview screen; For example, D1, D2, and so forth. Choose MS to select messages from the message server. By selecting from the menu System Log | Choose | Central Log, you can display the central log. Other options in the same menu allow you to select the remote and local system logs. The field Instance Name appears only when you select to display the central system log where it is located.
You may also choose a maximum number of pages you want to see in the log report. No. Pages for Individual Entries and select the check box With Statistics to show statistical information of the log analysis, such as message frequency by client, user, and transaction. In order to dump the output somewhere, you can select Settings next to the Output To pushbutton. The default is the screen output and you can select other outputs, such as a printer with a certain number of pages to print. Other settings allow you to change the layout of the output (selecting additional columns in the log, for example).
Main selection screen in the system log
Interpreting the System Log
The system log records all alerts sent to the kernel. Therefore, warnings and information and not only errors are also recorded. It is important to check the system log on a regular basis and to interpret the messages accurately. The column named "MNo" in the log report shows the log message codes, which are associated with a type of log event. Most of these codes have associated documentation explaining the cause of the log and, in case of errors, the possible cause of the error. To see this information, first double-click on a log entry to display the detail screen. In this screen, you can see the documentation for message codes. You can also display the short text documentation for the message code, by selecting See System Log Doc from the application toolbar. There is not always log documentation available.
You can also instruct the system to ignore certain codes by selecting Edit | Ignore Message from the menu. When you perform this function, the next time you request the log report, the system will not display messages with the ignored code. Events when a work process switches from one type to another when switching operation modes are recorded as warnings and are purely informational, unless something went wrong, which would be recorded, if so.
The best documentation for system log messages is contained in SAP Notes and a simple search with the error code and a short text will very likely retrieve a solution that suits the symptoms recorded in the system log.Pay special attention to system log messages related to operating system failures, database errors or inconsistencies, as well as printing problems that may affect users seriously.
Displaying and Troubleshooting ABAP Short Dumps
When serious program errors occur, the ABAP processor terminates the current program and the development workbench generates a so-called short dump that is presented to a user executing a program, as the program aborts without finishing successfully. An ABAP dump is a list that includes extensive information about the possible causes of the error and the guidelines to solve it. It is best practice to check your system for dumps on a regular basis, even if online users are not experiencing program terminations, since they may be due to background activity and RFC calls as well. System administrators, development personnel, or SAP specialists may access the Dump Analysis transaction ST22 or follow the menu path Tools | Administration | Monitor | Dump Analysis.
ABAP Dump Analysis in a SAP R/3 system
When displaying ABAP dumps, you can select the current day's dumps, or the previous day's dumps or even select a period of time. Other criteria to filter allow you to select a particular application server, a user and a dump identifier. In addition, new features allow you to filter by program name and dump exception. In addition, if you do not wish to use this type of screen or output and you are used to the look and feel of the dump analysis in previous releases, you may check the box Use Old Dump Analysis to analyze dumps in the old monitor.
When analyzing an ABAP dump, check the information provided in the dump, and you can also display the code that was being executed when the error was raised. Some of the information to be found is as follows:
Old dumps occupy space in the database. It is best practice to delete these entries on a regular basis by scheduling a clean up job or manually by choosing Goto | Reorganize from the main dump analysis screen and selecting how old the dumps to be deleted must be. However, you may keep dumps for further analysis. In the main selection screen you can choose to keep dumps by entering an X in the analysis list display, you can select whether there are any particular short dumps you want to keep for further analysis. Or, in the list of dumps that you selected, select the short dump to keep and click on the Keep/Release padlock-like icon or, from the menu, select Short Dump | Keep/Release.
Pay special attention to those dumps that are related to errors in the database (such as DBIF_RSQL_SQL_ERROR). Search for SAP Notes that explain the symptoms, because they will very likely contain a fix and an explanation for such dump. In addition, watch dumps related to memory management, such as SYSTEM_NO_ROLL, SYSTEM _NO _MORE _PAGING, TSV _TNEW _PAGE_ALLOC, and others. These may be due to a couple of things, either wrong parameter settings in memory management, or insufficient resources, or that the programs that dumped were too resource demanding and in regular operation they need more memory than other programs and they might need to be checked by developers for tuning potential. Sometimes, the user input in selection screens is also important and without filtering properly, they may launch a program than needs a large amount of resources and the program dumps due to insufficient resources at that time.
The System Tracing Utilities
Besides the system log and the ABAP short dumps, the R/3 system includes many facilities to debug, follow, and keep track—in other words, trace—its internal operations. The information provided by the different tracing functions is highly technical and it is primarily used for solving problems in the system or trying to optimize the performance and/or the coding of the ABAP programs. The basic tracing utilities available are
This section covers the basic handling and configuration of the system traces and developer traces. Both the SQL traces and ABAP program traces are mainly used by developers and are explained in previous sections.
Using the System Trace
The system trace functions can be set up to include a very extensive group of technical information which can later be used by expert administrators, developers, or SAP specialists to solve or tune specific system problems. This section covers how to configure and set up system traces, which is not an obvious matter by navigating through the menus. Each process in a SAP instance has its own trace buffer, where it writes the tracing information before being transferred to disk, if this option is selected. Call the System trace function by selecting Tools | Administration | Monitor | Traces | System Trace from the main menu. Alternatively, enter transaction code ST01 in the command field.
Starting the system trace and options for tracing
Select the trace records that you want to keep track of, such as authorization checks, kernel functions, database access, table buffer trace, RFC calls, and lock operations by checking the check box next to each option. Additionally, by clicking on General Filters, you may restrict the trace to a process only by entering the work process number, for a user, transaction or program. Otherwise, without specifying this data, when you activate the system trace, you will trace everything that happens in the system.
Therefore, it is important to understand that this tool is only to be used when errors occur and it is mainly used by kernel specialists. The name of the trace file in a system is defined in the profile parameter rstr/ filename.
The default value of this profile parameter is / usr/ sap/ <SID>/ <instance name>/ log/T RACE00. Its size can be configured with the parameter rstr/ max _filesize _MB. When a file is full, it is renamed with a different ending, a number from 00 to 99 and the maximum number of files is defined by rstr/max_files.
Using Developer Traces
The system developer traces are log files that contain technical information about the SAP work processes and other programs. They are normally used by specialized personnel, especially by SAP support, when looking for problems in the SAP kernel or the runtime programs. These traces can be useful also for administrators, since some of the files sometimes contain the explicit reason and explanation for system errors. To display the list of developer traces, from the monitoring menu, select Tools | Administration | Monitor | Traces | Developer Trace from the main menu or execute transaction code ST11.
The system will display a list with the title Error Log Files. These files are actually operating system files located under the Work and Profile directories. To display the contents of any file, just double-click on them, or select Log File | Display from the menu.
The developer traces
When you display any of the files, look for lines beginning with the string *** ERROR => message, because they contain error information. The error lines can be useful for displaying what functions and what operations caused the error message. If any of the entries are also writing system log entries, then the line begins with ***LOG <message ID>.
The names of all the developer trace files start with the character string dev_followed by an identifier, such as the work process number, or rfc in case of an RFC call, icm for Internet Communication Manager, ms for the Message Server, and so on. You can set the trace level by setting the parameter rdisp/TRACE=<n> in the instance profile file to any of these values:
Troubleshooting the Background Processing System
There are several options in the SAP system for monitoring and troubleshooting the background processing system. These options include utilities that can be used from the general administration monitoring utilities to extensive CCMS analysis tools. Where to look and what functions to use depends very much on the type of errors, which can range from configuration problems to authorizations or runtime problems. In general, the order to look for background job problems can be
To display a job log and analyse its status, you must access the job overview list from a previous job selection screen. This screen may be accessed from many different places in the SAP system. For example, directly by entering the SM37 transaction code in the command field or by selecting Tools | CCMS | Jobs | Maintenance from the main menu. Enter the criteria for restricting the jobs to analyze and then display the job or list of jobs.The first operation on a selected job will be to sec its status and check it for possible errors by using the Job | Check Status function. If the job status is OK, the system displays a message in the status bar.
If you suspect an active job is running for a longer time than normal, you can debug it for analysis by selecting it while running and then choosing Job | Capture Active Job. The system will display a debugging window where you can analyze the code of the ABAP program running in background. The running program stops and you can debug it. Re extremely careful doing this and try to avoid as much as possible to debug in a production environment. Tests of this caliber should only be done in copies of production or test systems, where the code of the program is the same and the data that it works with is similar to that in production. Prom the debugging window, you can continue to execute the job at the point it was stopped.
Analyzing the Background Work Processes
Another step in the analysis of problems with the background processing system is to display the general process overview monitor. From the main menu, select Tools | Administration | Monitor | System Monitoring | Process Overview or just execute SM50 in the instance where the job is running or SM66 to see a global view. The two types of work processes to look for are the background work processes and the dialog work processes. The Type column shows the type of work processes: BGD for background (batch) and DIA for dialog. And the Status column displays whether these processes are running, waiting, and so on.
The first column of the process overview ("No.") shows the number of the work process. This number can be very useful if you later want to analyze the system log and want to restrict the search to problems with that particular work process. The process monitor shows other interesting information such as the program it is executing at the moment, the user under which the job is running, and so forth. Selecting one of those processes, you can get further detailed information by choosing Process | Details from the menu. You can also display the developer trace file by selecting Process Trace | Display File. This will allow you to search for errors in the kernel, what happened while this background work process was executing the job, and so on.
With the system log, you can also analyze system errors, messages, or warnings regarding the background processing system. You can restrict your search just to the background work processes by entering the number in the SAP process input field.
The Job Analysis Tools
There is a set of utilities that can be used to analyze and monitor the background processing system. The utility Check Environment is used for analyzing the configuration and the status of thebackgroundenvimnment. To reach this function, select Tools | CCMS | Jobs | Check Environment or execute transaction SM65. An example of the initial screen for performing simple tests on the background system.
Checking the environment in background processing
These utilities check all the necessary conditions that must be met for the background processing system to work correctly. This analysis utility is helpful in determining if all the elements of the background system are configured and if there is any missing parameter. The analysis tools include two types of tests:
Additional expert tests in background processing
Job information is stored internally using several R/3 tables. With these additional tests, the system can find if there are any consistency problems in those tables, such as a missing index, duplicate entries, existence of all job data, and so forth. The results of the tests can either be displayed as a list or written to the file BTCSPY in the working directory of the application server to which you are logged on. The utility Background Objects allows you to display and maintain the elements or control objects that make up the runtime environment for processing jobs. To reach this function, select Tools | CCMS | Jobs | Background Objects or execute transaction SM61. These objects are as follows:
Every background control object can be maintained separately. The maintenance consists of either defining and activating any of the objects or activating the trace information for them. On the initial screen for background objects, select Maintain Objects. The left column shows an entry for each host and the right column an entry for the object. From this screen, you can create an object by clicking on the Create icon, or you can modify the control information of the object. To modify an object, select the object and click on the Change icon. The system will display a dialog box where you can activate or deactivate the object itself or activate and deactivate tracing for analysis.
Finally, with the Activity Log button, you can display when the job was last run and when the trace was last activated.
Analyzing Job Performance
Select Tools | CCMS | Jobs | Performance Analysis or execute transaction SM39 (this transaction has been replaced by SM37 with SAP Enterprise) to reach the Performance analysis tools. Here system administrators can analyze the runtime of jobs that are active, finished, or canceled. To look for additional information about a particular job, just double-click on it. It is important for everyone involved in the maintenance and care of a SAP system, as well as for everyone involved in an implementation, that jobs are analyzed for performance.
It is best practice for developers that create background jobs to execute ABAP programs to fulfill a business requirement to look at the Duration column while testing the execution of such jobs, not only the Status column. Especially when tables grow and the system ages, or when additional workload hits the system, the designed jobs are likely to have a longer runtime than before. Think of jobs like Payroll or financial reporting transactions and programs.
Developers can use the trace utilities SQL Trace and ABAP Trace. However, tracing a background job can be more complicate and tedious than an online transaction, due to its forecasted longer duration. To trace a background job with the SQL trace utility (transaction ST05), try to start and stop the trace recording "chunks" of the job, save them to a local file and analyze them individually later on. This way, you can try to avoid the trace filling up and overwriting the records that were previously recorded.
To perform an ABAP trace in a background job that is currently running in the system, execute transaction SE30 and choose Enable/Disable under In Parallel Session. This will take you to a list of work processes similar to the one of the Work Process Overview monitor. In this screen, choose Start Measurement by clicking on the matchlike icon or choose Edit| Measurement | Switch On from the menu.
Under the On column you will be able to see a symbol, first as a yellow triangle that changes to a green circle to indicate that the trace is on and the background work process is active executing a job. You can refresh the display from this screen continuously and monitor the job from the job overview monitor in SM37. This will not affect the trace. After the job is finished, simply deactivate the trace by selecting Edit | Measurement | Switch Off from the menu or by clicking in the extinguished matchlike icon.
Afterward, go back once with the green arrow to the main SE30 screen and choose Analyze to check the file that was created. As explained in the section on workload analysis, you can proceed to analyze where most of the time was spent while this job was running, the SAP system or the database. Therefore, you can proceed to analyze further the most expensive programs and the database for possible tuning actions.
Common Background Job Problems
The following list summarizes some of the typical problems that can be found in the background processing system and the check actions to perform to solve the problem. As a common practice for all of the typical problems, display the job log, the system log, and finally use the job analysis tool.
SAP BASIS Related Interview Questions
|SAP CRM Interview Questions||SAP HR Interview Questions|
|SAP ABAP Interview Questions||SAP HANA Interview Questions|
|SAP Crystal Reports Interview Questions||SAP SOLMAN Interview Questions|
|SAP Security Interview Questions||SAP BPC Interview Questions|
|SAP Netweaver Interview Questions||SAP UI5 Interview Questions|
|SAP Smart Forms Interview Questions|
Sap Basis Tutorial
Sap: From Sap R/3 To Sap Netweaver
The Architecture Of The Sap Web Application Server
Sap Netweaver: An Overview
Using Sap Systems
Upgrading To Sap R/3 Enterprise: The First Step Into Sap Netweaver
The Change And Transport System
Development Options With Sap Solutions: Abap Engine
User Management And Security In Sap Environments
Web Application Server System Management
Performance And Troubleshooting With Sap Solutions
Sap For It Managers: Implementation, Planning, Operation, And Support Of Sap Systems
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.