I'm not trying to start a windows/mac type discussion.
Personally, I don't need any convincing that
NOLOCK is not a good idea as a reflexive practice. It seems when you're developing everything should be purposeful not reactionary (/amen)
So... programmer-in-charge insists
NOLOCK is the way to go. Recommends with all ad-hoc queries and whenever querying production. I haven't seen a stored procedure without nolock hints on every table.
Don't want to be that guy who comes in and tells everyone a core belief is all wrong without something to back it up.
Just looking at the comment sessions under the various blog posts, sending a link may not be enough. Long-held beliefs etc... Some people aren't convinced it's a problem. See: Comments section under every nolock blog post I've read.
Currently some other DBAs are wrestling with some mysterious deadlocking. How does one determine whether NOLOCKs are the source?
It's been suggested looking at XML from traces etc, but this won't explicitly state that the deadlocks are causing the problem, will it? I've never seen error messages that straight forward. is that true?
How else could these deadlocks be pinned on this?
DDL statements like
CREATE would be a clue. Is there any output that I could point to or some piece of data I could find that would help corroborate my theory before I raise the alarm?
Or am I running trace flags or extended events to identify what's running when the deadlocks occur and then deducing from DDL statements?
Looking at all the different ways data can get messed up with nolock hints, it seems like a hard problem to decisively pin down.