views:

28

answers:

1

Hi,

I have a DTS package, which after running daily with no problems for a couple of years, has started to play up. Originally it was inserting data into a table which would then fire an insert trigger. The trigger used [inserted] to update three columns in the table. Usually, it was updating about 500,000 rows of inserted data.

When the problem started, the update statement inside the trigger was taking hours to run and usually had to be cancelled. Disabling the trigger allowed the DTS to run as normal. Running the UPDATE statement in a regular query window didn't cause any problems - it ran in less than 10 seconds.

To get around the problem, another task was added to the DTS to run the UPDATE after the INSERT in place of the trigger. This worked OK for a while, but the separate UPDATE task has now started to exhibit the same problem that the trigger had. The UPDATE still runs as expected if done in a regular query window.

The DTS package was created in SQL 2000 and is running on SQL 2005 Enterprise x64.

I'm at a bit of a loss to try and figure this one out. Any ideas?

A: 

Have you tried looking at the query plan for the UPDATE statement? You can do that in query analyzer/ssms.

What indexes does the table have on it? Maybe they are having to be maintained and are slowing the update down.

Can you go into detail on the UPDATE? Is it one SQL statement or are you using a CURSOR?

Converting the whole thing to SSIS would most likely add performance, but that depends on what you're actually doing in DTS.

Sam
The query plan doesn't show anything immediately obvious. The UPDATE is one statement, joining three other tables. No cursors involved. None of the fields being updated are in an index on the table. Unfortunately, converting to SSIS isn't really an option at the moment.
nellistc
The other thing I neglected to mention is that this on an 8 way multi processor machine and when the UPDATE statement is hung, sp_who2 shows 8 UPDATE statements in a RUNNABLE state and one SUSPENDED all with the same spid. I've used query hints to set maxdop to 1 (no improvement) but am hesitant to change the max degree of parallelism in the server settings as other DTS packages which perform the same queries work fine.
nellistc
The fact that it works in the query window is a little puzzling, which points to either DTS doing something funny, or a time based issue. Anything else running at the same time? Do you also run the insert statement before testing the update in query analyzer?
Sam
No, I haven't run the insert before the update in query analyzer. The DTS is quite complex so I haven't tried to replicate what it does outside of the package. Nothing else is running at the time. I certainly agree that it's puzzling !
nellistc
My point is that the insert may be putting the database in a state which is related to the issue.
Sam
I take your point. I have done other inserts into this table and have not had the same problem. The day before yesterday, the server was restarted and the problem seems to have gone away. No closer to finding out what the issue was, but for the moment, things have gone back to normal. Thanks for your ideas. ;)
nellistc