KB328476 - Descrição das definições de TCP/IP que poderá ter de ajustar quando SQL Server conjunto de ligações está desativado

Resumo

Quando utiliza o controlador ODBC SQL Server, o SQL Server fornecedor OLE DB ou o fornecedor gerido System.Data.SqlClient, pode desativar o conjunto de ligações através das respetivas interfaces de programação de aplicações (APIs). Ao desativar o agrupamento, o esforço na biblioteca de rede SQL Server subjacente poderá aumentar se a sua aplicação abrir e fechar ligações com frequência. Este artigo descreve determinadas definições de TCP/IP que poderá ter de ajustar nestas condições.

Mais Informações

Desativar o agrupamento pode fazer com que o controlador de rede subjacente SQL Server abra e feche rapidamente novas ligações de socket ao computador que está a executar SQL Server. Poderá ter de alterar as predefinições do socket TCP/IP para o sistema operativo e o computador que está a executar SQL Server para lidar com os níveis de stress mais elevados.

Tenha em atenção que este artigo aborda apenas as definições que afetam o SQL Server biblioteca de rede quando utiliza o protocolo TCP/IP. Desativar o agrupamento também pode causar problemas relacionados com o stress com outros protocolos SQL Server, como pipes nomeados, mas este artigo não aborda este tópico. Este artigo destina-se apenas a utilizadores avançados. Se não compreender os tópicos neste artigo, a Microsoft recomenda que veja um bom livro sobre sockets TCP/IP.

Tenha em atenção que a Microsoft recomenda vivamente que utilize sempre o agrupamento com os controladores SQL Server. A utilização do agrupamento melhora consideravelmente o desempenho geral do lado do cliente e SQL Server lado quando utiliza os controladores de SQL Server. A utilização do agrupamento também reduz consideravelmente o tráfego de rede para o computador que está a executar SQL Server. Por exemplo, um teste de exemplo que utilizou 20 000 SQL Server ligação é aberto e fecha com o agrupamento ativado utilizado cerca de 160 pacotes de rede TCP/IP, num total de 23.520 bytes de atividade de rede. Com o agrupamento desativado, o mesmo teste de exemplo gerou 225.129 pacotes de rede TCP/IP, num total de 27.209.622 bytes de atividade de rede.

Tenha em atenção que, quando vir estes problemas de socket TCP/IP relacionados com o stress com as bibliotecas de rede SQL Server, poderá receber uma ou mais das seguintes mensagens de erro quando tentar ligar a um computador com SQL Server:

Tenha em atenção que também pode receber estas mensagens de erro específicas quando estão a ocorrer outros problemas com SQL Server; por exemplo, poderá receber estas mensagens de erro se o computador remoto que está a executar SQL Server estiver encerrado, se o computador remoto que está a executar SQL Server não estiver a escutar os sockets TCP/IP, se a conectividade de rede ao computador que está em execução SQL Server está avariado porque o cabo de rede é retirado ou se estiver a ter problemas de resolução de DNS. Basicamente, tudo o que possa fazer com que o cliente não abra um socket TCP/IP no computador que está a executar SQL Server também pode causar as mensagens de erro. No entanto, com um problema de socket relacionado com o stress, o problema ocorre intermitentemente à medida que o stress aumenta e cai. O computador pode ser executado durante horas sem erros, o erro ocorre uma ou duas vezes e, em seguida, o computador é executado durante várias horas sem erros. Além disso, quando tiver este problema, a conectividade geral ao SQL Server funciona num instante, falha no seguinte e, em seguida, funciona novamente no instante seguinte. Por outras palavras, os problemas de socket relacionados com o stress ocorrem normalmente esporadicamente, mas os problemas reais de conectividade de rede com SQL Server normalmente não ocorrem esporadicamente.

Normalmente, ocorrem dois problemas principais relacionados com o stress quando desativa o agrupamento enquanto utiliza o protocolo TCP/IP SQL Server: pode ficar sem portas anónimas no computador cliente ou pode exceder a predefinição WinsockListenBacklog no computador que está a executar SQL Server.

Para obter informações adicionais sobre portas anónimas, clique no número do artigo abaixo para ver o artigo na Base de Dados de Conhecimento Microsoft:

319502 PRB: Mensagem de Erro "WSAEADDRESSINUSE" quando tenta ligar através de uma porta anónima depois de aumentar o limite de ligação IMAP

Ajustar as definições MaxUserPort e TcpTimedWaitDelay

Tenha em atenção que as definições MaxUserPort e TcpTimedWaitDelay são aplicáveis apenas a um computador cliente que esteja a abrir e fechar rapidamente ligações a um computador remoto que esteja a executar SQL Server e que não esteja a utilizar o conjunto de ligações. Por exemplo, estas definições são aplicáveis num servidor dos Serviços de Informação Internet (IIS) que está a servir um grande número de pedidos HTTP recebidos e que está a abrir e fechar ligações a um computador remoto que está a executar SQL Server e que está a utilizar o protocolo TCP/IP com o agrupamento desativado. Se o agrupamento estiver ativado, não tem de ajustar as definições MaxUserPort e TcpTimedWaitDelay.

Quando utiliza o protocolo TCP/IP para abrir uma ligação a um computador com SQL Server, a biblioteca de rede de SQL Server subjacente abre um socket TCP/IP para o computador que está a executar SQL Server. Quando abre este socket, a biblioteca de rede SQL Server não ativa a opção de socket TCP/IP SO_REUSEADDR. Para obter mais informações sobre a definição de socket SO_REUSEADDR, consulte o tópico "Setsockopt" na Microsoft Developer Network (MSDN).

Tenha em atenção que o SQL Server biblioteca de rede especificamente não ativa a opção de socket TCP/IP SO_REUSEADDR por motivos de segurança. Quando SO_REUSEADDR está ativada, um utilizador malicioso pode sequestrar uma porta de cliente para SQL Server e utilizar as credenciais fornecidas pelo cliente para obter acesso ao computador que está a executar SQL Server. Por predefinição, uma vez que a biblioteca de rede SQL Server não ativa a opção de socket SO_REUSEADDR, sempre que abrir e fechar um socket através da biblioteca de rede SQL Server do lado do cliente, o socket entra num estado de TIME_WAIT durante quatro minutos. Se estiver a abrir e fechar rapidamente SQL Server ligações através de TCP/IP com o agrupamento desativado, está a abrir e fechar rapidamente sockets TCP/IP. Por outras palavras, cada SQL Server ligação tem um socket TCP/IP. Se abrir e fechar rapidamente 4000 sockets em menos de quatro minutos, atingirá a predefinição máxima para as portas anónimas do cliente e as novas tentativas de ligação de socket falham até que o conjunto existente de sockets de TIME_WAIT exceda o tempo limite.

Do lado do cliente, poderá ter de aumentar as definições MaxUserPort e TcpTimedWaitDelay que são abordadas no Q319502 quando tiver o agrupamento desativado. As definições para estes valores são determinadas pelo número de SQL Server ligação aberta e os fechos ocorrem no lado do cliente. Pode examinar quantas portas de cliente estão num estado TIME_WAIT com a ferramenta Netstat no computador cliente. Execute a ferramenta Netstat com o sinalizador -n da seguinte forma e conte o número de sockets de cliente para o seu endereço IP SQL Server que estão num estado TIME_WAIT. Neste exemplo, o endereço IP do computador remoto que está a executar SQL Server é 10.10.10.20, o endereço IP do computador cliente é 10.10.10.10 e três ligações estabelecidas 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 netstat -n e vir que cerca de 4000 ligações ao endereço IP do computador de destino que está a executar SQL Server estão num estado TIME_WAIT, ambos podem aumentar a predefinição MaxUserPort e reduzir a definição TcpTimedWaitDelay para que não fique sem portas anónimas do cliente. Por exemplo, pode definir a definição MaxUserPort como 20000 e definir a definição TcpTimedWaitDelay como 30. Uma definição TcpTimedWaitDelay inferior significa que os sockets aguardam no estado TIME_WAIT por menos tempo. Uma definição MaxUserPort mais alta significa que pode ter mais sockets no estado TIME_WAIT.

Tenha em atenção que, se ajustar a definição MaxUserPort ou TcpTimedWaitDelay, tem de reiniciar o Microsoft Windows para que a nova definição entre em vigor. As definições MaxUserPort e TcpTimedWaitDelay destinam-se a qualquer computador cliente que esteja a falar com um computador que esteja a executar SQL Server através de sockets TCP/IP. Estas definições não têm qualquer efeito se estiverem definidas no computador que está a executar SQL Server, a menos que esteja a efetuar ligações de socket TCP/IP locais ao computador local que está a executar SQL Server.

Nota Se ajustar a definição MaxUserPort, recomendamos que reserve a porta 1434 para utilização pelo serviço SQL Server Browser (sqlbrowser.exe). Para obter mais informações sobre como fazê-lo, clique no seguinte número de artigo para ver o artigo na Base de Dados de Conhecimento Microsoft:

812873 Como reservar um intervalo de portas efémeras num computador com o Windows Server 2003 ou o Windows 2000 Server

Ajustar a definição WinsockListenBacklog

Para obter informações adicionais sobre esta definição de registo SQL Server específica, clique no número do artigo abaixo para ver o artigo na Base de Dados de Conhecimento Microsoft:

154628 INF: Registos SQL 17832 com Vários Pedidos de Ligação TCP\IP
Quando a biblioteca de rede SQL Server escuta em sockets TCP/IP, a biblioteca de rede SQL Server utiliza a API Winsock de escuta. O segundo parâmetro para a API de escuta é o atraso permitido para o socket. Este atraso representa o comprimento máximo da fila de ligações pendentes para o serviço de escuta. Quando o comprimento da fila exceder este comprimento máximo, o SQL Server biblioteca de rede rejeita imediatamente mais tentativas de ligação de socket TCP/IP. Além disso, a biblioteca de rede SQL Server envia um pacote ACK+RESET.

SQL Server 2000 utiliza uma predefinição de 5. Isto significa que o computador que está a executar SQL Server transmite o valor 5 ao parâmetro de registo de tarefas pendentes da API Winsock de escuta quando a API de escuta configura os threads de escuta do protocolo TCP/IP no computador que está a executar SQL Server. Pode ajustar a chave de registo WinsockListenBacklog para especificar um valor diferente a ser transmitido para este parâmetro. A partir de SQL Server 2005, a biblioteca de rede transmite um valor soMAXCONN como a definição de registo de tarefas pendentes para a API de escuta. SOMAXCONN permite que o fornecedor Winsock defina um valor máximo razoável para esta definição. Por conseguinte, a chave de registo WinsockListenBacklog já não é utilizada ou necessária no SQL Server 2005.

A definição de registo de tarefas pendentes funciona da seguinte forma: suponha que um serviço arbitrário está a escutar pedidos de socket TCP/IP recebidos. Se definir a definição do registo de tarefas pendentes para 5 e muitos pedidos de ligação de socket estiverem continuamente em fluxo, o serviço poderá não conseguir responder aos pedidos recebidos tão rapidamente quanto entram. Neste momento, a camada do socket TCP/IP coloca em fila estes pedidos recebidos na fila de registo de tarefas pendentes e o serviço pode, posteriormente, retirar os pedidos desta fila e processar o pedido de ligação do socket de entrada. Após o preenchimento da fila, a camada do socket TCP/IP rejeita imediatamente quaisquer pedidos de socket adicionais recebidos através do envio de um pacote ACK+RESET de volta para o cliente. Aumentar o tamanho da fila de registo de tarefas pendentes aumenta o número de pedidos de ligação de socket pendentes que a camada de socket TCP/IP coloca em fila antes de os pedidos serem rejeitados.

Tenha em atenção que a definição WinsockListenBacklog é específica para SQL Server. SQL Server tenta ler esta definição de registo quando o serviço SQL Server é iniciado pela primeira vez. Se a definição não existir, é utilizada a predefinição 5. Se a definição de registo existir, SQL Server lê a definição e utiliza o valor fornecido como a definição de registo de tarefas pendentes quando a escuta da API WinSock é chamada como os threads de escuta do socket TCP/IP são configurados dentro SQL Server.

Para determinar se está a deparar-se com este problema, pode executar um rastreio do Monitor de Rede no cliente ou no computador que está a executar SQL Server e procurar pedidos de ligação do socket que são imediatamente rejeitados com uma ACK+RESET. Se examinar pacotes TCP/IP no Monitor de Rede, verá um pacote como o seguinte quando este problema está a ocorrer:

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)

Tenha em atenção que a porta de origem é 0x599 ou 1433 em decimal. Isto significa que o pacote provém de um computador típico que está a executar SQL Server e que está em execução na porta predefinida 1433. Tenha também em atenção que o campo Reconhecimento é significativo e os sinalizadores Repor a ligação estão definidos. Se estiver familiarizado com a filtragem de um rastreio do Monitor de Rede, pode filtrar o valor dos Sinalizadores TCP 0x14 hexadecimal para ver apenas os pacotes ACK+RESET no rastreio do Monitor de Rede.

Tenha em atenção que também pode ver pacotes ACK+RESET semelhantes se o computador que está a executar SQL Server não estiver em execução ou se o computador que está a executar SQL Server não estiver a ouvir o protocolo TCP/IP, pelo que ver pacotes ACK+RESET não é uma confirmação definitiva de que está a ter este problema. Se o WinsockListenBacklog for demasiado baixo, algumas tentativas de ligação recebem pacotes de aceitação e algumas ligações recebem imediatamente pacotes ACK+RESET no mesmo período de tempo.

Tenha em atenção que, em casos muito raros, poderá ter de ajustar esta definição mesmo que o agrupamento esteja ativado nos computadores cliente. Por exemplo, se muitos computadores cliente estiverem a falar com um único computador que está a executar SQL Server, poderá ocorrer um grande número de tentativas de ligação de entrada simultâneas em qualquer altura, mesmo que o agrupamento esteja ativado.

Nota Se ajustar a definição WinsockListenBacklog, não tem de reiniciar o Windows para que esta definição entre em vigor. Basta parar e reiniciar o serviço SQL Server para que a definição entre em vigor. A definição do registo WinsockListenBacklog destina-se apenas ao computador que está a executar SQL Server. Não tem qualquer efeito em nenhum computador cliente que esteja a falar com SQL Server.