Author |
Topic |
MartinSmith
Starting Member
17 Posts |
Posted - 2004-09-07 : 10:18:20
|
Hi,A few times recently I have encountered issues whereby a query called from ADO within VB times out after 30 seconds, Yet the same query called from Query Analyzer executes in less than a second.There is a consistent pattern in that when one query starts doing this it will continue to do so until the server is rebooted. Running Profiler will show the expected text (e.g. "exec dbo.ReviewGetDetails 56, 0") and pasting this text into Query Analyzer works fine, it's just the call from the VB App that falls over.The result set for this query is very small so I can't believe it's anything to do with the amount of data being returned.The only difference I can see between the 2 calls in QA are that one is a SQL:Batch... event and the other is a RPC:Batch... event Any ideas?CheersMartin |
|
spirit1
Cybernetic Yak Master
11752 Posts |
Posted - 2004-09-07 : 10:32:35
|
set the SqlCommand.ConnectionTimeout = 5*60 (5 minutes) or moreQA doesn't have a timeout it just keeps running.use the profiler to see what is taking so long...Go with the flow & have fun! Else fight the flow |
|
|
MartinSmith
Starting Member
17 Posts |
Posted - 2004-09-07 : 10:42:27
|
Hiya,The point is though that 30 seconds should be quite sufficient as the exact same query only takes 1 second to run in QA!Cheers,Martin |
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
Posted - 2004-09-07 : 10:54:04
|
yes. so increase the ConnTimeout and use profiler to see what's going on if u run it from ado and from QA.Go with the flow & have fun! Else fight the flow |
|
|
MartinSmith
Starting Member
17 Posts |
Posted - 2004-09-22 : 06:47:11
|
I'm still getting this issue - anyone else have any ideas? |
|
|
slacker
Posting Yak Master
115 Posts |
Posted - 2004-09-22 : 07:04:03
|
Have you tested other queries within your vb app and does it do the same thing? Maybe there is another odbc ( oledb? )driver you can try. |
|
|
Kristen
Test
22859 Posts |
Posted - 2004-09-22 : 13:03:04
|
I would suggest you either use Profiled to see what is going on or, if you are not familiar with that, put some INSERT INTO MyLogTable GetDate(), 'Now at Point A'type statements in your SProc. You might find it has actually finished executing and its VB that has stalled!Kristen |
|
|
MartinSmith
Starting Member
17 Posts |
Posted - 2004-09-23 : 06:13:58
|
Hi,A bit more info...Increasing the timeout has no effect (eg. increasing it from 30 secs to 60 secs just means that instead of timing out after approx 30000 miliseconds it times out after 60000 miliseconds)In profiler the only information I see is the RPC:Batch starting info and the RPC:Batch completed info. Are there any other events I should be tracing to see what happens between these points?The only difference I see in profiler between running the stored procedure in QA and running it from the VB app is the EventClass (RPC vs. SQL)The stored procedure couldn't be simpler and just selects from a view.CREATE PROCEDURE dbo.ReviewGetDetails @CompanyID int = 0, @ReviewID int = 0 ASIF @ReviewID = 0 SELECT * FROM ReviewLatestDetails_vw WHERE CompanyID = @CompanyIDELSE SELECT * FROM ReviewDetails_vw WHERE ReviewID = @ReviewID(NB It isn't always this stored proc that fails but that is the example I gave above...)This is currently happening about once a week and whilst rebooting does (temporarily) fix it. It obviously isn't ideal! I'm wondering whether it could be something like a dodgy pooled connection or something like that - is that possible? |
|
|
MartinSmith
Starting Member
17 Posts |
Posted - 2006-08-22 : 15:34:54
|
OK.Two years on from my original post but I am still curious about this issue.I just had a similar issue again today.This time a SQL 2005 stored procedure (that has always been working fine previously) suddenly decided to consistently timeout on my ASP.NET 2.0 site.Again the query ran fine in Management Studio however.This time I resolved it by adding the line "set arithabort on" to the beginning of the sp as that was the only difference in "SET" options that I could see between the ADO.NET Connection and the Mgmt Studio one.I'm unsure whether this or the resultant recompile made the difference but all started working well again.This does seem to be an occasional SQL problem. I'm sure I'm not the only person this ever happens to. Am I?Anyone got a good explanation? |
|
|
shlms78
Starting Member
1 Post |
Posted - 2006-08-22 : 17:51:50
|
Just Curious,Is the SP you are currently having problems with similar in design to the original (Call the stored proc and execute one select or else execute another select)? In other words, the SP can return different result sets based on a parameter switch...Yak In the Box |
|
|
MartinSmith
Starting Member
17 Posts |
Posted - 2006-08-23 : 05:47:04
|
quote: Originally posted by shlms78 Just Curious,Is the SP you are currently having problems with similar in design to the original (Call the stored proc and execute one select or else execute another select)? In other words, the SP can return different result sets based on a parameter switch...Yak In the Box
No. I don't mind posting the whole proc here in case anyone sees any constructs that are likely to be problematic (or may require ARITHABORT to be on). I'm not using indexed views or computed columns.CREATE PROCEDURE [dbo].[spSelectChangeResults]@DatasetId int,@IndicatorId int, @AdditionalGeographicEntities varchar(200),@UserId int,@SiteId int,@ApplicationId int = 5,@IndicatorChangeTitle varchar(500) OUTPUT,@NumberOfYears int OUTPUT,@NumberOfGeographicEntities int OUTPUTAS--Determine: What Geographic Entities can the user see?DECLARE @GeographicEntitiesToUse TABLE( [GeographicEntityId] [int] NOT NULL ) INSERT INTO @GeographicEntitiesToUseSELECT tblGeographicEntitiesToUse.[value]FROM fnSplit(@AdditionalGeographicEntities, ',') tblGeographicEntitiesToUse INNER JOIN tblGroupApplicationGeographicEntities ON tblGeographicEntitiesToUse.[value] = tblGroupApplicationGeographicEntities.GeographicEntityId INNER JOIN tblGroups ON tblGroupApplicationGeographicEntities.GroupId = tblGroups.GroupId INNER JOIN tblUserGroups ON tblGroups.GroupId = tblUserGroups.GroupIDWHERE (tblUserGroups.UserID = @UserID) AND (tblGroups.SiteId = @SiteId) AND (tblGroupApplicationGeographicEntities.ApplicationId = @ApplicationId)--Out of this list of GEs. Determine: --For Each Year in the resultset what is the most recent datarelease for geographic entities at this Spatial Level --that is viewable to this site?DECLARE @tblMostRecentDataReleases TABLE( [SpatialLevelId] [int] NOT NULL , [IndicatorId] [int] NOT NULL , [Year] [int] NOT NULL , [DataReleaseId] [int] NULL ) INSERT INTO @tblMostRecentDataReleasesSELECT tblGeographicEntities.SpatialLevelId, tblMatrix.IndicatorId, tblMatrix.[Year], MAX(tblMatrix.DataReleaseId) AS DataReleaseIdFROM tblSiteDataReleases INNER JOIN tblMatrix ON tblSiteDataReleases.DataReleaseId = tblMatrix.DataReleaseId INNER JOIN tblGeographicEntities tblGeographicEntities_1 ON tblMatrix.GeographicEntityId = tblGeographicEntities_1.GeographicEntityId INNER JOIN tblGeographicEntities INNER JOIN @GeographicEntitiesToUse [@GeographicEntitiesToUse] ON tblGeographicEntities.GeographicEntityId = [@GeographicEntitiesToUse].GeographicEntityId ON tblGeographicEntities_1.SpatialLevelId = tblGeographicEntities.SpatialLevelIdWHERE (tblSiteDataReleases.SiteId = @SiteId) AND (tblMatrix.IndicatorId = @IndicatorId)GROUP BY tblGeographicEntities.SpatialLevelId, tblMatrix.IndicatorId, tblMatrix.[Year]DECLARE @tmpResults TABLE ( [GeographicEntityId] [int] NOT NULL , [GeographicEntityName] [varchar] (100) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL , [Year] [int] NOT NULL , [IndicatorValue] [float] NULL ) INSERT INTO @tmpResultsSELECT tblMatrix.GeographicEntityId, tblGeographicEntities.GeographicEntityName, tblMatrix.[Year], tblMatrix.IndicatorValueFROM @tblMostRecentDataReleases [@tblMostRecentDataReleases] INNER JOIN tblMatrix ON [@tblMostRecentDataReleases].IndicatorId = tblMatrix.IndicatorId AND [@tblMostRecentDataReleases].DataReleaseId = tblMatrix.DataReleaseId AND [@tblMostRecentDataReleases].[Year] = tblMatrix.[Year] INNER JOIN tblGeographicEntities ON tblMatrix.GeographicEntityId = tblGeographicEntities.GeographicEntityIdINNER JOIN @GeographicEntitiesToUse [@GeographicEntitiesToUse] ON tblGeographicEntities.GeographicEntityId = [@GeographicEntitiesToUse].GeographicEntityId--In the event that we have 2 Geographic Entities with the same name but different IDs use a concatenation of the 2 so that --the CrossTab data provider can tell them apart.SELECT COALESCE (tblNonDuplicated.GeographicEntityName, [@tmpResults].GeographicEntityName + ' - ' + CONVERT(VARCHAR(6), [@tmpResults].GeographicEntityId)) AS GeographicEntityName, [@tmpResults].[Year], [@tmpResults].IndicatorValueFROM (SELECT GeographicEntityName FROM @tmpResults [@tmpResults] GROUP BY GeographicEntityName HAVING (COUNT(DISTINCT GeographicEntityId) = 1)) tblNonDuplicated RIGHT OUTER JOIN @tmpResults [@tmpResults] ON tblNonDuplicated.GeographicEntityName = [@tmpResults].GeographicEntityNameORDER BY [@tmpResults].[Year], tblNonDuplicated.GeographicEntityName--Sort out all Output ParamsSELECT @IndicatorChangeTitle = IndicatorChangeTitleFROM tblIndicatorsWHERE (IndicatorId = @IndicatorId)SELECT @NumberOfYears = COUNT(DISTINCT [Year]), @NumberOfGeographicEntities = COUNT(DISTINCT GeographicEntityId)FROM @tmpResults |
|
|
pootle_flump
1064 Posts |
Posted - 2006-08-23 : 08:20:00
|
I've had this problem (sproc suddenly becomes a problem for the client. Put the exact same command in QA and runs perfectly). I sorted it out pretty easily and so can only offer an unverified theory (you don't tend to investigate further once fixed). The cached plan for the sproc used by the client is no longer optimal (as they tend to become). For some reason the server generates a new plan for the sproc call from QA even if the call is, to all intents and purposes, identical. I just got the plan to be recreated next run and it this has sorted the problem the half dozen times or so it has happened to me.EXEC sp_recompile spSelectChangeResultsHope this helps out |
|
|
pootle_flump
1064 Posts |
Posted - 2006-08-23 : 08:32:34
|
quote: Originally posted by MartinSmith I'm unsure whether this or the resultant recompile made the difference but all started working well again.
Oops missed this bit.I think it is that simple. I forgot to mention that the first few times I got this it was using Access paa throughs. You have to pass a SQL string so a copy and paste to QA guarentees the string is identical. I first tried adding WITH RECOMPILE on the end and this caused the query to run at normal speed. That's what led me to changing the cached plan. |
|
|
spirit1
Cybernetic Yak Master
11752 Posts |
|
pootle_flump
1064 Posts |
Posted - 2006-08-23 : 08:40:09
|
quote: Originally posted by spirit1 you're probably experiencing what is known as parameter sniffing.http://blogs.msdn.com/khen1234/archive/2005/06/02/424228.aspx
The crux of this problem (as I've always seen it) is not why a query runs poorly or smoothly, but why it runs well from one app submitting a string and poorly from another app submitting the same string.Parameter sniffing is when the server creates a plan that is optimal for the set of parameters provided at compile time but not optimal for a subsequent call using different parameters. This (I would expect) would be application independent.Does that make sense? |
|
|
MartinSmith
Starting Member
17 Posts |
Posted - 2006-08-25 : 15:59:22
|
Thanks for the responses and the Parameter sniffing link. Useful to know.In that case does it store different versions of the execution plan concurrently depending on options such as arithabort? |
|
|
dashman
Starting Member
1 Post |
Posted - 2009-02-25 : 15:53:40
|
I had a similar issue. What I did was add with recompile to my stored procedure that was having the problem as I found that it was using one of the parameters in a like clause. I believe this was causing the executed plan to provide varying results passed on parameter information.Forcing recompilation at the prodedure level seemed to resolve the issue. |
|
|
SwePeso
Patron Saint of Lost Yaks
30421 Posts |
Posted - 2009-02-25 : 16:16:23
|
Also don't use table variables if you expect the data to fill more than one page. E 12°55'05.63"N 56°04'39.26" |
|
|
|