I have the following scenario:
After a database deployment we have a .Net application server that is attempting to execute a stored procedure.
The timeout on the application is 30 seconds. When the application first attempts to execute the stored proc an attempt is made to create a new query plan but this takes longer than 30 seconds and the application has many timeouts. My experience with this is that if the stored procedure is run manually(with representative data inputs) from SSMS the first time it runs it takes about 1-2 minutes, a plan gets generated and then the application then runs smoothly.
I work with a third party company and there is s DBA there who is claiming the following:
"Manually invoking this stored procedure will create a plan that is specific to the connection properties used (SSMS), the plan generated would not be used when the procedure is invoked by an application server."
Is this correct? It seems like a poor design if query plan used was linked to connection properties? Is there a difference between a query plan created if you run the stored procedure manually in SSMS vs when it is executed by an application?
If so, What is the optimal way to resolve this issue? Is increase the timeout the only option?
Related
I have 5 stored procedures, called by an api, that run in under 100 ms normally, but intermittently, all the stored procedures suddenly take > 10 seconds in production. We did stress test before going live and it was all good during stress test.
For each of the stored procedures, I capture start time using SYSDATETIME() and log it an table at the end of the stored procedure with end time as well. So I run profiler on production and notice strange things.
For example, today, profiler RPC:completed event start time is 09:18:04.680 where as my stored procedure execution log tables says the execution started at 09:19:54.288. So there is a 110second mismatch between profiler execution start vs my stored procedure internal start time. So this happens to all stored procedures for a window of 2-3mins and everything clears by itself.
I've ran perfmon and nothing shows out of ordinary to me. The SQL Server has high capacity with the application only running few users currently so not a very high traffic application.
I also have Redgate SQL Monitor and it doesn't show any abnormal wait times.
I'm not even sure where to look for. I'm not sure its parameter sniffing because one of the stored procedure affected doesn't accept any parameters. After the 2-3 minutes all the stored procedures run as expected.
Environment:
ASP.NET MVC 5.2.3.0
SQL Server 2014 (v12.0.2000.8)
Entity Framework 6
hosted on Azure
We have one page that gets data from the database using a stored procedure.
Lately we’ve noticed that some time this page loads about 20 secs. So we started to investigate the problem. I’ve tried to execute this stored procedure directly from Management Studio and it took 150 ms+-:
So next thing I did is create a console application that connects to the Azure SQL database and executes this stored procedure:
I've also tried to use SqlQuery from EF 6:
Same thing.
Important thing: this is not permanent problem. Sometimes this problem occurs, sometimes it works just fine - 50/50.
I've checked the database load in the Azure portal - it is about 50% dtu usage (during this performance issue). But I don’t think this is related to database load because it executes fast from Management Studio.
Currently I have no idea what is the problem so I need help. I would like to notice that a lot of employees use this page (that executes the stored procedure) all the time. Maybe this is somehow related to problem.
So question: why does it take so long to execute this stored procedure using ado.net / EF?
Do some debugging.
Potential culprits include, mostly:
Database side locking that is not released fast, making a SP waiting.
Parameter sniffing where a query path is not optimal for a specific set of parameters (which may lead to locking blocking you). This is a SP problem - someone does not write proper SQL for cases like that.
The info you give is irrelevant. See... SP's are NOT EXECUTED IN EF6 - EF6 fowrards them to ADO.NET which sends them to the database. As you say they work slow, IN THE DATABASE, any C# level debugging is as useless as the menu from my local Pizzeria for this particular question. YOu have to go down and debug and analyze what happens on the database.
The SSMS screenshot you provide is totally useless - you need to run the SP in SSMS, for a case it happens, and then use.... the query plan and proper nalaysis traces to see what happens.
I'm trying to execute a query from my application which is based on asp.net. I'm using ADO commands to execute a function in the Azure SQL database. My application has high traffic during the work hours and this particular query takes too long to execute and eventually times out. I then have to use the below command to clear out the cache which fixes the issue temporarily:
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;
the query takes less than a second to execute from SSMS. After clearing the cache by using the above command, it works fine for a few days then the issue comes back.
Can someone help me understand what's the correlation between clearing cache and execution time in the asp.net application. How can I fix it permanently?
I have VBS called stored procedures starting but not completing and returning query timeout messages to the application.
We are on SQL Server 2008 SP2 release 1, Windows Server 2008 R2 Standard.
This is not an issue in production, but in dev we have VBS scripts associated with the DrillThrough database producing:
VBS<105,4> Microsoft OLE DB Provider for SQL Server: Query timeout expired.
These scripts are automated on the application server side. The stored procedure queries run fine in SSMS but do take over 40 seconds.
ALL the scripts are all set not to timeout:
conn.ConnectionTimeout = 0
conn.CommandTimeout = 0
The OLEDB login is the dbo. The only scripts failing are on the DrillThrough database. The failing scripts use more than one database and functions in the DrillThrough database to gather data in temp tables to update the actual drill through table.
There is one nightly process that is completing on the DrillThrough database where the stored procedure runs in about 2 seconds. It does not use any functions but does compare data from two records pulled from two other databases before writing the difference to a table.
I have compared the scripts and they are set up the same except for the stored procedures they call.
I updated statistics on the tables just in case. The query still timed out on the application side, and actually took a little longer to run in SSMS.
The SQL Server remote connections is set to 0 for no timeout.
It definitely gets into the procedure because it truncates the tables, bulk loads the holding table and deletes from the actual drill through table based on the holding table data and creates the first temp table but it is not completing and is dropping out somehow.
Again, the stored procedure runs fine in SSMS all the way through.
Everyone refers back to the SQL Server setting and the ConnectionTimeout and CommandTimeout. No one seems to be experiencing a situation where the stored procedure starts but doesn’t complete.
Other things I’ve tried with the same results:
Adding ‘With Recompile’ to the stored procedure
Setting an actual timeout time in the VB Script
I have tuned the query as much as I can
I can't get a faster development server.
We are getting timeout issues on our databases. So I trurned on SQL Server Profiler and see SQLQueryNotificationService running every second with long duration. I checked the Service Broker and there are bunch of SQLQueryNotificationService queues created. I don't think we created any of these queues also there are bunch of stored procedures like these SqlQueryNotificationStoredProcedure-15c5b84b-42b0-4cfb-9707-9b1697f44127. Could you please let me know how to drop them? If I drop them is there any impact on the database? Please let me know. I appreciate any suggestions.
Do you have an ASP.Net web site running or another application that creates Sql Server Cache dependencies? It is Sql Server Service Broker queues, it executes that WAITFOR ... statement which waits for around one minute (60000 msecs), then executes again next second. Shouldn't normally cause problems, it shouldn't block or delay your "normal" queries or stored procedures.
However, I saw it causing issues for me once - one of the stored procedures, when executed from the same web application that established the cache dependency, did timeout (or rather came back in 120 secs which is not acceptable). Exactly the same stored procedure, executed under the same account with same parameters, but from Management Studio, ran fine without any issues. It was SQL Server 2005 SP4.
SQL Profiler showed that in the middle of execution of my stored procedure (and always after the same INSERT INTO ... statement), its execution was interrupted and instead of its statement there was that WAIT FOR .... from Sql Query Notification, completed in one minute, then another WAIT FOR... starting and again, completed in 59 secs - and only after that the Profiler showed me my stored procedure completed. With the duration of 119000, which is almost exactly two minutes.
It was if that query notifications were joining the transaction within my stored procedure.
What helped: recompiled the offending stored procedure. I simply changed its script, did ALTER statement with some minor syntax changes. No problems after that.