Descrizione delle impostazioni TCP/IP potrebbe essere necessario regolare quando il pool di connessioni SQL Server Ŕ disattivato

Traduzione articoli Traduzione articoli
Identificativo articolo: 328476 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

Quando si utilizza il driver ODBC di SQL Server, il provider OLE DB o il provider gestito System.Data.SqlClient, Ŕ possibile disattivare utilizzando le rispettive application programming interface (API) del pool di connessioni. Quando si disattiva il pool, l'utilizzo della libreria di rete di SQL Server sottostante pu˛ essere incrementata se l'applicazione apre e chiude le connessioni. In questo articolo vengono descritte alcune impostazioni di TCP/IP che potrebbe essere necessario regolare tali condizioni.

Informazioni

Disattivazione di pool pu˛ causare il driver di rete di SQL Server sottostante aprire rapidamente e di chiudere le connessioni socket di nuovo al computer che esegue SQL Server. Potrebbe essere necessario modificare impostazioni di socket di TCP/IP predefinite per il sistema operativo e il computer che esegue SQL Server per gestire i livelli di stress superiori.

Si noti che questo articolo viene descritto solo impostazioni che influenzano la libreria di rete di SQL Server quando si utilizza il protocollo TCP/IP. Disattivazione di pool anche possibile la causa di problemi di stress di altri protocolli di SQL Server ad esempio named pipe, ma in questo articolo non viene trattata in questo argomento. Questo articolo Ŕ solo per utenti esperti. Se non si comprende gli argomenti in questo articolo, si consiglia di che Ŕ possibile visualizzare un buon libro su socket TCP/IP.

Si noti che Microsoft consiglia vivamente di utilizzare sempre il pool con i driver di SQL Server. L'utilizzo di pool notevolmente consente di migliorare le prestazioni generali sul lato client e sul lato server SQL quando si utilizza il driver di SQL Server. L'utilizzo di pool anche notevolmente riduce il traffico di rete al computer che esegue SQL Server. Ad esempio, un test di esempio utilizzato 20.000 SQL Server connessione apre e chiude con attivato il pool utilizzato circa 160 pacchetti di rete TCP/IP, per un totale di byte 23.520 dell'attivitÓ di rete. Con pool disattivato, lo stesso test esempio generato 225,129 pacchetti di rete TCP/IP, per un totale di byte 27,209,622 dell'attivitÓ di rete.

Si noti che la presenza di questi problemi socket TCP/IP relativi stress con le librerie di rete SQL Server, Ŕ possibile che venga visualizzato uno o pi¨ dei seguenti messaggi di errore quando si tenta di connettersi a un computer che esegue SQL Server:
Server SQL inesistente o accesso negato
Timeout scaduto
Errore generale di rete
Provider TCP: Un solo utilizzo di ogni indirizzo di socket (protocollo/indirizzo di rete/porta) norma Ŕ consentito.
Nota Ŕ inoltre possibile ricevere questi messaggi di errore specifico quando si verificano altri problemi con SQL Server, ad esempio, Ŕ potrebbe essere visualizzato questi messaggi di errore se il computer remoto che esegue SQL Server viene arrestato, se il computer remoto che esegue SQL Server non in ascolto per socket TCP/IP, caso connettivitÓ di rete al computer che esegue SQL Server interrotto perchÚ il cavo di rete Ŕ estratta, oppure se si verificano problemi di risoluzione DNS. In sostanza elementi che possono causare il client non Ŕ possibile aprire un socket TCP/IP al computer che esegue SQL Server pu˛ inoltre causare i messaggi di errore. Tuttavia, si con un problema di stress relativi socket, il problema verifica a intermittenza di stress raggiunge e se. Il computer pu˛ eseguire per le ore senza errori, quindi l'errore si verifica una o due volte e il computer, quindi viene eseguito per diverse altre ore senza errori. Inoltre, dopo avere questo problema, connettivitÓ generale a SQL Server funziona una immediata, ha esito negativo alla successiva, quindi funziona nuovamente l'immediata successivo. In altre parole, socket stress relativi problemi si verificano in genere occasionalmente, ma reali problemi di connettivitÓ di rete con SQL Server in genere non si verificano occasionalmente.

Due problemi principali relativi a stress si verificano solitamente quando si disattiva il pool mentre si utilizza il protocollo TCP/IP di SQL Server: si pu˛ eseguire uscita delle porte anonime sul computer client o pu˛ l'impostazione di WinsockListenBacklog predefinita nei computer in cui Ŕ in esecuzione SQL Server.

Per ulteriori informazioni sulle porte anonime, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
319502PRB: Messaggio di errore 'WSAEADDRESSINUSE' durante per connettersi tramite una porta anonima dopo si aumenta il limite di connessione IMAP

Regolare le impostazioni di MaxUserPort e TcpTimedWaitDelay

Si noti che le impostazioni di MaxUserPort e TcpTimedWaitDelay applicabile solo per un computer client che viene rapidamente di apertura e chiusura connessioni a un computer remoto che esegue SQL Server e che non utilizza il pool di connessioni. Ad esempio, queste impostazioni sono applicabili su un server Internet Information Services (IIS) che Ŕ in esecuzione per un numero elevato di richieste HTTP in ingresso e che Ŕ apertura e chiusura delle connessioni a un computer remoto che esegue SQL Server e che utilizza il protocollo TCP/IP con pool disattivato. Se il pool Ŕ attivato, non Ŕ necessario regolare le impostazioni di MaxUserPort e TcpTimedWaitDelay .

Quando si utilizza il protocollo TCP/IP per aprire una connessione a un computer che esegue SQL Server, nella libreria di rete di SQL Server sottostante viene aperto un socket TCP/IP al computer che esegue SQL Server. Quando apre questo socket, Ŕ possibile che la libreria di rete di SQL Server non Ŕ abilitato l'opzione di socket TCP/IP SO_REUSEADDR . Per ulteriori informazioni sull'impostazione SO_REUSEADDR socket, vedere l'argomento di "Setsockopt" in Microsoft Developer Network (MSDN).

Si noti che la libreria di rete di SQL Server in modo specifico non attiva l'opzione di socket TCP/IP SO_REUSEADDR per motivi di protezione. Quando si SO_REUSEADDR Ŕ attivata, Ŕ possibile che un utente malintenzionato interno di una porta del client a SQL Server e utilizzare le credenziali che il client fornisce per accedere al computer in cui Ŕ in esecuzione SQL Server. Per impostazione predefinita, poichÚ la libreria di rete di SQL Server non viene attivata l'opzione socket SO_REUSEADDR , ogni volta che si apre e chiude un socket tramite la libreria di rete di SQL Server sul lato client, il socket entra nello stato TIME_WAIT per quattro minuti. Se si Ŕ rapidamente apertura e chiusura connessioni SQL Server su TCP/IP con pool disattivato, rapidamente apertura e chiusura del socket TCP/IP. In altre parole, ogni connessione di SQL Server dispone di un socket TCP/IP. Se si apre e si chiudono 4000 socket in meno di quattro minuti, raggiungeranno l'impostazione di massima predefinita per client anonimi porte e nuovi tentativi di connessione di socket hanno esito negativo fino a quando l'insieme esistente di socket TIME_WAIT timeout.

Sul lato client, potrebbe essere necessario aumentare le impostazioni MaxUserPort e TcpTimedWaitDelay descritti in Q319502 dopo avere disattivato il pool. Le impostazioni di questi valori sono determinate da quanti connessione di SQL Server apre e chiude vengono effettuate sul lato client. ╚ possibile esaminare quante porte client sono in uno stato TIME_WAIT tramite lo strumento NETSTAT il computer client. Eseguire lo strumento NETSTAT con il flag - n , come illustrato di seguito e contare il numero di socket client al proprio indirizzo IP di SQL Server, che sono nello stato TIME_WAIT. In questo esempio, l'indirizzo IP del computer remoto che esegue SQL Server Ŕ 10.10.10.20, l'indirizzo IP del computer client Ŕ 10.10.10.10 e tre connessioni stabilite e due connessioni sono nello stato TIME_WAIT:
C:\>netstat -n

Active Connections

  Proto  Local Address         Foreign Address       State
  TCP    10.10.10.10:2000      10.10.10.20:1433      ESTABLISHED
  TCP    10.10.10.10:2001      10.10.10.20:1433      ESTABLISHED
  TCP    10.10.10.10:2002      10.10.10.20:1433      ESTABLISHED
  TCP    10.10.10.10:2003      10.10.10.20:1433      TIME_WAIT
  TCP    10.10.10.10:2004      10.10.10.20:1433      TIME_WAIT
				
se si esegue netstat n e si noterÓ che vicino a 4000 le connessioni all'indirizzo IP indirizzo del computer destinazione che esegue SQL Server sono in uno stato TIME_WAIT, Ŕ possibile sia aumentare l'impostazione di MaxUserPort predefinito e ridurre l'impostazione TcpTimedWaitDelay non si esegue di client anonimi porte. Ad esempio, Ŕ possibile impostare su 20000 l'impostazione di MaxUserPort e impostare il TcpTimedWaitDelay a 30. Un'impostazione TcpTimedWaitDelay inferiore indica che il socket attende nello stato TIME_WAIT per meno tempo. Un'impostazione di MaxUserPort superiore indica che utilizzare ulteriori socket nello stato TIME_WAIT.

Si noti che se si modifica l'impostazione di MaxUserPort o TcpTimedWaitDelay , Ŕ necessario riavviare Microsoft Windows per le nuove impostazioni abbiano effetto. Le impostazioni di MaxUserPort e TcpTimedWaitDelay sono per i computer client Ŕ comunicare con un computer che esegue SQL Server tramite socket TCP/IP. Queste impostazioni non sono necessario alcun effetto, se impostati sul computer che esegue SQL Server a meno che non si effettuano connessioni di socket TCP/IP locale al computer locale che esegue SQL Server.

Nota Se si modifica l'impostazione di MaxUserPort , si consiglia che Ŕ possibile prenotare la porta 1434 per l'utilizzo dal servizio SQL Server Browser (sqlbrowser.exe). Per ulteriori informazioni su come effettuare questa operazione, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato:
812873Come riservare un intervallo di porte effimere in un computer che esegue Windows Server 2003 o Windows 2000 Server

Modificare l'impostazione WinsockListenBacklog

Per ulteriori informazioni su questa impostazione del Registro di sistema di specifiche di SQL Server, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
154628INF: Log di SQL 17832 con pi¨ richieste di connessione TCP\IP
Quando la libreria di rete di SQL Server Ŕ in ascolto socket TCP/IP, la libreria di rete di SQL Server utilizza ascolto API Winsock. Il secondo parametro per l' ascolto API Ŕ il backlog di cui Ŕ consentito per il socket. Il backlog rappresenta la lunghezza massima della coda di connessioni per il listener in sospeso. Quando la lunghezza della coda di supera questa lunghezza massima, la libreria di rete di SQL Server rifiuta immediatamente ulteriori tentativi di connessione socket TCP/IP. Inoltre, la libreria di rete di SQL Server invia un pacchetto ACK + RESET.

SQL Server 2000 utilizza un' predefinita ascolta l'impostazione di backlog di 5. Ci˛ significa che il computer che esegue SQL Server passa il valore 5 al parametro backlog ascolto API Winsock quando l' ascolto API consente di impostare i thread in attesa del protocollo TCP/IP sul computer che esegue SQL Server. ╚ possibile modificare la chiave di registro WinsockListenBacklog per specificare un valore diverso da passare per questo parametro. A partire da SQL Server 2005, la libreria di rete passa un valore di SOMAXCONN come l'impostazione di backlog per l' ascolto API. SOMAXCONN consente al provider di Winsock impostare un valore di ragionevole massimo per questa impostazione. Di conseguenza, la chiave del Registro di sistema di WinsockListenBacklog Ŕ non Ŕ pi¨ utilizzata o necessarie in SQL Server 2005.

Il backlog l'impostazione funziona nel modo seguente: si supponga che un servizio non autorizzato Ŕ in ascolto per le richieste di socket TCP/IP in ingresso. Se si imposta l'impostazione di backlog a 5 e continuamente flusso di richieste di connessione del socket in, il servizio potrebbe non essere in grado di rispondere alle richieste in ingresso ad alta veloce come provengono. A questo punto, il livello di socket TCP/IP code queste richieste in ingresso nella coda di backlog, e il servizio in un secondo momento possibile estrarre le richieste della coda e gestire la richiesta di connessione socket in arrivo. Dopo la coda Ŕ piena, il livello di socket TCP/IP Rifiuta immediatamente le richieste di ulteriori socket sono disponibili in inviando un pacchetto ACK + RESET nuovamente il client. Aumentare l'aumento di dimensione coda di backlog che il numero di connessione socket in attesa di richieste che il livello di socket TCP/IP code prima le richieste vengono rifiutate.

Si noti che l'impostazione WinsockListenBacklog Ŕ specifica di SQL Server. SQL Server tenta di leggere questa impostazione del Registro di sistema al primo avvio del servizio SQL Server. Se l'impostazione non esiste, viene utilizzato il valore predefinito di 5. Se l'impostazione del Registro di sistema esiste, SQL Server legge l'impostazione e utilizza il valore fornito come l'impostazione di backlog quando l'API WinSock di ascoltare viene chiamato come i thread di ascolto del socket TCP/IP sono impostati all'interno di SQL Server.

Per determinare se in esecuzione in questo problema, Ŕ possibile eseguire una traccia di Network Monitor sul client o il computer che esegue SQL Server e cercare le richieste di connessione del socket vengono immediatamente rifiutate con un ACK + RESET. Se si esaminano pacchetti TCP/IP in Network Monitor, presente un pacchetto, ad esempio quando si verifica questo problema:
Frame: Base frame properties
ETHERNET:  EType = Internet IP (IPv4) 
IP: Protocol = TCP - Transmission Control; Packet ID = 40530; Total IP Length = 40; Options = No Options
TCP: Control Bits: .A.R.., len:    0, seq:         0-0, ack:3409265780, win:    0, src: 1433  dst: 4364 
  TCP: Source Port = 0x0599	
  TCP: Destination Port = 0x110C
  TCP: Sequence Number = 0 (0x0)
  TCP: Acknowledgement Number = 3409265780 (0xCB354474)
  TCP: Data Offset = 20 bytes
  TCP: Flags = 0x14 : .A.R..
    TCP: ..0..... = No urgent data
    TCP: ...1.... = Acknowledgement field significant
    TCP: ....0... = No Push function
    TCP: .....1.. = Reset the connection
    TCP: ......0. = No Synchronize
    TCP: .......0 = Not the end of the data
  TCP: Window = 0 (0x0)
  TCP: Checksum = 0xF1E7
  TCP: Urgent Pointer = 0 (0x0)
				
nota che la porta di origine Ŕ 0x599 o 1433 in formato decimale. Ci˛ significa che il pacchetto proviene da un tipico computer che esegue SQL Server e che Ŕ in corso la porta predefinita 1433. Si noti inoltre che siano impostati nel campo riconoscimento significativo e i flag Reimposta la connessione . Se si ha familiaritÓ con il filtro di una traccia di Network Monitor, Ŕ possibile filtrare il valore di flag TCP da 0 x 14 esadecimale per visualizzare solo i pacchetti ACK + RESET nella traccia di Network Monitor.

Si noti che Ŕ possibile visualizzare i pacchetti ACK + RESET simili se il computer che esegue SQL Server non viene eseguito affatto o se il computer che esegue SQL Server non in ascolto per protocollo TCP/IP, pertanto la visualizzazione di pacchetti ACK + RESET non Ŕ definita conferma che si Ŕ verificato questo problema. Se il WinsockListenBacklog Ŕ troppo bassa, alcuni visualizzato tentativi di connessione accettare pacchetti e alcune connessioni visualizzato immediatamente i pacchetti ACK + RESET nel stesso intervallo di tempo.

Si noti che in casi molto rari, potrebbe essere necessario regolare questa impostazione, anche se il pool Ŕ attivata sui computer client. Ad esempio, anche in se parla molti computer client a un singolo computer che esegue SQL Server, un numero elevato di tentativi di connessione in ingresso simultanee pu˛ verificarsi in qualsiasi momento particolare anche se Ŕ attivato il pool.

Nota Se si modifica l'impostazione WinsockListenBacklog , non Ŕ necessario riavviare Windows per questa impostazione abbia effetto. ╚ sufficiente arrestare e riavviare il servizio SQL Server rendere effettiva l'impostazione. L'impostazione di registro di sistema di WinsockListenBacklog Ŕ solo per il computer che esegue SQL Server. Non Ŕ necessario alcun effetto su qualsiasi computer client che Ŕ comunicare con SQL Server.

ProprietÓ

Identificativo articolo: 328476 - Ultima modifica: giovedý 1 gennaio 2009 - Revisione: 11.0
Le informazioni in questo articolo si applicano a:
  • Driver Microsoft ODBC per Microsoft SQL Server 3.7
  • Microsoft OLE DB Provider for SQL Server
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft ADO.NET 1.0
  • Microsoft ADO.NET 1.1
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Chiavi:á
kbmt kbinfo KB328476 KbMtit
Traduzione automatica articoli
Il presente articolo Ŕ stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non Ŕ sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, pi¨ o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non Ŕ la sua. Microsoft non Ŕ responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 328476
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com