I will go with the others and posit parameter sniffing/plan caching as the culprit here. OPTION (RECOMPILE) or dynamic sql as a solution.

Grant Fritchey (11/9/2009)

---

12 tables in a join isn't exactly going to break the system assuming the tables are well indexed and the query is properly written. I wouldn't even start...

You can determine this by set statistics IO on and running a single-row-hit select on the indexed column (that doesn't have to hit the base table). whatever you get...

How about encryption??

IIRC the "best practice" when installing SQL 2008 is to PRE-install SP1, then install RTM, then REinstall SP1 and CUx if you wish. There are a number of issues...

Yepper. I have had several clients that have benefited...

pauljacob (11/4/2009)

---

Yes still hangs on Query num 9. Query is bascially fired from our reporting server using Cognos applications. Yes alternative solutions are to spilt the queries but it works...

Vincent Central (10/30/2009)

---

I have been looking at wait stats to try and figure out some processing time problems that I have not been able to improve with simeple index analysis...

huston.dunlap (10/30/2009)

---

Currently I am working on a database table that has a very large text field (we will call it ExtractedText). The query has to look for wildcard searches through...

second should be faster since the move AND the creation of the clustered index are done in one step. BTW, be prepared for a pretty sizeable tlog for this...

No harm will be done, but the table/index will (continue to) be blocked while the rollback occurs, which can take pretty much as long as the work to that point...

As long as your second job is PURELY reads, then you shouldn't get deadlocks. However, it WILL be blocked by the first (updating) job while the first is running....

It always worked (exclusive of bugs). But it did (and in my completely uninformed opinion will continue...

Hmm - in my experience CXPACKET waits are almost always the result of a suboptimal...

If you have the same problem did you try the same solution (-g startup setting)?