Performance problem with 8 Nested Stored Procedures

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....


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.

Need Your Help

'Exports' naming convention - how does it work?

delphi naming-conventions pe-exports

What rules apply to the name that ends up in the exports section of an PE (Portable Executable)?

resolve macro variables for saving/naming a dataset in SAS

macros sas naming resolve

I have problem saving a dataset using macro variables to a desired directory.

About UNIX Resources Network

Original, collect and organize Developers related documents, information and materials, contains jQuery, Html, CSS, MySQL, .NET, ASP.NET, SQL, objective-c, iPhone, Ruby on Rails, C, SQL Server, Ruby, Arrays, Regex, ASP.NET MVC, WPF, XML, Ajax, DataBase, and so on.