Performance problem with 8 Nested Stored Procedures

Question

I have a performance problem
I need to run a Stored Procedure from .Net 1.1. This stored procedure calls 8 Stored Procedures. Each one of them process information to throw a comparative between old an new informacion and anter afects the physical table in DataBase.

The problem comes since I try to run it directly from SSMS. Servers starts crashing, getting so slow and almost impossible to work. I think infrastructure people has to restar service directly on the server.

I'm working in development enviroment so there is no much problem, but I can't upload this into production enviroment.

I've been thinking in use procedures only for comparison purposes and never affect physical data. Retrive information from them in Temporary tables in principal procedure and then open my try-catch and begin-end transactions blocks and affect database in my principal stored with the informacion in Temp tables.

My principal stored look as follows: Is this the best way I can do this??

create proc spTest
as
/*Some processes here, temporary tables, etc...*/
begin try
begin distributed transaction
sp_nested1
sp_nested2
sp_nested3
sp_nested4
sp_nested5
sp_nested6
sp_nested7
sp_nested8
/*more processes here, updates, deletes, extra inserts, etc...*/
commit transaction
end try
begin catch
rollback transaction
DECLARE @ERROR VARCHAR(3000)
SELECT @ERROR = CONVERT(VARCHAR(3000),ERROR_MESSAGE())
RAISERROR(@ERROR,16,32)
RETURN
end catch

The basic structure of each nested stored proc is similar but doesn't call any other proc, only each one has their own try and catch blocks.

Any help will be really appreciated... The version Im using is SQL Server 2005

Thank you all in advance....

Answer 1

First when things are slow, there is likely a problem in what you wrote. The first place to look is the execution plan of each stored proc. Do you have table scans?

Have you run each one individually and seen how fast each one is? This would help you define whether the problem is the 8 procs or something else. You appear to have a lot of steps involved in this, the procs may or may not even be the problem.

Are you processing data row-by-row by using a cursor or while loop or scalar User-defined function or correlated subquery? This can affect speed greatly. Do you have the correct indexing? Are your query statements sargable? I see you have a distributed transaction, are you sure the user running the proc has the correct rights on other servers? And that the servers exist and are running? Are you running out of room in the temp db? Do you need to run this in batches rather than try to update millions of records across multiple servers?

Without seeing this mess, it is hard to determine what might be causing it to slow.

But I will share how I work with long complex procs. First they all have a test variable that I use to rollback the transactions at the end until I'm sure I'm getting the right actions happening. I also return the results of what I have inserted before doing the rollback. Now this initially isn't going to help the speed problem. But set it up anyway because if you can't figure out what the problem would be from the execution plan, then probably what you want to do is comment out everything but the first step and run the proc in test mode (and rollback) then keep adding steps until you see the one that it is getting stuck on. Of course it may be more than one.