SQL Server «ошибка, связанная с сетью или экземпляром», один раз в день (недоумение!) - PullRequest
Новая
       25

SQL Server «ошибка, связанная с сетью или экземпляром», один раз в день (недоумение!)

4 голосов
/ 19 января 2012

Мы наблюдаем ту же ошибку, что и этот StackOverflow Q ... 

System.Data.SqlClient.SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)
   at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
   at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
   at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
   at System.Data.SqlClient.SqlConnection.Open()
   at System.Data.Linq.SqlClient.SqlConnectionManager.UseConnection(IConnectionUser user)
   at System.Data.Linq.SqlClient.SqlProvider.get_IsSqlCe()
   at System.Data.Linq.SqlClient.SqlProvider.InitializeProviderMode()
   at System.Data.Linq.SqlClient.SqlProvider.System.Data.Linq.Provider.IProvider.Execute(Expression query)

... за исключением того, что в указанном StackOverflow Q они должны перезапустить SQL Server, как только произойдет ошибка, а мы нет. Мы получим эту ошибку один раз в день или раз в несколько дней - и все хорошо после того, как ошибка произошла, до следующего раза.

Это заставляет нас думать, что это не проблема "забыли закрыть соединения". У нас есть умеренно загруженное приложение ASP.NET 4.0 WebForms / SQL Server 2008 R2; но мы вполне уверены, что не превышаем максимальное число соединений с базой данных.

Есть мысли по этой проблеме или подход к диагностике?

1 Ответ

2 голосов
/ 02 февраля 2012

Думаю, я бы прокомментировал наш прогресс в этом.

Хотя ни в одной из документации / статей / блогов по SQL Server не упоминается, что эта ошибка может быть вызвана занятостью сервера , я обнаружил сообщение на форуме , где некоторые опытные ИТ-специалисты по имени Мэтт Неринкс утверждает, что может быть следующим: 

Possible reasons for this error include:

1. Poor network link from client to server.

2. Server is very busy (meaning high CPU) and cannot respond to new connection attempts.

3. Server is running out of memory (so high memory usage for SQL).

4. tcp-ip layer on client is over-saturated with connection attempts so tcp-ip layer rejects the connection.

5. tcp-ip layer on server side is over-staturated with connection attempts and so tcp-ip layer is rejecting new connections.

6. With SQL 2005 SP2 and later there could be a custom login trigger that rejects your connection.

You can increase the connect timeout to potentially alleviate issues #2, #3, #4, #5.  Setting a longer connect timeout means the driver will try longer to connect and may eventually succeed.

To determine the root cause of these intermittent failures is not super easy to do unfortunately.  What I normally do is start by examining the server environment, is the server constantly running in high CPU for example, this points to #2.  Is the server using a hugh amount of memory, this points to #3.   You can run SQL Profiler to monitor logins and look for patterns of logins, perhaps every morning at 9AM there is a flurry of connections etc...

Таким образом, в настоящее время мы идем по этому пути - уменьшаем количество запросов, выполняемых одновременно в некоторых наших пакетных запросах, оптимизируем некоторые из наших запросов и т. Д.

Кроме того, в строке подключения нашего приложения мы увеличили тайм-аут подключения и установили Min Pool Size равным 20 (считая целесообразным попытаться обеспечить некоторые существующие, неиспользуемые подключения для захвата приложения, а не устанавливать новое соединение).

В этот момент прошло почти 48 часов без получения ошибки; делает нас очень обнадеживающими.

...