views:

77

answers:

2

I have a simple procedure that selects 1000 rows from a table. For the sake of clarity, here's what the stored procedure looks like:

alter procedure dbo.GetDomainForIndexing
  @Amount int=1,
  @LastID bigint,
  @LastFetchDate datetime
as
begin

   select top (@Amount) *
     from DomainName with(readuncommitted)
    where LastUpdated > @LastFetchDate 
      and ID > @LastID 
      and ContainsAdultWords is not null
 order by ID

end

I've been having issues where it would run this particular procedure fine a bunch of times, the only difference being that a different @LastID value was being passed in each time. As soon as I get to a specific ID though, the procedure will return the first 880 rows almost instantly (this is happening in management studio) and then sit there and literally stall for the next 6 minutes before returning the remaining 120 rows.

What on earth could cause behaviour like this? There are no transactions associated with the connection and there are no connection pool issues. The (readuncommitted) bit does not affect the issue. The issue occurs both from within my application and when I copy the command text into SQL Management Studio for testing; indeed it is there that I discovered this weird stalling behaviour. Initially I was just trying to work out why this procedure would work fine a bunch of times and then suddenly start stalling for no apparent reason.

Any ideas?

UPDATE

The issue also occurs (stalling after 880 rows have been returned) when asking for 883 rows, but not when asking for 882 rows.

UPDATE 2

Selecting from sys.sysprocesses and sys.dm_exec_requests indicates a lastwaittype of PAGEIOLATCH_SH. What should I do?

A: 

Have you tried rebuilding the indexes on DomainName?

Ian Jacobs
Have tried that to no avail, thanks for the suggestion though.
Nathan Ridley
A: 

Quite likely "parameter sniffin"g and an suboptimal cached plan for the offending @LastID value Try this:

DECLARE @ILastID bigint
SET @ILastID = @LastID

select top (@Amount) *
from DomainName with(readuncommitted)
where LastUpdated > @LastFetchDate and ID > @ILastID and ContainsAdultWords is not null
order by ID

Another option:

What does sysprocesses say as LastWaittype? ASYNCH_NETWORK_IO? If so, then the client can't deal with the SQL Server output

gbn
Already tried parameter sniffing as a resolution, that didn't help. What do you mean with regards to lastwaittype? I'm no db admin :D
Nathan Ridley
Basically, is the client choking on data and filling the SQL Server network buffers... after your update, have you masked *all* parameters
gbn
I fired off the procedure, then once 880 rows had been returned, I ran `select * from sys.dm_exec_requests` which returned a single row with a status of `RUNNING` and a last_wait_type of `MISCELLANEOUS`. So I guess it's not `ASYNCH_NETWORK_IO`...
Nathan Ridley
Oh, also I checked sysprocesses and it says last_wait_type is `PAGEIOLATCH_SH`
Nathan Ridley
The sys.dm_exec_requests will be showing you it's own SPID because of "MetaData visibility". You need "VIEW SERVER STATE" rights to see the SPID of the offending command. Ditto sysprocesses
gbn
I am running as system administrator in this case (sa) so have full rights to do anything. The `PAGEIOLATCH_SH` wait type is no longer being reported and is instead showing `MISCELLANEOUS`.
Nathan Ridley
my bad sorry: I mixed up sys.dm_exec_requests and sysprocesses. Back to "did you mask all parameters?"
gbn
Tried that before posting this question. It had no effect on the issue.
Nathan Ridley
My bad, the connection was not sa, I forgot I'd disconnected and reconnected as a different user. Yep, the lastwaittype for both sysprocesses and dm_exec_requests is `PAGEIOLATCH_SH`. What should I do?
Nathan Ridley
I'd google "PAGEIOLATCH_SH" waittype...?
gbn
Yep been doing that... haven't found anything practical yet, but I'll continue looking.
Nathan Ridley
http://www.google.co.uk/search?q=PAGEIOLATCH_SH+stalling IO related, look for links with DMVs mentioned...
gbn
In the end, removing `and ContainsAdultWords is not null` completely eliminated the issue. Not sure why exactly.
Nathan Ridley