And, depending on what features you have in use in your 2008 database, you won't even be able to migrate your databases over.

ChrisM@home (5/13/2014)

---

Lynn Pettis (5/13/2014)

---

Is the temp table created on the fly (SELECT INTO) or is it predefined using CREATE TABLE and then populated with an INSERT INTO statement? If...

And based on that, I still don't see any way to speed this up. Oh, and I know you obfuscated the query, but we can see the objects and the...

lkennedy or LK (5/13/2014)

---

Been there done that! Been burned one to many times. It just safer to start over, it really, well ya know, but in the long run you...

Megha P (5/13/2014)

---

Don't know if it will be correct in this case or not ..

but just try by taking filtered records of

first query [select from table1 where PartitionID...

OK. Sounds fine. But, you still don't know why the log was that big. Maybe there are load processes or something that require that level of log space. You may...

ashok84.kr (5/13/2014)

---

As I said temp table is consumed in another procedure in which complex business logic is written and based on the data in this temp table various things happen...

You can just run the shrink operation on the file.

But, the bigger question is, what caused the log to get so big? Was it a one-time event that's not...

Excellent point on the storage of the cluster key in nonclustered indexes Ed. I completely missed that one.

Again, because I can't see the behavior of your queries, I don't know.

A view doesn't do anything but store the query. It won't help performance at all unless you're talking...

The ANSI connection settings can be changed by the connecting application. That's where I'd focus.

And if that index is needed by the queries, while it's gone you'll see table scans instead of index access, so that impact could be substantial.

It depends. A common practice for large data loads is to drop the indexes because they're not used during inserts and then recreate them after the inserts are complete. In...

Well, a lot of the information is right there in the SQL Server documentation. A GUID is 16 bytes while a bigint is 8 bytes. That alone affects the distribution...

In theory, the estimated values are a measure of the resources needed to execute a query. But they're just mathematical constructs with no actual relation to reality. Further, those constructs...