HELP: Strange Blocking Performance Problem with Simultaneous Queries

[loosecannon_1]

Hello everyone, I am hoping someone can help me with this problem. I
will say up front that I am not a SQL Server DBA, I am a developer. I
have an application that sends about 25 simultaneous queries to a SQL
Server 2000 Standard Edition SP4 running on Windows 2000 Server with
2.5 GB of memory. About 11 of these queries are over views (all over
the same table) and these queries are all done from JDBC but I am not
sure that matters. Anyway, initially I had no problem with these
queries on the tables and the views with about 4 years of information
(I don't know how many rows off hand). Then we changed the tables to
replicated tables from another server and that increased the amount of
data to 15 years worth and also required a simple inner join on 2
columns to another table for those views.

Now here is the issue. After times of inactivity or other times during
the day with enough time between my test query run I get what looks
like blocking behavior on the queries to the views (remember these all
go to the same tables). I run my 25 queries and the 11 view queries
all take about 120 seconds each to return (they all are within
milliseconds of each other like they all sat there and then were
released for processing at the same time). The rest of the queries are
fine. Now if I turn around and immediately run the 25 queries again,
they all come back in a few seconds which is the normal amount of time.
Also, if I run a query on one of views first (just one) and then run
the 25 queries they all come back in a few seconds as well.

This tells me that some caching must be involved since the times are so
different between identical queries but I would expect that one of the
queries would cache and thus take longer but the other 10 would be
fast, not all block for 2 minutes. What is more puzzling is that this
behavior didn't occur before where now the only differences are:

1) 3 times more data (but that shouldn't cause a difference from 3
seconds to 120 and all tables have been through the index wizard with a
SQL trace file to recommend indexes)
2) There is now a join between 2 tables where there wasn't before
3) The tables are replicated throughout the day.

I would appreciate any insight into this problem as 120 seconds is way
too long to wait. Thanks in Advance.

Chris

[Erland Sommarskog]

lo***********@yahoo.com (lo***********@yahoo.com) writes:

This tells me that some caching must be involved since the times are so
different between identical queries but I would expect that one of the
queries would cache and thus take longer but the other 10 would be
fast, not all block for 2 minutes. What is more puzzling is that this
behavior didn't occur before where now the only differences are:

Well, if the is not in the cache but must be read from disc, it is not
the case that one process actually gets the data from disk and runs for a
long time, whereas the other gets the data out of thin air in lieu out of
a cache.

Exactly what happens, I don't know, but I don't really think that there
11 requests for each data page. Nevertheless, all physical must complete
before the queries can complete.

120 seconds sounds a wee bit, though.

One way to study the issue is to run one of the queries from Query
Analyzer when the cache is empty with SET STATISTICS IO ON and watch
physical IO.

It is also worth testing the impact of running a lesser number of the
queries, and see what happens in this case.

DBCC DROPCLEANBUFFERS can be used to flush the cache.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx