Что вызывает "Неустранимые ошибки внутреннего соединения"
У меня есть несколько сайтов ASP.Net(.Net v3.5), работающих на сервере с бэкэнд базы данных SQL 2000. В течение нескольких месяцев я получал, казалось бы, случайные InvalidOperationExceptions с сообщением "Внутренняя фатальная ошибка соединения". Иногда бывает несколько дней между ними, в то время как в других случаях есть несколько ошибок в день.
Исключение не ограничивается одним сайтом, в частности, хотя они совместно используют сборку данных и доступа к данным. Ошибка всегда выводится из SqlClient.TdsParser.Run(). Иногда он вызывается из вызовов SqlCommand.Execute() из старой школы, тогда как в других случаях он выдается из кода Linq2Sql.
Я был уверен, что сетевые ребята, что на их концах нет ошибок или пакетов. Кто-нибудь еще испытал это? Это может быть проблема с драйвером? Мы еще не смогли определить конкретный триггер для этого исключения.
Мы запускаем II6 на Windows Server 2003.
Ответы
Ответ 1
После нескольких месяцев игнорирования этой проблемы, он начал достигать критической массы, поскольку трафик постепенно увеличивался. При большой нагрузке, включая некоторых сканеров, все сошло с ума, и эти ошибки вылились в беспорядок.
Через пробную версию и ошибку мы в итоге выследили несколько запросов SqlCommand или LINQ, SqlConnection которых не был закрыт сразу после использования. Вместо этого через некоторое неаккуратное программирование, возникшее из-за непонимания соединений LINQ, объекты DataContext были расположены (и соединения закрыты) только в конце запроса, а не сразу.
Как только мы реорганизовали эти методы, чтобы немедленно закрыть соединение с блоком С# "using" (освободив этот пул для следующего запроса), мы не получили больше ошибок. Хотя мы до сих пор не знаем основной причины, по которой пул соединений будет настолько запутан, мы смогли прекратить все ошибки такого типа. Эта проблема была решена в связи с другой аналогичной ошибкой, опубликованной мной: Почему мой SqlCommand возвращает строку, когда она должна быть int?
Ответ 2
Похоже на то, что соединение с базой данных теряется или отключается.
Недавно у нас были аналогичные проблемы, связанные с IIS 6 из IIS 5, подключающимися к SQL 2000. Наша проблема была решена за счет увеличения количества доступных эфемерных портов.
Посмотрите на использование эфемерных портов сервером IIS. Значение по умолчанию max. доступных портов, как правило, 4000. Возможно, вам стоит подумать об увеличении этого, если сайты на вашем сервере особенно заняты или ваше приложение совершает много вызовов в базе данных.
Вы можете следить за этим первым, чтобы увидеть, превышает ли максимальный предел.
Найдите базу знаний Microsoft для "MaxUserPort" и "TcpTimedWaitDelay" и внесите необходимые изменения в реестр. Перед внесением изменений убедитесь, что вы создали резервную копию реестра или сервера моментальных снимков. Необходимо будет перезагрузить, чтобы изменения вступили в силу.
Вы должны дважды проверить, что ваша база данных и соединение с наборами записей закрываются после использования. Не закрытие будет использовать этот диапазон портов без необходимости.
Проверяйте эффективность ваших хранимых процедур в любом случае, поскольку они могут занять больше времени, чем нужно.
"Если вы быстро открываете и закрываете 4000 сокетов менее чем за четыре минуты, вы достигнете максимального значения по умолчанию для анонимных портов клиента, а новые попытки подключения к сокету провалится, пока не будет отключен существующий набор гнезд TIME_WAIT." - от http://support.microsoft.com/kb/328476
Ответ 3
Проверьте папку журнала сервера (\ program files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG или аналогичный) для файлов с именем SqlDump *.mdmp и SqlDump *.txt. Если вы найдете какие-либо данные, вам придется обратиться к службе поддержки продуктов.
