The processor issue could be that parallel execution plans are running slower. Slower transactions can lead to more deadlocks since locks are held longer and lock escalations are delayed. If...

That is something I was curious about but never pursued. Thanks for the info.

So then, would you say, there's pretty much no reason to ever use a table variable (except,...

Whoop!

Hold the phone. Did you say it goes against another database? Is that other database only performing reads or does it also have inserts & updates? And now that we're...

I know of a .22 revolver that holds 10 or 12 shots, but since most of these guys are toting Police Specials, etc., I don't think so.

I agree with the last post. You must be doing inserts, updates, deletes, somewhere in order to get deadlocks.

Are you possibly creating global temporary tables as part of the querying...

If you fixed it, post the solution so that anyone else reading the post knows how to solve it too.

Did you multiply by 60.0?

While breaking up the files and filegroups as you've outlined will help, don't forget about the database log. It needs to be on a pretty fast disk (RAID 5 would...

My experiences with virtualization haven't been terribly great either. To date, the technology I've seen all comes at a performance cost that most users don't want to pay. That said,...

Based on the query that you've described, I'd say a clustered index on the Registration Number. You should probably experiment with a clustered index on the registration number and the...

I finally got one reply over in the Microsoft forum. Buck Woody, Microsofts SQL Server Program Manager, thinks it might be a bug. If anyone can replicate it, please go...

I still entertain myself counting the number of times people can fire a standard revolver without reloading. It's when you break 10 that things get really irritating.

In addition to the query itself, you might want to check the statistics on your indexes. I don't know how many rows the query ought to return, but the index...

When you deploy the stored procedures, they'll use the statistics to compile a new plan. If the statistics are maintained well enough for normal purposes, they'll be fine for this....

If you're using table variables that are more than a few rows in size, switch them to temp tables. Except for a primary key, table variables have not statistics where...

If you also get an execution plan, that will allow focus on the parts of the query that are causing the most problem.

First thing that jumped out at me was...