...or how to exercise the error recovery in Solarwinds products.
Several of us make use of Custom SQL for Alerts, Reports, display widgets and other more dangerous activities. If you are doing this I would strongly encourage you to get friendly with your application DBA, or at the least look into the SQLserver Profiler. I have discovered one way to kill parts of the product is to cause deadlocks, some of these are of my making, others are just bugs that need to be addressed.
Deadlocks are an example of the Dining philosophers problem. SQLserver when two processes (for example the trap receiver and some custom SQL, or two pollers) attempts to read or modify data that another process is modifying or reading. SQLserver resolves this by metaphorically pulling a gun and shooting one of the philosophers (in this case a application thread). How the program recovers from having a thread killed is up to the programmer.
the SQLserver profiler will show which process got killed, and allow you to look at the conflicting SQL statements. You should really try to avoid deadlocks as they will slow down your code and cause
How to Track Down Deadlocks Using SQL Server 2005 Profiler is a good article on how to troubleshoot these. I find that the deadlock graph is sufficient. In terms of fixing them, as users we can't do much about ensuring good database design (other than whinging here or opening a support case), but we might sprinkle with (nolock) in our queries and spend some time optimizing them to help avoid deadlocks. This isn't a panacea but keeping an eye on deadlocks is something to do in our free time (laughs hollowly).
