SQL Server: мы должны использовать TCP или именованные каналы или использовать по умолчанию?


17

При подключении к SQL Server 2008 R2 из клиентского приложения .NET 4 на другом сервере в той же локальной сети можно установить три разных сетевых протокола:

  1. TCP
  2. Именованные трубы
  3. Не устанавливайте ничего в строке подключения и используйте значение по умолчанию

Что такое лучшая практика? Что выбрать?

Дополнительная информация: как TCP, так и именованные каналы включены как на сервере, так и на клиенте. Приложение использует зеркальное отображение базы данных. Клиент и сервер общаются через быструю локальную сеть.

Мы исследуем это, потому что у нас есть редкие и ложные проблемы с подключением и временем ожидания. (Но независимо от этого я хотел бы знать лучшие практики).

На MSDN есть статья на эту тему, но она очень общая и расплывчатая. Он не советует и не рекомендует ничего полезного.


2
@ccook, я верю, что это сделал. tcp:Несколько лет спустя я обнаружил, что настроен как часть большинства строк подключения в среде другой компании. Я предполагаю, что они нашли похожие проблемы.
USR

1
Я не достаточно уверен, чтобы опубликовать это как ответ. Однако странно, что такая вопиющая проблема не устранена. Должно быть очень редким или трудно воспроизводимым. @ccook
usr

1
Это очень редко и трудно воспроизвести для нас. К счастью, когда мы создали это приложение, которое спамит соединения одновременно каждую минуту, оно может время от времени воспроизводить его. Это все еще очень непредсказуемо. Мы сейчас тестируем это изменение - немного подождем, прежде чем оно будет исправлено. Посмотрев на это, я определенно склонен использовать tcp: по умолчанию, если только приложение и сервер не находятся на одной машине.
ccook

1
@ccook У меня была новая мысль. Общие файловые ресурсы Windows, как известно, ненадежны. Ложные ошибки и сбои подключения видны многим. Это редко, но трудно / невозможно диагностировать. При использовании именованных каналов вы теперь используете всю эту технологию в своем развертывании SQL Server. Это кажется неразумным на общих основаниях.
USR

1
согласовано. Пока что tcp: похоже решает проблему. Мы немного ждем, чтобы это подтвердили.
ccook

Ответы:


18

Я предпочитаю TCP / IP вместо именованных каналов, хотя в большинстве случаев не будет заметной разницы. Это можно сделать, изменив протоколы, поддерживаемые экземпляром в диспетчере конфигурации SQL Server, а не жестко кодируя вещи в строке подключения (это упрощает внесение изменений или устранение неполадок).

По сути, маршрутизация и другие издержки, связанные с именованными каналами (если только ваши приложения не находятся на том же компьютере, что и SQL Server, в этом случае есть только небольшая дополнительная нагрузка), делают его менее эффективным вариантом, особенно в масштабе, в более медленной сетевой среде. (100 МБ или меньше), или если ваши рабочие нагрузки приходят в пакетах.

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

Подробнее о преимуществах TCP / IP вы можете прочитать подробнее .


Так что, в принципе, это не имеет большого значения, но обычно предпочтительнее использовать TCP, потому что нет причин выбирать именованные каналы. Согласитесь ли вы с этим резюме?
USR

1
@usr Ну, это важно, когда вы масштабируете, или если ваша сеть отстой. Но да, в общем, нет никакой реальной выгоды в выборе именованных каналов в любом случае, о котором я знаю.
Аарон Бертран

7

Протокол Named Pipes полезен для приложений, разработанных на основе NetBIOS или других протоколов на основе локальной сети.

Именованные каналы обеспечивают легкий доступ к удаленным вызовам процедур (RPC) в пределах одного домена безопасности и, таким образом, выгодны для этих приложений.

Обычно протокол TCP хорош на практике, потому что вам не нужно заботиться обо всем этом в сети.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.