Я получаю ошибку SQL Server:
Произошла ошибка транспортного уровня при получении результатов сервер. (поставщик: общая память Провайдер, ошибка: 0 - Ручка недействительным.)
Я запускаю Sql Server 2008 SP1, Windows 2008 Standard 64 бит.
Это веб-приложение .NET 4.0. Это происходит, когда запрос поступает на сервер. Это прерывисто. Любая идея, как я могу ее решить?
Соединение с базой данных закрывается сервером базы данных. Соединение остается действительным в пуле подключений вашего приложения; в результате, когда вы берете общую строку соединения и пытаетесь выполнить ее, вы не сможете добраться до базы данных. Если вы разрабатываете Visual Studio, просто закройте временный веб-сервер на панели задач.
Если это происходит в процессе производства, сброс пула приложений для вашего веб-сайта должен переработать пул соединений.
Попробуйте выполнить следующую команду в командной строке:
netsh interface tcp set global autotuning=disabled
Это отключает возможности автоматического масштабирования сетевого стека
Для тех, кто не использует IIS, у меня была эта проблема при отладке с Visual Studio 2010. Я закончил все процессы отладчика: WebDev.WebServer40.EXE, который решил проблему.
У меня была та же проблема. Я перезапустил Visual Studio и исправил проблему
Все, что вам нужно, это остановить сервер разработки ASP.NET и снова запустить проект
Получил это, всегда после приблизительно 5 минут работы. Расследовали и обнаружили, что предупреждение от e1iexpress всегда происходило до сбоя. По-видимому, это ошибка, связанная с некоторыми адаптерами TCP/IP. Но переход от WiFi к проводному не повлиял на него.
Итак, попробовал Plan B и перезапустил Visual Studio. Затем он работал нормально.
В ближайшем исследовании я заметил, что при правильной работе сообщение The Thread '<No Name>' has exited with code 0 произошло почти точно в момент, когда в предыдущих попытках произошел сбой. Некоторые из Google Google показывают, что это сообщение появляется, когда (среди прочего) сервер обрезает пул потоков.
Предположительно, в пуле потоков был фиктивный поток, и каждый раз, когда сервер пытался "обрезать" его, приложение заняло.
Если вы подключены к базе данных через Microsoft SQL Server Management, закройте все свои подключения и повторите попытку. Если бы эта ошибка возникла при подключении к другой базе данных Azure и работала для меня, когда она была закрыта. Все еще не знаю, почему..
Вы получите это сообщение, когда ваш script заставляет SQL-службу останавливаться по некоторым причинам. поэтому, если вы снова запустите службу SQL, возможно, ваша проблема будет решена.
Ошибки уровня транспорта часто связаны с подключением к серверу sql, который прерывается... обычно в сети.
Время ожидания истекает, как правило, вызывается, когда SQL-запрос занимает слишком много времени.
Так мало вариантов:
Я знаю, что это может не помочь всем (кто знает, может быть, да), но у меня была такая же проблема, и через какое-то время мы поняли, что причиной является что-то из самого кода.
Компьютер, пытающийся связаться с сервером, находился в другой сети, соединение можно было установить, но затем удалить.
Как мы это исправили, было добавление статического маршрута к компьютеру, что обеспечило прямой доступ к серверу без прохождения через брандмауэр.
route add –p YourServerNetwork mask NetworkMask Router
Пример:
route add –p 172.16.12.0 mask 255.255.255.0 192.168.11.2
Я надеюсь, что это поможет кому-то, лучше иметь это, по крайней мере, как подсказку, поэтому, если вы сталкиваетесь с этим, вы знаете, как его решить.
Я получил ту же ошибку в среде разработки Visual Studion 2012, остановил IIS Express и перезапустил приложение, он начал работать.
Посмотрите на блог MSDN, в котором описывается эта ошибка:
Удаление соединений
Пул соединений удаляет соединение из пула после того, как он долгое время простаивали, или если пул обнаруживает, что соединение с сервером было отключено.
Обратите внимание, что отключенное соединение может быть обнаружено только после попытки для связи с сервером. Если обнаружено соединение, которое не является более длинный подключенный к серверу, он помечен как недопустимый.
Недействительные подключения удаляются из пула соединений только тогда, когда они закрыты или возвращены.
Если соединение существует на сервере, который исчез, это соединение может быть выведено из пула, даже если пул соединений не обнаружил отключенное соединение и отметил его как недействительный.
Это так, потому что накладные расходы на проверку того, что соединение остается в силе, исключит преимущества наличия пула в результате чего произойдет еще одна поездка на сервер.
Когда это произойдет, первая попытка использовать соединение обнаружит что соединение было отключено, и выбрано исключение.
В основном то, что вы видите, это исключение в последнем предложении.
Соединение берется из пула соединений, приложение не знаю, что физическое соединение ушло, попытка его использования сделано в предположении, что физическое соединение все еще существует.
И вы получите свое исключение.
Есть несколько общих причин для этого.
- Сервер был перезапущен, это приведет к закрытию существующих подключений.
В этом случае просмотрите журнал SQL Server, который обычно находится по адресу: C:\Program Files\Microsoft SQL Server\\MSSQL\LOG
Если отметка времени для запуска очень недавно, мы можем подозревать, что это и послужило причиной ошибки. Постарайтесь сопоставить эту метку времени с время исключения.
2009-04-16 11: 32: 15.62 Server Logging Сообщения SQL Server в файле 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\ERRORLOG.
- Кто-то или что-то убил используемый SPID.
Снова загляните в журнал SQL Server. Если вы найдете убийство, попробуйте сопоставить эту метку времени со временем исключения.
2009-04-16 11: 34: 09.57 идентификатор процесса spidXX XX был убит имя хоста xxxxx, идентификатор хост-процесса XXXX.
- Повторите попытку (например, в зеркальной настройке), загляните в журнал SQL Server.
Если происходит переход на другой ресурс, попробуйте сопоставить эту метку времени с временем исключения.
2009-04-16 11: 35: 12.93 spidXX Зеркальная база данных "меняет роли от" PRINCIPAL "до" MIRROR" из-за Failover.
У меня была такая же проблема. Я решил это, обрезая SQL Server LOG. Проверьте это, а затем сообщите нам, если это решение вам помогло.
Для меня ответ заключается в том, чтобы обновить ОС с 2008 года2 до 2012 года2, решение iisreset или перезапустить приложение не сработало для меня. Я также попытался включить параметр TCP Chimney Offload, но я не перезапустил сервер, потому что это производственный сервер, который тоже не работает.
Для меня решение было совершенно другим.
В моем случае у меня был объект objectsource, который требовал параметр datetimestamp. Несмотря на то, что этот параметр ODS ConvertEmptyStringToNull был истинным, 1/1/0001 передается SelectMethod. Это, в свою очередь, вызвало исключение переполнения sql datetime, когда это datetime было передано серверу sql.
Добавлена дополнительная проверка для datetime.year!= 0001, и это решило для меня.
Странно, что это вызовет ошибку транспортного уровня, а не ошибку переполнения datetime. В любом случае..
Мы столкнулись с этой ошибкой недавно между нашим бизнес-сервером и нашим сервером базы данных. Решение для нас состояло в том, чтобы отключить "Разделение IP-адресов" на сетевых интерфейсах. Затем ошибка исчезла.
Одна из причин, по которой я нашел эту ошибку, - " Packet Size = xxxxx" в строке подключения. если значение xxxx слишком велико, мы увидим эту ошибку. Удалите это значение и позвольте серверу SQL обрабатывать его или поддерживать его на низком уровне, в зависимости от сетевых возможностей.
Это случилось со мной, когда я пытался восстановить базу данных SQL и проверил следующий флажок в закладке Options,
Поскольку это отдельный сервер базы данных, просто закрывающий SSMS и возобновляющий его, решил проблему для меня.
В моем случае служба сервера SQL Server остановлена. Когда я перезапустил службу, которая позволила мне запустить запрос и устранить ошибку.
Также неплохо изучить ваш запрос, чтобы узнать, почему запрос остановил эту службу
Это происходит, когда база данных удаляется и воссоздается, некоторые общие ресурсы по-прежнему считают, что база данных по-прежнему существует, поэтому, когда вы повторно запускаете запрос выполнения для создания таблиц в базе данных после его восстановления, ошибка не будет отображаться и сообщение Command(s) completed successfully. будет отображаться вместо сообщения об ошибке Msg 233, Level 20, State 0, Line 0 A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.).
Просто игнорируйте эту ошибку, когда вы бросаете и воссоздаете базы данных и повторно выполняете свои DDL-запросы без каких-либо проблем.
Недавно я столкнулся с той же проблемой, но я не смог получить ответ в google. Поэтому подумал о том, чтобы поделиться им здесь, чтобы он мог помочь кому-то в будущем.
Ошибка:
Во время выполнения запроса запрос будет содержать несколько выходных данных, тогда он будет вызывать ошибку ниже.
"Ошибка транспортного уровня произошла при получении вывода из server (TCP: поставщик, ошибка: 0 - указанное сетевое имя больше не доступны"
Решение: