Dbnetlib connectionread recv общая ошибка сети - Решение и исправление самых разных ошибок на TopOshibok.ru

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 badges47 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

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

5,0049 gold badges38 silver badges53 bronze badges

answered Oct 7, 2016 at 18:39

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,8294 gold badges34 silver badges30 bronze badges

Источник

Problem

User runs an intensive task, and receives an error message.

Scenario #1 — User running a database optimisation.
Scenario #2 — User running a ‘reports conversion’ process, as part of a migration from Controller 2.x to 8.x.
Scenario #3 — User is trying to import data into Controller, via a CSV file.

Symptom

(0x80004005): [DBNETLIB][ConnectionRead(recv()).]General

network error. Check your network documentation.

Example #2:

The underlying connection was closed: An unexpected error occurred on a receive.

Scenario #2:

(0x80004005): [DBNETLIB][ConnectionOpen

(PreLoginHandshake()).]General network error. Check your network documentation.

Scenario #3

[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.

Cause

There are several potential causes for errors similar to those shown above.

For another example, see separate IBM Technote #1587557 & 1674415.

This Technote shall concentrate on the scenario where the cause is a TCP/IP network failure, causing a «General network error«, which has been triggered by one of the following Microsoft Windows TCP/IP mechanisms:

Scenario #1 — Microsoft TCP Chimney Offload feature is enabled on the server

For more details, see separate IBM Technote #1445735.

Scenario #2 — Microsoft SynAttackProtect feature is enabled on the server

This IBM Technote shall concentrate on this scenario.

The user’s task triggers a high level of network activity to/from the Microsoft SQL database server. In our scenario, this triggers Microsoft ‘SynAttackProtect’ feature on the SQL server:

‘SynAttackProtect’ causes Windows to drop connections if the requests arrive faster than SQL Server can service them.

This is a security feature of Windows Server 2003 Service Pack 1, which implements a finite queue for incoming TCP connection requests.

SynAttackProtect is enabled (by default) on a server with Windows 2003 SP1 or later. This shuts down the network connection to the Controller application server, which therefore gives an error.

TIP: For TCP/IP in Windows XP (all versions) and Windows Server 2003 with no service packs installed, SynAttackProtect is set to 0 by default.

More information about ‘SynAttackProtect’:
To mitigate the impact on a host experiencing a SYN attack, TCP/IP minimizes the amount of resources devoted to incomplete TCP connections and reduces the amount of time before abandoning half-open connections. When a SYN attack is detected, when SynAttackProtect is enabled, TCP/IP in Windows Server 2003 and Windows XP lowers the number of retransmissions of the SYN-ACK segment and does not allocate memory or table entry resources for the connection until the TCP three-way handshake has been completed.

For more information, see section inside ‘Related Documents’
One of the best summaries on this topic can be found here: http://blogs.technet.com/b/pabenois/archive/2010/06/10/sharepoint-2007-and.aspx

Environment

Microsoft Windows 2003 servers, with Service Pack 1 or later.

NOTE: SynAttack protection is enabled by default and cannot be disabled for all modern Windows versions, for example: Vista, Windows 2008, Windows 7 and Windows 2008 R2.

See third-party (non-IBM) link below for more details.

Diagnosing The Problem

One method to investigate is to check the current number of TCP network connections that the server currently has. One easy method is to ‘pipe’ the results of netstat to a text file, and then open that in a spreadsheet (e.g. Excel) to analyst. In other words, run the following command (inside a command prompt) and then open the resultant file «connections.txt» inside EXCEL:

netstat -o >connections.txt

Resolving The Problem

Fix:

Improve:

the quality/speed of the network connection between the Controller application server and the SQL server
the server hardware (CPU speed, number of CPU cores etc.) of the SQL server.

Workaround

Disable Microsoft SYN attack protection on the Windows 2003 Microsoft SQL server.

Steps to disable ‘SynAttackProtect’:

Obtain some downtine to the system, to ensure no end-users are using any database on the relevant SQL server
Logon to the SQL server as an administrator
START — RUN — REGEDIT
Navigate to the location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Double-click on the entry SynAttackProtect (or create it if it does not exist!)
Change its value from 1 to 0
Reboot the SQL server

Related Information

[{«Product»:{«code»:»SS9S6B»,»label»:»IBM Cognos Controller»},»Business Unit»:{«code»:»BU059″,»label»:»IBM Software w\/o TPS»},»Component»:»Controller»,»Platform»:[{«code»:»PF033″,»label»:»Windows»}],»Version»:»8.4;8.3″,»Edition»:»Not Applicable»,»Line of Business»:{«code»:»LOB10″,»label»:»Data and AI»}}]

Historical Number

1035583

Источник

Hello together,

since over a week I’ve been looking to
find out the reason for two error messages I get from our users and
servers, unfortunately without success up to now.

I really hope you can help me.

We are using Win 2k servers with active directory and SQL Server 2000,
clients are all Win XP with SP2. Versions of access are 2002 &
2003. The errors are userspecific and occur in both versions. The
SQL-Servers are accessed with an adp-file in 2002-format.

We have one usergroup which is member of specially many groups. This
affects the size of their windows access token which becomes constantly
larger. In order to enable those users to still access their mailboxes
on our Exchange servers, the DWORD entry «MaxTokenSize» with the
decimal value «65535» was made to the newly created key «Parameters» of
their registry branch
«HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos «.

Since then those users can not access any of our SQL Servers using the
windows authentification. One of them gets the error
«[DBNETLIB][ConnectionRead(recv().] General network error. Check your
network documentation.», the others the error «Check connection:
Failed: Cannot generate SSPI context».

In case of resetting the registry entries (by deleting them), the one
user receives the same error message as the rest while it doesn’t make
any difference to those (but at least they can’t connect to their
mailboxes).

After having researched the web, I realised in one of the SQL-Servers
logfiles the entry «Invalid buffer received from client..» which lead
me to start to believe it could have to do something with the kerberos
encryption in the first place. Therefore I asked if changes to the
tokensize had been made. I applied the change with «EXEC sp_configure
‘network packet size’, 65535 RECONFIGURE» on our testsystem and «EXEC
sp_configure» confirms that the value is run.

Consequence: The entry in the SQL Server log doesn’t appear any longer, but the users still receive their error messages.

Do you have any hints?

Your comments will be highly appreciated!

Regards,
caracol

Источник

В большинстве случаев истинная причина периодически возникающей проблемы с подключением клиентского компьютера к удаленному серверу базы данных 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. Еще раз использовав временную метку возникновения ошибки, мы можем определиться с файлом трассировки, с которого нам нужно начать.

Данный материал доступен только зарегистрированным пользователям!
Войдите или зарегистрируйтесь бесплатно, чтобы получить доступ!
Регистрация займёт несколько секунд.

См. также:

Источник

February 14, 2006 at 7:24 pm

#170598

I have a 3rd party application that is reading tables from SQL Server 2005 Express. Last night I set the program running on a continuous loop that reads values from a few tables, and updates a «heartbeat» record every few seconds — nothing else. This morning I found that after running for about 4 and a half hours it crashed with the following message:

Number = 0x80004004

Source = Microsoft OLE DB Provider for SQL Server

Description =[DBNETLIB][ConnectionRead (recv()).]General network error. Check your network documentation.

SQL State = 08S01

NativeError = 11

I am running it on a machine operating on Windows XP Professional SP2 and the version of SQL Server 2005 I am running is 2005.090.1399.00. The 3rd party application is running on the same machine as SQL Server. The only systems that interrogate the table are:

1. The main program thread of the 3rd party application that does the work mentioned above.

2. A MS Access front end that interrogates some of the tables (linked) once every 5 seconds using an On Timer Event

3 There are 8 other threads running that are linked to the database on the 3rd party application but, when the application is idling as it was overnight, they do not interact with SQL tables at all.

There are a total of 7 tables, the largest having 99 records.

I have no idea what this message means or what to do to prevent it from happening. I chose SQL Server because I thought it was going to be robust but this is not inspiring confidence. Can anyone help me understand this message please?
Robbo

Old Hand

Points: 368

February 15, 2006 at 3:46 am

#620943

I think I can close this out as I suspect I have found the answer. Norton’s antivirus seems to randomly conclude that the comms between client and server via TCP/IP is a Trojan Virus at work and stops it. I turned off the firewall and it appears to have fixed the problem. These comments are posted in case someone else has a similar problem.
milton_msu

SSC Journeyman

Points: 86

i m getting the same error but there is no norton installed on my machine .. so it could be some other problem
Robbo

Old Hand

Points: 368

It was a while ago but if I recall correctly I discovered what was causing the problem when I looked at the Event Viewer and found that Nortons was causing the problem. Have a look there and it may help you find the problem. In my case I changed to Trend Security and the problem never re-appeared.

Start>Control Panel>Administrative Tools>Event Viewer>System
Gift Peddie

SSC Guru

Points: 73570

You get this error because SQL Server 2005/8 Express, Express Advanced and Developer comes with most features disabled by default. In 2005 you have to go to SAC(surface area configuration tool) to enable TCP/IP and Named Pipes, enable local and remote connection. And in 2008 you go to Configuration manager and enable same. This is not available in VS2005/8 Express except VWD because web development require remote connection.

Kind regards,
Gift Peddie
Robbo

Old Hand

Points: 368

Thanks for your comments. In my case I don’t think that was the problem as I had enabled those comms. My application would run for minutes to hours before this error would appear out of the blue. As soon as I changed away from Nortons the problem disappeared and hasn’t reappeared since.

Viewing 6 posts — 1 through 5 (of 5 total)

Источник