August 22, 2014 at 3:07 am
Sometime following stored procedure suddenly taking 10 seconds when we called through application.
CREATE PROCEDURE TestStatus
AS
BEGIN
SELECT1 AS [StatusCount]
END
At that time memry pressure and cpu pressure is not so high. And our production environment is on VMWare.
can you please guide me why it takes 10 seconds.
Thanks in advance..
August 22, 2014 at 7:15 am
patelchandresh330 80387 (8/22/2014)
Sometime following stored procedure suddenly taking 10 seconds when we called through application.CREATE PROCEDURE TestStatus
AS
BEGIN
SELECT1 AS [StatusCount]
END
At that time memry pressure and cpu pressure is not so high. And our production environment is on VMWare.
can you please guide me why it takes 10 seconds.
Thanks in advance..
I suspect that isn't your actual procedure code?
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
August 22, 2014 at 7:20 am
patelchandresh330 80387 (8/22/2014)
Sometime following stored procedure suddenly taking 10 seconds when we called through application.CREATE PROCEDURE TestStatus
AS
BEGIN
SELECT1 AS [StatusCount]
END
At that time memry pressure and cpu pressure is not so high. And our production environment is on VMWare.
can you please guide me why it takes 10 seconds.
Thanks in advance..
If that's your actual code, then there are a thousand reasons.
If your code is a bit more sophisticated and takes parameters, then possibly parameter sniffing of initial caching.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 22, 2014 at 7:30 am
I also noticed that the OP doesn't mention the normal time it takes to run. It's possible that 10 seconds could actually be an improvement. Things inexplicably running better can be as puzzling as them slowing down.
How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537
August 22, 2014 at 8:37 am
Jeff Moden,
This is the actual code, we used this stored procedure to check connection to the database and this is also taking 10 seconds sometimes. and also other SP which have business logic taking 10 seconds..
so from where we start to troublshooting..
August 25, 2014 at 12:04 pm
Please check if there are network issues. Try running the same query directly on the server & retrieve the time
September 3, 2014 at 4:36 pm
patelchandresh330 80387 (8/22/2014)
Jeff Moden,This is the actual code, we used this stored procedure to check connection to the database and this is also taking 10 seconds sometimes. and also other SP which have business logic taking 10 seconds..
so from where we start to troublshooting..
My apologies for the late reply.
The first step, if you already haven't done so, is to log into the server itself, fire up SSMS, and execute that proc. If it takes longer than 0 ms the second time you run it, then something is seriously wrong with the server.
Next stepSET STATISTICS TIME,IO ON;
EXEC dbo.TestStatus;
SET STATISTICS TIME,IO OFF;
The next step (after logging off the server), would be to do the same thing from a local desktop looking for not only the same results, but also checking how long it takes from the time you punch the execute button until you get a return. If it's a lot slower, it could be your machine or something on the network. Try the same thing from a couple of machines. If there's no appreciable delay, it could be the app/webserver or the network connection from those to the server or it could be those other machines are IO saturated.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 4, 2014 at 2:14 am
Jeff Moden,
we replaced #table to @table in stored procedure.. it works for 2 days. and suddenly it started to taking more then 10 seconds.
if we execute from Java application then only it behave like this.. in "SQL Performance Dashboard" shows top 20 CPU Pressure.. whithin that showing me one of the sql statement of same SP.
but if i excecutes it from SQL Server 2012 SSMS it takes 0 to 1 seconds only.
Please guide me..
Thanks in Advanced
//
September 5, 2014 at 7:42 am
You don't have #table or @table in your original post so it clearly isn't the whole procedure. Please post the full definition of the stored procedure and the definition of #table/@table.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply