Are you running those statements in a distributed transaction, both step-by-step and complete?
Main Topics
Browse All TopicsI am trying to understand what is causing a tremendous increase in run time for a series of queries.
I have run them individually and found the actual time to be 3-5 times faster than when run in series.
I tested this on a small set (just over 500 records), but this also runs on data sets in the 10-20k rows.
E.G.
Query 1 -- 500 rows, .020 min <-- This is a select into Query with joined tables on 2 different servers.
Query 2 -- 475 rows, 2.55 min <-- This is an update Query with joined tables on 2 different servers.
Query 3 -- 25 rows, 0.15 min <-- Also and update Query with joined tables on 2 different servers, and a statement to select only rows not affected in Query 2.
Query 4A-D -- Upto 500 rows each, 0.02 min in total. <-- simple update queries to format fields collected above.
Total run time when executed step by step - Just under 3 min. When I select all steps and run in a batch this takes over 8 min.
Can anyone explain why this would be, and how to minimize this? Bringing the tables to the same server is not an option. I am primarilly interested in why the whole process runs quicker when done step by step.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
These were not tested with distributed transactions explicitly stated. I may be misunderstanding the value of such statements. If I explicitly declared and then committed a transaction for each query in the process, wouldn't I have the same problem as mentioned by Thenelson?
Would begin/end explicitly stated in the code streamline this so that the different queries do not run in parallel?
"Queries run asynchronously" - that is not true in general. If you use Management Studio or Query Analyzer (MSSQL 2000), or the cmdline pendants, each query is executed one after another. T-SQL has no syntax for running queries asynchronously.
In a program, e.g. using ADO, you can determine whether queries are async or sync.
How do you run "step by step"? Selecting the single query, and executing it? That will issue an COMMIT anyway. And it will delay the execution (because you execute each step manually), giving the database time to clean up buffers. I don't know whether that could even be the reason, it's only a guess.
I am running the queries in management studio.
When I run them step buy step; yes select and execute each query in turn - manually.
That of course has it's own time sink, depending on how steady my mouse hand is on a given day.
When I run them in series, I select all 4 at once and then execute. Perhaps the extra time is the database clearing out the buffers, and temp tables used for the previous steps?
Business Accounts
Answer for Membership
by: thenelsonPosted on 2009-10-28 at 12:02:10ID: 25686943
It would be nice to see the queries and the "batch" but my guess would be time sharing of the processor by the processing of the queries. For example, query I runs a little, then query 2 takes over, then query 3, then back to 1, etc. Each time a query swaps control of the processor, large amounts of data needs to be transferred.
Queries run asynchronously which means they run in the background while the code or macro continues so if the "batch" is not designed carefully, they will all run at the same twice and will need to share the processor.