Прерывистое исключение SQL - ошибка, связанная с сетью или экземпляром

Question

У нас есть очень странная, периодически возникающая проблема, которая начала появляться в течение последнего месяца или около того, в результате чего некоторые подключения к серверу mssql завершаются с ошибкой:

System.Data.SqlClient.SqlException: 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: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

Ошибка не приводит к сбою сайта и не требует перезапуска базы данных - если вы просто перезапустите тот же запрос, он будет работать во второй раз. Это означает, что многие пользователи время от времени сталкиваются с ошибками, и им приходится обновлять страницу ошибок, чтобы все работало.

Теперь, моя первоначальная реакция на коленный рефлекс была такой:

1. Проблема, связанная с ресурсами - поэтому я начал запускать SQL profiler и perfmon, но не обнаружил никаких проблем с обслуживанием, изо всех сил пытающихся не отставать от количества соединений / сек. Я смотрю на MSSQL: ошибки SQL, MSSQL: статистика ожидания, MSSQL: статистика Exec, MSSQL: блокировки. У кого-нибудь есть какие-либо рекомендации по поводу других характеристик, которые я должен здесь высовывать и подталкивать?

2. Незакрытые соединения с БД - я исключил это после прохождения всего кода уровня данных. У нас есть все сейфы, чтобы не допустить этого.

3. Проблема, связанная с подключением / сетью: наш SQL-сервер расположен на отдельном сервере (MS SQL Server Standard 2008) для нашего сервера приложений (на ASP.Net на IIS7) - оба сервера работают на больших экземплярах Amazon EC2 со всеми настроены политики безопасности (согласно направлению Amazons). Кто-нибудь получил руководство о том, как проверить соединение между двумя серверами или это может быть проблемой?

4. Возможна ли проблема со строкой подключения IIS? Я не проверял это, но мы должны полностью квалифицировать сервер с именем компьютера, к которому мы подключаемся (только подумал)? Мы используем строку подключения в формате: server=xxxxx;Database=xxxx;uid=xxxx;password=xxx;

Ваши мысли и проницательность очень ценятся!

Заранее спасибо

Answer 1

решаемая.После тестирования почти всех возможных метрик производительности и изучения каждого фрагмента кода я обнаружил, что ошибка вызвана небольшим количеством устаревшего кода базы данных.Основная проблема была вызвана использованием кода:

SqlConnection.ClearPools;

. Для дальнейшего использования, если вы захотите отладить свой код и управлять пулами подключений, отличный ресурс можно найти здесь: http://www.codeproject.com/KB/dotnet/ADONET_ConnectionPooling.aspx

Answer 2

Попробуйте изменить строку подключения на FQDN + порт

server=xxxxx.domain.tld,1234;

Примечание: вам не нужно имя экземпляра, если вы используете порт

В нашей глобальной корпоративной интрасети ...у нас была похожая проблема, которая случалась с удаленными клиентами: чаще, если они были дальше, никогда не в том же здании, что и сервер.

После некоторого возни, беседы с администраторами баз данных и MS, это было вызвано синхронизацией / Kerberos / слишком большим количеством брандмауэров и т. Д. Добавление порта FQDN + устранило все наши проблемы.

Answer 3

Кажется, что соединение закрывается неправильно, и через некоторое время вы не можете открыть больше новых соединений.Поскольку общее количество разрешенных соединений с базой данных является постоянной цифрой.

Если вы используете C # / VB.net

Используете ли вы операторы " Using " для открытия соединений?

using (System.Data.SqlClient.SqlConnection con = new SqlConnection("YourConnection string")) 
{ 
    con.Open(); 
}

Answer 4

Это может быть решено переключением на TCP / IP вместо именованных каналов, если вы можете. Возможно, вы можете проверить это, изменив имя сервера на IP-адрес сервера.

Я использую server = tcp: servername в моей строке подключения для принудительного TCP. KB313295