Назад | Перейти на главную страницу

Спорадические проблемы с подключением к SQL 2005 - проблема с именованными каналами и TCP / IP?

У нас есть рабочий веб-сайт, на котором возникают периодические ошибки подключения к нашему серверу SQL 2005, несколько раз в день во время пиковой нагрузки:

Произошла ошибка при установлении соединения с сервером. При подключении к SQL Server 2005 этот сбой может быть вызван тем, что в настройках по умолчанию SQL Server не разрешает удаленные подключения. (поставщик: поставщик именованных каналов, ошибка: 40 - не удалось открыть соединение с SQL Server)

Мы, конечно, изучаем другие возможности, но пока мы не видели ничего необычного на стороне SQL. Нам интересно, может ли это быть проблемой именованных каналов, или мы увидим то же самое, если заставим веб-сервер использовать вместо этого TCP / IP. Итак, мои вопросы:

Кто-нибудь видел такую проблему? В основном я ищу эту ошибку для людей, которые не могут разговаривать со своим SQL-сервером. вообще потому что конфигурация площади поверхности испорчена. Это не наша ситуация.
Что за разница между двумя? Они по-другому делают разрешение имен? Эти серверы не являются членами домена, они изолированы в своих собственных DMZ, если это что-то меняет.
Интернет-команда установила псевдоним SQL на веб-сервере: «mySQLserverName - tcp / ip - xxx.xx.x.xx, 1433». Было бы это только использоваться для разрешения TCP / IP, а не именованных каналов? Может ли это быть частью проблемы?
Если я делать хотите принудительно использовать TCP / IP вместо именованных каналов, какой рекомендуемый способ сделать это? Это Microsoft KB говорит, что я могу это сделать, изменив строку подключения. Эта ветка форума MSDN говорит, что я могу изменить «предпочтительный порядок» протоколов конфигурации собственного клиента. Полагаю, я мог бы также полностью отключить именованные каналы на сервере SQL, но это кажется немного резким и, вероятно, не то, что можно попробовать на производственном компьютере.

sql-server tcpip

Если это происходит только в часы пик и другие попытки подключения из того же приложения работают нормально, возможно, вы столкнулись с конфликтом памяти на сервере SQL или проблемой тайм-аута.

Обычно именованные каналы хороши для LAN-коммуникаций или других быстрых, стабильных сетей, но они немного болтаются (т. Е. Больше накладных расходов), чем сокеты TCIP / IP, поэтому не обязательно подходят для более медленных соединений, таких как WAN.

Когда вы говорите, что каждый сервер изолирован в своей собственной DMZ, вы имеете в виду, что у вас несколько сетей DMZ, и каждый сервер находится в другом? Если это так, попросите вашу команду в Интернете проверить журналы брандмауэра на наличие сброшенных / отклоненных / неудачных соединений. Если ваши серверы находятся в разных подсетях, вы можете установить TCP / IP в качестве предпочтительного протокола.

Вот пара статей, в которых рассказывается о различиях в протоколах:

Обычно мы используем только TCP / IP в наших строках подключения (с номером порта не по умолчанию) и не имеем проблем с масштабируемостью как для локальных, так и для WAN-серверов.

Вы можете ПРИНУДИТЕЛЬНО использовать соединение для использования TCP / IP, используя server = dbservername, 1433 в строке соединения (т.е. указав номер порта).

Обычно мы оставляем именованные каналы открытыми, поскольку это позволяет видеть в SQL Management Studio индикатор состояния сервера «Зеленый» / «Красный».

Я бы посмотрел на общее состояние сервера, особенно на сетевую нагрузку (соединения / коллизии) и использование ОЗУ (счетчики SQL Server PerfMon). Иногда у вас могут возникнуть проблемы с объединением / освобождением соединений на очень загруженных серверах (обычно при 1000 соединений в секунду).