No Deadlock?
-
No Deadlock?
Wow, I couldn't believe it when I saw this kb article. A deadlock in SQL Server 2005 may not be detected?
Granted there are some specific conditions associated with this particular issue, but they're not what I would see as a very rare situation. Most of these I'd expect to occur regularly and the others I'm not sure how often you'd know if they occurred. Add to that the possibility that there are other situations in which this could occur or other conditions and it's a potential big problem.
Can you imagine if this occurred regulary? Would you even know to look for a deadlock if one wasn't reported? Might it just seem like some strange blocking? This might be one of the situations that would drive a DBA nuts killing connections every day.
I think that SQL Server is a great product, and I know that all software has bugs, but this seems to be a pretty big one. While I don't know how the deadlock code functions, it would seem that this type of bug shouldn't occur. There are some people that think we should more exhaustively test software and no bugs should be in released software, but I don't think that's practical.
Of all the reports of issues I've seen with SQL Server 2005, most have been of the annoying kind. This is one of the more serious ones that could caused major issues in a production environment. Especially if it occurs with any frequency.
I rarely see deadlocks on my systems, and I hope that if this occurs, I can figure out what's going on.
Steve Jones
-
If you are using SQL 2005 and want any stability, you are already on build 2153 and this is not an issue. We had to use build 2153 just to get SSIS to play nice with Oracle. And who actually would expect to have this happen on their SQL box - ALL conditions have to be true. Do you actually run queries in parallel without checking for locks? That's just bad programming.
This undetected deadlock problem only occurs when all the following conditions are true:
• The server is running SQL Server 2005 Service Pack 1 (SP1) or the original release version of SQL Server 2005. • The server has multiple processors. • SQL Server is configured to run queries in parallel. • One of the deadlocked statements runs in parallel across multiple processors. • Typically, the execution plan of this deadlocked statement performs a sort operation or a hash join operation. • The scan operation or the seek operation under this sort operation or under this hash join operation waits for a lock. • This lock is incompatible with a lock that is held by a separate update statement in a different session. • This different session may not be running in parallel. Maybe if the guys that report on Microsoft software didn't push them so hard to get a release out the door, they might release the software with fewer bugs. But, really, think about it. Microsoft releases software that runs on hundreds of thousands of different pieces of hardware with millions of different configurations with thousands of other software packages and the software runs right out of the box with no configuration changes or tweaks.. Name any other software company with that level of software quality. And name another software company that does not make you pay for the bug fixes and service releases.
Joshua Perry
http://www.greenarrow.net -
I think the MS guys do a great job, but keep in mind that most of us run queries. We don't check for locks or parallelism. We let the optimizer decide when to do that.
And this occurs with these circumstances, but it could occur with others. Those either haven't been reported or identified.
I depend on that deadlock manager and it seems that this is a big deal.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply