web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics AX (Archived)

Preventing / handling SQL Deadlocks

(0) ShareShare
ReportReport
Posted on by 1,200

Good evening,

We sometimes encounter unexpected deadlocks on SQL server related to standard non-customized AX processes. These deadlocks cause the AX clients to become unresponsive. Killing one of the processes involved solves the problem.

The processes involved are standard processes, so I do not expect that code changes are an solution, also because the locks are happening in random processes for random users (for example deletes of a temporary parm table).

Any suggestions how to handle / prevent these locks? Getting notified about the locks and killing them is not the problem, but are there any suggestions how we can prevent them (for example changes in the SQL Server configuration?)

Thanks for your help!

*This post is locked for comments

I have the same question (0)
  • Dick Wenning Profile Picture
    8,705 Moderator on at

    Hy Gertjan,

    look on sql for the query that is the head lock

    this query has a where statement and an table.

    from that point search back the query in AX.

    you can call me i'm also duct +3161479895

  • Gertjan Profile Picture
    1,200 on at

    Hi Dick,

    Thanks for your response. I know your dutch, we know each other :-)

    The question is mainly on general infrastructure settings that can make SQL Server less vulnerable for deadlocks. I know how to analyse individual cases and how to solve them. I am curious if there are any parameters in AX or SQL Server that make the system less vulnerable for these kinds of deadlocks.

  • Martin Dráb Profile Picture
    237,878 Most Valuable Professional on at

    What you're describing does NOT sounds like a deadlock. If a deadlock occurs, SQL Server detects it and rollback one of the transactions (AX would throw Exception::Deadlock), therefore they won't stay blocked. What you described sounds more like a process waiting for a resource locked by another process, but the other process doesn't wait for the first one.

    There are two main things to consider:

    a) What resources are locked and is it necessary? You can influence that by Optimistic Concurrency Control, avoiding unnecessary write locks, configuring lock escalation and so on.

    b) Why is the lock held for such a long time? Locking is a normal and good thing, but locks should be held for a short time only. The transaction may be unnecessary long and/or the process may wait for something outside database (such as a long-running X++ code) and holding locks unless it's done. In such a case the problem isn't anywhere in database.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

#1
Priya_K Profile Picture

Priya_K 4

#1
Martin Dráb Profile Picture

Martin Dráb 4 Most Valuable Professional

#3
Ali Zaidi Profile Picture

Ali Zaidi 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans