Question

This is a pretty strange issue so bear with me. I have a stored proc that does some heavy duty processing. When it runs well it usually takes a few minutes depending on server load, but occasionally it appears to get stuck.

I have looked at the results of sp_who2 and what I see is that the process is not blocked, it’s still listed as ‘RUNNABLE’, but the value in disk IO stays the same. Once the process gets in this state it never finishes. If I kill the process and re-execute the stored proc, I usually get the same result.

Sometimes re-executing the stored proc works, but increasingly I end up having to restart SQL Server. Not ideal… After restart the stored proc executes as expected. Has anyone even hit a problem like this? Any advice would be greatly appreciated.

Some more context. The stored proc I am executing looks something like this:

delete
from table1

insert into table1
select columns
from 
(
    select columns
    from giant_table_1 WITH (NOLOCK)
    where condition
    group by columns

    UNION

    select columns
    from giant_table_2 WITH (NOLOCK)
    where condition
    group by columns
)
where condition

more crud on table1
.
.
.

If I insert some logging statements into the stored proc I can see that when it hangs it hangs on the insert/select. Wondering if this could be a weird consequence of the NOLOCK statement. We (and by we I mean my boss :)) added the nolock because giant_table_1 and giant_table_2 are constantly being changed. Without the nolock our sproc was getting blocked a lot by other long running processes and vice versa.

Thanks in advance!

Answer 1

Union can be a real hog. To test it you could do the individual inserts and see if the Union is significantly longer than the sum of the individual inserts.

If union is the hog I would try to refactor without the union but that last where condition may not allow you to break it down. Pretend you can move the last where into the into the individual wheres.

insert into table1 with (holdlock) 
select columns
from giant_table_1 WITH (NOLOCK)
where conditionPlus
group by columns
order by giant_table_1.PKoftable1;

insert into table1 with (holdlock) 
select columns
from giant_table_2 WITH (NOLOCK)
where conditionPlus 
and conditionToEliminateInsertsAlreadyInTable1
group by columns
order by giant_table_2.PKoftable1;

Notice the order by PK of table1. This can be huge. It is way faster to sort the insert than perform page splits. Tune the fill factor on Table1.