Помилка рівня транспорту сталася при отриманні результатів від сервера [закрито]

Я отримую помилку SQL Server:

Під час отримання результатів від сервера сталася помилка на транспортному рівні. (постачальник: Постачальник спільної пам’яті, помилка: 0 - ручка недійсна.)

Я використовую 64-бітний сервер Sql Server 2008 SP1, Windows 2008 Standard.

Це веб-додаток .Net 4.0. Це відбувається, коли запит робиться на сервер. Це переривчасте. Будь-яка ідея, як я можу це вирішити?

З'єднання з базою даних закривається сервером баз даних. З'єднання залишається дійсним у пулі з'єднань вашого додатка; як результат, коли ви підбираєте спільну рядок з'єднання та намагаєтесь виконати, вона не може дійти до бази даних. Якщо ви розробляєте Visual Studio, просто закрийте тимчасовий веб-сервер на панелі завдань.

Якщо це трапляється у виробництві, для скидання пулу додатків для вашого веб-сайту слід переробити пул зв’язків.

Спробуйте в командному рядку наступну команду:

netsh interface tcp set global autotuning=disabled

Це вимикає можливості автоматичного масштабування мережевого стеку

У мене була така ж проблема. Я перезапустив Visual Studio, і це вирішило проблему

Для тих, хто не використовує IIS, у мене виникла ця проблема під час налагодження з Visual Studio 2010. Я закінчив усі процеси налагодження: WebDev.WebServer40.EXE, які вирішили проблему.

Помилки рівня транспорту часто пов'язані з тим, що з'єднання з сервером sql порушено ... зазвичай мережу.

Час вичерпання закінчується, як правило, кидається, коли запит sql запускається занадто довго.

Отож мало варіантів може бути:

1. Перевірте наявність з'єднання в VPN (якщо використовується) чи будь-якому іншому інструменті
2. Перезапустіть IIS
3. Перезавантажте машину
4. Оптимізуйте запити sql.

Все, що вам потрібно - це зупинити сервер розвитку ASP.NET і запустити проект ще раз

Якщо ви підключені до своєї бази даних за допомогою Microsoft SQL Server Management, закрийте всі підключення та повторіть спробу. Була ця помилка під час підключення до іншої бази даних Azure і працювала для мене, коли її закривали. Досі не знаю, чому ..

Отримував це, завжди, приблизно через 5 хвилин роботи. Досліджували та з’ясували, що попередження від e1iexpress завжди виникало перед збоєм. Це, мабуть, помилка, пов'язана з певними адаптерами TCP / IP. Але перехід з WiFi на жорсткий провід не вплинув.

Тому спробував План B і перезапустив Visual Studio. Тоді це спрацювало чудово.

При більш детальному дослідженні я помітив, що при правильній роботі повідомлення The Thread '<No Name>' has exited with code 0виникало майже в той самий час, коли запуск попередніх спроб зазнав краху. Деякі Googling виявляють, що це повідомлення з'являється, коли (серед іншого) сервер обробляє пул потоків.

Імовірно, в пулі потоків була хибна нитка, і кожен раз, коли сервер намагався "обрізати" його, він знімав додаток.

Подивіться на блог MSDN, в якому детально викладено цю помилку:

Видалення з'єднань

Пуллер з'єднання видаляє з'єднання з пулу після того, як він довго не працює, або якщо пулер виявить, що з'єднання з сервером було розірвано.

Зауважте, що розірване з'єднання можна виявити лише після спроби спілкування з сервером. Якщо знайдено з'єднання, яке більше не підключено до сервера, воно позначається як недійсне.

Недійсні з'єднання видаляються із пулу з'єднань лише тоді, коли вони закриті або відновлені.

Якщо з'єднання існує з сервером, який зник, це з'єднання можна вивести з пулу, навіть якщо пул з'єднання не виявив розірване з'єднання і позначив його як недійсне.

Це так, оскільки накладні перевірки того, що з'єднання все-таки є дійсним, позбавлять від переваг наявності пулера, викликаючи чергову поїздку в обидва кінці до сервера.

У цьому випадку перша спроба використання з'єднання виявить, що з'єднання було розірвано, і викинуто виняток.

В основному те, що ви бачите, - це виключення в останньому реченні.

З'єднання береться з пулу з'єднань, програма не знає, що фізичне з'єднання відсутнє, спроба його використання робиться за умови, що фізичне з'єднання все ще існує.

І ви отримуєте своє виняток.

Для цього є кілька загальних причин.

1. Сервер був перезапущений, це закриє існуючі з'єднання.

У цьому випадку подивіться журнал SQL Server, який зазвичай знаходиться за адресою: C: \ Program Files \ Microsoft SQL Server \\ MSSQL \ LOG

Якщо часова мітка для запуску зовсім недавня, то ми можемо підозрювати, що саме це спричинило помилку. Спробуйте співвіднести цю мітку часу з часом виключення.

2009-04-16 11: 32: 15.62 Реєстрація сервера Повідомлення SQL Server у файлі 'C: \ Програмні файли \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ LOG \ ERRORLOG'.

2. Хтось чи щось убив SPID, який використовується.

Знову загляньте в журнал SQL Server. Якщо ви виявили вбивство, спробуйте співвіднести цю часову позначку з часом виключення.

2009-04-16 11: 34: 09,57 Ідентифікатор процесу spidXX XX був убитий іменем хоста xxxxx, ідентифікатором хост-процесу XXXX.

3. Знову виникає відмова (наприклад, у програмі дзеркала), подивіться у журнал SQL Server.

Якщо є відмова, спробуйте співвіднести цю часову позначку з часом виключення.

2009-04-16 11: 35: 12,93 spidXX Дзеркальна база даних "" змінюється ролями з "ПРИНЦИПАЛЬНОГО" на "Дзеркальне відображення" через відмову.

Це повідомлення ви отримуєте, коли ваш сценарій зупиняє службу 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 і перезапустив програму, вона почала працювати.

У моєму випадку сервер сервера "SQL Server" припинився. Коли я перезапустив службу, яка дозволила запустити запит та усунути помилку.

Також хороша ідея вивчити ваш запит, щоб з’ясувати, чому запит зупинив цю послугу

У мене було те саме питання. Я вирішив це, обрізаючи лог SQL Server. Перевірте це, а потім повідомте нам, чи допомогло вам це рішення.

Для мене відповідь - оновити ОС з 2008R2 до 2012R2, рішення iisreset або перезапустити apppool не працювало для мене. Я також намагався змінити налаштування TCP Chimney Offload, але я не перезапустив сервер, оскільки це виробничий сервер, який також не працював.

Для мене рішення було зовсім іншим.

У моєму випадку у мене був ресурс об'єктів, який вимагав параметра datetimestamp. Навіть незважаючи на те, що параметр ODS ConvertEmptyStringToNull був істинним, 1/1/0001 передавались SelectMethod. Це в свою чергу спричинило виняток переповнення дати sql, коли цей час передано на сервер sql.

Додано додатковий чек на datetime.year! = 0001 і це вирішило це для мене.

Дивно, що це призведе до помилки транспортного рівня, а не до помилки переповнення дати. Все одно ..

Нещодавно ми зустріли цю помилку між нашим бізнес-сервером та нашим сервером баз даних. Рішенням для нас було відключити "IP Offloading" на мережевих інтерфейсах. Потім помилка пішла.

Однією з причин, за якою я виявив цю помилку, є « Розмір пакета = xxxxx » у рядку з'єднання. якщо значення хххх занадто велике, ми побачимо цю помилку. Або видаліть це значення, і дозвольте SQL-серверу обробляти його або тримати його низьким, залежно від можливостей мережі.

Це трапилося зі мною, коли я намагався відновити базу даних SQL і поставив прапорець "Встановити прапорець" у Optionsвкладці,

Оскільки це окремий сервер бази даних, просто закриття SSMS та його повторне відкриття вирішили проблему для мене.

Це відбувається, коли база даних відкидається і знову створені деякі спільні ресурси, як і раніше вважає, що база даних все ще існує, тому при повторному запуску виконання запиту для створення таблиць у базі даних після її повторного створення помилка не з’явиться знову і 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. Тому подумайте поділитися цим сюди, щоб це могло допомогти комусь у майбутньому.

Помилка:

Під час виконання запиту запит дасть небагато результатів, то він знизить нижче помилки.

"Помилка транспортного рівня сталася при отриманні виводу з сервера (TCP: постачальник, помилка: 0 - вказане мережеве ім'я більше недоступне"

Рішення:

1. Перевірте постачальника цього пов'язаного сервера
2. У властивостях цього постачальника увімкніть для цього конкретного постачальника варіант "Дозволити процес" для вирішення проблеми.