• Chuck Bevitt (6/30/2016)


    Here's the deadlock graph from one of the occurrences.

    I think a light is starting to come on - what I was looking at as a simple read query with a filter can involve several indexes on a single table. Since I'm reading committed, this would require some level of locks on multiple indexes - which is where the potential for a deadlock would come from. One process might have a lock on index A and trying to get a lock on index B while another process has a lock on index B and trying to get a lock on index A. I just wasn't thinking of deadlocks in terms of indexes.

    Will appreciate further comments on this.

    I had mentioned in my post that Snapshot wasn't an option as we don't have Snapshot turned on in our databases. As our business volume increases, we seem to be getting more issues like deadlocks and (ADO.Net) timeouts. We can't go back and overhaul 15 years of application coding all at once; however for new or updated app there might be places were dirty reads would be unacceptable but snapshot would be. Should I push our IT department to consider turning Snapshot on? I know it involves additional overhead, is there a way to predict in advance what the impact would be?

    SELECT query would only apply S(hared) locks - that's what you have on the left side of your graph.

    But what is causing X(clusive) locks on the right side?

    It cannot be a SELECT.

    _____________
    Code for TallyGenerator