MRP deadlocks on 10.2.200

10.2.200.16 here…
I’ve been looking at MRP deadlock issues reported on E10.1, but I wanted to ask if anyone is still having these issues on 10.2.200? We’re having deadlocks reported occasionally on up to 7 processes out of 8 during our nightly regen MRP runs, and it looks like this issue should have been resolved by our version. Most of the parts it seems to deadlock on are purchased parts where it’s trying to delete prior suggestions. No other processes are running at the time the deadlocks are occurring, to my knowledge. Any help or feedback would be greatly appreciated!

I suggest that you lower down the processes to 4 or 5 (unless you are short on time) and see if it helps.

Our current processing takes between 5-6.5 hrs. to complete. Reducing processors would extend that, wouldn’t it? Is there anything on the SQL Server side that could
impact this issue?

Are you running your MRP to log files? You can see if there is any additional information in the log files to support this. Your server is not trying to run any sql jobs during this same time is it? Have you checked the system monitor for all processes to make sure someone has not scheduled a process along side this process? Do you have an opportunity to run the process at a different time and see if it still hangs up?

Yes, it might take longer, but it might help to have the process completing successfully.

  • Can you make the horizon (cut-off date) shorter?
  • About performance and settings, have you ran the Performance Diagnostic Tools?
  • Are you running a SQL backup while the MRP is running?
  • Sometimes rebuilding indexes can help.

Hi John,

When we have MRP deadlocks in past (haven’t in a while, we’re on 10.1.600.20) it has been useful to review the MRP log details and see where the lags are occurring and then look into those part/method setups, etc. Historically our problems have had to do with bad method setup, eg pulling make direct part that has different site for mfr than top level job, phantom parts with different site than parent job, 0 required per parent, etc.
In summary, we have multiple plants manufacturing and parts being shared and Epicor doesn’t like certain setups. We ensure we pass all of our parts through inventory and then send via transfer order to keep it stable. So no make direct from another plant to a job, no job to job, one part revision approved per part, etc.

Nancy