Stuck update records can cause a lot of issues related to locking of tables, performance of the system. So if someone complains about this, you need to check SM13 for such stuck update records and do some troubleshooting to find the root cause.
This blog will cover below topics:
- How to troubleshoot such issues ?
- What is the root cause ?
- Is there any quick workaround ?
- What should be the possible final solution to avoid such issues in future?
So lets start.
First we need to check SM13/SM14 to identify the stuck update records. In most of the production system, you will see 2-3 application servers. So you may see that the updates are getting stuck on only 1 particular server. In that case, we narrow down our search for the root cause.
How to identify on which server the updates were running?
This we can check in SM13 –> Select the stuck update record and click on below icon “Update header”
You should see below 2 fields, Update Server and UD Client.
Update Server —> Shows the name of the application server where the update is running/stuck
UD Client —> Shows the server name from where this update is triggerred.
What is important in our case is the field “Update Server”. If you see all the update records having the same value in the field “Update Server”, then that is enough proof to consider that the issue is only on that particular server.
Also you should see that the update records on other application servers are being processed with no issues.
Now as you have identified the impacted servers, you can execute SM21 to see if there any error messages or warnings for that particular application server.
If you don’t see any error messages in SM21 then you will now need to dig deep into the trace files to identify the root cause. Check the dev_* trace files for more information on this. Usually you will see below errors in your dev_* files.
Error in EmAlloc –> This error occurs when the Swap file space has been completely exhausted. Because of this, System is unable to process those update records on that particular server.
Quick solution would be to remove that particular server from the update group of servers. logon groups as well as from the background Job server groups. Once we are sure that nobody else is logged on into that server, you may stop the sap application server via SAP MMC and restart the complete windows system.
- Deactivate from SM13 –> Administration
Select the impacted application server and then click on “Deactivate” button. This will stop new update records from going to this particular server.
2. Logon groups SMLG
Remove the application server from the logon groups if there is any custom groups maintained in SMLG.
3. Job server groups SM61
Remove the application server from any of the maintained Job server groups. This will avoid running jobs on that particular server.
Also check in SM37, if there is any job in released/Active state executing on this particular server. If yes, then change the server by going into edit mode. For active job, wait for the jobs to get completed before restarting the server. If the active jobs are not critical they can be stopped and restarted after the server is restarted.
Post the complete server restart, start the SAP application and add the server back in SMLG, SM61. Server will be in active status by default in SM13.
But we still need to find the real root cause for the EMalloc failed error. We need to check if there was any long running job or dialog session which consumed all the EM memory as well as the heap memory. This you can check with STAD, ST03N, SM04. We will create a detailed blog on this.
Second root cause could be kernel issue. As you know, Since kernel 74X the update request needs a piece of Extended Memory to start the processing. If this is not available, the trigger of the update request gets discarded and therefore the update request itself remains in SM13 forever.
So if you see such issues getting repeated again and again, then check if your kernel version has a memory leak. SAP frequently releases such bugs and regression notes for each Kernel version and patch level. You can check if your particular kernel is impacted by checking this blog How to check SAP kernel regressions/bugs.
If you want to know you kernel patch level, then this blog should help – How to check your SAP kernel version
If your kernel is impacted, then plan the kernel upgrade to the latest version or latest minus 1 version.