Home/ Questions/Q 6707861
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T07:41:22+00:00

I’m wondering what is the correct solution to the below is. I have an

  • 0

I’m wondering what is the correct solution to the below is.

I have an UPDATE statement in T-SQL that needs to be run as a daily task. The procedure will update one bit column in one table. Rows affected is around 30,000.

A pseudo version of the T-SQL

UPDATE TABLE_NAME
SET BIT_FIELD = [dbo].[FUNCTION](TABLE_NAME.ID)
WHERE -- THIS ISN'T RELEVANT

The function that determines true or false basically runs a few checks and hits around 3 other tables. Currently the procedure takes about 30 minutes to run and update 30,000 rows in our development environment. I was expecting this to double on production.

The problem I’m having is that intermittently TABLE_NAME table locks up. If I run it in batches of 1000 it seems ok but if I increase this it appears to run fine but eventually the table locks up. The only resolution is to cancel the query which results in no rows being updated.

Please note that the procedure is not wrapped in a TRANSACTION.

If I run each update in a separate UPDATE statement would this fix it? What would be a good solution when updating quite a large number of records in a live environment?

Any help would be much appreciated.

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In your case, the SQL Server Optimizer has probably determined that a table lock is needed to perform the update of your table. You should perform rework on your query so that this table lock will not occur or will have a smaller impact on your users. So in a practical way this means: (a) speed up your query and (b) make sure the table will not lock.
    Personally I would consider the following:
    1. Create clustered and non-clustered indexes on your tables in order to improve the performance of your query.
    2. See if it is possible to not use a function, but instead use joins, they are typically a lot faster.
    3. Break up the update in multiple parts and perform these parts separately. You might have an ‘or’ satement in your ‘where’ clause, that is a good splitting point, but you can also consider creating a cursor to loop through the table and perform the update at one record at a time.

    • 0