[Case Study] Detecting and Resolving SQL Deadlocks and fixing SQL Server Performance. How did we do it?

Problem Summary

Deadlocks are a common problem handled by SQL Server automatically. Nevertheless, you have to make sure that you minimize deadlocks as much as possible because every rolled back transaction negatively influences your end-users.

In many cases, we can fix or reduce them using index tuning. Sometimes, we need to go deeper into every detail to find the main cause of the problem.

Resolving deadlocks

After adding new indexes to help the deadlocking problem, there was a significant decrease in deadlocks per day for this client. The average number of deadlocks was clear reduced, as shown below:

Figure 1- Total of remaining deadlocks per day after index tunings.

To deal with remaining deadlocks required DB changes and most likely app too.

The problem was split into three scenarios, as described below:

Problem # 1: clustering key issue.

  • Analysis: Table’s clustered index key is chosen badly (not numeric, not sequential).
  • Object: Estimates.dbo. insert_tblNugenRuleldentifiers
  • Solution: Need a new clustering key for this table. We recommend creating a new column as INT identity and using that as a clustered key. The primary key remains the same.
Figure 2- Bad Table’s clustered index –  Column RuleIdentifierID.

Problem internals: The clustered key isn’t sequential. When new records are inserted, records need to be moved around internally, and SQL does that without the user seeing it, but that causes more time for the operation to complete.

Problem # 2: ad-hoc UPDATE

  • Analysis: Ad-hoc UPDATE has too many conditions. This forces SQL Server to perform a table scan. This table scan leads to a deadlock when other operations are also updating the table, even when it should only affect a single row and should be fast.
  • Object: ad-hoc update on tblLineltems. (TSQL script was sent to client)
  • Solution: UPDATE seems to be generated by an object-relational mapping, which often creates inefficient SQL. Replace with stored proc.

Problem # 3: ad-hoc DELETE

  • Analysis: Ad-hoc DELETE has too many conditions, which forces SQL Server to perform a table scan. Deletion of a single row should be fast and should not cause this.
  • Object: ad-hoc delete on [tblLineltems] . (TSQL script was sent to client)
  • Solution: DELETE seems to be generated by an object-relational mapping, which often creates inefficient SQL. Replace with stored proc.

Conclusion

As soon as we begin providing our services, you will be able to monitor the progress in every segment influenced by our activities.

You will notice how your system performance improves. In addition, the number of critical incidents will dramatically decrease. As a result, your overall productivity and efficiency will be enhanced beyond the most optimistic expectations.

We’re confident we are the only database services, support, or consulting firm you will need to provide SQL Services to your business.

See more SQL Server Performance Optimization examples here.

We tune slow SQL Servers every day. For over a DECADE now. Contact us!

Mark Varnas

Mark Varnas

Hey I'm Mark, one of the guys behind Red9. I make a living performance tuning SQL Servers and making them more stable. I channel my SQL into our SQL Managed Services, SQL Consulting and our internal database products.

Leave a Reply

Your email address will not be published. Required fields are marked *