DetailPage-MSS-KB

Base de Dados de Conhecimento

Artigo: 328476 - Última revisão: domingo, 15 de Março de 2015 - Revisão: 12.0

 

Nesta página

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ção

Como 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 predefinições de socket de TCP/IP 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. Como 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 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 aos sockets de TCP/IP, se a conectividade de rede ao 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 também pode causar as mensagens de erro. No entanto, relativamente a 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, funciona novamente 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.

Problemas relacionados com a tensão de principais dois ocorrem normalmente quando desactivar o agrupamento 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:
319502  (http://support.microsoft.com/kb/319502/EN-US/ ) PRB: 'WSAEADDRESSINUSE' mensagem de erro quando tentar ligar através de uma porta anónima após aumentar o limite de ligações de IMAP

Ajuste as definições 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 é necessário 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 activa 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 pode apoderar-se uma porta de cliente para o SQL Server e utilizar as credenciais que o cliente fornece para aceder ao computador que esteja a executar o SQL Server. Por predefinição, porque 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 de servidor de SQL sobre TCP/IP com agrupamento desactivado, está 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 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é o conjunto de TIME_WAIT sockets existente expirar.

No lado do cliente, poderá ter de aumentar as definições de MaxUserPort e TcpTimedWaitDelay abordados são Q319502 quando tiver desactivado o agrupamento. As definições para estes valores são determinadas por quantos ligação do 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 estão 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 como 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 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 tem 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 com 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  (http://support.microsoft.com/kb/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  (http://support.microsoft.com/kb/154628/EN-US/ ) INF: Registos de SQL 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 tarefas pendentes 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 passados 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ários em SQL Server 2005.

O registo de segurança definição funciona do seguinte modo: 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 transmissão em sequência no, o serviço poderá não conseguir responder a pedidos tão rápidos quanto proveniência na. Neste momento, a camada de socket de TCP/IP filas estes pedidos recebidos na fila de registo de segurança e o serviço mais tarde possa solicitam os pedidos fora 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 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 reposição + ACK. Se examinar os pacotes de TCP/IP no Monitor de rede, verá um pacote tais como os seguintes quando ocorre este 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)
				
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 da predefinição do 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 é a confirmação definitiva que está a ter este problema. Se o WinsockListenBacklog for demasiado baixa, alguma ligação a receber de tentativas de aceitar pacotes 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.

NotaSe 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 do SQL Server para a definição entrem em vigor. 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.

A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2000 Standard Edition
  • 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 2005 Server Enterprise
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL 2005 Server Workgroup
Palavras-chave: 
kbsqlsetup kbinfo kbmt KB328476 KbMtpt
Tradução automáticaTradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática… erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 328476  (http://support.microsoft.com/kb/328476/en-us/ )
Partilhar
Opções de suporte adicionais
Fóruns de Suporte da Comunidade Microsoft
Contacte-nos directamente
Encontre um parceiro certificado Microsoft
Loja Microsoft