Hats off to both Andrew and Steve. You supplied plenty of food for thought, espeically regarindg the need for developer access to production data and what to do in the...

Good point:

>>>>>

The earlier you can realistically unit test and performance tune an app, the less issues you are going to have in production.

>>>>>

Of course while it may not match production...

Steve,

I agree with you. Privacy of sensitive data is forieted when it appears in test and dev. I think that's nothing but trouble and one day, if \when the...

A number of excellent ideas were suggested. I will take the bits and pieces that apply to our situation. Thanks to everyone for your help.

Barkingdog

Jeff,

Per the Extimated Execution Plan, TableA (with 60 millon rows) uses about 56% of the query for a table scan! (I will investigate the "predicate" shown in the display...

More info:

1. Temp 550GB was not enough. t-sql job ran into 550GB limit and failed.

2. Found statement causing the issue. The essence is shown below:

insert into

..

select distinct ....

....

from

tableA join tableB...

Good idea, Jeff.

I will use the sql 2008 "Data File Auto Grow" and "Log File Auto Grow" trace events for the given database. (From what I understand, the 3rd party...

Jeff,

I agree with what you wrote:

>>

You need to reset TempDB to a reasonable size and setup a trace for TempDB growth to help isolate the code that's causing this monstrosity....

Thank to everyone for the good advice.

barkingdog

Greg,

You wrote

>>> 2. I see no reason for a developer to ever be dbo of a production database. As GSquared said, they should do their troubleshooting in dev or test....

Thank you, Lee.

Barkingdog

Lee,

What is RML?

Barkingdog

Thanks, I will look into it.

Barkingdog

You are all correct! I missed this entirely.

Barkingdog

Thank you "Ten"

I didn't realize (duh!) that developers could access the FILSTREAM object using C#.

Barkingdog