A SQL deadlock in Dynamics 365 occurs when two or more processes block each other by holding locks on resources the other processes need, causing a circular dependency that SQL Server cannot resolve without intervention. In the D365 context this typically arises during high-concurrency scenarios like batch jobs or heavy data imports where multiple threads compete for the same database rows or tables. The SQL engine resolves deadlocks by automatically terminating one of the conflicting transactions (the “victim”), which results in an error. In some situations, this also lead to DB fail and where sessions are moved to the secondary DB (That may not be scaled up as the primary DB)

So when experiencing sudden slowness and “strange” errors, please check in LCS for deadlocks like this, and start analyzing the call-stack.

One scenario I experienced when importing large sales orders in parallel, and where the sales orders have the same items.   When having a lot of Commerce or EDI imports, it is common to place the entire sales order creation within the same transaction scope.  Making sure that either is entire order is imported correct. 

I would like to exemplify one specific instance that recently was identified together with Microsoft friends. 

1. We experienced that frequently the D365 F&O started to be unstable and slow.  And there where no clear indications of why.  We could not repro. Customer reported sudden TTS errors, and that user get errors about losing connection to the DB.  Typically, towards SysClientSessions.
2. Microsoft then carried out a deep analysis of telemetry, and the findings showed instances of frequent SQL failovers.  Basically the DB failed, and the recovery mechanism moved the database sessions to fail-over DB clusters. 
3. While going deeper, we found traces of deadlocks.  It seems that DB architecture don’t like massive deadlocks, and when this happens, there are auto recovery mechanisms that kick-in to ensure up time and that users can continue to use the system.

In this specific instance the deadlock was caused by inserting a record table MCRPriceHistory, and the index RefRecIdIdx.  This table is used for recording pricing details on the sales order.  Finding deadlocks on insert are rare and a unicorn, and therefore I just had to write about is. 

In this specific situation, there are two options :

1. Disable the Price History feature.  (Unified pricing related), and wait for fix from Microsoft.

2. Create a support case to Microsoft, and ask for a index change on MCRPriceHistory, adding recid to the index RefRecIdIdx.

End note;

My main message to the community is to be aware of database deadlocks, as deadlock-escallation can have major impact on performance and may also trigger fail-safe mechanism in the Dynamics 365 architecture.  And they are also very difficult to find and analyze.  If you have deadlocks, please create a support case. I’m so grateful we as a partner have invested in Microsoft Premier Support, as this has been crucial to find root cause and final fix.