Frequently Asked Questions: Lock Concept - High availability & Performance

Question

What happens to locks when the enqueue server is restarted?                                                             

Answer

If they have not been saved to disk in the backup file, they will be lost. The locks that are inherited by the update task when COMMIT WORK is executed after CALL FUNCTION .. IN UPDATE TASK are saved to disk. The locks are saved to disk when the update request becomes valid, that is, with the COMMIT WORK. Each time the enqueue server is restarted, the lock entries saved on the disk are reloaded to the lock table.

A lock is saved to disk at the point at which the backup flag is set.     

 

If the enqueue replication service is used as part of a high availability solution, locks will not be lost if the enqueue server fails or is restarted. See next question.

Question

The enqueue server is a single-point-of-failure in the SAP System. Can I guarantee high availability for the Enqueue Server?                   

Answer

To guarantee this you must use the standalone Enqueue Server with the Replication Server.

SAP note 524816 contains the prerequisites that must be fulfilled for using the standalone Enqueue Servers with the Replication Server.

Question

How fast are lock operations?                                

Answer

In work processes on the enqueue server, a few 100 microseconds. In work processes of external application servers you have to include network communications and process changes. Depending on CPU and network load this amounts to a few milliseconds.       

                                    

Question

With a single-process system as an enqueue server, we have reached X  SD Benchmark users. Can this number be increased by using a multiprocessor system (message server on the same machine as the enqueue server)? Can we assume that scaling is linear (number of CPUs * X SD users)? How many processes are advisable if message servers, dispatchers, one dialog, and two enqueue processes are to run on the system?                  

Answer

A significant increase in the enqueue server throughput can be expected by using several processors. The CPU load on the enqueue server is distributed relatively evenly between message servers, dispatchers, and enqueue work processes, which means that up to 3 processors can be occupied simultaneously. The dispatchers and the message server represent the bottleneck with the enqueue.

Linear scaling can be expected for up to three processors, even if lock requests are so frequent that message server, dispatchers, and work processes are occupied simultaneously. Due to asynchronous system processes (for example, syncer), using more processors can further enhance throughput.                                                  

 

Frequently Asked Questions: Lock Concept - Problem Analysis

Question

What should I do first if a problem arises?                          

Answer

Use the diagnosis functions:

sm12  Extras ® Diagnosis and then

sm12 Extras ® Diagnosis in update

If a problem is reported, back up the trace files dev_w*, dev_disp, dev_eq* and check the Syslog.    

       

Question

The following message is displayed in the diagnosis details in SM12:

Lock management operation mode                                  

Internal lock management in same process                         

What does this message mean and what are the other options?         

 Answer

"Internal lock management in same work process" in the diagnosis function means that you are logged onto the enqueue server and your work process can access the lock table straight away. You do not have to delegate enqueue requests to an enqueue process on a remote enqueue server. If you are logged onto an application server that is not an enqueue server, the diagnosis function will provide you with the name of the enqueue server.     

Each SAP System has exactly one application server that functions as an enqueue server. This enqueue server maintains the lock table, which is located in a shared memory segment. All of the work processes on the enqueue server can access the lock table. All work processes on other application servers delegate their enqueue requests to a special enqueue work process on the enqueue server.

                                            

This procedure is configured automatically. The parameter line "rdisp/enqname =<application server name>" in the default profile DEFAULT.PFL indicates which application server is currently acting as the enqueue server. When an application server detects that its name matches the name of the enqueue server, it creates the lock table and all of its work processes process enqueue requests inline. If an application server detects that its name does not match the name of the enqueue server, it sends all enqueue requests to the enqueue server.

Work processes of the type "enqueue" guarantee that incoming requests are processed immediately. One enqueue process is usually sufficient. In very large SAP Systems with many application servers, a second process can be beneficial. However, it is not expedient to define more than two enqueue processes. If the transaction SM50 -> [CPU] shows that only the first enqueue process is being used, the bottleneck is due to something else. 

Question

The Syslog often contains messages such as "Enqueue: total wait time during locking: 2500 seconds". How should I analyze this problem? Or is the entry not critical? (There are no records of terminations or timeouts.)                                                  

Answer

The message is output for information purposes only but may indicate parallel processing errors with ABAP programs. The specified wait time is the time that has elapsed since startup due to the use of the WAIT parameter when the enqueue function module was called.                                                 

The WAIT parameter enables a lock attempt to be repeated a number of times, for example, so that the update task does not have to be cancelled when a lock is set temporarily by other programs. The work process remains busy between the lock attempts.  

Frequently Asked Questions: Lock Concept - Programming

Question

What does the _SCOPE parameter mean? How does the lock owner concept work?            

Answer

Click on Lock Owners and _SCOPE-Parameter.

Question

How can I find out who is currently holding the ungranted lock? In other words, how can check the program after an ENQUEUE to determine which use is currently holding the lock so that I can let him or her know?                                  

Answer

When the ENQUEUE_... function module is returned, the name of the lock owner is listed in SY-MSGV1.

 

Question

Can I use special characters in my lock argument (especially the 'at' sign (@))?

 Answer

The 'at' symbol is used as a wildcard in SAP locks (enqueues). In other words, it can stand for any other character during collision checks. For example, the parameter value 12345@ locks the quantities 123450 to 123459, 12345a to 12345z, and 12345A to 12345Z, and all other values with any special character in the 6^th character position.               

In order to prevent the wildcard mechanism from being activated in SAP locks when it is not required, you need to ensure when enqueue function modules are called that key value parameters do not contain any wildcard characters.                                     

If key values that you want to use to lock individual entities do contain wildcard characters, you have to replace the wildcards with different characters before the enqueue is called.          

 

Frequently Asked Questions: Lock Concept - Architecture

Question

Where is the lock table stored?                                        

Answer

In the main memory, shared memory, of the Enqueue Server. All work processes in the enqueue server have access to it. External application servers execute their lock operations in the enqueue process on the enqueue server. Communication in this case takes place via the relevant dispatchers and the message server. 

Question

Can locks exist directly after startup?              

Answer

Yes, the saved locks, which were inherited by the update task, are reloaded to the lock table during startup (see first question).       

      

Question

Why is an enqueue work process required in a central system? Don't all work processes have the same access to the shared memory and thus to the lock table?     

Answer

Although the enqueue process is not used in a central system, it does not do any harm. Since almost all customers install an application server sooner or later, problems will inevitably arise if the enqueue process is missing. For this reason, the enqueue diagnosis function will output an error if an enqueue process has not been configured.                    

       

Question

Are the locks in the lock table also set at the database level? If not, database functions could be used to process objects locked in the SAP system.                                        

Answer

Locks are not set on the database. The lock table is stored in the main memory of the enqueue server. 

                          

Question

Is a lock table built if an enqueue work process is not started on the enqueue server in the instance profile?           

Answer

Yes, because the work processes on the enqueue server use the lock table directly, and not via the enqueue process. The latter is only responsible for lock requests from external application servers.  

Categories of ABAP Runtime Errors

An ABAP program can be terminated during its runtime for a number of different reasons. The database table SNAPTID lists all potential runtime errors (in total, around 1900).

To allow clearer processing, the runtime errors are divided into categories. The category of the runtime error returns hints on cause of the error and troubleshooting.

Internal Kernel Error	Error in ABAP Kernel.  RECOMMENDATION Sending an error message to SAP.
Errors in the ABAP runtime Errors in the screen runtime Errors in the database interface	The system was able to roughly determine the area in which the error occurred. Next, clarify whether it was triggered by an internal error or by a programming error.
ABAP programming errors	Errors in the ABAP program, such as a division by zero or a catchable exception that was not caught.  RECOMMENDATION If you are dealing with a non-modified SAP application, send an error message to SAP.
Installation errors	These include, for example, inconsistencies between the kernel and the database.  EXAMPLE A typical installation error is the error START_CALL_SICK.
Resource bottleneck	EXAMPLE Example: SYSTEM_NO_ROLL: The application does not have enough memory available.
External errors	The error was caused by a call outside the system.  EXAMPLE The code page of the operating system does not match the SAP system language An incorrect logon attempt occurred when calling outside the SAP system (for example, RFC SDK).
End user errors	Incorrect printer settings at end user.
No error	The program was not terminated due to an error, but rather due to deliberately performed actions.  EXAMPLE If an administrator cancels a running transaction, the runtime error SYSTEM_CANCELED is thrown.
ST runtime errors	The error occurred during a Simple Transformation (ST). The cause is a programming error in the ST program.
Internal ST errors	The error occurred during a Simple Transformation (ST). There is an internal error in the ST VM.
XSLT runtime errors	The error occurred during the execution of an XSLT transformation.
ITS errors	The error occurred in ITS. This is usually an HTMLB error.

Managing ABAP Short Dumps

A short dump is saved in the database table SNAP in the error log for every runtime error that occurs in an ABAP system. Unless they are intended for retention and marked accordingly, these long texts are automatically released for deletion one week after they are generated.

The deletion of old short dumps takes place successively: If a program that is running in a window of the SAP GUI terminates with a runtime error and the short dump is displayed directly then older short dumps are searched and deleted (maximum 100 for performance reasons). The number of short texts not intended for retention in an ABAP system is therefore regularly regulated.

Manually Reorganizing Short Dumps

This mechanism does not apply, however, if a runtime error occurs during background processing, an RFC call (including JCo), or an HTTP call. It is therefore also possible, to selectively manually delete short texts from the database. To do this, on the initial screen of the transaction ABAP Dump Analysis (ST22), choose the Goto menu and the Reorganize option.

A selection screen appears, on which you can define the age as of which the short texts are to be deleted.

Reorganization as Automatically-Scheduled Operation (by the System Administrator)

If you need to regularly perform reorganization operations in a system and want to automate this step, you can schedule the program RSSNAPDL. This program provides the same function as the menu option Reorganize.

You can view the current size of table SNAP at any time by choosing the SNAP Statistics option from the Goto menu.

Stopping Short Dumps from Being Automatically Deleted

You can stop a short dump from being deleted automatically. Start the ABAP Dump Analysis (St22) for this and select the related runtime error. Choose  Runtime Error  Save/Release  from the menu. The short dump is then stored in the database until you revoke the lock using the same function.

ABAP Dump Analysis (ST22)

You can use the tools of the ABAP dump analysis (ST22) to list the ABAP runtime errors that have occurred in an ABAP system as well as the relevant short dumps.

• Displays and analyzes update statistics again

• Save in a local file

• Print

• Store for a longer period of time

  
  

Listing and Selecting Runtime Errors

To list the runtime errors that have occurred:

• Log on to the affected ABAP system.

• Start the ABAP Dump Analysis using transaction code ST22.

• On the initial screen, you can define the Selection Criteria that is searched for the whole list of stored runtime errors.

• A list appears of all of the runtime errors relevant to the selection criteria. You can sort the list according to various criteria.

  
  

  It is very easy to call the most current runtime errors: if you choose the Today button in the Standard selection group box, the system displays a list of runtime errors for the current day in reverse chronological order – that is, the newest files first.

Displaying Long Texts of Runtime Errors

You can open the long text of a runtime error for Detailed Review with a double click.

Alternatively you select the runtime error in the list and choose

 Runtime Error  Display Long Text 

or  (Display Long Text F2)

Unedited Display

In case of this, you can display the unformatted related short dump. Follow the procedure below:

Select the runtime error in the list. Choose

 Runtime Error  Unformatted Display 

or  (Unformatted Display F9)

Stopping Short Dumps from Being Automatically Deleted

Select the runtime error in the list. Choose

 Runtime Error  Save/Release Ctrl + F1 

or  (Save/Release Ctrl + F1)

Emergency Solutions for Displaying Short Dumps

The ABAP Dump Analysis uses SAP technologies as in ALV. It brings a higher level of usability but also a higher level of dependency.

Should transaction ST22 (ABAP Dump Analysis) not start correctly or if short dumps are not displayed correctly then there are two emergency solutions that you can implement. You can then continue to analyze problems with the help of short dumps.

First Emergency Solution: On the ST22 start screen, select the Use Old Dump Analyses option before you list the short dumps. ST22 then switches to the old list technology for displaying dumps.

Second Emergency Solution: If you cannot start transaction ST22, you can display short dumps in a simplified list form using report RSNAPREAD.

To use RSNAPREAD, proceed as follows:

1. Start transaction SA38or SE38.

2. Run the report RSNAPREAD. Enter a date for selecting short dumps

   RSNAPREAD gives a list of the short dumps that were created for the specified date.

3. Open the short dump you want to view.

   For technical reasons, RSNAPREAD is simply able to display the technical paragraphs from the short dump. You can, for example, view contents such as Contents of System Fields or Selected Variables in the list display.

   However, all headers are missing and all contents generated by ST22 with its section from the source text, such as the introductory texts about the error or the Termination Information paragraph.

Setting timezone in SAP EP

System Trace: Relevant Profile Parameters

With system profile parameters, you can set the maximum size of the SQL and system trace files and specify its path name. All trace parameter names begin with the string rstr/. For default values and parameter documentation, see transaction RZ11.

The trace parameters that you can set are as follows:

Profile Parameters	Meaning
rstr/buffer_size_kB	The SAP trace (such as SQL trace) writes the trace data to the trace files. For performance reasons, this is done via an internal buffer and not directly. The profile parameterrstr/buffer_size_kB determines the size of this buffer in kilobytes.
rstr/filename rstr/max_files rstr/max_filesize_MB	Since Release 6.10, the SAP trace stores the data in several files. These files are written to sequentially. The parameter rstr/filenamesets the basic name of these files. There is always one file with the basic name. When this file is full (parameterrstr/max_filesize_MB), the file is re-named and a new file is created with the basic name. When the file is re-named, a number from 00 to 99 is added to the filename. The parameter rstr/max_files determines how many files there are in total. If this number is exceeded. the files are overwritten.

The System maintains additional trace parameters which you should not change.

You can obtain further information on the parameters using transaction RZ11.

Protecting Trace Information from Being Overwritten

If you want to protect a trace from being overwritten later, choose the Save button on the initial screen, or choose Go To -> Save from the menu.

On the next screen, you can create a short text for a trace, and choose whether the new file that is created specifically for this trace should be automatically created, or whether you want to specify a file. If you do not specify an absolute path, a file of this name is created in the log directory. In the case of automatic file creation, the system determines the filename and stores the file in the log directory. The advantage of this is that, unlike a manually created file, the F4 help can be used for to search for the file from the analysis screen.

If you choose automatic creation, you can delete the file again in this transaction (use the  button in the analysis screen). This is not possible if you specify a filename. If you want to delete this kind of file, you have to do so at the operating system level.

(Enter transaction code ST01. Alternatively, choose Administration -> System administration -> Monitor -> Traces -> SAP System Trace.)

Interpreting the Analysis in System Trace

Information in trace entries includes the following:

• Time (to the millisecond). Double-click to see the time to the microsecond.
• Type of the trace entry, that is, the component selected when the trace was activated or when the analysis settings were made.

Component	Key	Object
Authorization check	AUTH	Authorization object used
Kernel functions	CMOD	Corresponding C function in kernel
General kernel	USER	C module in the kernel in which the trace is written
Database accesses (SQL trace)	SQL	Database table being accessed
Table buffer trace	BUFF	Database table being accessed
RFC calls	RFC	Called function module
Lock operations	ENQUE	Lock object used

• Duration of the trace, provided this is useful. In the case of an authorization trace, a USER trace (free text that can be written by a kernel module), and the beginning of a C function in CMOD trace, a duration is not useful and therefore not required.
• Object: the object is different, depending on the trace component, and can be obtained from the table above.
• Trace message text

Double-click on a line to get additional detailed information on this trace record.

Options for Trace Analysis in System Trace

If you choose Analysis, a screen opens on which you can make various analysis settings.

Besides determining the trace components, you can restrict the analysis to particular users, work processes, transactions, and times.

For performance analysis, you can use the field Duration to analyze only records for which the duration of a trace record exceeds a specific period of time. This also applies to trace components that have a duration. This setting does not apply to the authorization trace.

You can also set a restriction that only specific tables are included in the trace analysis (this also applies to the SQL and the table buffer trace). You can enter two table names directly on the screen; you can add other tables using the button of the same name. The button changes color if there are more than two tables in the list.

In the lower part of the screen, you can specify a separate file, in order to protect a trace from being automatically overwritten. If you specify a separate file here, the "normal" trace files are ignored and the specified file is used.

Besides the  button, there are 3 more buttons:

 Filter history

This shows you that last 10 filter settings of the user in question.

 Use default values

The filter gets the following default values: own user, own client, from 10 minutes ago (rounded off) until now, all trace types, not tables D010* and D020*.

 Delete all values

This button deletes the values in all fields.

The menu "Filter Settings" also contains all these functions.

Once you are finished making the settings for the analysis criteria, choose  to display the results of the analysis.

Activating and Deactivating System Traces in SAP

First configure the trace components. If necessary, restrict the selection using the pushbutton General filter, and then choose Trace on. You can also change the components while the trace is activate by choosing Change trace.

You can use both Settings buttons to save your settings and call them up again later.

You can use the Save button (or Go To -> Save in the menu) to save trace records in dedicated files. 

You are presented with a screen on which you can create a remark for the trace file and select whether this should be created automatically or whether a file has to be created for this purpose. 

System Traces in SAP

If you want to record the internal SAP system activities, use the function SAP system trace. Recording the processes in your application server enables you to monitor the system and facilitates troubleshooting.

The system trace is primarily used when an authorization trace is to be used. The system log or the developer trace are recommended for system monitoring and problem analysis.

The following components can be monitored using the SAP system trace:

• Authorization checks
• Kernel functions
• Kernel module
• Database accesses (SQL trace)
• Table buffer
• RFC calls
• Lock operations (client side)

The last 4 components can also be monitored using Performance Analysis (transaction ST05). 

There are two ways of selecting what traces you want displayed. In the initial screen, the components to be logged are selected and more filters are set, if required. The filters and restrictions for the traces that have these settings can be set when the traces are evaluated.

Trace Facility in SAP

With the trace facility, you can trace various operations in your SAP System. You thus monitor the system and reduce the problems that occur

You can use the trace facility to monitor the following operations in your system:

• SQL database accesses

• ABAP programs

• Internal operations in the SAP System and authorization check.You can use transaction ST01 for this.

• Traces generated by SAP processes (developer traces).

These are the trace files that are written by the individual host system processes. These trace files contain highly technical information for use in the event of problems in your System. 

To access the trace facility, choose Tools ® Administration ® Monitor ® Traces.

Example of Trace Logging in Use

Let us assume that your work processes terminate sporadically. In the work process trace file, there is always a message like the following just before the termination point:

*** Error => ShmProtect(1002,3) shmat(4,0x700000490000000,(SHM_RND 0)) (22: Invalid Argument) [shmux.c 2904]

However, you cannot reproduce the problem. You have configured 20 work processes and do not want the trace files to occupy more than 500 MB in the work directory.

In RZ11, set the parameters as follows:

Parameter	Setting	Reason
rdisp/TRACE_LOGGING	on, 10 m	Trace logging is active. When the trace files reach 10 MB, they are copied to <file name>.old. In the case of 20 work processes, this makes 400 MB, plus the dispatcher trace and some buffer.
rdisp/TRACE_PATTERN_0	Error => ShmProtect* shmat*	The wildcard symbol * can be any character string.
rdisp/TRACE_SEARCH_LIST	WP, DISP	Only the work process trace file and the dispatcher trace file are logged. The gateway, the message server, and the ICM are not relevant here.
rdisp/autothtime	Keep the default of 60.	It should not be necessary to change the time interval at which the task handler checks the trace files. However, if so much trace is written that the size limit is reached within one minute, this value can be reduced.

Now change the trace level from the default 1 to 2 or 3. To do this, open SM50, select all work processes, and choose Process -> Trace -> Active Components. You can specify the components and the trace level in the dialog box that opens. For an error of this type, it should be sufficient to select the components Taskhandler, ABAP Proc., Scrn.proc., and Extended Memory. To increase the trace level of the dispatcher, choose Process ®Trace ® Dispatcher ® Change trace level.

You can now let the system run and check periodically whether the pattern was found. If the pattern is found, the parameter rdisp/TRACE_LOGGINGis automatically set back to OFF, and the trace level is set back to 1 (default). This is indicated in SM50 when the processes no longer have a yellow background. Once this happens, you can look in the trace files of the work processes and in the older trace files (files with the extension .old) to see what preceded the error.

Once you have finished your analysis, you can either reset the parameters in RZ11 or re-start the system. Any dynamic changes made to parameters are then lost.