SQL Server: dovremmo usare TCP o Named Pipes o usare l'impostazione predefinita?

Quando ci si connette a SQL Server 2008 R2 da un'applicazione client .NET 4 su un server diverso nella stessa LAN, è possibile impostare tre protocolli di rete diversi:

TCP
Tubi con nome
Non impostare nulla nella stringa di connessione e utilizzare l'impostazione predefinita

Qual è la migliore pratica? Cosa scegliere?

Ulteriori informazioni: Sia TCP che Named Pipes sono abilitati sia sul server che sul client. L'applicazione utilizza il mirroring del database. Client e server comunicano su una LAN veloce.

Stiamo indagando su questo perché abbiamo problemi di connettività e timeout rari e spuri. (Ma a prescindere da ciò, mi piacerebbe conoscere la migliore pratica).

C'è un articolo su questo argomento su MSDN ma è molto generico e vago. Non consiglia o consiglia nulla di utile.

sql-server sql-server-2008-r2 network

— usr
fonte

@ccook Credo di si. Ho anche trovato tcp:configurato come parte della maggior parte delle stringhe di connessione nell'ambiente di un'azienda diversa anni dopo. Presumo che abbiano riscontrato problemi simili.

— usr

Non sono abbastanza sicuro di pubblicarlo come risposta. È strano, tuttavia, che un problema così grave non sia risolto. Deve essere molto raro o difficile da riprodurre. @ccook

— usr

È molto raro e difficile da riprodurre per noi. Fortunatamente quando abbiamo creato quell'app che invia connessioni simultanee ogni minuto, può riprodurla ogni tanto. È ancora molto imprevedibile. Stiamo testando quel cambiamento ora - aspettando un po 'prima di chiamarlo fisso. Detto questo, sono comunque propenso a usare tcp: per impostazione predefinita, a meno che l'app e il server non si trovino sullo stesso computer.

— cokok

@ccook ho avuto un nuovo pensiero. Le condivisioni di file di Windows sono notoriamente inaffidabili. Molti errori spuri e guasti alla connessione sono visti da molti. È raro ma difficile / impossibile da diagnosticare. Quando si utilizzano le pipe denominate, è ora possibile inserire l'intera tecnologia nella distribuzione di SQL Server. Sembra poco saggio per motivi generali.

— usr

concordato. Finora tcp: sembra affrontare il problema. Tuttavia stiamo aspettando un po 'di chiamarlo confermato.

— cok

Risposte:

Preferisco TCP / IP su Named Pipes, anche se nella maggior parte delle situazioni non ci saranno differenze evidenti. È possibile farlo modificando i protocolli supportati dall'istanza in Gestione configurazione SQL Server anziché codificare gli elementi nella stringa di connessione (ciò semplifica le modifiche o la risoluzione dei problemi).

In sostanza, il routing e altri costi generali associati alle pipe denominate (a meno che le app non si trovino sullo stesso computer di SQL Server, nel qual caso vi è solo un piccolo sovraccarico aggiuntivo) lo rendono l'opzione meno efficiente, soprattutto su scala, in un ambiente di rete più lento (100 MB o meno) o se i carichi di lavoro arrivano a raffica.

Se le tue app si trovano nella stessa casella di SQL Server, dovresti anche tenere presente la memoria condivisa: se hai applicazioni nella casella di SQL Server che comunicano direttamente con SQL Server, questa sarà l'opzione più efficiente.

Puoi leggere i vantaggi prestazionali di TCP / IP in modo più dettagliato .

— Aaron Bertrand
fonte

Quindi, in pratica, non importa molto, ma è generalmente preferibile utilizzare TCP perché non ci sono motivi per scegliere named pipe. Sei d'accordo con quel riassunto?

— usr

@usr Bene, è importante quando si ridimensiona o se la rete fa schifo. Ma sì, in generale, non ci sono reali vantaggi nella scelta delle pipe nominate, che io conosca.

— Aaron Bertrand

I protocolli Named Pipes sono utili per l'applicazione progettata attorno a NetBIOS o altri protocolli basati su LAN.

Named Pipes fornisce un facile accesso alle Remote Procedure Calls (RPC) all'interno di un singolo dominio di sicurezza ed è quindi vantaggioso per queste applicazioni.

Di solito il protocollo TCP è buono in pratica perché non devi preoccuparti di tutto ciò sulla rete.

— JP Chauhan
fonte