Seems to me it would...

Unfortunately, you really can't accurately look at one index recommendation in isolation. You really have to consider indexes in toto, including a minimum of missing index and existing index...

A longshot, but, in the interests of being thorough ...

Are there possibly different "table1" tables under different schemas? Could one session be reading from a different schema.table1 than the...

select 18 * 1.0/94

Yep, sure did :blush:

The INSERT could fail if it ran out of physical file space to hold the new rows.

ChrisM@Work (8/7/2014)

---

ScottPletcher (8/7/2014)

---

ChrisM@Work (8/7/2014)

---

Each reply posted to your question implies "maybe", "probably" or "definitely". The average of these...

ChrisM@Work (8/7/2014)

---

Each reply posted to your question implies "maybe", "probably" or "definitely". The average of these isn't "definitely...

They definitely could. The WHERE conditions determine...

Bill Talada (8/6/2014)

---

To be chosen as a deadlock victim, two threads must be inside transactions. If thread one updates tableA then tableB while thread two updates tableB then tableA...

For best performance overall, I strongly suspect you need to change the clustered indexes on the tables. We would have to look at least at missing index and index...

LutzM (8/6/2014)

---

Here are a few options to make that single table "smaller":

If the table contains a rather large number of columns (e.g. 50 or more) you might consider "vertical partitioning",...

Again, I urge you to...

For that, you could create a proc on the remote server. You execute the proc remotely, and the proc can issue the start job, and then monitor for job...

8 hours seems extraordinarily extreme for 172M rows. It seems like there must be more to the story.

Are you changing the clustered index on the table? Does the...