Sumário
Quando utiliza o controlador de ODBC para SQL Server, o servidor fornecedor SQL OLE DB ou o fornecedor gerido System.Data.SqlClient, pode desactivar o pooling de conexões utilizando as respectivas application programming interfaces (APIs). Quando desactivar o agrupamento, a tensão na biblioteca de rede subjacente do SQL Server pode ser aumentada se a aplicação frequentemente abre e fecha ligações. Este artigo descreve determinadas definições de TCP/IP que poderá ter de ajustar nestas condições.
Mais informações
Desactivar o agrupamento pode fazer com que o controlador de rede subjacente do SQL Server para rapidamente abrir e fechar ligações de socket novo ao computador que esteja a executar o SQL Server. Poderá ter de alterar as definições de socket de TCP/IP predefinida para o sistema operativo e o computador que esteja a executar o SQL Server para lidar com os mais elevados níveis de tensão.
Tenha em atenção que este artigo aborda apenas as definições que afectam a biblioteca de rede do SQL Server quando utiliza o protocolo TCP/IP. Desactivar o agrupamento também pode causar problemas relacionados com a tensão com outros protocolos de SQL Server como pipes nomeados, mas este artigo não aborda este tópico. Este artigo é apenas para utilizadores avançados. Se não compreender os tópicos neste artigo, a Microsoft recomenda que visualiza um livro boa sobre TCP/IP sockets.
Tenha em atenção que a Microsoft recomenda vivamente que utilize sempre o agrupamento com os controladores do SQL Server. Utilizar o agrupamento bastante melhora o desempenho global no lado do cliente e do lado do servidor de SQL quando utiliza os controladores do SQL Server. Utilizar o agrupamento também consideravelmente reduz o tráfego de rede ao computador que esteja a executar o SQL Server. Por exemplo, um teste de amostras utilizado 20.000 SQL Server, ligação abre e fecha com agrupamento activado utilizado 160 Pacotes de rede de TCP/IP, para um total de bytes 23,520 da actividade da rede. Com agrupamento desactivado, o mesmo teste de exemplo gerado 225,129 pacotes de rede de TCP/IP, para um total de bytes 27,209,622 da actividade da rede.
Tenha em atenção que quando vir estas questões de socket de TCP/IP relacionados com a tensão com as bibliotecas de rede do SQL Server, poderá receber uma ou mais das seguintes mensagens de erro quando tenta ligar a um computador que esteja a executar o SQL Server:
O SQL Server não existe ou o acesso negado
Tempo de espera expirou
Erro geral de rede
Fornecedor TCP: Normalmente é permitida a utilização apenas um de cada endereço de socket (protocolo/rede endereço/porta).
Tenha em atenção que também pode receber estas mensagens de erro específico quando ocorrem outros problemas com o SQL Server; Por exemplo, poderá receber estas mensagens de erro se o computador remoto que esteja a executar o SQL Server é encerrado, se o computador remoto que esteja a executar o SQL Server não está à escuta para TCP/IP sockets, se a conectividade de rede para o computador que esteja a executar o SQL Server é interrompida uma vez que o cabo de rede é solicitado, ou se estiver a ter problemas de resolução de DNS. Basicamente, tudo o que pode fazer com que o cliente não conseguir abrir um socket de TCP/IP para o computador que esteja a executar o SQL Server pode também causar as mensagens de erro. No entanto, com um problema relacionado com a tensão socket, o problema ocorrer intermitentemente a tensão aumenta e diminui. O computador pode executar para horas, sem erros, em seguida, o erro ocorre uma ou duas vezes e o computador, em seguida, executa a vários mais horas, sem erros. Além disso, quando tiver este problema, gerais de conectividade ao SQL Server funciona um instantâneo, falhar o seguinte, em seguida, novamente funciona o instantâneas seguinte. Por outras palavras, relacionados com a tensão socket problemas ocorrem normalmente o esporadicamente, mas real problemas de conectividade de rede com o SQL Server não ocorrem normalmente esporadicamente.
Dois problemas principais relacionados com a tensão ocorrem normalmente quando desactivar o agrupamento de enquanto utiliza o protocolo TCP/IP de servidor de SQL: pode ficar sem portas anónimas no computador cliente ou pode exceder a predefinição de WinsockListenBacklog no computador que esteja a executar o SQL Server.
Para obter informações adicionais sobre as portas anónimas, clique no número de artigo abaixo para visualizar o artigo na Microsoft Knowledge Base:
Problema de 319502 : 'WSAEADDRESSINUSE' mensagem de erro quando tentar ligar através de uma porta anónima após aumentar o limite de ligação de IMAP
Ajustar as definições de MaxUserPort e TcpTimedWaitDelay
Tenha em atenção que as definições de MaxUserPort e TcpTimedWaitDelay são aplicáveis apenas um computador cliente que é rapidamente abrir e fechar ligações a um computador remoto que esteja a executar o SQL Server e que não está utilizar agrupamento de ligações. Por exemplo, estas definições são aplicáveis num servidor de serviços de informação Internet (IIS) que serve um grande número de pedidos HTTP de entrada e de que abrir e fechar ligações a um computador remoto com o SQL Server e que está a utilizar o protocolo TCP/IP com agrupamento desactivado. Se o agrupamento está activado, não tem de ajustar as definições de MaxUserPort e TcpTimedWaitDelay .
Quando utiliza o protocolo TCP/IP para abrir uma ligação a um computador que esteja a executar o SQL Server, a biblioteca de rede subjacente do SQL Server abre um socket de TCP/IP para o computador que esteja a executar o SQL Server. Quando abre este socket, a biblioteca de rede do SQL Server não permite que a opção de socket de TCP/IP SO_REUSEADDR . Para mais informações sobre a definição de socket SO_REUSEADDR , consulte o tópico "Setsockopt" no Microsoft Developer Network (MSDN).
Note que a biblioteca de rede do SQL Server especificamente não activar a opção de socket de TCP/IP de SO_REUSEADDR por razões de segurança. Quando SO_REUSEADDR está activada, um utilizador mal intencionado poderá apoderar-se uma porta de cliente para o SQL Server e utilizar as credenciais que o cliente fornece acesso ao computador que esteja a executar o SQL Server. Por predefinição, uma vez que a biblioteca de rede do SQL Server não activa a opção de socket SO_REUSEADDR , sempre que abrir e fechar um socket através da biblioteca de rede de SQL Server do lado do cliente, o socket entra num estado TIME_WAIT durante 4 minutos. Se estiver rapidamente abrir e fechar ligações do SQL Server através de TCP/IP com agrupamento desactivado, são rapidamente abrir e fechar os sockets de TCP/IP. Por outras palavras, cada ligação de SQL Server tem um socket de TCP/IP. Se abrir e fechar os 4000 sockets em menos de quatro minutos rapidamente, irá chegar a predefinição máxima para as portas do cliente anónimo e novas tentativas de ligação de socket falharem até que o conjunto de TIME_WAIT sockets existente expirar.
No lado do cliente, poderá ter de aumentar as definições de MaxUserPort e TcpTimedWaitDelay descritas em Q319502 quando tiver desactivado o agrupamento. As definições para estes valores são determinadas pelo quantos ligação ao SQL Server abre e fecha ocorre no lado do cliente. Pode examinar as portas de cliente quantas estão num estado TIME_WAIT, utilizando a ferramenta Netstat no computador cliente. Execute a ferramenta Netstat com o sinalizador -n , do seguinte modo e contar o número de sockets de cliente para o seu endereço de IP do servidor de SQL que se encontram num estado TIME_WAIT. Neste exemplo, o endereço IP do computador remoto que esteja a executar o SQL Server é 10.10.10.20, o endereço IP do computador cliente é 10.10.10.10 e três estabelecidas ligações e duas ligações estão num estado 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 executar o netstat - n e verá que próximo 4000 ligações para o período de inquérito endereço do computador de destino com o SQL Server estão num estado TIME_WAIT, pode tanto aumentam a MaxUserPort predefinida e reduzir a definição de TcpTimedWaitDelay de forma a não ficar sem portas anónimo do cliente. Por exemplo, pode repor a definição de MaxUserPort 20000 e configure a definição de TcpTimedWaitDelay 30. Uma definição de TcpTimedWaitDelay inferior significa que os sockets de esperar no estado TIME_WAIT menos tempo. Uma definição mais elevada de MaxUserPort significa que pode ter mais de sockets no estado TIME_WAIT.
Note que se ajustar a definição de MaxUserPort ou TcpTimedWaitDelay , deve reiniciar o Microsoft Windows para a nova definição tenha efeito. As definições de MaxUserPort e TcpTimedWaitDelay destinam-se a qualquer computador cliente que está a falar para um computador que esteja a executar o SQL Server através de TCP/IP sockets. Estas definições não têm qualquer efeito se estiverem definidas no computador que esteja a executar o SQL Server, a menos que estiver a efectuar ligações de socket de TCP/IP locais no computador local que esteja a executar o SQL Server.
Nota Se ajustar a definição de MaxUserPort , recomendamos que reservam a porta 1434 para utilização pelo serviço de Browser de servidor SQL (sqlbrowser.exe). Para mais informações sobre como efectuar este procedimento, clique no número de artigo seguinte para visualizar o artigo na Microsoft Knowledge Base:
812873 como reservar um intervalo de portas efémeras num computador que esteja a executar o Windows Server 2003 ou Windows 2000 Server
Ajuste a definição de WinsockListenBacklog
Para obter informações adicionais sobre esta definição de registo específicas do SQL Server, clique no número de artigo abaixo para visualizar o artigo na Microsoft Knowledge Base:
154628 INF: SQL inicia 17832 com vários pedidos de ligação TCP\IP.
Quando a biblioteca de rede do SQL Server escuta em sockets de TCP/IP, a biblioteca de rede do SQL Server utiliza a escutar Winsock API. O segundo parâmetro para o ouvir API é o registo de segurança que é permitido para o socket. Este registo de segurança representa o comprimento máximo da fila de ligações para a escuta pendentes. Quando o comprimento da fila excede este comprimento máximo, a biblioteca de rede do SQL Server rejeita imediatamente mais tentativas de ligação de socket de TCP/IP. Além disso, a biblioteca de rede do SQL Server envia um pacote de confirmação + reposição.
Definição de registo de tarefas pendentes de 5 de escuta de SQL Server 2000 utiliza uma predefinição. Isto significa que o computador que esteja a executar o SQL Server transmite o valor 5 para o parâmetro de registo de segurança da escutar Winsock API, quando a API de ouvir configura os threads de escuta do protocolo TCP/IP no computador que esteja a executar o SQL Server. Pode ajustar a chave de registo WinsockListenBacklog para especificar um valor diferente para ser transmitido para este parâmetro. Iniciar no SQL Server 2005, a biblioteca de rede passa um valor de SOMAXCONN como a definição de registo de segurança para o ouvir API. SOMAXCONN permite ao fornecedor de Winsock definir um valor razoável máximo para esta definição. Por conseguinte, a chave de registo WinsockListenBacklog já não é utilizada ou necessária no SQL Server 2005.
O registo de segurança definição funciona da seguinte forma: Suponhamos que um serviço arbitrário está à escuta para pedidos de socket de TCP/IP. Se definir a definição de registo de tarefas pendentes para 5 e muitos pedidos de ligação de socket são continuamente de transmissão em sequência no, o serviço poderá não conseguir responder a pedidos tão rápidos quanto são. Neste momento, a camada de socket de TCP/IP filas estes pedidos na fila de registo de segurança e o serviço mais tarde poderá obter os pedidos desta fila e processar o pedido de ligação de socket recebido. Depois da fila é preenchida, a camada de socket de TCP/IP rejeita imediatamente quaisquer pedidos de socket adicionais que entram em enviando um pacote de confirmação + reposição para o cliente. Aumentar o aumento do tamanho de registo de tarefas pendentes de fila que o número de enquanto se aguarda a ligação de socket de pedidos que a camada de socket de TCP/IP filas antes dos pedidos são rejeitados.
Tenha em atenção que a definição de WinsockListenBacklog é específica para o SQL Server. SQL Server tenta ler esta definição de registo quando inicia pela primeira vez o serviço SQL Server. Se a definição de não existir, é utilizada a predefinição de 5. Se a definição de registo existir, o SQL Server lê a definição e utiliza o valor fornecido como a definição de registo de segurança quando a API do WinSock escutar denomina-se como os threads em escuta do socket de TCP/IP estão definidos cima dentro do SQL Server.
Para determinar se está a executar este problema, pode executar um rastreio do Monitor de rede no cliente ou o computador que esteja a executar o SQL Server e procure a pedidos de ligação de socket que são imediatamente rejeitados com uma confirmação + reposição. Se examinar os pacotes de TCP/IP no Monitor de rede, consulte um pacote seguintes quando ocorre este problema:
Frame: Base frame propertiesETHERNET: 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)
Note que a porta de origem é 0x599 ou 1433 em decimal. Isto significa que o pacote provém de um típico computador que esteja a executar o SQL Server e que está em execução na porta predefinida de 1433. Tenha também em atenção que o campo de confirmação significativo e os sinalizadores de reinicializar a ligação estão definidos. Se estiver familiarizado com a filtragem de rastreio do Network Monitor, pode filtrar o valor de sinalizadores de TCP por 0x14 hexadecimal para ver apenas os pacotes de confirmação + REPOR o rastreio do Monitor de rede.
Tenha em atenção que também pode consultar semelhantes ACK + reposição pacotes se o computador que esteja a executar o SQL Server não está a executar em todos os ou se o computador que esteja a executar o SQL Server não está à escuta protocolo TCP/IP, para que ver os pacotes de confirmação + reposição não é definitiva confirmação de que está a ter este problema. Se o WinsockListenBacklog for demasiado baixa, alguma ligação tentativas recebem pacotes de aceitação e algumas ligações imediatamente recebem pacotes de confirmação + REPOR o mesmo período de tempo.
Note que em casos raros, poderá ter de ajustar esta definição, mesmo que o agrupamento está activado nos computadores cliente. Por exemplo, se muitos computadores clientes estiverem a falar para um único computador que esteja a executar o SQL Server, um grande número de tentativas de ligação de entrada simultâneos pode ocorrer em qualquer altura determinada, mesmo que o agrupamento está activado.
Nota Se ajustar a definição de WinsockListenBacklog , não é necessário reiniciar o Windows para esta definição tenha efeito. Basta parar e reiniciar o serviço SQL Server para a definição tenha efeito. A definição do registo WinsockListenBacklog é apenas para o computador que esteja a executar o SQL Server. Não tem qualquer efeito sobre qualquer computador cliente que está a falar para o SQL Server.
