Occasionally, on a ASP (classic) site users will get this error:
[DBNETLIB][ConnectionRead (recv()).]General network error.
Seems to be random and not connected to any particular page. The SQL server is separated from the web server and my guess is that every once and a while the «link» goes down between the two. Router/switch issue… or has someone else ran into this problem before?
asked Sep 5, 2008 at 20:35
Using the same setup as yours (ie separate web and database server), I’ve seen it from time to time and it has always been a connection problem between the servers — typically when the database server is being rebooted but sometimes when there’s a comms problem somewhere in the system. I’ve not seen it triggered by any problems with the ASP code itself, which is why you’re seeing it apparently at random and not connected to a particular page.
answered Sep 6, 2008 at 3:49
I’d seen this error many times. It could be caused by many things including network errors too :).
But one of the reason could be built-in feature of MS-SQL.
The feature detects DoS attacks — in this case too many request from web server :).
But I have no idea how we fixed it :(.
answered Sep 5, 2008 at 23:29
Grzegorz GierlikGrzegorz Gierlik
11.1k4 gold badges45 silver badges55 bronze badges
SQL server configuration Manager
Disable TCP/IP , Enable Shared Memory & Named Pipes
Good Luck !
answered Sep 29, 2011 at 7:57
0
Not a solution exactly and not the same environment. However I get this error in a VBA/Excel program, and the problem is I have a hanging transaction which has not been submitted in SQL Server Management Studio (SSMS). After closing SSMS, everything works. So the lesson is a hanging transaction can block sprocs from proceeding (obvious fact, I know!). Hope this help someone here.
answered Jul 30, 2013 at 9:27
yangli.liyyangli.liy
1013 silver badges5 bronze badges
open command prompt — Run as administrator and type following command on the client side
netsh advfirewall set allprofiles state off
FishStix
4,9669 gold badges37 silver badges53 bronze badges
answered Oct 7, 2016 at 18:39
1
FWIW, I had this error from Excel, which would hang on an EXEC which worked fine within SSMS. I’ve seen queries with problems before, which were also OK within SSMS, due to ‘parameter sniffing’ and unsuitable cached query plans. Making a minor edit to the SP cured the problem, and it worked OK afterwards in its orginal form. I’d be interested to hear if anyone has encountered this scenario too. Try the good old OPTION (OPTIMIZE FOR UNKNOWN) 
answered Mar 14, 2018 at 17:13
AjV JsyAjV Jsy
5,7394 gold badges34 silver badges30 bronze badges
В большинстве случаев истинная причина периодически возникающей проблемы с подключением клиентского компьютера к удаленному серверу базы данных MS SQL Server связана с сетевым уровнем модели OSI. Собирая данные трассировки сети и анализируя их, мы можем сузить зону поиска и определить точную причину того, почему не удалось установить соединение или было внезапно разорвано существующее соединение.
Для большей наглядности предоставляемой информации в рамках данной статьи, мы дополнили ее пошаговыми иллюстрациями практического решения проблемы из реальной жизни. Проблема в предлагаемом нами кейсе заключалась в том, что клиент с определенной периодичностью получал сообщение GNE (General Network error, «Общая ошибка сети») от приложения, которое пыталось подключиться удаленно к серверу Microsoft SQL Server. Ниже приведен пример такого сообщения об ошибке:
«OleDB Error Microsoft OLE DB Provider for SQL Server [0x80004005][11] : [DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation».
После проведения некоторых стандартных начальных процедур по поиску неисправностей (таких как проверка, не была ли отключена функция разгрузки TCP chimney, или не было ли превышено значение установленного максимального количества соединений и т.д.) были в одно и то же время собраны сетевые трассировки, как с сервера приложений, так и с MS SQL server. Когда вы собираете трассировки сети, всегда соблюдайте следующие два правила:
- Используйте данные, полученные с помощью утилиты «ipconfig», запущенную с ключом «/all», со всех задействованных серверов.
- Ориентируйтесь на сообщения об ошибке с установленной временной меткой (timestamp). Если по какой-то причине сообщения об ошибке с временной меткой вам недоступны, попросите клиента сделать запись точного времени возникновения проблемы и отправить ее вам.
Далее мы детально, шаг за шагом рассмотрим, как были проанализированы собранные трассировки сети. Вы можете использовать подобные методы для анализа трассировок, собранных вами для решения периодически возникающих проблем с подключением к серверу SQL.
Для захвата и анализа трассировок вы можете использовать Wireshark, либо любой другой инструментарий с подобной функциональностью. В данном примере был использован Wireshark, поскольку трассировки, отправленные клиентом, не могли быть открыты другим инструментарием (это было связано с расширением полученных файлов).
IP-адреса и точное время возникновение проблемы
Для начала стоит проверить информацию, полученную с помощью утилиты ipconfig, чтобы узнать необходимые нам IP-адреса. В рассматриваемом примере они следующие:
«SQL server:
IP Address. . . . . . . . . . . . : 10.10.100.131
App server:
IP Address. . . . . . . . . . . . : 10.10.100.59»
Теперь из сообщения об ошибке выясним, когда именно возникла проблема. Наше сообщение об ошибке выглядит так:
«02/24/2010 09:28:08 DataBase Warning OleDB Error Microsoft OLE DB Provider for SQL Server [0x80004005][11] : [DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation».
Таким образом, проблема произошла 24.02.2010 в 09:28:08.
Почему так важно точное время события? Зачастую, при сборе трассировок сети для решения периодически возникающих сетевых проблем вы получите внушительное количество файлов трассировки с каждого сервера, так как вам может понадобиться осуществлять захват сетевых трассировок в течение довольно продолжительного периода времени, и это может привести к генерации большого количества файлов трассировки, хранящих информацию о всей цепочке событий, произошедших за это время. В рассматриваемом нами примере клиент отправил более 60 файлов трассировки размером 25 МБ каждый для сервера приложений, а также было получено 6 подобных файлов для сервера Microsoft SQL Server. Когда у вас слишком много данных для анализа, информация о точном времени возникновения проблемы становится бесценной.
Анализ трассировок сервера приложений
Начнем наш анализ с файлов трассировки, полученных от сервера приложений. С помощью временной метки мы можем определить, какой файл трассировки необходимо проанализировать первым. Первое, что необходимо сделать, когда мы имеем дело с периодически возникающими проблемами сетевого соединения, это проверить данные трассировки сети на наличие каких-либо сбросов соединения (сообщений по протоколу TCP с установленным флагом RST, означающим «RESET»). Кроме того, из журнала ошибок сервера SQL можно узнать, какой порт прослушивает SQL-сервер. В рассматриваемом нами примере это был порт 1433. Таким образом, мы начинаем свой анализ со следующего фильтра:
«tcp.port eq 1433 && tcp.flags.reset==1»
С помощью данного фильтра можно получить список всех сообщений «RESET», относящихся к данному SQL-серверу (конечно же, сразу стоит удостовериться, что сервер приложений подключается только к проблемному SQL-серверу, и не происходит других подключений еще к какому-то другому SQL-серверу, который также прослушивает порт 1433). В рассматриваемом нами примере с помощью этого фильтра было обнаружено около 20 сообщений по протоколу TCP с флагом RST:
Следующим нашим шагом будет проверка полного взаимодействия в течение состоявшегося TCP-соединения, частью которого является сообщение о сбросе соединения. Для того чтобы увидеть сетевое взаимодействие, включающее в себя фрейм с флагом RST, следуйте следующему шаблону действий:
«Выберите фрейм с флагом RST —> кликните правой кнопкой мыши —> Conversation Filter («Фильтр взаимодействия») —> TCP».
В результате вы получите все фреймы для текущего взаимодействия. В ходе выполнения аналогичной проверки для рассматриваемого нами примера было найдено всего два фрейма:
Теперь, если вы работаете с несколькими файлами трассировки, формирующих непрерывную цепочку событий, а не с одним файлом, вам следует проанализировать и другие файлы трассировки, которые содержат информацию о событиях непосредственно до и после обнаруженного вами события, чтобы найти и другие фреймы этого сетевого взаимодействия, если таковые существуют. Нам необходимо восстановить полную картину событий и узнать, что происходило до того, как сообщение о сбросе соединения было отправлено. Эта информация поможем нам узнать первопричину отправки сообщения с флагом RST. Чтобы сделать это, скопируйте фильтр для данного взаимодействия из текущего файла трассировки. Для нашего примера он следующий:
«(ip.addr eq 10.10.100.59 and ip.addr eq 10.10.100.131) and (tcp.port eq 1194 and tcp.port eq 1433)»
Затем следует открыть файл трассировки, собранный на сервере приложений непосредственно перед текущим файлом трассировки, и, используя вышеупомянутый фильтр, найти фреймы, которые являются частью одного и того же сетевого взаимодействия.
Если вы не нашли проблему, а только наблюдаете нормальный траффик (наподобие пакетов «keep-alive»), откройте файл трассировки, предшествующий этому, и проанализируйте его, используя тот же фильтр. Продолжайте делать это, пока не увидите какую-то проблему или не дойдете до начала разговора (трехстороннего рукопожатия TCP для установления соединения).
В нашем примере было много траффика «keep-alive». Microsoft SQL Server (10.10.100.131) и сервер приложений (10.10.100.59) отправляли туда и обратно пакеты «TCP Keep-Alive» и «TCP Keep-Alive ACK». Но в конце сетевого взаимодействия сервер приложений (10.10.100.59) отправил пять пакетов «TCP Keep-Alive» на сервер SQL, но не получил никакого ответа от сервера SQL, как вы можете убедиться ниже:
Проверка всех предыдущих файлов трассировки, содержащих исследуемое взаимодействие, других проблем не выявила. Затем был проверен файл трассировки, следующий за изначальным файлом трассировки (в котором было обнаружено сообщение с флагом RST), но он не содержал фреймов для текущего соединения. Таким образом, данное сетевое взаимодействие закончилось после этого сообщения с сигналом о разрыве соединения.
Анализ трассировок сервера Microsoft SQL Server
Теперь приступаем к проверке файлов трассировки, которые были получены от сервера SQL. Еще раз использовав временную метку возникновения ошибки, мы можем определиться с файлом трассировки, с которого нам нужно начать.
Данный материал доступен только зарегистрированным пользователям!
Войдите или зарегистрируйтесь бесплатно, чтобы получить доступ!
Регистрация займёт несколько секунд.
См. также:
- Remove From My Forums
-
Вопрос
-
Hi All ,
In of our application accessing SQL Server 2005 , the SSIS package failed because of the following error:
============================================================
Plan Execution: Plan[advice] Failed: Error while processing the data for the step ‘OLEDB Source 3 2’
Error while processing the data for the step ‘OLEDB Source 3’ Error while processing the data for the step ‘OLEDB Source 3 2’ Error while processing the data
for the step ‘OLEDB Source 3’ Description: [DBNETLIB][ConnectionRead (recv()).]General network error. Check your network documentation. Source: Microsoft OLE DB Provider for SQL Server HRESULT: 0x80004005, Minor Code: 11 SQL State: 08S01 SQL Error Number: 11 28.12.2009 06:50:00 .===============================================================
The call stack got in the .NET application is as follows:For Statement Error:[ISTCMESD118|5496|8504|SAPPCOM|INFO|09.12.2009 06:40:46|d:dataflowgfdailyprocess.log] Plan Execution: Plan[gf_daily] Failed: Error while calculating the output schema for the step ‘OLEDB Source 4’ Description: [DBNETLIB][ConnectionOpen (PreLoginHandshake()).]General network error. Check your network documentation. Source: Microsoft OLE DB Provider for SQL Server HRESULT: 0x80004005, Minor Code: 11 SQL State: 08001 SQL Error Number: 11 Error while calculating the output schema for the step ‘OLEDB Source 4’ Description: [DBNETLIB][ConnectionOpen (PreLoginHandshake()).]General network error. Check your network documentation. Source: Microsoft OLE DB Provider for SQL Server HRESULT: 0x80004005, Minor Code: 11 SQL State: 08001 SQL Error Number: 11 09.12.2009 06:40:00 For Fax Statement Error:[ISTCMESD118|7228|9540|SAPPCOM|INFO|09.12.2009 06:30:30|d:dataflowgfdailyfaxprocess.log] Plan Execution: Plan[gf_daily_fax] Failed: Error while calculating the output schema for the step ‘OLEDB Source 4’ Description: [DBNETLIB][ConnectionOpen (PreLoginHandshake()).]General network error. Check your network documentation. Source: Microsoft OLE DB Provider for SQL Server HRESULT: 0x80004005, Minor Code: 11 SQL State: 08001 SQL Error Number: 11 Error while calculating the output schema for the step ‘OLEDB Source 4’ Description: [DBNETLIB][ConnectionOpen (PreLoginHandshake()).]General network error. Check your network documentation. Source: Microsoft OLE DB Provider for SQL Server HRESULT: 0x80004005, Minor Code: 11 SQL State: 08001 SQL Error Number: 11 09.12.2009 06:30:00 Advice Statement Error:[ISTCMESD118|8676|4840|SAPPCOM|INFO|09.12.2009 06:50:26|d:dataflowadviceprocess.log] Plan Execution: Plan[advice] Failed:
===================================================================
We have TCP/IP & Shared Memory enabled in the SQL server.Named pipes diabled. No eorror could be found in the Errorlog corresponding the same. Even in the EventVwr , we could not find any error as such or related . And this error is occuring occasionally only sometimes ,not regularly.
Kindly help regarding the same .
Thanks,
Mohit-
Перемещено
7 января 2010 г. 15:56
SSIS Question (From:SQL Server Database Engine)
-
Перемещено
Ответы
-
-
Помечено в качестве ответа
Zongqing Li
13 января 2010 г. 9:29
-
Помечено в качестве ответа
07.02.08 — 16:02
Вываливаеться окошко:
SQL State: 01000
Native: 64
Message: [Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionRead(WrapperRead)
SQL State: 08S01
Native: 11
Message: [Microsoft][ODBC SQL Server Driver][DBNETLIB]Общая ошибка сети. Обратитесь к документации по сети.
Собственно проблема такая в определенное время всегда одно и тоже вываливается база с такой ошибкой(в одной канторе), а в другой какие то пользователи работают нормальноЮ а каких то просто выбрасывает при попытке создать новый объект(только справочник материалы), при этом долго думает и вываливает из 1С. Достало уже всех!!!
На вирусы проверял — 0;
Протестить базу пока не удалось, т.к. не дают остальные бухи.
1С 7.7 (7.70.025)
SQL 2000
Что за фигня кто то справился с ней? Я уже много от кого о ней слышу
1 — 07.02.08 — 16:02
2 — 07.02.08 — 16:03
ТИИ
3 — 07.02.08 — 16:04
(2)?
4 — 07.02.08 — 16:03
надо проверить сеть, оборудование, диски на сервере
5 — 07.02.08 — 16:04
ААА, плин, это и сеть могет быть, ведь на нее ругается.
6 — 07.02.08 — 16:04
(3) тестирование и исправление
7 — 07.02.08 — 16:05
Смотри что делается на сервере в это время?
Может архивирование какое? Проверяй сеть…
8 — 07.02.08 — 16:05
попробуй ping большими покетами погоняй
9 — 07.02.08 — 16:05
А тестирование….
вот надесь сделать, как время появиться
10 — 07.02.08 — 16:06
на серваке голяк, в логах 0, на SQL в профайлере ошибки тоже не ловяться
11 — 07.02.08 — 16:06
ping <IP> -l 640000
12 — 07.02.08 — 16:06
(8) как пингануть большим пакетом?
13 — 07.02.08 — 16:07
опережаешь мысли))
14 — 07.02.08 — 16:07
СервисПак СКЛ-сервера какой?
15 — 07.02.08 — 16:09
и к пингу в конце добавь » -t100″:
ping IP -L 64000 -t100
-L — размер пакета.
16 — 07.02.08 — 16:09
если провалы есть, значит что с сетевой или кабелем, как предположение и поэтому пакеты не все доходят.
17 — 07.02.08 — 16:10
(15) по 11 мс все
18 — 07.02.08 — 16:10
если на всех провалы, попробуй меньше пакеты поставить.
19 — 07.02.08 — 16:10
тогда в сети нет проблем.
20 — 07.02.08 — 16:11
(14) SP1
21 — 07.02.08 — 16:11
кабель проверь, порты сервера/маршрутизатора.
22 — 07.02.08 — 16:11
(20)Ну а чего тогда удивляться… Ставь скорее SP4…
23 — 07.02.08 — 16:14
(22) Ладно, попробую, осталось только его найти
24 — 07.02.08 — 16:15
(22) не подскажешь где взять?
25 — 07.02.08 — 16:15
(22) О, на серваке нашел!
26 — 07.02.08 — 16:16
В Microsoft как вариант, либо ковыряй интернет, или www.nnm.ru фпоиск.
27 — 07.02.08 — 16:16
Млин, торможу.
28 — 07.02.08 — 16:18
Админ грит что ставил, а ентерпрайз пришет SP1.
Может я где не там посмотрел?
29 — 07.02.08 — 16:19
(28)Значит не ставил, лично я доверял бы EM…
30 — 07.02.08 — 16:21
Всем СПС!
Постараюсь поставить как можно раньше!
Если проблемма повториться ветку подниму
31 — 11.02.08 — 23:00
Что за фигня?
Поставил SP4 и начались такие тормаза
В частности 1 пользователь работает нормально, но если к базе пытаеться подключиться еще кто-то то все ППЦ.
Первый как работал так и работает, а другие не могут сдвинуться со стартовой желтой картинки «Загрузка структуры данных программы» и все так минут на 5-10 потом прожовывается и загружаеться. Но это ведь не дело! Может еще какой то фигни не хватает?
32 — 11.02.08 — 23:04
(31) А память под скл выделена статично?
33 — 11.02.08 — 23:32
(31) больше похоже на совпадение. Скорее это
Похоже на антивирус
34 — 12.02.08 — 14:45
(32) Памяти на Серваке 5 Гиг, по SQL выделяеться динамически в полном объеме. (не фиксировал)
(33) Антивир — NOD32
DarkAn
35 — 12.02.08 — 14:47
Притом тормаза только после установки SP4.
Пришлось вернуться снова к перваночальной установке SP1? там все работает как часы, но повторяеться то что описано в начале (((((
Общая сетевая ошибка после ночи бездействия
Вопрос:
В течение некоторого времени у нашего флагманского приложения были загадочные ошибки. Сообщение об ошибке является общим
[DBNETLIB] [ConnectionWrite (send()).] Общая сетевая ошибка. Проверьте свою сетевую документацию.
Это надежно воспроизводится, оставив приложение открытым на ночь и возобновив работу утром. Поскольку это серверное приложение для бэкэнд, это обычный сценарий.
Самое смешное – мы перенесли с SQL Server 7 на 2000 по 2008 год, и проблема присутствует на всех из них. Но то, что кажется важным, – это ОС, на которой мы запускаем приложение. На WinXP он отлично работает, на Vista/7 он терпит неудачу. Таким образом, проблема находится на стороне клиента.
Результаты Google в сообщении об ошибке охватывают очень широкий спектр различных причин (так как это очень общая ошибка), и ни один из найденных там сценариев не похож на наш.
Итак, может быть, кто-то здесь узнает, в чем проблема в нашем случае?
Ответ №1
Вы должны иметь возможность воспроизвести это условие ошибки по запросу:
1. Открытие соединения с базой данных (в вашем клиентском приложении)
2. Отсоединение сетевого кабеля
3. Повторное подключение сетевого кабеля (подождите, пока сетевое соединение будет восстановлено)
4. Используя ранее открытое соединение для запроса базы данных
Насколько я могу судить по опыту, код ADO на стороне клиента не может последовательно определить, действительно ли базовое сетевое соединение действительно или нет. Проверка открытия соединения с базой данных (в клиентском коде) возвращает значение true. Однако выполнение любых операций над этим соединением приводит к General network error.
Пул соединений, по-видимому, может определить, когда соединение “плохо”, поэтому оно никогда не возвращает плохое соединение с приложением. Вместо этого он просто открывает новое соединение.
Таким образом, если соединение с базой данных поддерживается в течение длительного времени (используется или не используется) приложением, базовая связь TCP/IP может быть нарушена.
Суть в том, что соединения с базой данных должны быть закрыты и возвращены обратно в пул соединений, когда они не используются.
Изменить
Кроме того, в зависимости от количества клиентов, подключающихся к db, использование пула соединений может вызвать другую проблему. Вы можете поразить максимальное количество сокетов, открытых на стороне сервера. Это из памяти. Когда соединение закрывается на стороне клиента, соединение на сервере переходит в состояние TIME_WAIT. По умолчанию серверный сокет занимает около 4 минут, поэтому он недоступен для других клиентов за это время. Суть в том, что на сервере имеется ограниченное количество доступных сокетов. Сохранение слишком большого количества подключений может создать проблему.
Один проект, над которым я работал, легко попал в этот сокет с примерно 120 пользователями. Добавлена новая “функция”, которая абсолютно забила сервер, и через несколько часов после использования приложения внезапно замедлится сканирование для всех. SQL-сервер не закрывал достаточно сокетов вовремя для новых запросов на подключение. Несмотря на то что есть 65K сокетов, только первые 5000 доступны для ADO (это стандартная настройка реестра, поэтому ее можно изменить).
Количество сокетов в состоянии TIME_WAIT будет медленно наращиваться до тех пор, пока ОС не будет выделять больше. Таким образом, клиентам приходилось ждать, пока сокеты на стороне сервера не будут закрыты, и тогда может быть создано новое соединение.
Ответ №2