SQL Server: devemos usar TCP ou pipes nomeados ou usar o padrão?


17

Ao conectar-se a um SQL Server 2008 R2 a partir de um aplicativo cliente .NET 4 em um servidor diferente na mesma LAN, é possível definir três protocolos de rede diferentes:

  1. TCP
  2. Tubos nomeados
  3. Não defina nada na cadeia de conexão e use o padrão

Qual é a melhor prática? O que escolher?

Informações adicionais: o TCP e os pipes nomeados são ativados no servidor e no cliente. O aplicativo está usando o espelhamento de banco de dados. Cliente e servidor se comunicam através de uma LAN rápida.

Estamos investigando isso porque temos problemas raros e falsos de conectividade e tempo limite. (Mas, independentemente disso, eu gostaria de conhecer as melhores práticas).

Há um artigo sobre esse assunto no MSDN, mas é muito genérico e vago. Não aconselha nem recomenda nada útil.


2
@cook Acredito que sim. Também achei tcp:configurado como parte da maioria das cadeias de conexão no ambiente de uma empresa diferente anos depois. Suponho que eles encontraram problemas semelhantes.
usr

11
Não tenho confiança suficiente para postar isso como resposta. É estranho, porém, que um problema tão flagrante não tenha sido solucionado. Deve ser muito raro ou difícil de reproduzir. @ccook
usr

11
É muito raro e difícil de reproduzir para nós. Felizmente, quando criamos esse aplicativo que gera conexões simultaneamente a cada minuto, ele pode ser reproduzido de vez em quando. Ainda é muito imprevisível. No entanto, estamos testando essa mudança - aguardando um pouco antes de chamá-la de corrigida. Tendo analisado isso, estou definitivamente inclinado a usar o tcp: por padrão, a menos que o aplicativo e o servidor estejam na mesma máquina.
ccook

11
@cook Eu tive um novo pensamento. Os compartilhamentos de arquivos do Windows são notoriamente não confiáveis. Erros espúrios e falhas de conexão são vistos por muitos. É raro, mas difícil / impossível de diagnosticar. Ao usar pipes nomeados, você coloca toda essa tecnologia em sua implantação do SQL Server. Isso parece imprudente por motivos gerais.
usr

11
acordado. Até agora, o tcp: parece estar resolvendo o problema. Estamos esperando um pouco para chamá-lo de confirmado.
ccook

Respostas:


18

Prefiro o TCP / IP ao invés de pipes nomeados, embora na maioria das situações não haja diferença perceptível. Você pode fazer isso ajustando os protocolos suportados pela instância no SQL Server Configuration Manager em vez de codificar as coisas na cadeia de conexão (isso facilita fazer alterações ou solucionar problemas).

Essencialmente, o roteamento e outras despesas gerais envolvidas nos pipes nomeados (a menos que seus aplicativos estejam na mesma máquina que o SQL Server; nesse caso, há apenas uma sobrecarga extra) tornam a opção menos eficiente, especialmente em escala, em um ambiente de rede mais lento (100 MB ou menos) ou se suas cargas de trabalho ocorrerem em rajadas.

Se seus aplicativos estiverem na mesma caixa que o SQL Server, você também deve ter em mente a memória compartilhada - se houver aplicativos na caixa SQL Server se comunicando diretamente com o SQL Server, essa será a opção mais eficiente.

Você pode ler sobre as vantagens de desempenho do TCP / IP em mais detalhes .


Portanto, basicamente não importa muito, mas geralmente é preferível usar o TCP porque não há motivos para escolher pipes nomeados. Você concorda com esse resumo?
usr

11
@usr Bem, importa quando você dimensiona ou se sua rede é péssima. Mas sim, em geral, não há benefícios reais em escolher pipes nomeados em qualquer caso, que eu saiba.
Aaron Bertrand

7

O protocolo de pipes nomeados é útil para o aplicativo desenvolvido em torno do NetBIOS ou de outros protocolos baseados em LAN.

Os pipes nomeados fornecem acesso fácil às chamadas de procedimento remoto (RPC) em um único domínio de segurança e, portanto, são vantajosas para esses aplicativos.

Normalmente, o protocolo TCP é bom na prática porque você não precisa se preocupar com tudo isso na rede.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.