1с общая ошибка сети
[DBNETLIB][ConnectionWrite (send()).]Общая ошибка сети. Проверьте сетевую документацию.
Это достоверно воспроизводится, если оставить приложение открытым на ночь и возобновить работу утром. Поскольку это серверное приложение, это нормальный сценарий.
Самое смешное, что мы перешли с SQL Server 7 с 2000 на 2008, и проблема присутствует на всех из них. Но что, кажется, имеет значение, так это ОС, на которой мы запускаем приложение. В WinXP работает нормально, в Vista/7 не работает. Так что проблема на стороне клиента.
Так что, возможно, кто-то здесь знает, в чем проблема в нашем случае?
Поддерживает ли ваше приложение одно SQL-соединение открытым в течение всего времени существования приложения?
@Vilx-ты разобрался с этим в конце? мы сталкиваемся с точно такой же проблемой, и исключение слишком широкое, чтобы сосредоточиться на чем-то.
3 ответа
Вы должны быть в состоянии воспроизвести это состояние ошибки по требованию следующим образом:
1. Открытие подключения к базе данных (в клиентском приложении)
2. Отключение сетевого кабеля
3. Снова подключите сетевой кабель (подождите, пока сетевое соединение восстановится)
4. Использование ранее открытого соединения для запроса базы данных
Насколько я могу судить по опыту, код ADO на стороне клиента не может постоянно определять, действительно ли базовое сетевое соединение действительно или нет. Проверка того, открыто ли соединение с базой данных (в клиентском коде), возвращает значение true. Однако выполнение любых операций с этим соединением приводит к General network error .
Пул соединений, по-видимому, может определить, когда соединение становится «плохим», поэтому он никогда не возвращает плохое соединение приложению. Вместо этого он просто открывает новое соединение.
Таким образом, если соединение с базой данных поддерживается приложением в течение длительного времени (используется или не используется), базовое соединение TCP/IP может быть нарушено.
Суть в том, что соединения с базой данных должны закрываться и возвращаться обратно в пул соединений, когда они не используются.
Редактировать
Кроме того, в зависимости от количества клиентов, подключающихся к базе данных, неиспользование пула соединений может вызвать другую проблему. Вы можете достичь максимального количества сокетов, открытых на стороне сервера. Это по памяти. Как только соединение закрывается на стороне клиента, соединение на сервере переходит в состояние TIME_WAIT. По умолчанию для закрытия серверного сокета требуется около 4 минут, поэтому в это время он недоступен для других клиентов. Суть в том, что количество доступных сокетов на сервере ограничено. Слишком большое количество подключений может создать проблему.
Один проект, над которым я работал, легко преодолел этот лимит сокетов, имея около 120 пользователей. Была добавлена новая «функция», которая полностью забила сервер, и после нескольких часов использования приложения все внезапно замедлилось для всех. SQL-сервер не закрывал достаточное количество сокетов для новых запросов на подключение. Несмотря на то, что всего сокетов 65 000, только первые 5000 доступны для ADO (это параметр реестра по умолчанию, поэтому его можно изменить).
Количество сокетов в состоянии TIME_WAIT будет медленно увеличиваться до тех пор, пока ОС не перестанет выделять ресурсы. Таким образом, клиентам приходилось ждать, пока сокеты на стороне сервера не закроются, и тогда можно будет создать новое соединение.
Вчера переутановил все SQL сервера. Последовательность была такая:
1. Удаление старого MSSQL
3. Install MSSQL 2000
9. Install SQL2000-KB899761-v8.00.2040-x86x64-ENU
Сегодня результаты. как выкидывало, так и выкидывает. что мне делать.
Попробую в обед обновить драйвера для сетевых карточек. Но! Есть клиентская машина с установленным 2003 сервером и MSSQL (для локальной обработки даннных). Вчера к этой базе пытался подключиться наш программер (по сети) - получил ту же ошибку. В чём может быть затык?! Ошибка (как мне видится) не серверная. а именно сетевая! Даж и не знаю на что грешить.
Вам тут куча людей уже сказали, что проблема в сети. Пробуйте разные варианты. Подключите кого-нибудь из клиентов напрямую в сервер и проверьте - будет ли повторяться проблема. подключите одновременно другого клиента через другое активное оборудование. Так же пронаблюдайте. Поставьте другую карточку в сервер. По результатм уже можно будет судить. Я в своей проблеме даже траффик нюхал - видел сброс SMB сессии в момент появления ошибки.
заметил интересную закономерность.
сотрудник работал в 2х базах.
№1 - локально у себя на компе - путь сетевой на Сервер
№2 - через удалённый рабочий стол (тобиш - на самом серваке крутилось чтото)
вылет из 2х баз прошёл синхронно.
не совсем понятно - вылет из 2х баз прошёл синхронно.
это как? вместе с ошибкой локального клиента закрылась и терминальная сессия?
Или терминальная сессия осталась открытой?
А если пользователь просто работает в терминальной сессии 1с у клиента вылетает также как и по сети?
Позвольте и свои пять копеек вставить: в нашей деревне аналогичный случай - внедряем сейчас "1С v 7.70.027 sql" по схеме: "SQL server" + "Терминальный сервер", время от времени получаем эту же ошибку. Пользователи работают только через терминал. Что характерно, после появления этой ошибки, ВСЕ пользователи не могут работать, приходится перезагружать терминал. Используемое П/О:
Windows 2003 SP2 Rus (MDAC 2.82.3959.0)
Microsoft SQL Server 2000 - 8.00.2187 (Intel X86)
На терминале ещё и Citrix PS 4.5 c репозиторием на тоже SQL сервере. И если пользователи словили эту ошибку, то Citrix Access Management Console тоже не запускается.
Такое впечатление, что насмерть заклинивает ODBC драйвер.
Чтобы исключить версию ошибок сети собираюсь завтра с утречка связать вторые сетевые карточки серверов кроссовером, помимо всех свичей, и завернуть туда 1с-ный трафик к mssql серверу.
Отпишите, если вы смогли решить эту проблему.
Информация о железе:
Серверы HP Proliant DL380 и DL360 G5, сетевые адаптеры - HP NC373i Multifunction Gigabit Server Adapter
Alexey_Zhogolev написано: | ||||
это как? вместе с ошибкой локального клиента закрылась и терминальная сессия? Или терминальная сессия осталась открытой? Да. Терминальная сессия тоже рвётся. Увы. Причём именно 1С Предприятие. Именно MSSQL. Вобщем ошибка появляется ТОЛЬКО при работе по сети ( \\server\1c_share_folder\) Ошибка имеет место быть. и никуда не пропадает. Хелп. Попробуйте отключить гиперпоточность. имеется ввиду - Hyperthreating. Если да - то через часик - попробую. отпишусь в течении дня. Попробуйте отключить гиперпоточность. Сервер был запущен на сутки с отключенным Hypperthreating`ом. Результат нулевой. На днях установил MSSQL Enterprise Edition 2000 (+SP4). Знакомый гуру посоветовал установить на клиентских машинах MDAC 2.7 Сегодня сделал пробный запуск с одной машины с установленным обновлённым MDAC`ом. "Тьфу-тьфу-тьфу" (постучал по дереву), вроде как прошло (запускалось объединение *.md файлов по сети с клиентской машины с сервером) без проблем. Завтра буду применять решение повсеместно. К слову о настройках клиентов: в консоли набираем "cliconfg" и удаляем все с первых двух закладок (если я не прав или не совсем понимаю, что я делаю - спецы - поправьте меня). На первой - прооколы которые использует клиент. Если на сервере прописано что использовать только TCP/IP - то используемый клиентом протокол по-умолчанию соответственно, тоже будет TCP/IP На второй - алиасы. Вот тут я несколько запутался. Но по сути в домене нет нужды указывать какие либо алиасы если имя SQL сервера совпадает с его FQDN и порт используется по-умолчанию (1433)? Так? В общем промежуточный итог моего полночного бреда: грешу на связку SQL+клиент (MDAC). Прошу за онлайн обсуждением сей проблемы стучаться в аську: семнадцать, сорок пять, девятнадцать Вчера переутановил все SQL сервера. Последовательность была такая: 1. Удаление старого MSSQL 3. Install MSSQL 2000 9. Install SQL2000-KB899761-v8.00.2040-x86x64-ENU Сегодня результаты. как выкидывало, так и выкидывает. что мне делать. Попробую в обед обновить драйвера для сетевых карточек. Но! Есть клиентская машина с установленным 2003 сервером и MSSQL (для локальной обработки даннных). Вчера к этой базе пытался подключиться наш программер (по сети) - получил ту же ошибку. В чём может быть затык?! Ошибка (как мне видится) не серверная. а именно сетевая! Даж и не знаю на что грешить. Вам тут куча людей уже сказали, что проблема в сети. Пробуйте разные варианты. Подключите кого-нибудь из клиентов напрямую в сервер и проверьте - будет ли повторяться проблема. подключите одновременно другого клиента через другое активное оборудование. Так же пронаблюдайте. Поставьте другую карточку в сервер. По результатм уже можно будет судить. Я в своей проблеме даже траффик нюхал - видел сброс SMB сессии в момент появления ошибки. заметил интересную закономерность. не совсем понятно - вылет из 2х баз прошёл синхронно. это как? вместе с ошибкой локального клиента закрылась и терминальная сессия? Или терминальная сессия осталась открытой? А если пользователь просто работает в терминальной сессии 1с у клиента вылетает также как и по сети? Позвольте и свои пять копеек вставить: в нашей деревне аналогичный случай - внедряем сейчас "1С v 7.70.027 sql" по схеме: "SQL server" + "Терминальный сервер", время от времени получаем эту же ошибку. Пользователи работают только через терминал. Что характерно, после появления этой ошибки, ВСЕ пользователи не могут работать, приходится перезагружать терминал. Используемое П/О: Windows 2003 SP2 Rus (MDAC 2.82.3959.0) На терминале ещё и Citrix PS 4.5 c репозиторием на тоже SQL сервере. И если пользователи словили эту ошибку, то Citrix Access Management Console тоже не запускается. Такое впечатление, что насмерть заклинивает ODBC драйвер. Чтобы исключить версию ошибок сети собираюсь завтра с утречка связать вторые сетевые карточки серверов кроссовером, помимо всех свичей, и завернуть туда 1с-ный трафик к mssql серверу. Отпишите, если вы смогли решить эту проблему. Информация о железе: Серверы HP Proliant DL380 и DL360 G5, сетевые адаптеры - HP NC373i Multifunction Gigabit Server Adapter
|