Question

I recently had a web application migrated to a different data center. That included moving the database from SQL 2000 to 2005, which shouldn’t be a problem per se (I run other instances of the same app with SQL 2000 to 2008 R2).

The problem is, after the migration some operations, especially UPDATEs, became extremely slow (timing out after whatever limit I define in my app, and I tried up to 6 minutes).

I tried running the same query on Management Studio, but the results were inconsistent. Sometimes it just runs instantly, but sometimes it takes forever and I have to cancel the query. On my app, it always time out (Classic ASP app).

It’s happening on more than one query, but most frequently on one that looks like this:

UPDATE mytable SET timestampcol = GETDATE() WHERE record_id = 12345 /* record_id is the PK */

What I tried already:

• First, I suspected of the table size (~2M rows). So I deleted old records, leaving only ~40,000 rows, but the problem persisted.
• Then I tried recreating my indexes, and it didn’t work.
• I also tried running both sp_updatestats and sp_updatestats 'resample', but no luck.

So, I’m stuck. Does anyone has a clue of what might be happening, and how could I fix it?

UPDATE

Looking at sys.dm_tran_locks, I can see that two locks are in place while the query is running from my app:

request_mode        request_type    request_session_id
S                   LOCK            65
IX                  LOCK            67

I also realized the S lock appears before I try to run the query that gets stuck, on an SP call. I’m now revising the SP to try and understand why the lock persists after the SP finishes running.

UPDATE 2 – Answers to Aaron Bertrand questions (see comments)

• Does the procedure use transactions?
  No, there are no transactions in the whole app

• Are there any code paths where the transaction might not be committed? N/A

• Who is calling this other stored procedure? The same script is calling it, a few lines before the problematic query

• Are you using some kind of transaction context in .NET? No, and it’s not .NET, it’s classic asp (old legacy code I have to maintain)

• Why isn’t the app calling stored procedures? You means instead of running the problematic query directly from (ADO) connection.execute? Well, also tried it, same result.

• Why does calling the other stored procedure not affect you when you run the problematic query in SSMS? I have no idea! But the update is currently running just ok from SSMS, whether I call the sp before that or not.

Guys, thank you for all your help, but I’m about to give up on this. Things just worked before someone decided to move the server. The problem was just dropped on my hands, I’ll try to pass it along to someone else.

Answer 1

This turned out to be a lock on the table. I still don’t understand why it was getting locked, but I solved it by adding the WITH(NOLOCK) hint to my stored procedure.