For the process you have to be blocking itself, you're probably looking at a parallel plan on one or more of the queries involved. Here's what I'd do. First, capture all the statements for the stored procedure using Extended Events. You want the events sp_statement_completed and sp_statement_starting. That way you can tell what each and ever statement is doing and you'll know for sure which statement is causing the issues. When you set up the Extended Events make sure you include causality tracking so that it orders the events for you. You'll also want to put in some very stringent filtering by adding predicates. I'd suggest filtering first by the object id for the procedure in question. That should ensure that you only collect data for when this process runs. This will tell you exactly where the problem is occurring. After that, it's a question of determining what's wrong. Probably, as I said, parallelism is causing it to block itself as it attempts to modify stuff that it's also attempting to read. The best thing to do, first, make sure your cost threshold for parallelism is set to a realistic number. The default value of 5 is bad. Change it to something between 30 and 50. Then, tune the queries. All of them. The longer any given process takes to run, the more blocking it does. Finally, examine the logic. Could you do smaller transactions? It sounds like this transaction is very large. Smaller is better. Break it down into tinier chunks where you can. But, make each of the chunks run as fast as possible. Examine the query plans, ensure that you're using your indexes well, that the code doesn't have any standard issues, etc.