Questions about transaction SM50 and SM66
How do I proceed if I come across lengthy database accesses in SM50 or SM66?
The first step should be to determine the database task (and possibly the database session as well) that belongs to the work process. To do this, note the PID from SM50 or SM66 and search in
Transaction DB50 -> Current Status -> Kernel Threads -> Task Manager
First, find your application PID under Active Tasks. Under ID, you are given the database task and under the session ID column, the database session connected to the work process.
The Task State column shows you how the database task of your application is currently occupied, and can provide the first indicators for the cause of the performance problems.
In the MaxDB documentation (Note: 767598), you can branch directly to the description of the task states by going to the glossary and following the term task states.
For the detail analysis, you can then use the Database Analyzer and the command monitor. Note that the command monitor must first be activated before you can send an SQL statement to the database for it to be logged in the command monitor.
If you cannot find your application PID in this list, then your application is currently not active in the database. It could be waiting for database resources. You should therefore look for your application PID under 'Executable tasks'. If it is there, your application is if waiting for a
The Task State column provides further information about the reason for the queue. In the MaxDB documentation (Note: 767598), you can search in the glossary for the term task states and branch directly to the description of the task states and find out the cause of the
The output of the database console can also help you in this case to analyze the cause of the resource problem. For information about the database console, see the MaxDB documentation (Note 767598767598@SapNote).
However, if you cannot find your application PID under executable tasks either, then the application is not active in the database at all. You can see whether it still has any connection to the database by looking under User Tasks.
Here too, you need to check the status of the corresponding database task.
If the task belonging to your application PID is in the COMMAND WAIT status, then the application has not sent an SQL statement to the database. This means that the performance problems are not to do with the database.
If you cannot find your application PID in this overview either, then the application is no longer connected to the database. The cause of the problem is not the database. The database connection
could have been terminated due to network problems. For information about the causes of this, see the Developer Trace of the work process in the Appl-Diag or in the x_server log.