Comments
1 comment
-
Hi,Unfortunately, this is a case of the query causing the deadlock, and it's not something we can fix.
Reading table metadata requires taking out a schema stability lock (Sch-S) so that you can't drop a table while its metadata is being read. Whereas dropping a temporary object (either explicitly or at the end of a query running) requires a schema modification lock (Sch-M); thus these two locking modes aren't compatible: (https://docs.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view=sql-server-ver15#lock_compatibility), which leads to deadlock since someone has to give. It's one of those things that's necessary for SQL Server to maintain internal consistency.
We are working on lowering deadlock priority of Monitor queries, but there are downsides to doing this - such as decreased accuracy of monitoring which can lead to gaps on graphs - but we haven't finalised this at all yet.
Add comment
Please sign in to leave a comment.
Combination of Sch-S and Sch-M locks causes deadlocks. Why does SQL Monitor need to use NOLOCK on the system tables? And is this changed/fixed in latest version?
thanks