ADO.NET calling T-SQL Stored Procedure causes a SqlTimeoutException

前提是你 提交于 2019-11-27 11:55:33
crowleym

Once I determined that it is the ADO.NET connection at the root of the problem, this thread led me to the answer.

Basically connections through Sql Server Management Studio (SSMS) by default have SET ARITHABORT ON. ADO.NET connections do not.

Setting ARITHABORT OFF and executing the query directly through SSMS gives me the same slow response time.

The main difference when running with or without this setting is a different query plan is created for the two calls. When ARITHABORT was OFF, the SSMS command would use the pre-compiled cached query plan that the ADO.NET connection was using, and therefore timeout.

By running the following commands as administrator on the database all queries run as expected regardless of the ARITHABORT setting.

DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE

I can only assume a compiled query plan became corrupt, or invalid.

I will go with this as the solution (I have up-voted the answer) on the other thread

Thanks.

I stand corrected - yes, you CAN have both - an OUTPUT parameter as well as a set of rows being returned. You learn something new every day :-)

As to why a timeout happens - hmm.... hard to tell. A quickie little sample works fine for me. Can you post your stored proc (at least relevant bits of it)?

How many rows are we talking about, that get returned here?

At what point in your stored proc are you calculating the number of rows that you need to return back as OUTPUT parameter?

What if you try to add another parameter MaxRows to your one SProc as a test and do a SELECT TOP (@MaxRows)....... on your data? Does that return quickly?

Marc

In short - I fixed my issue by forcing SQL Server to use the most appropriate index to limit lob logical reads when it couldn't figure it out on its own.

In long -

I just ran into this issue and resolved it in a different way after trying all of the other suggested answers. In SSMS the query was running in ~3s, but was timing out when called from a .Net MVC web application.

Statistics IO output in SSMS was telling me that there were over 195,500,000 lob logical reads on one table (20M-row table with a clustered columnstore index and also has row indexes, but has no "LOB" columns). I noticed from the execution plan that a bulk of the load (76%) was coming from an index seek on one of the row indices. I used the following:

from [table] with (index([clustered columnstore index name]))

in my query to force the usage of the clustered columnstore index and my query was reduced to <1s and the lob logical reads dropped to <6k from >195M, and when calling the SP from the web app now, it is round-tripping in 1.3s.

I tried option recompile, set arithabort on, parameter sniffing, and in the end SQL Server just couldn't figure out which index to use. This is an edge case too btw, and the only time I have had to force an index in this database.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!