SQL connection timeout

问题

We have been facing weird connection timeouts on one of our websites.

Our environment is composed of an IIS 7 web server (running on Windows Server 2008 R2 Standard Edition) and an SQL Server 2008 database server.

When debugging the website functionality that provokes the timeout, we notice that the connection itself takes milliseconds to complete, but the SqlCommand, which invokes a stored procedure on the database, hangs for several minutes during execution, then raises the timeout exception.

On the other hand, when we run the stored procedure directly on the database, it takes only 2 seconds to correctly finish execution.

We already tried the following:

• Modified SqlCommand timeout on the website code
• Modified execution timeout on the web.config file
• Modified sessionState timeout on the web.config file
• Modified authorization cookie timeout on the web.config file
• Modified the connection timeout on the website properties on IIS
• Modified the application pool shutdown time limit on IIS
• Checked the application pool idle timeout on IIS
• Checked the execution timeout on the SQL Server properties (it's set to 0, unlimited)
• Tested the stored procedure directly on the database with other parameters

We appreciate any help.

Nirav

回答1:

I've had this same issue with a stored procedure that was a search feature for the users. I tried everything, include ARTIHABORT etc. The SP joined many tables, as the users could search on anything. Many of the parameters for the SP were optional, meaning they had a default value of NULL in the SP. Nothing worked.

I "fixed" it by making sure my ADO.NET code only added parameters where the user selected a value. The SP went from many minutes to seconds in execution time. I'm assuming that SQL Server handled the execution plan better when only parameters with actual values were passed to the SP.

Note that this was for SQL Server 2000.

回答2:

A few years ago I had a similar problem when migrating an app from SQL2000 to SQL2008.

I added OPTION (RECOMPILE) to the end of all the stored procs in the database that was having problems. In my case it had to do with parameters that were very different between calls to the stored proc. Forcing the proc to recompile will force SQL to come up with a new execution plan instead of trying to use a cached version that may be sub-optimal for the new params.

And in case you haven't done it already, check your indexes. Nothing can kill db performance like lack of a badly needed index. Here is a good link (http://sqlfool.com/2009/04/a-look-at-missing-indexes/) on a query that will display missing indexes.

回答3:

Super-super late suggestion, but might come handy for others: A typical issue I saw and rather applicable to Java is the following:

You have a query which takes a string as a parameter. That string is search criterion on a varchar(N) column in the database. however, you submit the string param in the query as Unicode (nvarchar(N)). This will result in a full-table scan and conversion of every single field values to Unicode for proper comparison, to avoid potential data loss (if SQL Server converted the input param to non-Unicode, it may lose information).

Simple test: run the query twice (for the sake of simplicity, I'm assuming it's an SP):

exec spWhatever 'input'
exec spWhatever N'input'

See how they behave. Also, you may want to take a look at the Recent Expensive Queries section on the Activity Monitor in SSMS and ask for the execution plan, to clarify the situation.

Cheers, Erik

来源：https://stackoverflow.com/questions/7230244/sql-connection-timeout