SAP UPD work process full

[reaganchan]

Hi, I had a question about UPD process. All the UPD work process are fully occupy and the time is adnormal. When the current user confirm to kill the process, the other users will fully occupy the UPD work process. Can someone explain this? thanks

[Former Member · Accepted solution]

Hi Teck

When update processes get stuck, it is a database problem in most cases. Check for an archiver stuck (log filesystem/space full), your database log, and SM21 for database errors.

Regards Michael

[Former Member · Accepted solution]

Hi,

This kind of situation occur, when number of locks. Please check transaction sm12.

Regards

Ben

[reaganchan · Accepted solution]

Hi, i had check the sm12. There are 7000++ locks. So, I force to restart the system and all the locks entry gone after reset,

[Former Member · Accepted solution]

Hi,

Your problem has been resolved or not?

Regards

Ben

[reaganchan · Accepted solution]

yes, the problem has been resolved after restart SAP system. Is there any alternative way to solve this problem without restart SAP system

[Former Member · Accepted solution]

Hi Teck

It would be interesting to see if a majority of the locks came from one user / one application. If yes, then the application should be investigated. Instead of restarting SAP, you can logout this User (or cancel his job) to release its locks.

You should <b>never</b> just delete the locks in SM12, this could lead to data inconsisteny.

Regards

Michael

[Former Member · Accepted solution]

Hi, my skill is very obsolete as my last SAP system was a 4.6C.

I would check whether the issue appears randomly or if there's aspecific time of day when it happens.

From SM12 you can order the lock entries (and I expect there are many) by lock argument and see which is the biggest list and which is the oldest enqueued record.

At that point identify the relative dialog or batch and look at the work process log via SM50. If there are not too much updates to rollback, kill that process (in the worst case it will be stuck). Don't terminate the work process and don't just delete the locks. Give the system the time to clean it up.

If, after killing the task, the situation return normal you have identified the user and the program.

Remember that is UP2 and not UPD in charge of database writes, so also giving a look to the UP2 work process log can be useful.

If you think to have identified the user, get in touch and arrange a session with ST05. Put him under trace and have him retrying the operation. When it stucks stop the trace and examine it. You can run explain plans over SQL statements, check the relative cost and also see if there is any kind of database issue (i.e. missing statistics or broken indexes). If the database is fine look at the abap. It's possible that the program commits the updates only at the end of a massive update and intermediate commits have to be added to the program code.

As M Ho writes, NEVER delete a lock from SM12 unless you are absolutely sure of what you are doing. 

Also restarting the instance may be useless if you restart an application server as the enqueue table is resident in the memory of the central instance.

On the DB side you can give a look to V$session, V$process, V$lock and V$session_wait, but if you have a big SAP instance with a lot of active work processes, finding out the one to check can be very tricky.

Of course during the years the names and the structures of the above views may have changed.

I'm not working on tech stuff since 2004 and I'm a bit missing it... apologies in advance for the rubbish. Things are likely very different from what I remember.

[Former Member]

You mean to say all your update processes are occupied during the normal operation??. What activity/transactions are getting executed?

Just take ST03N and see the wait time for update processes. If you see high wait time, then increase the number of update processes and distribute it across appication servers.