tpsharp (12/2/2014)

---

We are looking to move it to a hosted platform shortly which should resolve the issue, but this is a strange why this is running each day. This...

Sean Lange (12/2/2014)

---

This beauty was around 6,000 lines long. That was not a typo. It was a "single" query with something on the order of 200 instances of the word...

If you're trying to implement a checked in/checked out feature, please do some reading up first. It's one of those things that's easy to get wrong and very hard to...

Because the one select took the lock, ran the select and automatically released the lock once it finished. The second would have waited for the first to finish (because the...

Grant Fritchey (12/2/2014)

---

GilaMonster (12/2/2014)

---

Or restore the backups to another...

This is just a sheer lack of indexes (pk only on all tables), compounded with Entity Framework (so essentially SELECT * for all queries) and a lack of archiving.

This...

There will always be intent exclusive locks, that's a normal part of locking, nothing unusual there.

Or restore the backups to another server and CheckDB...

For @#$^%&%$

"The server's got 8 cores and 28GB of memory. It doesn't matter if it's scanning a 200 000 row table. It's not going to be a problem."

From the CTO.

Why...

XLOCK

The optimiser, which is what generates those estimated costs, does not have...

Nothing will automatically cause SQL to run a CheckDB

You probably have a job, or a job step in the backup job, which runs CheckDB on all databases.

Post the plans please, descriptions of them don't help.

Plus table definitions, index definitions and the query itself.

What do you mean by 'recently'? More than a few days? From before the prod server started running slow?

And to check indexes on both and data volumes. If the data volumes are different between the servers, a different plan is expected.